{ "api_version": "1", "kind": "dse_post", "self": "https://update.dsesecurity.com/api/v1/posts/entra-authentication-methods-policy-migration/", "item": { "id": "https://update.dsesecurity.com/updates/entra-authentication-methods-policy-migration/", "slug": "entra-authentication-methods-policy-migration", "url": "https://update.dsesecurity.com/updates/entra-authentication-methods-policy-migration/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/entra-authentication-methods-policy-migration.md", "json": "https://update.dsesecurity.com/api/v1/posts/entra-authentication-methods-policy-migration/" }, "title": "Finish authentication-method policy migration without opening a sign-in gap", "summary": "Microsoft's authentication methods migration moves MFA and self-service password reset method control into one policy, with transitional states that require an exact before-and-after comparison.", "format": { "slug": "checklist", "name": "Checklist" }, "priority": { "slug": "important", "name": "Important" }, "featured": false, "image": { "theme": "identity-cloud", "label": "Identity & cloud", "alt": "Governed cloud identity system with connected service and lifecycle nodes.", "card_url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" }, { "slug": "microsoft-365-identity", "name": "Microsoft 365 & Identity", "url": "https://update.dsesecurity.com/topic/microsoft-365-identity/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-08-25T21:35:29+00:00", "modified_at": "2026-08-25T21:36:18+00:00", "reviewed_on": "2026-08-25", "reading_minutes": 3, "word_count": 494, "potentially_affected": "Microsoft Entra tenants with authentication methods still represented in legacy MFA or self-service password reset policy settings.", "dse_recommendation": "Inventory effective legacy and modern method scope, enter migration deliberately, test sign-in and recovery populations, and preserve evidence before selecting Migration Complete.", "primary_source": { "name": "How to migrate to the Authentication methods policy", "url": "https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-authentication-methods-manage", "published_on": null, "authority": "Microsoft Learn" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "

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.

\n

Source fact: what Microsoft documents

\n

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.

\n

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.

\n

What the source does not establish

\n

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.

\n

Applicability questions

\n\n

DSE recommendation: controlled next steps

\n

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

\n
    \n
  1. Export or document every relevant legacy and modern setting, target group, exclusion, and registered-method report before changing migration state.
    2. \n
  2. Build an effective-state matrix showing whether each method is intended for authentication, SSPR, or both for each population.
    3. \n
  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. \n
  4. Test new registration, normal sign-in, MFA challenge, password reset, lost-device recovery, helpdesk recovery, and emergency administration.
    5. \n
  5. Select Migration Complete only after discrepancies are resolved and a rollback decision has been documented.
    6. \n
\n

Verification and evidence

\n\n

Official references

\n", "content_text": "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.\nSource fact: what Microsoft documents\nMicrosoft’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.\nThe 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.\nWhat the source does not establish\nThe 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.\nApplicability questions\n\nWhat methods are enabled in the legacy MFA policy, legacy SSPR policy, and Authentication methods policy, and for which populations?\nWhich users depend on SMS, voice, security questions, hardware tokens, certificates, passkeys, or Microsoft Authenticator?\nAre administrators, guests, frontline workers, shared-device users, and emergency accounts tested separately?\nWhich Conditional Access and authentication-strength policies depend on a method being registered and usable?\nWhat current Microsoft migration state and licensing apply to the tenant?\n\nDSE recommendation: controlled next steps\nThe following steps are DSE recommendations based on the cited source.\n\nExport or document every relevant legacy and modern setting, target group, exclusion, and registered-method report before changing migration state.\nBuild an effective-state matrix showing whether each method is intended for authentication, SSPR, or both for each population.\nEnter Migration in progress and reproduce the desired method scope in controlled groups. Avoid broad enablement merely to make the matrices look equal.\nTest new registration, normal sign-in, MFA challenge, password reset, lost-device recovery, helpdesk recovery, and emergency administration.\nSelect Migration Complete only after discrepancies are resolved and a rollback decision has been documented.\n\nVerification and evidence\n\nPreserve before-and-after policy exports or screenshots and the migration-state change record.\nRecord test identities, method registrations, sign-in results, SSPR results, and relevant sign-in log details.\nCompare intended groups with users enabled by each method policy and investigate unexpected overlap.\nSchedule a post-change review for failed registration, MFA, and SSPR events and helpdesk volume.\n\nOfficial references\n\nHow to migrate to the Authentication methods policy — Microsoft", "content_markdown": "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.\n\n## Source fact: what Microsoft documents\n\nMicrosoft’s [migration guide](https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-authentication-methods-manage) 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.\n\nThe 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.\n\n## What the source does not establish\n\nThe 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.\n\n## Applicability questions\n\n- What methods are enabled in the legacy MFA policy, legacy SSPR policy, and Authentication methods policy, and for which populations?\n\n- Which users depend on SMS, voice, security questions, hardware tokens, certificates, passkeys, or Microsoft Authenticator?\n\n- Are administrators, guests, frontline workers, shared-device users, and emergency accounts tested separately?\n\n- Which Conditional Access and authentication-strength policies depend on a method being registered and usable?\n\n- What current Microsoft migration state and licensing apply to the tenant?\n\n## DSE recommendation: controlled next steps\n\nThe following steps are DSE recommendations based on the cited source.\n\n- Export or document every relevant legacy and modern setting, target group, exclusion, and registered-method report before changing migration state.\n\n- Build an effective-state matrix showing whether each method is intended for authentication, SSPR, or both for each population.\n\n- Enter Migration in progress and reproduce the desired method scope in controlled groups. Avoid broad enablement merely to make the matrices look equal.\n\n- Test new registration, normal sign-in, MFA challenge, password reset, lost-device recovery, helpdesk recovery, and emergency administration.\n\n- Select Migration Complete only after discrepancies are resolved and a rollback decision has been documented.\n\n## Verification and evidence\n\n- Preserve before-and-after policy exports or screenshots and the migration-state change record.\n\n- Record test identities, method registrations, sign-in results, SSPR results, and relevant sign-in log details.\n\n- Compare intended groups with users enabled by each method policy and investigate unexpected overlap.\n\n- Schedule a post-change review for failed registration, MFA, and SSPR events and helpdesk volume.\n\n## Official references\n\n- [How to migrate to the Authentication methods policy](https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-authentication-methods-manage) — Microsoft" }, "json_ld": { "@context": "https://schema.org", "@graph": [ { "@type": "Organization", "@id": "https://dsesecurity.com/#organization", "name": "Detection Systems & Engineering", "alternateName": "DSE Security", "url": "https://dsesecurity.com/", "logo": { "@type": "ImageObject", "url": "https://update.dsesecurity.com/assets/dse-logo-20260812.png?v=1.8.20" } }, { "@type": "Organization", "@id": "https://update.dsesecurity.com/#editorial-team", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/", "parentOrganization": { "@id": "https://dsesecurity.com/#organization" } }, { "@type": "WebSite", "@id": "https://update.dsesecurity.com/#website", "name": "DSE Updates", "alternateName": "DSE Security Knowledge Hub", "url": "https://update.dsesecurity.com/", "inLanguage": "en-US", "publisher": { "@id": "https://dsesecurity.com/#organization" }, "potentialAction": { "@type": "SearchAction", "target": { "@type": "EntryPoint", "urlTemplate": "https://update.dsesecurity.com/?q={search_term_string}" }, "query-input": "required name=search_term_string" } }, { "@type": "WebPage", "@id": "https://update.dsesecurity.com/updates/entra-authentication-methods-policy-migration/", "url": "https://update.dsesecurity.com/updates/entra-authentication-methods-policy-migration/", "isPartOf": { "@id": "https://update.dsesecurity.com/#website" }, "lastReviewed": "2026-08-25" }, { "@type": "BreadcrumbList", "@id": "https://update.dsesecurity.com/updates/entra-authentication-methods-policy-migration/#breadcrumbs", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "DSE Updates", "item": "https://update.dsesecurity.com/" }, { "@type": "ListItem", "position": 2, "name": "Finish authentication-method policy migration without opening a sign-in gap", "item": "https://update.dsesecurity.com/updates/entra-authentication-methods-policy-migration/" } ] }, { "@type": [ "Article", "TechArticle" ], "@id": "https://update.dsesecurity.com/updates/entra-authentication-methods-policy-migration/#article", "identifier": "https://update.dsesecurity.com/updates/entra-authentication-methods-policy-migration/", "url": "https://update.dsesecurity.com/updates/entra-authentication-methods-policy-migration/", "headline": "Finish authentication-method policy migration without opening a sign-in gap", "description": "Microsoft's authentication methods migration moves MFA and self-service password reset method control into one policy, with transitional states that…", "abstract": "Microsoft's authentication methods migration moves MFA and self-service password reset method control into one policy, with transitional states that require an exact before-and-after comparison.", "articleBody": "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.\nSource fact: what Microsoft documents\nMicrosoft’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.\nThe 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.\nWhat the source does not establish\nThe 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.\nApplicability questions\n\nWhat methods are enabled in the legacy MFA policy, legacy SSPR policy, and Authentication methods policy, and for which populations?\nWhich users depend on SMS, voice, security questions, hardware tokens, certificates, passkeys, or Microsoft Authenticator?\nAre administrators, guests, frontline workers, shared-device users, and emergency accounts tested separately?\nWhich Conditional Access and authentication-strength policies depend on a method being registered and usable?\nWhat current Microsoft migration state and licensing apply to the tenant?\n\nDSE recommendation: controlled next steps\nThe following steps are DSE recommendations based on the cited source.\n\nExport or document every relevant legacy and modern setting, target group, exclusion, and registered-method report before changing migration state.\nBuild an effective-state matrix showing whether each method is intended for authentication, SSPR, or both for each population.\nEnter Migration in progress and reproduce the desired method scope in controlled groups. Avoid broad enablement merely to make the matrices look equal.\nTest new registration, normal sign-in, MFA challenge, password reset, lost-device recovery, helpdesk recovery, and emergency administration.\nSelect Migration Complete only after discrepancies are resolved and a rollback decision has been documented.\n\nVerification and evidence\n\nPreserve before-and-after policy exports or screenshots and the migration-state change record.\nRecord test identities, method registrations, sign-in results, SSPR results, and relevant sign-in log details.\nCompare intended groups with users enabled by each method policy and investigate unexpected overlap.\nSchedule a post-change review for failed registration, MFA, and SSPR events and helpdesk volume.\n\nOfficial references\n\nHow to migrate to the Authentication methods policy — Microsoft", "datePublished": "2026-08-25T21:35:29+00:00", "dateModified": "2026-08-25T21:36:18+00:00", "mainEntityOfPage": { "@id": "https://update.dsesecurity.com/updates/entra-authentication-methods-policy-migration/" }, "inLanguage": "en-US", "isAccessibleForFree": true, "author": { "@type": "Organization", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team" }, "publisher": { "@id": "https://dsesecurity.com/#organization" }, "image": { "@type": "ImageObject", "@id": "https://update.dsesecurity.com/updates/entra-authentication-methods-policy-migration/#primaryimage", "url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-social-v2.jpg?v=1.8.20", "contentUrl": "https://update.dsesecurity.com/assets/editorial/identity-cloud-social-v2.jpg?v=1.8.20", "width": 1200, "height": 630, "caption": "Finish authentication-method policy migration without opening a sign-in gap" }, "articleSection": [ "Cybersecurity", "IT", "Microsoft 365 & Identity" ], "keywords": [ "Cybersecurity", "IT", "Microsoft 365 & Identity", "Checklist", "Important priority" ], "genre": "Checklist", "about": [ { "@type": "Thing", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "@type": "Thing", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" }, { "@type": "Thing", "name": "Microsoft 365 & Identity", "url": "https://update.dsesecurity.com/topic/microsoft-365-identity/" } ], "wordCount": 494, "timeRequired": "PT3M", "publishingPrinciples": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usageInfo": "https://update.dsesecurity.com/usage/", "copyrightHolder": { "@id": "https://dsesecurity.com/#organization" }, "copyrightNotice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "citation": { "@type": "CreativeWork", "name": "How to migrate to the Authentication methods policy", "url": "https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-authentication-methods-manage" } } ] } }