Entra Legacy MFA and SSPR Policy Migration: move every method to one policy safely

Microsoft Entra ID no longer lets administrators manage authentication methods in the legacy multifactor authentication and self-service password reset policies, so any tenant that has not finished moving to the Authentication methods policy is running on settings it can no longer change. Microsoft announced the deprecation in March 2023 and states that beginning 30 September 2025 authentication methods can't be managed in the legacy MFA and SSPR policies. The practical risk is not an outage on a set date but drift: methods such as SMS and voice calls stay enabled through a legacy setting nobody can see in the new policy, and attempts to retire them quietly fail. This guide covers the three migration states, how legacy settings map to the new policy, how to find which users depend on which method, how to retire SMS and voice, and how authentication strengths finish the job. It is written for Entra administrators and identity engineers. General MFA design is covered in the MFA Guide; this page is only about the Entra policy migration.

This is an independent guide from NHI Mgmt Group, based on Microsoft's public documentation as of November 2026. It is not sponsored or reviewed by Microsoft. Product features change, so confirm settings against Microsoft's current documentation.

Key takeaways

• Three states, limited return. Pre-migration, Migration in Progress and Migration Complete decide whether legacy settings are respected. You can move between In Progress and Complete freely. A tenant that started in Pre-migration can move to any state, but one that started in Migration in Progress cannot move to Pre-migration.
• A method enabled anywhere is enabled everywhere. Until migration is complete, a user enabled for a method in any of the three policies can register and use it. Disabling SMS in one place does nothing if a legacy policy still allows it.
• The mapping is not one to one. Legacy SSPR "Mobile phone" turns on both SMS and voice, and the single legacy OATH control splits into three method policies. Read the mapping before you migrate, not after.
• Security questions are the exception. They can still only be managed in the legacy SSPR policy, and Microsoft lets you complete the migration with them enabled there.
• Migration is the precondition for strengths. Authentication strengths in Conditional Access can only demand methods the policy allows, so a clean Authentication methods policy is what makes phishing-resistant requirements enforceable.

What is changing and why

Entra ID historically had three places that controlled authentication methods. The legacy MFA policy (the per-user MFA service settings page) applied to every user in the tenant, with no way to say who could use a method. The legacy SSPR policy controlled which methods could reset a password, scoped to all users, one group or none. The Authentication methods policy, introduced later, supports per-method targeting by group, per-method configuration and the modern methods: passkeys (FIDO2), Temporary Access Pass, certificate-based authentication, Windows Hello for Business and platform credentials.

Microsoft's concept page is explicit that settings are not synchronised between these policies. Three overlapping policies produce three security problems:

• Invisible enablement: a method can be live for every user because of a legacy checkbox while the Authentication methods policy shows it as off.
• No targeting: the legacy MFA policy cannot restrict a weak method to a small exception group.
• Weak recovery paths: SSPR often allowed SMS, voice, email and security questions long after sign-in had moved to stronger methods, and password reset is a takeover route in its own right. See the Secure Password Reset Flow Guide.

The per-user MFA enforcement states (Enabled, Enforced) are a separate topic from the methods settings and are covered in the Entra Per-User MFA to Conditional Access guide.

Official timeline and current status

The table lists only what Microsoft Learn states, as checked on 8 November 2026. Microsoft can change its documentation, so recheck the concept page before relying on any detail.

The migration states are defined on the Microsoft Graph authenticationMethodsPolicy resource as the policyMigrationState property:

Read the current value with GET /policies/authenticationMethodsPolicy in Microsoft Graph, or open Entra ID, Authentication methods, Policies, Manage migration in the admin center.

Who and what is affected

Every Entra tenant is affected, but the impact depends on what the legacy pages still enable. The method mapping from Microsoft Learn is the core reference for the migration:

