Almost every tenant I work in has had the MFA SSPR migration deadline warning sitting in the Entra admin center banner for months. That grace period is now ending. On September 30, 2025, the old multifactor authentication and self-service password reset policies are retired for good. After that date, the Authentication methods policy alone decides which sign-in and password reset methods your users can use. If the migration isn't finished yet, there's not much time left to do it calmly and without disruption.

Your migration state shows how far the tenant has come

You'll find the authentication methods migration state in the Microsoft Entra admin center under Protection → Authentication methods → Policies → Manage migration. It shows one of three values (Pre-migration, Migration in progress or Migration complete), and you need at least the Authentication Policy Administrator or Global Administrator role to see it. Plenty of environments I look at are still in pre-migration, which is a real risk this close to the deadline. The state isn't just cosmetic. A tenant that's only half migrated can give users inconsistent behavior at sign-in or during SSPR. Microsoft documents the new logic in detail here: Authentication methods – Overview.

flowchart TD
    PreMigration["Pre-migration"] --> MigrationInProgress["Migration in progress"]
    MigrationInProgress --> MigrationComplete["Migration complete"]
    MigrationComplete --> OnlyNewPolicy["Only new policy active"]

Figure: Stages and effects of the MFA SSPR migration deadline in Entra ID

Legacy settings and the new policy often differ in the details

In many tenants, the legacy MFA service settings and the SSPR policies were managed separately, and that's usually where the surprises come from. The new Authentication methods policy brings both together, but it doesn't pull over every legacy setting automatically. A typical case: Authenticator app and SMS were allowed for MFA, while SSPR only allowed email. In the new policy you have to define each method and its target explicitly. Before changing anything, document your old settings in whatever form suits you (screenshots, notes) and then go through them one by one against the new policy. Microsoft's how-to guide for managing authentication methods helps a lot with that step-by-step review.

My tip from client projects: First, activate all required methods in the new policy as "enabled but not enforced" for pilot groups. Only move to full enforcement after a targeted pilot.

I follow a fixed sequence for a safe migration

This is the order that has worked best for me:

  • Check your migration state in the Entra admin center
  • Compare legacy MFA/SSPR settings with the new policy
  • Enable all relevant authentication methods for target groups in the new policy
  • Test enforcement with a pilot group and review the user experience
  • Launch a registration campaign for all users (see my detailed post here)

I wouldn't skip the registration campaign. It prompts users to register or re-register their methods, which clears out stale data and saves you from a lot of annoying support tickets.

Doing nothing leaves users without working methods

Once the MFA SSPR migration deadline has passed, Entra ID ignores every legacy MFA and SSPR setting, and only the Authentication methods policy applies. Any method you haven't explicitly enabled there stops working for users, whether it's SMS for MFA or phone for password reset. I've seen this go badly: entire groups suddenly couldn't complete MFA or SSPR because their method never made it into the new policy. In hybrid environments, on-premises users can be hit as well if their password reset depended on methods that were only allowed in the legacy settings. That's not something you want to find out when people are already locked out.

A late migration still works if you start now

If you've put the migration off until now, you're in good company, but please don't push it any further. Use Microsoft's authentication methods management concepts and what I learned during the January 2024 preview (see this post) as your checklist. Check the state, line up your methods, roll out the new policy with pilot groups first and turn on the registration campaign so the switch goes smoothly before the deadline.