AZ-104
Deep Dive
MFA blocks 99.9% of account attacks. The AZ-104 tests the available methods, the difference between per-user MFA and MFA via Conditional Access, and SSPR configuration.
Contents
MFA requires the user to verify their identity with two or more factors from different categories. If an attacker steals the password, they can't get in without the second factor.
Something you KNOW
Something you HAVE
Something you ARE
Password + PIN ≠ MFA
Both are "something you know" — the same category. MFA requires factors from different categories. Password + authenticator app = valid MFA.
| Method | Description | MFA | SSPR | Security |
|---|---|---|---|---|
| Microsoft Authenticator App | Push notification or TOTP code. Free iOS/Android app. | ✓ | ✓ | ⭐⭐⭐⭐⭐ Recommended |
| FIDO2 Security Key | Physical USB/NFC key. Passwordless + phishing-resistant. | ✓ | ✓ | ⭐⭐⭐⭐⭐ Maximum security |
| Windows Hello for Business | Biometric or PIN on a domain-joined Windows device. | ✓ | ✗ | ⭐⭐⭐⭐⭐ |
| TOTP (Authenticator or 3rd party) | 6-digit code that rotates every 30 seconds. | ✓ | ✓ | ⭐⭐⭐⭐ |
| SMS / Phone call | Code by text or call. Convenient but susceptible to SIM swap. | ✓ | ✓ | ⭐⭐ — discouraged if an alternative exists |
| Email (SSPR only) | Verification code to an external email. SSPR only, not for login MFA. | ✗ | ✓ | ⭐⭐ |
| Security questions (SSPR) | Answers to predefined questions. SSPR only. Easy to compromise. | ✗ | ✓ | ⭐ — last resort only |
How it works
In Entra ID → Users → Per-user MFA, each user has a state:
⚠ Why it's "legacy"
Conditional Access applies MFA intelligently based on context signals. Requires Entra ID P1.
Anatomy of a CA Policy
Assignments → Users
Who it applies to: all users, specific groups, or excluding emergency (break-glass) accounts.
Assignments → Cloud apps
Which apps: all apps, Microsoft Admin Portals, or specific apps (Salesforce, etc.).
Conditions
Signals: location (named location), device platform, client app, sign-in risk, user risk.
Access controls → Grant
What to do: Block access, or Grant with conditions (require MFA, compliant device, hybrid Azure AD join, etc.).
Access controls → Session
Session controls: re-authentication frequency, read-only mode for unmanaged apps.
Common CA policies — AZ-104
Require MFA for Admins
All users with directory roles (Global Admin, etc.) must always do MFA.
Require MFA from untrusted locations
MFA only when the login comes from IPs not included in trusted Named Locations.
Block legacy authentication
Block legacy protocols (IMAP, SMTP, EAS) that don't support MFA.
Require compliant device
Access only from devices marked compliant in Intune.
Report-only mode
Before enabling a CA policy, use it in "Report-only" mode — it evaluates without enforcing. Check Sign-in logs to see who would be impacted. Avoids accidental lockouts.
Authentication Strength lets you specify in a CA policy exactly which combinations of authentication methods are acceptable. More granular than just "require MFA."
Built-in policies
Multifactor authentication
BasicAny valid MFA combination. Equivalent to the classic "require MFA." Accepts password + SMS, password + app, passwordless, etc.
Passwordless MFA
IntermediateOnly methods that don't require a password + second factor: Microsoft Authenticator (passwordless sign-in), FIDO2, Windows Hello for Business.
Phishing-resistant MFA
MaximumOnly phishing-resistant methods: FIDO2 Security Keys, Windows Hello for Business, Certificate-based authentication. The most secure.
Custom Authentication Strength
Create your own allowed combinations. For example: allow only FIDO2 or certificate-based auth, blocking SMS and voice calls.
→ Entra ID → Security → Authentication methods → Authentication strengths → New authentication strength
→ Select the allowed method combinations (AND combinations)
→ Assign the custom strength in a CA policy → Access controls → Grant → Require authentication strength
When to use Authentication Strength vs "Require MFA"
"Require MFA": any valid MFA method is acceptable. Flexible.
Authentication Strength: when you need to require specific methods. E.g., very sensitive resources where SMS isn't acceptable due to SIM swap risk.
MFA fatigue attacks bombard the user with push notifications until they accidentally accept one. Microsoft implemented protections that have been enabled by default since 2023.
Number Matching
When the user receives an Authenticator push notification, they must enter the 2-digit number shown on the login screen. The attacker doesn't have that number.
Enabled by default (cannot be disabled)
Additional Context
The push notification shows: the name of the app requesting access (e.g., "Azure Portal") and the approximate location of the login (e.g., "Mexico City, Mexico"). The user can spot if it isn't them.
Enabled by default
GPS Location (optional)
The user can optionally share their GPS for additional context. Lets the admin see where the authentication came from. Not mandatory.
Optional, controlled by the user
MFA Fatigue Attack — how it works
The attacker has the user's password (obtained via phishing). They repeatedly attempt to log in, generating dozens of push notifications to the user's phone. The user, frustrated or confused, eventually accepts one. With number matching, the attacker has the password but not the number shown on the victim's screen → the attack fails.
Many corporate apps (VPN, Remote Desktop Gateway, network switches) use RADIUS for authentication. They don't support modern OIDC/SAML. The NPS Extension extends the on-premises NPS server to invoke Entra MFA.
Architecture with the NPS Extension
Requirements
• License: Entra ID P1 minimum
• OS: Windows Server 2012 R2+ with the NPS role installed
• Connectivity: the NPS server needs outbound HTTPS to Azure
• Users must have an MFA method registered in Entra ID
• PowerShell: the AzureAD module and the tenant configuration script
NPS Extension limitations
• Only supports Microsoft Authenticator (push/TOTP) and voice call — no FIDO2 or passwordless
• Doesn't support B2B guest accounts
• If Azure MFA is down, authentication can fail (no fallback to password-only by default)
• RADIUS timeout can be an issue — extend the timeout in the VPN client to 60+ seconds
SSPR configuration
Entra ID → Password reset → Properties. Three scope options:
Number of methods required
You can configure how many methods the user must verify to reset:
1 method
Less friction
Less secure — one compromised method = reset possible
2 methods
More secure
The user must have 2 registered methods
Combined registration unifies the registration of methods for MFA and SSPR into a single experience at aka.ms/mysecurityinfo.
Registration Campaign
A feature to nudge users toward registering more secure methods (e.g., migrating from SMS to the Authenticator App). Configured in Authentication methods → Registration campaign.
• Appears as an interruption during login: "Improve your security"
• The user can snooze it N times (configurable)
• Includes or excludes specific groups
• Adoption progress can be monitored
Break-glass (emergency) accounts
Emergency access accounts that must exist outside the normal MFA/CA flow to recover the tenant if admin access is lost.
• At least 2 accounts, long random password, stored offline
• Explicitly excluded from all CA policies
• Use the *.onmicrosoft.com domain (doesn't depend on a custom domain or ADFS)
• Monitor access — an alert should trigger if they're used
Did you get this topic?
Test what you just learned
Which MFA method in Microsoft Entra ID is the most secure and resistant to phishing and SIM swapping attacks?
Put what you learned to the test with original AZ-104 exam questions.
Start AZ-104 mock examUnlimited mock exams with the Pro plan
Log in to track your progress.