Microsoft Entra passkey onboarding: policy, bootstrap, and recovery
Separate passkey registration, device sign-in, and SMS retirement. Pilot the complete onboarding and recovery path before changing access for everyone.
Passkey onboarding is an account-lifecycle problem. A user needs a supported method, a policy that permits it, an appropriate way to register it, and a recovery path when it is lost. A tenant-wide announcement does not establish that every user and device can complete the same registration flow.
Can a verified new user register an allowed method, access the required application, sign out, sign in again, and recover after losing the method? Test that whole path with a pilot account. Do not treat a successful registration screen as the end of the deployment.
Default prompts are not the same as one universal deadline
Microsoft's current notice says passkeys become the default experience from 1 September 2026 for users enabled for SMS or voice. Microsoft-provided SMS and voice delivery retires on 1 February 2027 for most users, with Global Administrators and external users following on 1 July 2027. Internal guest users remain in the February group.
The notice describes an enforced passkey-registration prompt for in-scope users whose only available MFA method remains SMS or voice after the February retirement. It also describes continued use of other phishing-resistant methods and a telephony-provider route for organizations retaining SMS or voice. This is not a statement that every user must abandon every other method for a passkey.
Use the linked notice to classify your users. Record actual tenant behavior and relevant service notices. This guide does not assert an unverified January-to-February “direct onboarding” rollout window or a separate universal B2B rollout date.
Name the credential precisely
| Term | What to verify |
|---|---|
| Passkey / FIDO2 | Supported authenticator, device and browser, tenant policy, and the credential type allowed by the organization |
| Windows Hello for Business | Its own deployment and device-registration configuration; do not describe it as identical to registering a FIDO2 passkey |
| Temporary Access Pass | Who may receive it, who may issue it, expiry, and whether it permits one or multiple uses |
| Conditional Access authentication strength | The actual methods permitted for the protected application and the pilot user's sign-in result |
A label such as “passwordless” does not settle all four rows. Check support for the authenticator you intend to deploy and the policy used by the target application. Test users with the devices they will actually carry, including accessibility or shared-device requirements.
Bootstrap with a verified identity
A Temporary Access Pass is a time-limited bootstrap credential that can support registration and recovery. Enable it for the intended group in Authentication methods policy. Authentication Policy Administrators manage that policy; Authentication Administrators can manage TAPs for members, while managing administrator accounts requires the appropriate privileged role. Follow the documented role restrictions.
Before issuing a pass, use the organization's established identity-verification procedure. A help-desk request and a familiar display name alone do not prove the requester is the account owner. Deliver the pass through an approved channel, with a lifetime and use count appropriate to the onboarding task. Do not put live codes in a ticket screenshot or shared runbook.
Creating a pass is different from enabling its use for the user. Verify policy scope and relevant account restrictions. Follow the documented guest-user limitations; do not assume a TAP issued in the resource tenant bootstraps every external identity.
A pilot checklist with evidence
- Inventory methods. Identify who uses SMS or voice, their account category, and available alternatives. Keep emergency access accounts under a separate documented procedure.
- Check policy scope. Record the groups enabled for the intended method and the application policies the pilot must satisfy.
- Test registration. Use a verified pilot user and an allowed authenticator. Record the browser, OS, relevant policy, and result without capturing secrets.
- Test real access. Sign out and authenticate again to each required application. Inspect the sign-in evidence and confirm the expected strength requirement is met.
- Test recovery. Simulate an unavailable method. Use the approved recovery procedure, then confirm access can be regained and the temporary credential is no longer usable when intended.
- Prepare support. Give users a short guide and a clear contact for device incompatibility or recovery. Expand the pilot only after common failures have a documented response.
When the direct registration path is unavailable
Capture the exact error and check method eligibility, device/browser support, policy scope, and the user's existing registration state. Compare the tenant's behavior with the current passkey deployment guidance. Avoid loosening a production access policy merely to make an untested onboarding shortcut work.
Use an approved bootstrap path such as TAP where supported, or another existing method permitted by policy. Escalate unsupported cases before the user's required access is removed. A migration plan needs exceptions and support capacity as well as a deadline.
Common questions
Are passkeys the only method everyone can use?
No. Check the current retirement notice, supported methods, and your application's authentication-strength policy. Account categories and existing methods affect the migration.
Does every SMS or voice user have the same retirement date?
No. Microsoft's current notice distinguishes most users from Global Administrators and external users. Classify accounts using the notice rather than assuming all guest accounts are identical.
Does a Temporary Access Pass remove identity verification?
No. Verify the requester through the approved process before issuing a bootstrap credential. Use an appropriate scope, expiry, delivery channel, and recovery record.
Sources and review
Reviewed 1 October 2026. Method and retirement claims were checked against Microsoft documentation. Tenant eligibility and sign-in results must be confirmed in your pilot; no tenant settings were changed for this review.
- Passkeys by default and SMS/voice retirement
- Enable passkeys in Entra ID
- Temporary Access Pass policy and roles
Every class is open to read. A free account saves your progress. Azure resources used for labs may incur charges.