2.3 MFA and Passwordless Authentication

2.3 MFA and Passwordless Authentication

Quick Answer: MFA requires multiple factors at sign-in; passwordless removes the password from the primary credential. Prefer phishing-resistant methods (FIDO2/passkeys, Windows Hello for Business, certificate-based auth) and enforce them with authentication strengths in Conditional Access. Use Temporary Access Pass and registration campaigns to onboard users; treat SMS as legacy/phishable.

Authentication is the front door for every Entra-protected resource. On SC-500, “implement MFA and passwordless” means designing method policy, registration, recovery, and Conditional Access enforcement—not just enabling a checkbox.

MFA vs Passwordless (Exam Distinction)

Key exam nuance: Passwordless methods are often also multifactor (device + biometric/PIN). Conversely, classic MFA can still be password-based (password + SMS). “Passwordless” describes the credential type; “MFA” describes factor count; “phishing-resistant” describes attack resistance.

Microsoft’s direction for privileged and high-risk access is phishing-resistant passwordless, not “any MFA.”

Authentication Methods You Must Know

Microsoft Authenticator

• Push notifications (with number matching recommended to reduce MFA fatigue attacks)
• TOTP codes
• Passwordless phone sign-in (user approves on the phone without typing a password)

Authenticator is the common enterprise default for broad MFA rollout. It is stronger than SMS but not as phishing-resistant as hardware-backed FIDO2 in high-assurance designs.

Passkeys (FIDO2) and FIDO2 security keys

• Phishing-resistant credentials bound to the relying party origin
• Hardware keys or platform/synced passkeys depending on configuration
• Excellent for admins and users who need portable strong auth

Windows Hello for Business

• Device-bound credentials unlocked by biometric or PIN
• Strong for corporate Windows fleets; pairs well with hybrid or cloud trust deployments
• Counts toward phishing-resistant authentication strength scenarios

Temporary Access Pass (TAP)

• Time-limited passcode issued by an admin
• Configurable for one-time or multiple-use within a short lifetime
• Primary uses: onboard passwordless methods for new hires; recover access when a user loses a FIDO2 key or phone
• Treated as a strong method for bootstrap—not a long-term daily credential

SMS and voice

• Widely available but phishable and vulnerable to SIM swap / interception
• Acceptable only as fallback in low-assurance scenarios or during migration—not for Global Administrators or sensitive admin portals in a modern design

Certificate-based authentication (CBA)

• Smart card / certificate scenarios for regulated environments
• Can satisfy multifactor/phishing-resistant strengths when configured as multifactor CBA

Authentication Strengths in Conditional Access

Authentication strength is a grant control that whitelists allowed method combinations.

You can also define custom strengths. SC-500 loves questions that pair admin portals with phishing-resistant strength and standard users with broader MFA strength.

How this differs from “Require MFA”

• Require MFA — any registered method that completes MFA may work (including weaker ones if enabled)
• Require authentication strength — only methods in that strength are accepted

If the exam asks how to prevent SMS for Global Administrators while still allowing FIDO2, the answer is authentication strength (and method enablement policy), not merely “enable MFA.”

Registration Campaigns and Method Lifecycle

Users cannot use Authenticator or FIDO2 until methods are registered.

• Registration campaign (Authenticator) prompts users during sign-in to set up the app—drives adoption without a help-desk ticket for every user
• Authentication methods policy enables/disables methods (SMS, TAP, FIDO2, etc.) and scopes them to groups
• Combined registration experiences let users set MFA and SSPR methods in one flow when configured

Lifecycle controls:

1. Enable strong methods in the authentication methods policy
2. Scope TAP to help desk / identity admins for issuance
3. Run registration campaigns for Authenticator
4. Issue TAP for FIDO2/Windows Hello onboarding where users have no existing strong method
5. Enforce strengths via Conditional Access once registration metrics look healthy
6. Remove SMS for privileged groups when ready

SSPR vs MFA

They often share registered methods (mobile app, email, phone) but solve different problems. Enabling SSPR does not equal enforcing MFA at sign-in. Conditional Access / security defaults / per-user MFA settings govern sign-in MFA; SSPR policies govern reset.

Exam trap: A user who can reset a password via SSPR may still be blocked by Conditional Access if they lack a required phishing-resistant method for an admin portal.

Passwordless Rollout Pattern (SC-500 Design)

1. Discover — inventory who still uses SMS; identify admin population
2. Enable methods — Authenticator passwordless, FIDO2, Windows Hello for Business, TAP
3. Register — campaigns + TAP-assisted onboarding
4. Enforce lightly — CA require MFA for all users (report-only → on)
5. Enforce strongly — CA phishing-resistant strength for admins and sensitive apps
6. Decommission weak methods — disable SMS for privileged groups; monitor fallback usage
7. Recover — documented TAP process for lost keys/devices; break-glass accounts remain separate

SC-500 Scenario Table

Common Exam Traps

1. Passwordless is not the opposite of MFA — many passwordless methods are MFA.
2. SMS counts as MFA but fails phishing-resistant designs — do not recommend SMS for GA.
3. TAP is temporary onboarding/recovery, not a permanent replacement for FIDO2.
4. SSPR ≠ MFA enforcement — different control planes.
5. Authentication strength is the precision tool when “require MFA” is too broad.

Strong authentication protects human sign-ins. Applications and Azure resources also need identities—without embedding secrets in code. The next section covers app registrations, OAuth consent, and managed identities.