• Users with only weak methods: users whose only registered method is SMS or voice lose MFA ability if you disable telephony before they register something else.
• B2B guests: disabling Email OTP is blocked while external users are allowed to use it, and guest sign-in depends on that setting.
• Cross-tenant synchronisation: Microsoft notes users with SMS sign-in are skipped by cross-tenant synchronisation, which is a reason to switch "Use for sign-in" off unless you need it.
• Service desks and break-glass accounts: emergency access accounts and help desk recovery flows often rely on whatever the legacy pages allowed. Inventory them before changing anything.

Finding affected systems and identities

Build the picture from configuration first, then from usage.

1. Snapshot the three policies: per-user MFA, service settings (verification options); Password reset, Authentication methods and Properties (scope, number of methods, security questions); Authentication methods, Policies (each method's include and exclude groups and configuration such as Authenticator number matching context). Microsoft's manual steps list exactly these pages. Export the Authentication methods policy JSON from Graph so you can diff later.
2. Read the registration details: Entra ID, Authentication methods, Activity, Registration tab, and the User registration details view. It shows per user whether they are MFA capable, passwordless capable, SSPR registered and which methods they have registered. Export it. Note the data can lag by up to 36 hours and disabled users are not listed.
3. Find telephony-only users: filter the export for users whose registered methods contain only mobile phone, alternate phone or office phone. They are the cohort that breaks when SMS and voice go.
4. Read the Usage tab: sign-ins by authentication method and password resets by method show which methods are actually used, not just registered. Usage and insights need Entra ID P1 or P2.
5. Query sign-in logs: in Log Analytics or your SIEM, summarise successful MFA sign-ins by the authentication method recorded in the authentication details of each sign-in, over at least 30 days, and list accounts still completing MFA by text message or voice call.
6. Check service desk processes: find every procedure that resets MFA or reads out a code by phone. These must change when telephony is restricted.

Migration options

Wizard or manual

• Automated wizard: under Entra ID, Authentication methods, Policies. It recommends enabling in the Authentication methods policy every method enabled in either legacy policy, and also recommends passkeys, Temporary Access Pass and Microsoft Authenticator. You can edit each method before selecting Migrate, after which legacy methods are greyed out and the state becomes Migration Complete. It migrates tenant settings only, not individual user settings. Best for small tenants with simple legacy settings.
• Manual control: set Migration in Progress, configure each method in the Authentication methods policy, remove methods from the legacy policies one at a time, test, then set Migration Complete. Best for larger tenants, because it lets you change one method at a time and target groups instead of all users. Requires at least the Authentication Policy Administrator role.

Deciding what to enable

Microsoft's rule of thumb: a method enabled in both legacy policies can be enabled for all users; a method off in both stays off; a method on in only one needs a decision. Use the migration to tighten, not copy:

Retiring SMS and voice

1. Create an exception group for telephony and target SMS and Voice calls at it only, with every user who currently relies on telephony added.
2. Run a registration campaign for Microsoft Authenticator or Passkey (FIDO2), with limited snoozes so registration becomes required after three snoozes. Microsoft's guidance is that Authenticator campaigns need the Authenticator mode set to Any or Push.
3. Leave system-preferred authentication on (Microsoft managed or Enabled). It prompts users with their most secure registered method, and Microsoft ranks telephony seventh of nine, so users who have registered something better stop being offered SMS.
4. Remove users from the exception group as the registration report shows a stronger method, in weekly batches.
5. When the group is empty or holds only documented exceptions, disable SMS and Voice calls, and check that legacy SSPR "Mobile phone" and "Office phone" are off, since the legacy policy is ignored only once Migration Complete is set.

Authentication strengths

Once the methods policy is clean, use Conditional Access authentication strengths for the sensitive cases: the built-in Phishing-resistant MFA strength (passkeys, Windows Hello for Business or platform credential, multifactor certificate-based authentication) for administrators and high-risk applications, Passwordless MFA where Authenticator phone sign-in is acceptable, and custom strengths where you need a specific combination. Microsoft notes that a strength cannot enable a method the Authentication methods policy disallows, that the Require authentication strength and Require multifactor authentication grant controls cannot be combined in one policy, and that SMS sign-in is not part of any built-in strength. See the Conditional Access Guide and the Phishing-Resistant MFA Guide.

Testing and rollback

1. Pilot ring: during Migration in Progress, target new method settings at a pilot group of IT staff, including at least one guest account, one frontline user and one service desk operator.
2. Test both journeys: sign-in with MFA and self-service password reset, on desktop and mobile, for each method you keep. SSPR uses the Authentication methods policy from Migration in Progress onwards, so reset can change before sign-in does.
3. Change one method at a time: remove each method from the legacy policies separately and wait for a full business cycle of sign-ins before the next.
4. Mind the known issues: Microsoft recommends one group per method, adding the new group and removing the old one in the same operation, and notes that policy changes cannot be saved if the policy exceeds 20 KB.
5. Rollback: switching from Migration Complete back to Migration in Progress re-applies the legacy settings and asks for a reason; Microsoft describes the process as fully reversible. Keep the Graph JSON snapshot from step 1 so you can restore method targeting exactly.
6. Protect emergency access: exclude break-glass accounts from method changes until you have tested their sign-in with a phishing-resistant method.

Risks of doing nothing

• Frozen weak methods: SMS, voice and security questions remain available through legacy settings you can no longer manage, which keeps SIM-swap and social engineering routes open. See the SIM Swap Fraud Guide.
• False assurance: the Authentication methods policy shows a method as disabled while users still register and use it.
• Weak password reset: SSPR stays the soft path to account takeover even when sign-in is phishing-resistant.
• No phishing resistance where it matters: authentication strengths are only as good as the methods policy beneath them, and MFA interception (ATT&CK T1111) and push fatigue (T1621) target exactly the weaker methods. See the MFA Fatigue and Bypass Guide.
• Audit findings: NIST SP 800-63B-4 treats PSTN out-of-band authentication as restricted and requires alternatives to be offered; an auditor will ask why telephony is open to everyone.

Detection, metrics and framework mapping

Monitor Entra audit logs for changes to the Authentication methods policy and the migration state, and alert on any change outside a change ticket, because attackers who gain admin rights may weaken MFA settings (ATT&CK T1556.006, Modify Authentication Process: Multi-Factor Authentication). Track these measures weekly:

• Migration state: migrationComplete, verified from Graph.
• Telephony dependence: users whose only registered method is phone, trending to zero.
• Telephony usage: share of MFA sign-ins completed by SMS or voice.
• Phishing-resistant coverage: percentage of administrators and all users with a passkey, Windows Hello for Business or certificate registered.
• Recovery quality: password resets by method, with security questions and SMS at zero.

Practitioner checklist

• Record the current policyMigrationState and export the Authentication methods policy JSON.
• Screenshot or export legacy per-user MFA service settings and legacy SSPR methods, scope and security questions.
• Export user registration details and list telephony-only users by name.
• Set Migration in Progress and configure each method by group, with "Use for sign-in" off for SMS.
• Split OATH into Authenticator OTP, third-party software and hardware tokens as needed.
• Run an Authenticator or passkey registration campaign with limited snoozes; enable Temporary Access Pass for onboarding.
• Remove legacy methods one at a time, testing sign-in and SSPR after each.
• Set Migration Complete, then disable security questions in legacy SSPR unless there is a documented reason.
• Apply the Phishing-resistant MFA strength to administrators through Conditional Access.
• Alert on audit log changes to the Authentication methods policy and review the metrics monthly.

Standards and references

• Microsoft Learn: Manage authentication methods for Microsoft Entra ID
• Microsoft Learn: How to migrate MFA and SSPR policy settings to the Authentication methods policy
• Microsoft Graph: authenticationMethodsPolicy resource type
• Microsoft Learn: Conditional Access authentication strengths
• Microsoft Learn: System-preferred authentication
• Microsoft Learn: Run a registration campaign
• Microsoft Learn: Authentication methods activity
• NIST: SP 800-63B-4 Authentication and Authenticator Management

Related NHI Mgmt Group resources: MFA Guide · Entra Per-User MFA to Conditional Access · Phishing-Resistant MFA Guide · Passkey Rollout Guide · Conditional Access Guide