Three MFA Policies Become One: Migrating to the Entra Authentication Methods Policy Before the Deadline
TL;DR
- Beginning September 30, 2025, authentication methods can no longer be managed in the legacy per-user MFA and SSPR policies in Microsoft Entra.
- The Authentication methods policy replaces three overlapping policies and supports modern methods like passwordless authentication.
- Until migration, Entra evaluates the new policy first, then the legacy MFA policy, then the legacy SSPR policy to decide what a user can register.
- Microsoft ships a migration wizard on the Authentication methods page so admins control the cutover tenant by tenant.
- Most end users notice nothing after migration, unless their only registered method is one you disable in the new policy.
Microsoft gave this deprecation a long runway. The announcement came in March 2023, and the deadline arrived on September 30, 2025: authentication methods can no longer be managed in the legacy multifactor authentication and self-service password reset (SSPR) policies. Any tenant still leaning on those screens needs to move to the consolidated Authentication methods policy.
Here is where the legacy settings live, what replaces them, and how to run the migration with your customers without surprising any end users.
Where do the legacy settings live?
Per-user MFA. These settings were how everyone used to manage which authentication methods a user could pick when setting up multifactor: SMS, phone call, Authenticator, and so on. Location: Entra ID Admin Center > Multifactor authentication > Getting started > Configure > Additional cloud-based multifactor authentication settings > Service Settings.
Self-service password reset. SSPR methods are managed separately under Entra ID > Password reset > Authentication methods. In this policy, the Mobile phone option allows either voice calls or text messages, while the Office phone option allows voice calls only.
Why three policies were always a problem
Until now, Entra decided whether a user could register a given MFA method by walking a chain. It checked the Authentication methods policy first. If the method was not allowed there, registration fell back to the legacy MFA policy. If that also failed for Microsoft Authenticator, it checked the legacy SSPR policy last.
Three policies, three places for a setting to hide, three chances for two admins to disagree without knowing it. Clunky is the polite word.
The replacement: one Authentication methods policy
Microsoft is consolidating everything into the single Authentication methods policy at Entra ID Admin Center > Authentication methods > Policies. It is the recommended way to manage authentication methods going forward, including modern methods like passwordless authentication.
Authentication Policy Administrators (opens in new tab) can edit the policy to enable methods for all users or for specific groups, which the legacy screens never handled well. Reference: Manage authentication methods in Microsoft Entra ID (opens in new tab).
How do you run the migration?
Microsoft built a migration tool directly into the Authentication methods page so you control the rollout tenant by tenant.
The wizard walks you through selecting which authentication methods should be available once the legacy policies stop being consulted.
Before you click through it, pull up Entra ID Admin Center > Authentication Methods > User Registration Details and check what users have actually registered. The only migration risk is disabling a method that is somebody's only method, and that report tells you who is exposed before they find out at sign-in.
Frequently asked questions
What happens to end users after the migration?
In most cases, nothing. The exception is a user whose only registered MFA method is one you disable in the new policy. For example, if a user's only method is SMS and you turn SMS off, their next sign-in forces registration of an enabled method such as Authenticator. Check primary methods under Entra ID Admin Center > Authentication Methods > User Registration Details before you cut over.
Are per-user MFA states like Enabled and Enforced going away?
No. As of September 2025 there are no changes to enforcing MFA through the per-user settings (Disabled, Enabled, Enforced). The deprecation covers managing authentication methods in the legacy policies, not the per-user enforcement states.
Do App passwords and Trusted IPs still work?
Yes, both remain. Microsoft's recommendation, and ours, is to move that logic into Conditional Access instead of relying on legacy carve-outs.
What about security questions for SSPR?
Security questions are not yet supported in the new Authentication methods policy. You can still manage and modify them in the legacy view for now; Microsoft says support is being moved over.
Catch the tenants that never migrated
A deprecation deadline is exactly how configuration drift happens: some tenants migrate, some quietly do not. CloudCapsule checks MFA and authentication method controls across every tenant you manage, 250+ controls in about 60 seconds each.
Run a free scan
Written by
Nick Ross
CEO · Microsoft MVP · Founder, T-Minus 365
Nick is not just a CEO, he's a respected thought leader and influencer in the MSP space. Tens of thousands of MSPs learn through his YouTube channel, T-Minus365. Nick has been honored as a three-time Microsoft MVP for his educational content; his expertise and influence are the backbone of our mission, ensuring that you are in the best hands when it comes to security.
Nick joined Pax8 in 2017, where he would ultimately oversee product management for PSA and Microsoft integrations. Following his tenure at Pax8, Nick has continued to demonstrate his leadership prowess as an executive at various MSPs, culminating in his most recent role at Sourcepass.
Nick holds a Bachelor's Degree in Business Management from Florida State University, as well as a Minor Degree in Entrepreneurship. In his free time, Nick is an avid hiker, reader, and fitness-junkie.
