Preparing Microsoft Entra ID for passkey-first authentication

Passkeys remove the shared secret. There is no password to phish, replay or spray, and the credential is bound to the relying party so a convincing fake sign-in page gets nothing. That is a genuine improvement over every other method in common use.

The deployment difficulty is not the passkey. It is that removing passwords exposes every assumption your organisation has been making about how people recover access, and those assumptions have usually never been examined.

Requirements: what has to be true before you start

Know which passkey types you intend to support. Microsoft Entra ID supports passkeys in two shapes, and they behave differently:

• Device-bound passkeys, where the private key is created on one physical device and never leaves it. Security keys and passkeys in Microsoft Authenticator are both of this kind — Authenticator passkeys are device-bound and cannot be synced.
• Synced passkeys, which are backed up to a platform provider’s account and available across that person’s devices.

Device-bound is the stronger assurance and the harder logistics. Synced passkeys are far easier to enrol and recover, and the trade is that the key’s availability now depends on a consumer account you do not administer. Decide deliberately, and expect the answer to differ by population: a synced passkey may be right for the general workforce and wrong for administrators.

Know your current method inventory. Before changing policy, find out what people actually use. You cannot plan an exception list without it, and the answer is always more varied than expected — particularly for shared devices, frontline staff and anyone using a method that predates your current standards.

Confirm your recovery path does not depend on the thing you are removing. This is the requirement people skip. If password reset relies on an SMS code, and you are moving away from SMS, you have a circular dependency to break before the rollout, not during it.

Design: the decisions that shape the rollout

Registration is the hard part

A passkey has to be registered by an already-authenticated user. That is straightforward for someone with a working method today, and it is the entire problem for a new starter, a person who has lost their device, or anyone whose existing method you are retiring.

Two mechanisms are worth designing around. Temporary Access Pass issues a time-limited passcode that lets a user register a strong method without an existing one — it is the intended answer for onboarding and recovery, and I would have it configured before the first pilot. Self-service registration is controlled per method in the Authentication methods policy; where it is set to no, users cannot register a passkey themselves even when passkeys are enabled, which is a deliberate control and a common cause of confusion during a pilot.

Restricting which authenticators are acceptable

The Authentication methods policy lets you restrict passkeys to specific authenticator models by targeting the AAGUID — the identifier a authenticator reports for its make and model. This is how you enforce “only these security keys” or “only Authenticator passkeys”.

Use it if you have a genuine assurance requirement and a procurement route. Do not use it because it sounds thorough: an AAGUID allowlist is a list you must maintain, and it will block a user holding a perfectly good key you have not added.

Two populations, two timelines

Administrators and general users should not be on the same schedule. Privileged accounts benefit most from phishing-resistant authentication and are the smallest, most supportable population — start there. The general workforce follows once enrolment and recovery have been proven on people who can tolerate friction.

Deployment: a sequence that does not strand anyone

1. Enable Temporary Access Pass and confirm your service desk can issue one, with an identity verification step that is itself not phishable. A TAP issued to whoever phones up is a credential-reset attack with extra steps.
2. Enable the passkey method in the Authentication methods policy, targeted at a pilot group. Decide self-service registration and any AAGUID restriction at this point.
3. Pilot with administrators. Register, sign in, and deliberately exercise the failure cases: a lost key, a replaced phone, a sign-in from an unfamiliar device.
4. Write the recovery runbook from what the pilot taught you, before widening.
5. Widen by population, tracking registration rates rather than policy state. A policy that permits passkeys tells you nothing about how many people hold one.
6. Only once registration is high, begin constraining weaker methods. This is the step that converts an option into a standard, and doing it early is how you generate a lockout incident.
7. Require phishing-resistant authentication through Conditional Access for the populations that are ready, using the authentication strength control rather than a generic multifactor requirement. Run it in report-only first, as in Conditional Access baselines.

Validation

Registration coverage is the measure that matters: what proportion of each population holds a passkey, not whether the policy is enabled. Track it per group and expect a long tail.

Then verify the behaviours rather than the settings:

• A pilot user can sign in with a passkey on a managed device and an unmanaged one.
• A user without a passkey is still able to work, until you deliberately decide otherwise.
• A user who has lost their device can recover, using your documented path, within your target time — and the service desk can do it without an exception.
• Sign-in logs show the authentication method actually used. This is where you find out that a proportion of sign-ins are still falling back to something weaker.
• Your break-glass accounts still work, and are excluded from the new requirement. Verify this by testing them, as described in emergency access accounts.

Operations: what changes permanently

The service desk’s workload shifts from password resets to credential recovery, and the new work is less frequent but higher stakes. A lost passkey is not a five-minute call; it is an identity verification followed by a re-registration. Train for it and measure it.

Device refresh becomes an identity event. Replacing a phone now means re-registering a credential, so the process that hands someone a new device needs to include it or people will arrive at the service desk already locked out.

Method retirement continues. Microsoft has published the direction on passkeys by default and the retirement of Microsoft-provided SMS and voice authentication; treat the method inventory as something you re-check rather than a one-off exercise.

Rollback

Every step above is reversible while you are still adding a method. Re-enabling a previously allowed method restores the old behaviour, and Conditional Access policies can be returned to report-only or off.

What is not cleanly reversible is a population you have stranded — people who no longer hold a working method because a policy change removed the only one they had. That asymmetry is the argument for running each restriction in report-only, for tracking registration rather than policy state, and for never constraining a method before its replacement is widely registered.

Honest limits

Passkeys are phishing-resistant, not compromise-proof. They do not protect against a compromised endpoint, token theft after a successful sign-in, or an attacker who can register a new credential because your recovery process is weak. That last one is worth dwelling on: once passwords are gone, your recovery process is your authentication security, and it becomes the most attractive target you have.

This article covers preparation and sequencing. It does not cover the specific enrolment steps for each authenticator type, platform support details, or External ID scenarios, all of which are version-specific and documented properly by Microsoft.

Verification and limits

Device-bound versus synced passkey behaviour, Authenticator passkeys being device-bound only, AAGUID targeting, the self-service registration control and the direction on SMS and voice retirement were checked against current Microsoft documentation on 20 September 2026.

No tenant configuration was performed for this article. Authentication method policy changes affect who can sign in — pilot with a small group, keep excluded emergency access accounts, and never restrict a method before confirming registration coverage for its replacement. Capability in this area moves quickly; re-check the current documentation before you deploy.

References

• Passkeys (FIDO2) authentication method in Microsoft Entra ID
• How to enable passkeys (FIDO2) in Microsoft Entra ID
• Enable and support passkeys in Authenticator
• Passkeys by default and retirement of Microsoft-provided SMS and voice authentication