The authentication methods policy: migrate, clean up and enforce the right methods
For years, Entra ID authentication methods were configured in two separate places: the legacy MFA portal and the self-service password reset settings. The unified authentication methods policy ends that split. The migration is also the right moment to get rid of weak methods.
Why a unified policy
With the old settings, a method disabled for MFA could remain allowed for SSPR, and vice versa. The result was hard-to-read configurations and weak methods that lingered without anyone noticing. The authentication methods policy brings everything together: for each method you decide whether it is enabled, for which groups and with which settings.
Microsoft has announced the end of method management in the legacy MFA and SSPR policies. If your tenant does not yet show the "Migration complete" state, treat it as a priority; check the current status in the portal.
Migrating without breaking things
The portal offers a three-step migration state: pre-migration, migration in progress, migration complete. During the intermediate phase both configurations are honoured, so you can reproduce your existing setup in the new policy before switching the old one off. A sensible approach:
- inventory the methods actually in use with the authentication methods activity report;
- recreate the required methods in the unified policy, targeting groups rather than all users where appropriate;
- switch to "migration in progress" and monitor sign-ins;
- complete the migration, then remove per-user MFA states ("Enabled", "Enforced") in favour of Conditional Access.
Disabling SMS and voice
SMS and voice calls remain exposed to SIM swapping, interception and, above all, real-time phishing. They should no longer be primary methods. Before disabling them, identify the populations that still rely on them (staff without a corporate smartphone, contractors) and plan an alternative: Microsoft Authenticator, a FIDO2 security key, or a Temporary Access Pass for onboarding.
Mind SSPR. If SMS is the only reset method registered for part of your users, disabling it will cut them off from self-service password reset. Check the coverage of alternative methods before switching it off.
Registration campaigns and system-preferred MFA
A registration campaign prompts users at sign-in to register Microsoft Authenticator if they still rely on a weaker method. You can target it, limit how many times users may snooze it and exclude specific groups. It is a simple way to move the user base forward without manual effort.
System-preferred MFA, which is Microsoft-managed, automatically presents the strongest method a user has registered rather than the one they chose as default. It stops users who already have Authenticator from receiving SMS codes out of habit.
Going further: authentication strengths
The methods policy defines what is allowed; authentication strengths, used in Conditional Access, define what is required for a given resource. Together they let you, for example, require a phishing-resistant method for administrators while keeping Authenticator for everyone else.
Where to start
- Check the tenant's migration state.
- Use the methods activity report to measure reliance on SMS and voice.
- Launch a targeted Authenticator registration campaign.
- Plan the removal of weak methods, group by group.