3.5 Multifactor Authentication

What MFA actually requires

Multifactor authentication (MFA) requires an identity to present two or more verification proofs from different categories before sign-in succeeds. The categories are the same three factors from 3.4:

• Something you know — password or PIN
• Something you have — a phone, FIDO2 key, or token
• Something you are — a biometric (fingerprint/face)

The critical exam rule: the factors must come from different categories. A password and a security question are both "something you know," so that combination is not true MFA. A password (know) plus an Authenticator approval on your phone (have) is MFA. This "two factors must be different types" distinction is a favorite SC-900 trap.

MFA matters because it directly addresses the weakness of password-only sign-in: even if an attacker steals or guesses the password, they still lack the second factor. Microsoft has reported that MFA blocks the vast majority (over 99%) of account-compromise attacks, which is why identity is treated as the primary perimeter in Zero Trust.

Entra MFA methods and number matching

Microsoft Entra multifactor authentication can use any of the second-factor methods Entra ID supports:

Number matching is an important modern control: instead of just tapping "Approve," the user must type a number shown on the sign-in screen into the Authenticator app, which defeats MFA fatigue / push-bombing attacks where an attacker spams approval prompts hoping the user taps yes. SMS and voice still count as MFA factors but are the weakest because they can be intercepted or SIM-swapped.

How MFA is enforced

MFA is rarely a standalone toggle; it is triggered by policy. Two SC-900-relevant enforcement mechanisms:

• Security defaults — a free, tenant-wide baseline that, among other protections, requires all users to register and use MFA and forces MFA for administrators. It is on by default for many newer tenants and is the simple, all-or-nothing option.
• Conditional Access — the flexible, policy-based engine (covered in Chapter 4) that requires MFA based on signals such as user/group, app, location, device state, and sign-in risk. For example, "require MFA when accessing finance apps from outside the corporate network."

Exam cue: "require MFA for everyone with no configuration" → Security defaults; "require MFA only under certain conditions" → Conditional Access.

MFA versus its neighbors — staying in lane

MFA strengthens the authentication step only. It does not decide whether someone should be a global administrator, whether their access should be recertified, or how to respond to a risky sign-in. Keep these adjacent capabilities separate:

• Stronger proof at sign-in → MFA.
• Decide what a signed-in user may access → authorization / roles.
• Periodically confirm a user still needs access → access reviews (governance).
• Time-bound activation of a privileged role → Privileged Identity Management (PIM).
• Detect and respond to risky sign-ins / leaked credentials → Identity Protection.

Common traps: MFA is not the same as passwordless — passwordless removes the password, while MFA can still include the password as one of its factors (though passwordless methods can themselves satisfy MFA). And MFA does not eliminate the need for authorization; a successfully MFA'd user still only gets the access their roles and policies allow. When a scenario says "add a second verification step" or "reduce risk from stolen passwords," MFA should be at the top of your list.

Putting MFA in the Zero Trust picture

MFA is the clearest, most exam-friendly example of the Zero Trust principle "verify explicitly." Rather than trusting a password because it was correct, the system demands additional, harder-to-forge evidence before granting the sign-in. That is why MFA shows up across multiple SC-900 objective areas — concepts, identity, and security — and why "require MFA" is one of the most common recommended controls.

A few precise points the exam can probe:

• MFA can be per-user enabled (legacy), via Security defaults (free baseline), or via Conditional Access (P1+, signal-based). Conditional Access is the modern, recommended approach.

• MFA strengthens interactive sign-in; it does not by itself protect against an already-stolen session token (that's where Conditional Access session controls and Identity Protection add value).

• Passwordless phishing-resistant methods (passkeys, Windows Hello) can satisfy the MFA requirement and remove the password at once.

• Verify explicitly → require MFA.

• All users, no config → Security defaults.

• Targeted by conditions → Conditional Access.

• Remove the password while keeping MFA-grade assurance → phishing-resistant passwordless.

Grounding MFA in "verify explicitly" ties this section back to Chapter 2 and forward to Conditional Access, which is exactly how the exam connects the dots.