Finish authentication-method policy migration without opening a sign-in gap

Bottom line: Microsoft provides migration states for moving authentication-method administration from legacy multifactor authentication and self-service password reset settings to the Authentication methods policy. During transition, more than one policy can affect a user. Migration should begin with an effective-state inventory and end only after both sign-in and recovery tests prove the intended result.

Source fact: what Microsoft documents

Microsoft’s migration guide tells administrators to capture the methods available in current legacy policies, select Migration in progress, and configure the Authentication methods policy to match the intended state. Microsoft explains that a method enabled in both legacy policies should be represented for the intended users in the modern policy, while methods disabled in both should remain disabled.

The broader Microsoft documentation defines migration states. In Migration in progress, the Authentication methods policy can govern authentication and password reset while legacy settings are still respected. In Migration Complete, only the Authentication methods policy is used for supported method management and the legacy method settings are ignored. Microsoft calls out remaining legacy SSPR controls and method-specific exceptions, so administrators must read the current page rather than assuming every setting moves identically.

What the source does not establish

The guide does not know which users have registered which methods, whether those methods satisfy an organization’s authentication requirements, or whether a user can complete recovery without helpdesk intervention. It does not prove that Conditional Access, authentication strengths, registration campaigns, guest policies, or break-glass access remain correct after the method-policy change.

Applicability questions

• What methods are enabled in the legacy MFA policy, legacy SSPR policy, and Authentication methods policy, and for which populations?
• Which users depend on SMS, voice, security questions, hardware tokens, certificates, passkeys, or Microsoft Authenticator?
• Are administrators, guests, frontline workers, shared-device users, and emergency accounts tested separately?
• Which Conditional Access and authentication-strength policies depend on a method being registered and usable?
• What current Microsoft migration state and licensing apply to the tenant?

DSE recommendation: controlled next steps

The following steps are DSE recommendations based on the cited source.

1. Export or document every relevant legacy and modern setting, target group, exclusion, and registered-method report before changing migration state.
2. Build an effective-state matrix showing whether each method is intended for authentication, SSPR, or both for each population.
3. Enter Migration in progress and reproduce the desired method scope in controlled groups. Avoid broad enablement merely to make the matrices look equal.
4. Test new registration, normal sign-in, MFA challenge, password reset, lost-device recovery, helpdesk recovery, and emergency administration.
5. Select Migration Complete only after discrepancies are resolved and a rollback decision has been documented.

Verification and evidence

• Preserve before-and-after policy exports or screenshots and the migration-state change record.
• Record test identities, method registrations, sign-in results, SSPR results, and relevant sign-in log details.
• Compare intended groups with users enabled by each method policy and investigate unexpected overlap.
• Schedule a post-change review for failed registration, MFA, and SSPR events and helpdesk volume.

Official references

• How to migrate to the Authentication methods policy — Microsoft