Legacy MFA & SSPR are retiring -How to migrate MFA and SSPR settings to the Authentication methods policy
- welka2111
- 21 hours ago
- 6 min read
Introduction
Microsoft has been gently nudging us toward modernising how we handle Multifactor Authentication (MFA) and (Self-Service Password Reset) SSPR for a while now. Well, the gentle nudges are over. Come 30 September 2025, the legacy setup will be retired, and the torch will be fully passed to Authentication Methods in Microsoft Entra.
So if you’re still fiddling with the old Multi-Factor Authentication page under Active Users in admin.microsoft.com, it’s officially time to move on. The good news? The migration’s straightforward - if you know what to watch out for.
In this post, I’ll guide you through:
What authentication methods and SSPR actually are
How the new and old setups compare
A step-by-step on the migration process
Gotchas I ran into myself
Recommendations based on real-life experience
Table of contents
What are authentication methods and SSPR?
Let’s start with the basics.
Authentication methods control what users are allowed to register to prove their identity - like SMS, Authenticator app, or a fancy FIDO2 key.
Self-Service Password Reset (SSPR) lets users reset their password without IT help; assuming they’ve got the right authentication methods set up.
Here’s where people get confused: authentication methods don’t enforce anything. They just allow users to register and use them. Conditional Access is what says “you must use MFA to sign in”.
Think of authentication methods like installing a lock on your front door. It’s a great start - the hardware is in place. But just having the lock isn’t enough to stop someone from walking right in. You still need to turn the key and actually lock the door - that’s what Conditional Access does. It enforces the rules, making sure only people with the right key (i.e. the correct authentication method) can get in.
Without Conditional Access, you’ve got a door with a fancy lock... just swinging open.
The hardware’s there, but without the policy, it’s just decorative.
Available ≠ enforced.
Comparison: legacy MFA policy vs authentication method policy
If you're currently relying on the legacy MFA policy, here's how the methods you’ve been using map to the newer Authentication Methods policy in Entra:
Multifactor authentication policy | Authentication method policy |
Call to phone | Voice calls |
Text message to phone | SMS |
Notification through mobile app | Microsoft Authenticator |
Verification code from mobile app or hardware token | Third-party software OATH tokens Hardware OATH tokens Microsoft Authenticator |
Comparison: SSPR vs Entra authentication method policy
Trying to map your old setup to the new one? Here’s how SSPR methods from the old portal translate to Entra Authentication Methods:
SSPR authentication methods | Authentication method policy (Entra) |
Mobile app notification | Microsoft Authenticator |
Mobile app code | Microsoft Authenticator Software OATH tokens |
Email OTP | |
Mobile phone | Voice calls SMS |
Office phone | Voice calls |
Security questions | ❌ Not yet available (copy these for now!) |
Security questions are the odd one out here - they’re not yet supported in Entra Authentication Methods. So if you're relying on them in your current setup, take note and plan accordingly.
Where to find the current legacy MFA settings?
Navigate over to admin.microsoft.com > Users > Active Users > Multi-factor authentication > (Legacy per-user MFA) > Service settings
OR
Navigate over to entra.microsoft.com > 'Multifactor authentication' blade under the Entra ID section> under 'Configure', select 'Additional cloud-based multifactor authentication settings' > Service settings
Where to find the new authentication methods policies?
Navigate over to entra.microsoft.com > 'Authentication methods' blade under the Entra ID section > Policies
Where to find the SSPR settings?
Navigate over to entra.microsoft.com > 'Password reset' blade under the Entra ID section >
Look at 'Properties' and 'Authentication methods' sections
How to migrate MFA and SSPR policy settings to the Authentication methods policy for Microsoft Entra ID
Here's a step-by-step guide on how to migrate to authentication methods using the automated migration wizard (highly recommended):
I’ve personally used the automated migration wizard across multiple tenants, and honestly - it’s worked like a charm every time. Clean, simple, quick. No scary surprises.
This is the method I’m going to walk you through today.
Automated migration guide
The automated migration wizard lets you migrate where you manage authentication methods with just a few clicks. It lives inside the Microsoft Entra admin centre, and you can find it here: Entra ID > Authentication methods > Policies > Begin automated guide
What the wizard does?
The first page of the wizard gives you a quick overview of what’s about to happen. It also includes handy links to your existing legacy MFA and SSPR policy settings so you can double-check what’s configured before moving forward.
Next, the wizard takes a look at what your org currently has enabled in the legacy MFA and SSPR policies. It then suggests configuring the Entra Authentication Methods policy to match that setup - so users can keep signing in or resetting passwords just like they did before.
If something’s enabled in either of the old policies, the recommendation is to enable it in the new one. That way, no one suddenly loses access.
You can tweak the settings right there in the wizard - just hit the little pencil icon beside each method to edit it. And this is the perfect chance to add in more modern and secure options like:
Passkeys
Temporary Access Pass
Microsoft Authenticator (passwordless included)
Once everything looks good, hit Migrate, then confirm it by selecting Continue, and you’re off to the races.
The policy gets updated, and the legacy MFA/SSPR settings are effectively switched off (you’ll see them greyed out).
You’ll also see the migration status flip to “Migration Complete”.
If for any reason you need to roll back (maybe something broke, or you had that “uh-oh” moment), you can just change the status back to “In Progress”.
After that you'd want to make sure that you also have conditional access policies in place that enforce specific authentication methods too.
Set up Conditional Access (CA) policies to enforce MFA if you haven't already. Remember, just enabling a method doesn’t make anyone use it - CA does that job.
Gotchas – things to watch for
Even with a smooth process, a few pitfalls can trip you up:
Method mismatch = user lockouts
If a user is actively using a method like SMS, but it’s not enabled in the new Entra policy, they won’t be able to log in after migration. Make sure everything lines up before completing the move.
Passwordless might vanish
Post-migration, some users lose passwordless sign-in using the Microsoft Authenticator app. The culprit?The authentication mode is still set to “Push”.
Fix it by going to: Microsoft Entra > Entra ID > Authentication methods > Policies > Microsoft Authenticator and set the mode to “Any” to support both push notifications and passwordless.
Security questions not supported
As mentioned, SSPR security questions aren’t supported in Entra’s authentication methods… yet. Make sure you’ve got a backup plan or start phasing them out.
Recommendations – Welka’s edition
Here are my honest, real-world recommendations from the trenches:
Get ahead of the curve
Don't wait until Microsoft flips the switch for you. Doing the migration yourself now gives you control, visibility, and time to fix any quirks before they’re live. You’ll thank yourself later.
Enabling ≠ enforcing
Just because a method is enabled (e.g., Passkeys or FIDO2 keys), doesn’t mean users are forced to use it. If you want to enforce a specific method, you’ll need a Conditional Access policy that targets that method. Otherwise, it’s just sitting there waiting to be used... or ignored.
This is your chance to modernise
Use this migration as an excuse to review your MFA options and modernise. Stronger methods like Microsoft Authenticator (with passwordless), FIDO2 keys, or passkeys are miles ahead of SMS and voice calls.
In fact...
SMS and voice call MFA should be phased out where possible. They’re less secure and more vulnerable to phishing or SIM swap attacks.
Enable email OTP for guests only, and disable it for internal users. Your staff should be using more secure, primary methods.
Conclusion
This isn't just another Microsoft shuffle. The retirement of legacy MFA and SSPR policies is a clear step forward in improving identity security and streamlining how authentication is managed.
Done right, the migration is painless, and gives you more consistent control across your environment. The key is:
Understand what you’re changing
Sync the settings properly
Use conditional access to enforce what’s important
Test before switching over
Oh, and one last time for the people in the back: authentication methods allow - conditional access enforces. Don’t mix the two up.
Additional reading: