Microsoft stopped honoring legacy MFA and SSPR policies on September 30, 2025. If your tenant hasn’t migrated, those policies aren’t “deprecated”—they’re ignored. Users whose authentication methods aren’t explicitly configured in the unified Authentication Methods policy cannot authenticate. That’s not a warning. That’s the current state of your tenant.
The good news: the migration is well-tooled and reversible. Microsoft built an automated wizard that reads your legacy configuration and maps it into the new policy. The bad news: nobody warns you about the exceptions—the NPS registry keys, the security questions caveat, the “Migration in Progress” state you should stay in longer than you think. This guide covers the full path: audit, configure, flip the switch, and validate.
Prerequisites
Before starting, verify you have:
-
Authentication Policy Administrator or Global Administrator role in Microsoft Entra ID (formerly Azure Active Directory)
-
Access to the Microsoft Entra admin center
-
Documented emergency access (break-glass) accounts—Microsoft’s guidance on emergency access accounts recommends at least two accounts excluded from Conditional Access and MFA policies so you can’t lock yourself out
-
Microsoft Graph PowerShell module installed if you want to check migration state via CLI (covered below)
What’s Actually Changing
Microsoft Entra ID historically managed authentication methods across two disconnected places:
-
Legacy MFA policy: Controlled which verification methods (call, SMS, app notification, OATH tokens) were available for MFA challenges. Accessed via a separate per-user MFA portal buried under service settings.
-
Legacy SSPR policy: Controlled which methods users could use for self-service password reset (SSPR). Managed separately under Password Reset in the Azure portal.
These two didn’t talk to each other. A user could have SMS enabled for SSPR but not for MFA, producing inconsistent prompts and the kind of support tickets that ruin Mondays.
The new Authentication Methods policy consolidates both into a single blade under Protection > Authentication methods > Policies in the Entra admin center.
| Capability | Legacy Policies | Unified Policy |
|---|---|---|
| Scope | Tenant-wide only | Per-user or per-group |
| FIDO2 / Passkeys | Not supported | Supported |
| Temporary Access Pass (TAP) | Not supported | Supported |
| System-Preferred MFA | Not supported | Supported |
| Management location | Two separate portals | Single Entra admin blade |
The granular targeting alone is worth the migration. You can now enable FIDO2 security keys for your IT admins group while keeping SMS available only for field workers on legacy hardware—something the old policy couldn’t do at any price.
Key Insight: If your tenant missed the September 30, 2025 deadline, legacy settings are already being ignored. Fix this now—every day users rely on legacy-only method configurations is another day authentication failures can occur.
Before You Touch Anything: Audit Your Current State
The migration wizard is helpful, but it can only map what it finds. Before you run it, take a baseline snapshot of your current legacy configuration. If something breaks post-migration, you’ll want to know exactly what changed.
Legacy MFA location: Navigate to Entra ID > Users > All users, click Per-user MFA, then select Service settings. This screen shows every verification method currently enabled for MFA.
Legacy SSPR location: Go to Entra ID > Password reset > Authentication methods. This shows what’s allowed for password reset, how many methods are required, and whether security questions are in play.
Document both screens. Screenshots are fine. What you’re looking for:
-
Which methods are enabled (Call to phone, Mobile app code, SMS, Email, etc.)
-
Whether security questions are enabled for SSPR (a special exception—covered below)
-
The number of methods required for SSPR registration
You can also check your current migration state via Microsoft Graph PowerShell:
Connect-MgGraph -Scopes "Policy.Read.All" Get-MgPolicyAuthenticationMethodPolicy | Select-Object -ExpandProperty PolicyMigrationState
The output will be PreMigration, MigrationInProgress, or MigrationComplete. If you’re post-deadline and still at PreMigration, you’re running on borrowed time.
Warning: Do not skip documenting your current state. If you run the migration wizard without a baseline, a misconfiguration in the new policy has no rollback reference.
Running the Migration
The migration is controlled through a three-state toggle. Understanding these states before you start prevents the kind of misstep that causes a Monday morning outage.
| State | Who Controls Auth Methods? | Effect on Users |
|---|---|---|
| Pre-migration | Legacy policies only | New policy inactive; legacy settings respected |
| Migration in Progress | Both (OR logic) | Methods from either policy are honored |
| Migration Complete | Unified policy only | Legacy settings fully ignored |
“Migration in Progress” is the critical state. While active, Entra evaluates both the old and new policies together using OR logic—if a method is enabled in either place, users can use it. This gives you a test window where no one gets locked out while you validate the new configuration.
Step 1: Open the Policies Blade
Navigate to Protection > Authentication methods > Policies in the Microsoft Entra admin center.
Step 2: Run the Automated Migration Guide
Click Manage migration in the top menu, then select Begin automated guide. The wizard scans your legacy MFA and SSPR configurations and pre-populates the corresponding toggles in the new policy. If SMS was enabled in legacy MFA, the wizard enables it for “All users” in the new policy. Same logic for every method it finds.
Review the wizard’s output before accepting it. This is your chance to make intentional changes—restricting SMS to a specific group rather than all users, for example.
Step 3: Configure Key Methods
Some settings deserve deliberate attention before you flip the migration state.
Microsoft Authenticator: Set the Authentication mode to Any (not just “Passwordless”). If you leave it at “Passwordless” only and a user hasn’t registered a compliant device, they’ll hit a “No methods available” error post-migration.
SMS and Voice: If these were enabled in legacy, enable them here. If you want to restrict them to a specific group (recommended—SMS is susceptible to SIM-swap attacks), create that group and scope the method accordingly.
Email OTP: Required for B2B guest users if your tenant has them. Easy to miss since it wasn’t prominent in the legacy UI.
Temporary Access Pass (TAP): TAP is a time-limited passcode available exclusively in the new policy. If you onboard new employees by temporarily exempting them from MFA, TAP replaces that practice with a proper, time-bounded credential.
Step 4: Set to “Migration in Progress”
Click Manage migration, select Migration in Progress, and save. Nothing breaks. Users continue to authenticate normally. The new policy is now active alongside the legacy one.
You can also set the migration state via Graph PowerShell if you prefer scripted changes:
Connect-MgGraph -Scopes "Policy.ReadWrite.AuthenticationMethod"
$params = @{
PolicyMigrationState = "MigrationInProgress"
}
Update-MgPolicyAuthenticationMethodPolicy -BodyParameter $params
Stay in this state for at least a few days. Test authentication flows. Verify SSPR works. Watch the sign-in logs. Only move to “Migration Complete” after you’ve confirmed the new policy handles everything correctly.
Pro Tip: Filter Entra ID sign-in logs by Authentication Details and look for “MFA satisfied by…” to confirm whether the new unified policy—or the legacy one—is satisfying MFA challenges. That’s your go/no-go signal.
Step 5: Complete the Migration
Once validated, return to Manage migration and select Migration Complete. Legacy settings are now ignored. The unified policy is the sole authority.
This step is reversible—you can toggle back to “Migration in Progress” if a critical issue surfaces. That said, treat reversion as an escape hatch, not part of the plan.
Exceptions and Gotchas
Two situations will catch you off guard if you don’t know about them ahead of time.
Security Questions Stay in the Legacy Portal
Security questions for SSPR are not supported in the unified Authentication Methods policy. They remain managed in the legacy SSPR portal and that’s the one setting that stays active even after “Migration Complete” is selected.
Microsoft plans to retire security questions in March 2027. Until then, manage them where they are. Don’t disable security questions in the legacy portal and replace them with another method unless you’ve confirmed every user who relies on them has an alternative registered.
NPS Extensions and RADIUS Authentication
If your organization uses the Network Policy Server (NPS) extension for Azure MFA—typically for VPN or Remote Desktop Gateway—number matching creates a problem.
Modern Authenticator policies enforce number matching (the user enters a displayed number in the app) to counter MFA fatigue attacks. Standard RADIUS protocols used by VPN clients can’t display that number. The result: users get a push notification asking for a number match that their VPN client never shows them, and authentication fails.
The fix is a registry key on the NPS server:
plain text
Registry path: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\AzureMfa
Key name: OVERRIDE_NUMBER_MATCHING_WITH_OTP
Value: FALSE (forces Approve/Deny prompt)
TRUE (forces OTP code entry)
NPS extension version 1.2.2216.1 or later defaults to OTP automatically. The registry key controls fallback behavior for older versions. Set this before completing the migration if VPN authentication is in scope.
| Scenario | Recommended Value | Result |
|---|---|---|
| Legacy NPS extension (<1.2.2216.1), VPN users | FALSE |
Approve/Deny push prompt |
| Legacy NPS extension, users prefer codes | TRUE |
OTP code entry |
| NPS extension ≥1.2.2216.1 | Not required | OTP selected automatically |
Warning: Skipping this NPS registry fix will lock VPN and RDS users out the moment “Migration Complete” enforces number matching. Test with one user before cutting over.
Post-Migration Validation
Don’t declare success until you’ve tested all three of these.
SSPR flow: Trigger a password reset with a test account. Confirm the methods available match your new policy configuration—not the old one.
MFA challenge: Sign in to an application requiring MFA (Outlook Web works) with a test account. Verify the expected verification options appear. If you enabled Authenticator in “Any” mode, both push notifications and OATH codes should work.
Sign-in logs: In the Entra admin center, navigate to Monitoring & health > Sign-in logs. Filter for a few users and check Authentication Details. You’re looking for confirmation that the unified policy—not the legacy one—is satisfying MFA requirements.
If you’re using the Registration Campaign (the feature that nudges users to register modern methods), verify it’s targeting the correct users in the new policy blade. This configuration doesn’t migrate automatically.
What You Unlock After Migration
The unified policy isn’t just consolidation—it opens authentication capabilities that weren’t available before.
Phishing-resistant MFA: FIDO2 security keys and Windows Hello for Business work only through the new policy. If your organization is working toward Zero Trust or has compliance requirements tied to US Executive Order 14028 on federal cybersecurity standards, phishing-resistant MFA is the requirement, and this migration puts you in position to meet it.
System-Preferred MFA: Entra now prompts users with their most secure registered method rather than whichever one they used last. A user with both SMS and the Authenticator app registered gets the app prompt, not the SMS prompt. That default behavior improves your security posture with zero additional user training.
Granular group targeting: Enable a method for specific groups only. Restrict SMS to a “Legacy Devices” group. Enable TAP only for your help desk during onboarding. None of this was possible with tenant-wide-only legacy settings.
Wrapping Up
The path is: audit your current state, run the automated wizard, review and adjust the output, move to “Migration in Progress” and validate, then complete when you’re confident. The whole process can be done in a single afternoon for a small tenant, or spread across a week for enterprise environments where extended validation is worthwhile.
If your tenant is post-deadline and still running legacy settings, you’re not in a grace period—legacy settings are already being ignored. Any users who depended on methods configured only in the old policy and haven’t registered alternatives are already affected.
Handle the NPS registry key before completing the migration if you have VPN users, leave security questions in the legacy SSPR portal (they have their own retirement date), and use sign-in logs to confirm the unified policy is doing the work before you declare done. The migration is reversible right up until “Migration Complete”—use that window.
