Guide: New Authentication methods policy migration

This article aims to simplify the migration from legacy MFA and SSPR policies to the new authentication methods policy in Entra ID.

While there is an official documentation from Microsoft on authentication methods policy migration, I find it is outlined in an unnecessary complicated manner in the article – I hate that it is not written in a step by step manner for migration. This guide will break down the migration into smaller steps making it easier to follow and understand.

What’s changing with authentication methods ?

Before we move forward with the migration steps to the new authentication methods policy, let’s briefly go over what is changing.

Currently, verification methods for MFA and SSPR (Self service password reset) are managed separately under two different areas in Entra ID – this is now being called the legacy settings.

• MFA method available to users is controlled via ‘Verification option’ under service settings in per-user MFA.

• SSPR methods available for users to register are controlled under authentication methods setting under ‘Password reset’ settings in Entra ID.

The above settings will be deprecated starting September, 2025. Starting September, 2025 (or as soon as you complete migration), you will be managing authentication methods available for users to register (for SSPR and MFA) under a combined policy set under the new ‘Authentication methods policy’ area in Entra ID.

The new area for managing authentication method can be found by navigating to Microsoft Entra admin center > Protection > Authentication methods > Policies.

Step by Step tutorial for moving to the new authentication methods policy

Step1 : Set migration status to ‘Migration in progress’

The first step is to set migration status to ‘Migration in progress’ under ‘Manage migration’ option for new authentication methods policy.

You can make this change blindly as your legacy policies will still be respected.

Step 2: Review and confirm what methods are needed for SSPR and MFA

Check MFA methods currently enabled under per-user MFA.

As you can see in the screenshot above, I have 2 methods enabled for user for MFA.

• SMS (Text message to phone)
• Microsoft authenticator push (Notification throgh mobile app)

Check SSPR methods enabled for users under SSPR settings

In my case, I had 3 methods available for users to use for SSPR.

• Microsoft Authenticator TOTP code
• SMS
• Security questions

I do not recommend the use of Security questions for password reset, however I wanted to include it in my example because Security questions is not available in the new authentication methods policy.

Combine methods currently enabled, then filter out, and decide what is needed under the new authentication methods policy.

I have the below methods enabled for SSPR and MFA combined in the tenant.

• SMS
• Microsoft Authenticator (Push + TOTP)
• Security questions

This will be a great time to re-evaluate your organizations policy on what methods should be available to users for MFA and SSPR. You won’t necessarily have to enable the combination of same methods above in the new authentication policy when migration is complete.

Step 3: Enable required methods under the new authentication methods policy.

I have decided to enable the below methods under the new policy for authentication methods based on step 2 results and checking organizational needs for future changes.

• SMS
• Microsoft Authenticator (Push)
• Security questions
• Third-party software OATH tokens (third party Authenticator apps like Google authenticator)

Where’s security questions ? Security questions aren’t yet available to manage in the Authentication methods policy. Keep it in SSPR settings for now.

Step 4: Disable the methods under legacy SSPR and MFA settings

Once you have enabled the required methods to be available for users to register and use under the new authentication methods, the next step is to disable the methods under old policies.

Uncheck everything under per-user MFA settings and save.

Uncheck everything except security questions (if you are still using security questions) under SSPR methods settings. If your environment is not allowing users to use security questions or wish not to use anymore, uncheck security questions option as well.

Step 5: Final step – complete the migration to the new authentication methods policy.

Before setting migration to complete, the only question you should be worried about answering should be the one below.

• Do you have enabled enough methods under the new authentication methods policy so that users can do MFA and SSPR with it ?

Make sure to check out to the Microsoft learn article with table showing which methods are usable for MFA and which are usable for SSPR.

To change the migration status to complete,

1. Go to Microsoft Entra admin centre > Browse to Protection > Authentication methods and choose ‘change‘ under Migration status
2. Set status to ‘Migration complete‘
3. Choose Save.

That’s it – migration to the new authentication methods policy is done. Your tenant will now be following the settings for authentication methods under the new policy.

Housekeeping

Number of methods required for SSPR

If you have set the number of methods required for password reset to 2, please make sure that you have enabled atleast two methods capable of SSPR in the new authentication methods policy.

Authenticator OTP

In the legacy MFA settings, the option to use OTP code from Microsoft Authenticator app and use of third party authenticator apps was combined to a single option ‘Verification code from mobile app or hardware token’.

However, in the new authentication methods policy, you have a separate control to allow or disable the use of verification code from Microsoft authentication app.

In my example above, my legacy SSPR settings had the use of Microsoft Authenticator OTP (mobile app code). However, I decided to disable it in the new authentication methods policy for Microsoft Authenticator.