If you’re experiencing inconsistent behaviour with your authentication method registration or the use of authentication methods for multi-factor authentication (MFA) or self-service password reset (SSPR), this article might be for you.
The groundwork
Have you inherited the administration duties for your organization’s Entra ID tenant that’s been around for a “while”? If yes, there’s a possibility that you’re running an authentication method configuration that may seem to produce confusing results. This behaviour has an explanation and stems from Microsoft centralizing the authentication methods policies into unified management. Now, this is not exactly news anymore and Microsoft announced April 14th 2023 that legacy policies that separately managed MFA and SSPR authentication methods will be deprecated on September 30th 2024. The deprecation date has since been rescheduled and is now September 30th 2025. This is the date that is also reflected in the Microsoft Learn documentation and on Microsoft Entra Admin Center.
Legacy policies
With legacy policies Microsoft refers to authentication methods managed on Entra ID Password reset > Authentication methods for SSPR and Per-user MFA site hosted at https://account.activedirectory.windowsazure.com/… You can find a link to this legacy site from Entra ID Users > All Users > Per-user MFA.
Notice the information block telling us that there is a converged policy to managed both SSPR and sign-in authentication methods. Below you can see how to navigate to the other legacy management from the Entra ID Users blade.
Per-user MFA
This is Microsoft’s original, now very very legacy, way to manage user’s multi-factor authentication, among some other things that are not in the scope of the topic here. This might be surprising to some, but the settings here might still be valid depending on your authentication method migration state.
Unified authentication method policies
We went through the legacy policies and now we’re going to take a look at the superseding method to manage authentication policies. Let’s again dive into the Entra ID admin center: Identity > Protection > Authentication methods.
I mentioned earlier that there is an authentication method migration state and you can check yours from the portal link highlighted in red underline above. It will open a flyout menu from the right. There are three different states: Pre-migration, Migration In Progress and Migration Complete.
- Pre-migration: Use policy for authentication only, respect legacy policies
- Migration In Progress: Use policy for authentication and SSPR, respect legacy policies
- Migration Complete: Use policy for authentication and SSPR, ignore legacy policies
Note! In order to save yourself from a ton of calls from users, don’t change the migration state just yet. First, you need to gather some information about the state of registered methods, MFA and SSPR capable users (especially users who are not capable) and what MFA methods your organization is requiring in your Conditional Access policies.
If you’re utilizing Authentication Strengths it might be that some users do not have required authentication methods registered. Study your situation well before making sudden changes!
To map your current situation you should spend some time analysing User registration details report (under ‘Authentication methods’ blade). Report lets you use diverse filtering and for further analysis you can get the data exported in .csv format from where you can load it into Power BI or just use Excel. Once you are confident that the MFA and SSPR registrations are in order you can move on to check if you’re using Authentication Strengths (still under the same blade). If you are, you might have limited the available methods for some users or for specific login situations. For reference, check what authentication method combinations belong to which built-in authentication strength from this document. You might also have custom Authentication Strengths, so pay attention when gathering the requirements for allowed methods.
When you move on with the authentication method migration you might end up excluding methods that you have not yet enabled using the unified authentication method management. To avoid this, first configure the desired allowed authentication methods using the unified experience so that you’re covering the required authentication methods that you’re demanding from users in your Authentication Strengths used by Conditional Access policies.
Moving on with the migration
In order to move to ‘Migration In Progress’ state, you need to understand the difference in terminology between legacy and unified authentication managements. Below tables explain how to map old setting (left) to the new setting (right). Some old settings have been divided into multiple more fine-grained policies.
| Per-user MFA authentication method policy | Unified 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 |
| SSPR authentication method policy | Unified authentication method policy |
| 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 questions for later use |
Assuming your migration state is Pre-migration, your configuration at the moment is a sweet mesh of all the configured authentication methods regardless of where they are managed or if they are legacy or not. Once you change the state to Migration In Progress your configuration is still a sweet mesh like before, but you’ve now allowed users to use new converged policies for SSPR also, still honouring all the legacy policies. But when you move to Migration Complete you no longer honour any of the legacy policies, which is why you should first enable wanted methods from unified authentication methods management. Notice that you’ll have to disable all authentication methods from legacy controls before you’re allowed to move to Migration Complete state.
Example: You have ‘Mobile phone’ SSPR legacy method and ‘Text message to phone’ Per-user MFA method enabled currently, but from Unified management you don’t have SMS enabled, but you have ‘Voice call’ enabled. Once you move on to ‘Migration complete’ state, users cannot use SMS as authentication method anymore, but they can still use voice calls.
Note! I’m strongly advising against enabling weaker authentication methods like security questions, SMS or voice calls. The migration presents a great opportunity to review and deprecate organizational weak authentication methods. Think 5 years ahead into the future; maybe your company policy will be going passwordless by then. Lay down the groundwork now while also making authentication more secure.
Your goal should be to ditch the legacy controls altogether and end up to Migration complete meaning that you’ll use only the unified authentication method management.
Rollback
A thorough review before starting the migration is advised to avoid unexpected situations, but humane mistakes happen. Luckily at any given point you can rollback from Migration Complete state to an earlier state respective to what that state was. If you rollback, expect Microsoft to ask you why did you decided to roll back.
Summary
That’s it! There are lots of related topics regarding Conditional Access, Registration Campaigns and Authentication Strengths, but those can be delved into another time.
In order to manage successful and pain-free migration put effort into pre-migration activities, reviewing current available methods across both legacy controls then mapping those controls to the new unified management while not forgetting to check the authentication method registration state in your organization to form a bigger picture that might in some cases need to be resolved before going into migration at all. Also remember to correlate available authentication methods and methods required by the authentication strengths.
Migration checklist:
- Review Per-user MFA authentication methods
- Review SSPR authentication methods
- Make gap analysis of methods you want to allow going forward and currently allowed methods
- Correlate above analysed methods with Authentication Strengths used in Conditional Access
- Address possible gap issues between methods required and configured available
- Analyse authentication method adoption in your organization using User registration details report page
- Address any issues found
- Configure unified management with methods you want to allow based on previous analysis work
- Soar through the migration states like a pro
Stay secure!
