Microsoft Entra’s passkey transition: evidence to approve each enforcement wave

Microsoft guidance checked September 22, 2026.

Approve a phishing-resistant authentication rollout only when the evidence covers the workflows entering the next wave. For each user, device, client, and resource combination, record the policy configuration, actual authentication method, enforced access result, independent backup test, and remaining remediation. Registration totals alone cannot establish readiness.

The earlier Entra ID account recovery article examines recovery paths, identity verification, support permissions, and emergency access governance. This article focuses on a narrower decision: whether a defined migration wave can operate under its proposed Conditional Access configuration. The acceptance procedure below is an editorial testing framework, not a Microsoft certification or a guarantee against lockout.

Microsoft’s published retirement schedule distinguishes three milestones:

Customer-managed telecom providers offer a continuation path. Otherwise, affected users with only SMS/voice MFA face mandatory passkey registration at their deadline. The temporary auto-enablement opt-out does not postpone retirement enforcement. Microsoft’s schedule

Retirement and your own phishing-resistant enforcement policy are separate changes. SMS, voice, Authenticator push, Authenticator phone sign-in, and Temporary Access Pass (TAP) do not satisfy the built-in Phishing-resistant MFA strength. A passkey stored in Authenticator is a different method from push or phone sign-in. Authentication strengths

Define the wave around actual work. A managed laptop, a shared terminal, and a privileged workstation need separate test cases. Record SMS/voice enablement and usage, the intended replacement credentials, and applicable policy assignments. Microsoft recommends deployment by user persona and staged enforcement. Deployment guidance

Keep guest and external-access cases separate from employee enrollment. For external users, record identity type, home and resource tenants, inbound MFA trust, accepted methods, and observed access. Supported methods depend on where MFA occurs and the resource tenant’s trust settings. Verify internal-guest registration separately too. External-user authentication strengths

Credential selection also affects the test. Passkeys use public-key cryptography bound to the legitimate sign-in origin. Device-bound private keys stay on one device; synced passkeys depend on a provider’s synchronization. Synced passkeys do not support attestation. Record the actual provider, passkey profile, and applicable restrictions. Passkey documentation

For this acceptance procedure, a backup must be independently available and satisfy the enforced strength and method restrictions. Two methods on the same unavailable phone fail that criterion. Test the backup without the primary device, including access to any credential store it needs. “Authenticator configured” is not a sufficiently precise credential description.

Use report-only results to select cases for investigation:

Report-only does not enforce controls or prove interactive challenge completion. User Actions policies are unsupported in this mode. Another policy can still block access. Device-compliance evaluation can produce certificate-selection prompts on some platforms. Report-only guidance

Before enabling the pilot, verify both emergency accounts. Check that they are cloud-only .onmicrosoft.com accounts with permanently active Global Administrator roles, independently available phishing-resistant credentials, secure storage, monitoring, and exclusions from policies that restrict sign-in—including the proposed pilot. Test sign-in and Conditional Access administration from the designated secure workstation. Exclusions do not remove Microsoft’s mandatory MFA requirements. Emergency-access guidance

Make rollback a prerequisite as well. Save the current and proposed configurations, identify who can restore them, and prepare the exact rollback steps and verification checks. Keep the instructions and required access available if the pilot user or normal administrator loses access. Do not enable the pilot until both emergency accounts and the rollback procedure have passed this preliminary check.

Then run the controlled enforcement exercise:

1. Freeze the test scope. Record policy IDs, configuration versions, group membership, resources, authentication strength, passkey restrictions, and other applicable policies.
2. Confirm that pilot users have registered the required credentials. Enable the proposed policy only for the approved cohort.
3. Perform fresh primary and backup authentication to each selected resource. Inspect authentication details to establish which method was used, and verify actual resource access. Repeat the backup attempt with the primary device unavailable.
4. Test the exact replacement-passkey registration route described below, followed by fresh access with the replacement credential under ordinary resource enforcement.
5. With the pilot enforced, test each emergency account separately and perform the planned reversible policy repair. Restore the saved pre-enforcement state, verify access for the affected test user, then restore the approved pilot configuration. Retain alerts and audit events.
6. Retest failed workflows after remediation. Keep the original failure and the successful retest together.

Treat replacement registration as a distinct acceptance test. Microsoft documents using TAP to enter Security info and register a FIDO2 security key. TAP must be enabled for the user. A single-use TAP requires passwordless registration to finish within ten minutes of sign-in; registration policies can also redirect the user into Interrupt mode. TAP guidance

Microsoft documents registration-strength precedence specifically for Interrupt mode: strengths targeting Register security information take precedence over All resources strengths; other controls still apply, and multiple registration strengths must all be satisfied. Passkeys cannot be registered in Interrupt mode. Their registration uses Managed mode, such as Security info. This precedence rule does not establish that TAP can reach and complete your Managed-mode registration route under its policies. Authentication-strength evaluation

Validate that exact route with the intended replacement device and credential. Capture the TAP scope, authorized issuance and identity-verification record, validity and usage limits, applicable registration and resource policy IDs, device and location requirements, redirects, and final result. Retain issuance references rather than the TAP secret. If a remaining control prevents registration, defer the case until a tested resolution exists. Any temporary exception needs a defined scope, owner, expiry, and removal check. Finish by proving access with the new passkey after the exception has been removed and normal enforcement restored.

The following record is illustrative. Names, versions, and outcomes are invented, not customer observations.

Attach timestamps, sign-in correlation IDs, audit references, configuration snapshots, and reviewer approval. Create separate records for materially different clients, resources, shared-device workflows, and privileged tasks. One successful record does not approve every device used by that person.

Defer affected cases when a legitimate workflow has an unresolved failure, an untested interactive requirement, an unexpected exclusion, or an unavailable compliant backup or registration route. Assign an owner and deadline. Consider support capacity before expanding the wave; Microsoft recommends slowing deployment when help-desk demand rises. Rollout guidance

Approval applies to the recorded configuration and tested workflows. Revalidate affected records after material policy, provider, device, or application changes.

Further reading

• Active Directory security
• LAPS, gMSA and tiered administration