Migrating to the authentication methods policy: retiring legacy MFA and SSPR settings

Microsoft Entra ID used to decide which authentication methods users may use in three places: the legacy MFA service settings, the SSPR policy and the authentication methods policy. The first two are deprecated for method management, so the unified policy should now be the only one that counts. In this post I'll walk through the migration states, how each legacy setting maps across, and how to prove that nobody loses a working method when you finish.

How it works: three policies, three states#

Until you finish, Entra ID honours every policy at once: if a method is enabled in any of them, users in scope can register and use it. That is why you can switch SMS off in the new policy and still see people receive texts — a legacy MFA or SSPR setting is still allowing it. The Manage migration control decides which policies count:

Tenants start in Pre-migration or Migration in progress depending on their history. If yours started in Pre-migration you can move to any state at any time; if it started in Migration in progress you can switch between that and Migration complete, but not back to Pre-migration. You need at least the Authentication Policy Administrator role.

Step-by-step#

1. Record the legacy settings and the current state#

Before changing anything, capture both legacy pages so you can roll back:

• Legacy MFA: Entra ID › Users, select Per-user MFA, then service settings (verification options).
• Legacy SSPR: Entra ID › Password reset › Authentication methods, plus who is in scope on Properties (All, Selected or None).

Connect-MgGraph -Scopes "Policy.Read.AuthenticationMethod"
$policy = Get-MgPolicyAuthenticationMethodPolicy
$policy.PolicyMigrationState
$policy.AuthenticationMethodConfigurations | Select-Object Id, State

2. Map each legacy method#

Rule of thumb: enabled in both legacy policies, enable it for all users; off in both, leave it off; enabled in only one, decide deliberately. You don't have to copy the old policy — scope SMS and voice to a small group instead of everyone, and enable Passkey (FIDO2) and Temporary Access Pass while you are there.

3. Switch to Migration in progress, then configure#

Open Entra ID › Authentication methods › Policies, select Manage migration and choose Migration in progress before editing methods, so the new policy governs password reset as well. Then enable and target each method. The same page also offers an automated migration guide that reads both legacy policies, proposes an equivalent configuration and completes the migration when you confirm — handy for simple tenants, but review every proposed method.

4. Test before you complete#

In Migration in progress the legacy settings still apply alongside the new policy, so test MFA registration, sign-in and password reset with pilot users for every method you kept. Where the legacy pages still accept edits, Microsoft's guidance is to remove methods there one at a time and retest after each change. Leave security questions enabled in SSPR if you rely on them.

5. Set Migration complete#

Select Manage migration › Migration complete, or script it (requires Policy.ReadWrite.AuthenticationMethod):

Update-MgPolicyAuthenticationMethodPolicy -PolicyMigrationState "migrationComplete"

Verify#

The registration report tells you who is at risk. IsMfaRegistered means the user registered a strong method; IsMfaCapable means that method is also allowed by policy. Registered but not capable is your call list.

Connect-MgGraph -Scopes "AuditLog.Read.All"
$reg = Get-MgReportAuthenticationMethodUserRegistrationDetail -All

# Registered for MFA, but no registered method is allowed any more
$reg | Where-Object { $_.IsMfaRegistered -and -not $_.IsMfaCapable } |
    Select-Object UserPrincipalName, @{ n = 'Methods'; e = { $_.MethodsRegistered -join ', ' } }

# Users whose only registered method is a mobile phone
$reg | Where-Object { ($_.MethodsRegistered -join ',') -eq 'mobilePhone' } |
    Select-Object UserPrincipalName

Good looks like: the state reads migrationComplete, the first query returns nobody you haven't already contacted, and Entra ID › Authentication methods › Activity shows MFA-capable numbers that didn't drop. The report can lag by up to 36 hours, skips disabled users and needs Microsoft Entra ID P1 or P2.

Tips & gotchas#

• Only tenant settings move. Individual user settings aren't migrated, so per-user MFA states stay as they are — a separate clean-up toward Conditional Access.
• SMS sign-in. Enabling SMS also turns on Use for sign-in by default, and users enabled for SMS sign-in are skipped by cross-tenant synchronization. Turn it off unless you really want it.
• Authenticator as a plain code app. Users who added it through "I want to use a different authenticator app" need Third-party software OATH tokens enabled.
• Email OTP and guests. While Allow external users to use email OTP is on, the method can't be disabled.
• Target groups, not users. Consolidate groups per method; a policy above 20 KB can't be saved and many groups can break registration.
• Leftovers. Even at Migration complete, the SSPR Number of methods required to reset and the SSPR administrator policy still live in the legacy SSPR settings.
• Break-glass accounts. Keep the method your emergency accounts use enabled for them — see Emergency access (break-glass) accounts.

Moving users to stronger methods next? See rolling out passkeys in Microsoft Authenticator and fixing SSPR and password writeback.

References#

• How to migrate MFA and SSPR policy settings to the Authentication methods policy
• Manage authentication methods for Microsoft Entra ID
• Authentication Methods Activity