10.4 Managing MFA with Conditional Access

Quick Answer: The Microsoft-recommended way to enforce MFA is a Conditional Access policy that includes all users (with break-glass exclusions), all cloud apps, and grants access with Require MFA. This replaces per-user MFA toggles, Security Defaults, and the legacy per-user MFA server. The Authentication Methods Policy governs which methods are available; number matching in Microsoft Authenticator defeats MFA-fatigue attacks; and you monitor MFA via the sign-in logs (which CA policy triggered the challenge) and the Authentication Methods usage report.

Why Conditional Access Is the Recommended Path

Microsoft's documented guidance is to enforce MFA through Conditional Access, not through any of the alternatives:

Conditional Access gives you scoping (who), conditions (when), controls (what), and report-only (impact before enforcing) — none of which the per-user toggle or Security Defaults provide.

The Standard 'Require MFA for All Users' Policy

The canonical MFA policy looks like this:

• Users — Include All users; exclude at least two break-glass / emergency access accounts
• Cloud apps or actions — Include All cloud apps
• Conditions — None required (you can add location or device-platform conditions to refine)
• Grant — Grant access, Require MFA
• Enable policy — Report-only first, then On

Layered on top of this baseline you typically add:

• Require MFA for admins — scoped to directory roles, often with a stricter control set
• Block legacy authentication — so legacy protocols cannot bypass MFA
• Require MFA for Azure management — scoped to the Azure Management app (Microsoft Azure Management), so Entra/ARM access is protected even if the all-apps policy is narrower

Migrating Off Per-User MFA and Security Defaults

If a tenant already enforces MFA another way, the migration to CA-based MFA follows a defined sequence:

1. Audit current state. Use the per-user MFA report and the Authentication Methods usage report to see who is enforced and which methods users have registered.
2. Create the CA policy in Report-only. Build the 'Require MFA for all users' policy above and run it in report-only to confirm coverage matches the existing enforcement.
3. Turn off per-user MFA. Disable the legacy per-user MFA enforcement for the users in scope. (Per-user MFA overrides CA, so leaving it on prevents CA from taking effect.)
4. Turn off Security Defaults. If Security Defaults is on, disable it — you cannot enable CA policies while it is on.
5. Enable the CA policy. Flip the policy from Report-only to On.
6. Monitor. Watch the sign-in logs for unexpected MFA prompts or failures, especially for service accounts and legacy protocols.

The order matters: per-user MFA overrides Conditional Access, so it must be off for CA to take effect; Security Defaults blocks CA creation, so it must be off before you enable the CA policy.

Authentication Methods Policy

The Authentication Methods Policy (Entra admin center → Protection → Authentication methods → Policies) governs which MFA methods are available in the tenant and how they may be used:

• Microsoft Authenticator — enable, allow push with number matching, allow hardware OTP through Authenticator
• FIDO2 security keys — enable, restrict to specific key manufacturers (AAGUIDs), enforce attestation
• Temporary Access Pass (TAP) — enable for onboarding/recovery, set lifetime and one-time vs multi-use
• SMS, Voice, Email OTP — enable/disable; Microsoft-provided SMS and voice delivery retires on 1 February 2027 (passkeys become the default sign-in experience on 1 September 2026), so migrate to passkeys/FIDO2, Windows Hello for Business, or Authenticator
• Software OATH tokens — enable for fallback

For each method you can target groups (who is allowed to use it) and set whether it can be used for MFA, SSPR, and Passwordless sign-in. This is separate from the CA policy — the CA policy says when MFA is required; the Authentication Methods Policy says what methods count as MFA.

Number Matching and MFA Fatigue

MFA fatigue (also called push-bombing) is an attack where the attacker repeatedly triggers MFA prompts hoping the user eventually approves one. Microsoft Authenticator mitigates this with number matching:

1. At sign-in, the user sees a number on the sign-in screen.
2. The user's Authenticator app shows the approval prompt.
3. The user must type the matching number into the app before they can approve.

Number matching has been enforced for every tenant since May 2023 and cannot be turned off — there is no toggle in the Authentication Methods Policy to enable or disable it. What you can configure there is the Authenticator authentication mode and the additional-context settings. The exam point is what number matching accomplishes: it defeats the 'just tap approve' attack, because an attacker who triggers the prompt cannot see the number displayed on the victim's sign-in screen.

Additional Authenticator protections include Additional context (showing the app name and location in the prompt) and App Lock (requiring biometrics or PIN to approve).

Trusted IPs, Named Locations, and Remembering MFA

• Named locations — defined IP ranges (for example, your corporate offices) labeled and available as a CA condition. A sign-in from a named location can be used to exclude MFA (trusted network) or to require it (untrusted network).
• Trusted IPs — a legacy MFA service setting; in the CA model you use named locations instead.
• Remembering MFA on trusted devices — historically a per-user MFA setting ('remember MFA for X days'); in the CA model this is replaced by the sign-in frequency session control, which sets how often a user must re-authenticate. Sign-in frequency can be applied per-session or for a configurable number of days.

Monitoring MFA

Two surfaces are essential for MFA operations:

• Sign-in logs (Entra admin center → Sign-in logs) — each sign-in shows the Conditional Access policy that applied, whether MFA was required, the result, and which method was used. Filter by 'Conditional Access' to see only CA-driven sign-ins. This is the primary troubleshooting tool when a user reports unexpected MFA prompts.
• Authentication Methods usage report (Protection → Authentication methods → Activity) — shows how many users are registered for each method and how often each method is used. Use it to track migration off SMS/voice and onto Authenticator/FIDO2.

The Exam Distinction: CA MFA vs Identity Protection Risk Policies

MS-102 tests the distinction between two related but separate mechanisms:

• Conditional Access Require MFA — a static, always-on MFA enforcement based on user/app/location. It does not consider risk.
• Identity Protection risk-based policies — Conditional Access policies that add user risk or sign-in risk as a condition. MFA is the remediation only when risk is detected.

A complete design uses both: a baseline CA policy that requires MFA for all users, plus Identity Protection risk policies that require MFA (sign-in risk) or SSPR (user risk) only when risk is present. The risk policies layer on top of the baseline — they do not replace it.