Enablement
Defines which users or groups may register and use a method. Record includes, excludes, authentication mode, method-specific configuration, and the effective overlap with legacy controls.
Microsoft Entra identity control migration
Microsoft Entra Authentication Methods Policy Migration Guide
Consolidate legacy multifactor authentication and self-service password reset controls into the Microsoft Entra Authentication methods policy without stranding users, weakening recovery, or losing proof of what changed.
Migration objective
Unify policy administration without confusing enablement, registration, and enforcement
The Authentication methods policy is Microsoft’s recommended control plane for modern methods and targeted groups. Migration is not merely a portal toggle. A user may be enabled by the Authentication methods policy, the legacy MFA service settings, or the legacy SSPR policy, and Microsoft Entra respects applicable settings while migration is in progress. A method is not truly removed until it is disabled in every policy that can still authorize it.
Registration
Shows what credentials users actually possess and whether those credentials are usable. Registered does not mean enabled; enabled does not mean registered; neither alone proves the user can complete a required journey.
Enforcement
Conditional Access and authentication strengths decide when MFA is required and which method combinations satisfy the requirement. Keep this separate from method availability and registration campaigns.
Important boundary: Microsoft’s migration guide moves tenant policy settings; it does not migrate individual per-user MFA settings. Inventory per-user enforcement state, default methods, exclusions, service accounts, emergency access accounts, federation or NPS dependencies, and noninteractive authentication separately.
Policy state model
Use the migration state as a controlled checkpoint, not a finish button
Document who can change the state, the approved window, before-and-after exports, pilot acceptance criteria, rollback authority, and the maximum acceptable help-desk impact. Do not set Migration Complete until each method, user population, recovery path, and dependent application has passed.
Pre-migration
The Authentication methods policy is used for authentication while legacy policy settings remain respected. Capture the full baseline here and reconcile overlaps before expanding scope.
Migration in Progress
The Authentication methods policy applies to authentication and SSPR while legacy settings are still respected. This is the practical state for method-by-method targeting, pilot validation, and reversible remediation.
Migration Complete
Only the Authentication methods policy governs authentication and SSPR, with the documented exception of remaining security-question handling. Legacy methods are ignored. The state can be returned to In Progress if rollback is required.
Current-state evidence
Capture every place that can authorize, satisfy, or interrupt authentication
Use read-only exports and screenshots with UTC timestamps, tenant ID, reviewer, role, source path, and file hash. Include representative users rather than relying only on tenant summary totals. Authentication-method reports can have reporting latency, so preserve the report’s last-updated value and corroborate critical users directly.
| Control or evidence source | Capture before change | Migration question | Validation evidence |
|---|---|---|---|
| Legacy MFA service settings | Call, SMS, mobile notification, verification code, remember-MFA settings, trusted IPs, fraud-alert behavior, and tenant-wide scope. | Which settings have a direct modern equivalent, and which require a separate Conditional Access or operational decision? | Before/after screenshots, mapped method configuration, test sign-ins, audit events, and approved retirement record. |
| Legacy SSPR policy | Population, number of methods required, mobile app, phone, email, office phone, security questions, notifications, customization, and writeback. | Will the modern method support the same reset journey for members, admins, guests, remote users, and users without a managed phone? | Successful and failed reset tests, registration evidence, writeback result where applicable, notifications, and help-desk escalation. |
| Authentication methods policy | Every method’s state, target groups, exclusions, authentication mode, OTP setting, SMS sign-in, voice configuration, passkey restrictions, TAP lifetime, and CBA rules. | Are targets simple enough to explain and below policy-size limits? Are users accidentally enabled by overlapping groups? | Policy export, effective user samples, registered/usable methods, audit log, and target-group ownership. |
| User registrations and activity | MFA capable, passwordless capable, SSPR registered/enabled/capable, methods registered, registration events, sign-in usage, failures, and last-updated time. | Can every scoped user satisfy both routine sign-in and recovery after legacy methods are removed? | Pilot cohort dashboard, real journeys, sign-in details, reset events, registration failures, and exception register. |
| Conditional Access | MFA grants, authentication strengths, register-security-information policy, exclusions, report-only output, named locations, device conditions, client apps, and session controls. | Does the policy require a method users are both enabled and registered to use? Are emergency and onboarding paths safe? | What If results, report-only logs, controlled enforcement tests, required strength, method used, token claim, and break-glass monitoring. |
| Dependent systems | NPS extension, AD FS adapter, VPN, VDI, RADIUS, legacy clients, service desks, federation, third-party MFA, HR onboarding, kiosks, and offline scenarios. | Does each dependency support number matching, modern MFA, passkeys, certificate authentication, recovery, and current server versions? | Named owner, supported path, test result, defect, remediation date, fallback, and business acceptance. |
Method mapping
Translate legacy labels into modern controls without broadening access by accident
| Legacy capability | Modern control | Decision to record | Common trap |
|---|---|---|---|
| Mobile app notification | Microsoft Authenticator | Target population, push versus passwordless mode, application and location context, registration campaign, and support model. | Assuming every Authenticator registration has push configured; OTP-only registrations and third-party apps need separate review. |
| Verification code from app or token | Authenticator OTP, third-party software OATH, and hardware OATH controls | Separate each token type, inventory seeds/devices, assign custodians, and define loss/replacement procedures. | Treating one legacy checkbox as one modern method and disabling a valid OTP path prematurely. |
| Text message / mobile phone | SMS | Use for MFA, SSPR, or SMS sign-in; identify exceptions and a plan toward stronger methods. | Leaving SMS sign-in enabled unintentionally or assuming SMS satisfies a phishing-resistant authentication strength. |
| Call to phone / office phone | Voice calls | Mobile versus office phone, supported populations, accessibility needs, and replacement roadmap. | Removing office-phone recovery before users can complete another supported SSPR method. |
| Email for SSPR | Email OTP for tenant members; separate B2B email OTP control | Member reset scope, external-user sign-in behavior, sponsor ownership, and guest lifecycle. | Conflating member SSPR with external-user email OTP or disabling one while the other still requires it. |
| Security questions | Legacy SSPR control during transition | Population, question set, risk acceptance, replacement method, communication, and retirement date. | Assuming Migration Complete automatically moves security questions. Microsoft has announced SSPR security-question retirement for March 2027. |
| Modern passwordless methods | Passkeys, Windows Hello for Business, Authenticator phone sign-in, CBA, and Temporary Access Pass | Bootstrap, device/platform support, attestation, key restrictions, lifecycle, authentication strength, and recovery. | Adding a strong method without a safe registration and recovery path, or requiring it before the pilot population is capable. |
Nine-stage runbook
Move one policy truth, method, and population at a time
Authorize and protect the change
Define tenant, decision owners, Authentication Policy Administrator access, pilot groups, exclusions, change freeze, success thresholds, rollback authority, evidence retention, help-desk coverage, and emergency contacts. Validate two cloud-only emergency accounts outside normal federation and device dependencies.
Capture immutable baselines
Export legacy MFA, legacy SSPR, modern methods, group membership, user registrations, Conditional Access, authentication strengths, registration campaign, sign-in activity, reset events, audit logs, service dependencies, and licensing. Hash raw files and work from copies.
Build the effective-method matrix
For each user population, mark method enabled, registered, usable, allowed for MFA, allowed for SSPR, capable of satisfying required strengths, and dependent on phone, device, token, certificate, or network. Record overlaps and gaps explicitly.
Simplify target groups
Use stable, owned groups for each method and avoid long lists of nested or overlapping exceptions. Microsoft notes that many groups can cause registration failures and that a policy beyond roughly 20 KB may fail to save. Add replacement groups before removing old targets in the same controlled operation.
Enter Migration in Progress
Record the exact state change and audit event. Configure the modern policy to preserve required current capability first; then improve security method by method. Do not retire a legacy control merely because its modern toggle exists.
Pilot registration and journeys
Test cloud, hybrid, remote, mobile, desktop, privileged, standard, guest, accessibility, shared-device, VPN, VDI, and lost-device scenarios. Validate initial registration, routine MFA, SSPR, method replacement, new-device bootstrap, offline recovery, and support escalation.
Expand with telemetry gates
Advance cohorts only when registration completion, authentication success, reset success, lockouts, help-desk contacts, suspicious reports, Conditional Access failures, and exception aging stay within approved thresholds. Pause automatically when a stop condition is met.
Retire legacy methods one by one
Remove each method from legacy MFA and SSPR settings only after modern enablement, real user registration, required strength, dependent system, and recovery validation pass. Observe the result before moving the next method; preserve security-question handling until its approved replacement is complete.
Complete, prove, and operate
Set Migration Complete after formal acceptance. Export final policy, targets, user capability, sign-in/reset evidence, exceptions, tickets, communications, audit logs, rollback results, residual risk, owners, and review date. Continue method hygiene and phishing-resistant adoption as an operating program.
Pilot and rollback design
Test the human journey as carefully as the policy object
Pilot acceptance checklist
- Every pilot user has an owned support record and at least one usable recovery path.
- Authenticator push, OTP, passkey, TAP, phone, token, or certificate tests match the approved method matrix.
- MFA and SSPR work from managed, unmanaged, new, replacement, and remote devices as designed.
- Authentication-strength prompts show an available registered method rather than a dead end.
- Registration campaign behavior, snooze limits, mobile limitations, and Conditional Access interactions are understood.
- Help-desk staff can verify identity, issue approved bootstrap credentials, revoke lost methods, and document evidence.
- Emergency accounts remain accessible, monitored, tested, and excluded only where explicitly approved.
Rollback package
- Before-state exports for every legacy and modern policy plus target-group membership.
- Named decision owner, rollback operator, communications lead, support bridge, and maximum outage window.
- Exact method, group, policy-state, and Conditional Access changes in execution order.
- Stop conditions: lockout threshold, critical-app failure, SSPR failure, unsupported dependency, or emergency-access defect.
- Return Migration Complete to In Progress when legacy policy behavior must be restored.
- Re-enable only the minimum required method/scope; validate sign-in and recovery immediately.
- Preserve incident timeline, affected users, audit events, remediation, residual risk, and reattempt criteria.
Authentication strength rule: enabling a method does not guarantee it can satisfy a Conditional Access strength. The method must be registered, enabled for the user, available in that sign-in context, and included in the required built-in or custom strength. Test from a fresh session and examine the sign-in details.
Common migration failures
Prevent lockouts, silent method expansion, and false completion
These patterns turn a reversible consolidation into an access incident or an audit gap. Treat any one of them as a reason to pause the rollout.
Wizard equals complete
The wizard migrates tenant settings, not individual per-user state, application dependencies, registration readiness, or support operations. Reconcile those separately.
Registered equals usable
A credential can be expired, disabled, outside policy scope, unsupported in the current flow, or unable to satisfy the required authentication strength.
Disable everywhere at once
Bulk removal before cohort evidence can strand remote users, block SSPR, break VPN/NPS or federation paths, and overwhelm support. Retire one method at a time.
Broad All users target
Unreviewed broad scope can enable weak or unintended methods. Start with owned groups, then deliberately expand after evidence supports the design.
Too many policy groups
Large target lists and overlapping groups create opaque effective scope and can hit save or registration limitations. Consolidate and document ownership.
No recovery journey
Phishing-resistant enforcement without bootstrap, replacement-device, lost-key, and identity-verification procedures creates predictable lockouts.
Ignored SSPR differences
A method available for MFA might not provide the same SSPR behavior. Test the reset journey, required method count, admin restrictions, and writeback.
Unprotected emergency access
Break-glass accounts that depend on normal federation, device compliance, a single fragile method, or untested exclusions cannot provide reliable recovery.
No observation window
Immediate closure hides delayed registration failures, token/session effects, rare applications, seasonal users, and help-desk patterns. Define an evidence window.
Evidence and measures
Close the project with reproducible proof and operating ownership
Use counts and rates with definitions, query timestamps, denominators, exclusions, and data-latency notes. A rising MFA-capable percentage is useful, but the review must also show which methods are usable, which strengths can be satisfied, and how users recover.
Minimum closeout: approved scope, baselines and hashes, effective-method matrix, policy states, group membership, method configuration, pilot results, communications, tickets, sign-in/reset evidence, audit events, rollback proof, exceptions, residual risk, owners, review cadence, and final acceptance.
Related ecosystem guides
Connect method policy to access, monitoring, recovery, and operations
Entra MFA deploymentDesign populations, registration, enforcement, support, and validation.
Conditional Access reviewValidate MFA grants, strengths, exclusions, report-only output, and dependencies.
Sign-in log operationsRead authentication requirement, method, result, risk, device, and policy evidence.
Emergency access securityProtect, monitor, test, and govern cloud-only recovery accounts.
Identity Protection reviewConnect risky users and sign-ins to secure remediation and method recovery.
User provisioning workflowBuild method registration, licensing, Conditional Access, and first-day validation into onboarding.
Microsoft 365 admin toolsetUse related planning, assessment, and evidence-building resources.
Microsoft 365 managed servicesGet ongoing identity, endpoint, email, collaboration, and tenant operations support.
Authoritative Microsoft references
Validate tenant behavior against current product documentation
- Migrate MFA and SSPR settings to the Authentication methods policy
- Manage authentication methods and understand policy interaction
- Authentication Methods Activity reporting
- Run a Microsoft Authenticator registration campaign
- How Conditional Access authentication strengths work
- Troubleshoot authentication strengths
- How Authenticator number matching works
- Security questions for SSPR and announced retirement guidance
Frequently asked questions
Authentication methods policy migration FAQ
Does the migration wizard migrate individual per-user MFA settings?
No. Microsoft states that the guide migrates tenant policy settings, not individual user settings. Inventory per-user MFA enforcement, default methods, usable credentials, exceptions, service accounts, and recovery paths separately.
Can we roll back after setting Migration Complete?
Yes. Microsoft documents that the migration state can be returned to Migration in Progress so legacy policy behavior can be re-enabled. A professional rollback still requires before-state evidence, precise changes, an authorized operator, communications, and immediate validation.
Why can a user still use a method we disabled in one place?
During coexistence, applicable settings across the Authentication methods policy and legacy policies can authorize a method. To prevent use, verify that the method is disabled in every policy still respected for that user and scenario.
Should we enable passkeys and phishing-resistant MFA during the same migration?
They can be part of the modernization roadmap, but policy consolidation and method-strengthening should have separate acceptance gates. Pilot bootstrap, platform support, key lifecycle, recovery, help-desk procedures, and Conditional Access authentication strengths before broad enforcement.
What happens to security questions?
Security questions remain managed in the legacy SSPR policy during this transition rather than moving into the Authentication methods policy. Microsoft has also announced their SSPR retirement for March 2027, so establish supported replacement methods, communications, and a completion date.
How do we know users will not be locked out?
No single report proves that. Combine effective policy scope, registered and usable methods, authentication-strength compatibility, representative real sign-ins, successful SSPR, replacement-device and lost-method tests, dependent-system tests, support readiness, emergency-access validation, and a monitored observation window.
IT Perfection identity and Microsoft 365 support
Migrate method policy with evidence, rollback, and a supportable user journey
IT Perfection helps organizations in Irvine, Orange County, Los Angeles County, and Southern California inventory authentication controls, design pilot groups, reconcile MFA and SSPR, test Conditional Access and authentication strengths, prepare support teams, stage safe retirement, and establish ongoing identity operations.
Created by Ali Hassani, CISO — 25+ years of IT, cybersecurity, compliance, and infrastructure experience.
This guide is for initial planning and operational guidance only and does not replace a professional cybersecurity audit, compliance assessment, penetration test, or legal/compliance review. Validate current licensing, tenant behavior, Microsoft documentation, accessibility requirements, and tested rollback procedures before implementation.
