Since FIDO2 security keys and device-bound Authenticator passkeys became generally available, passkeys in Microsoft Entra ID come up in almost every tenant I work with. Last year this was still a technical preview (see post). Now I'm seeing production projects, and customers no longer ask whether to do it but how to get from pilot to broad use. Passkeys in Entra ID offer real phishing resistance and a smoother passwordless sign-in. Switching the feature on is only the first step, though. Whether the new method actually sticks depends on operations, support and communication.

The passkey policy in Entra ID goes well beyond the basic toggle

You configure passkeys in Entra ID under Entra admin center → Protection → Authentication methods → Policies → Passkey (FIDO2). This is where you decide which users or groups may register passkeys and whether attestation is required. Many security teams care most about the option to restrict allowed FIDO2 keys by AAGUID, so you can permit only certain YubiKeys or FEITIAN devices, for example. Since late 2024, device-bound passkeys in Microsoft Authenticator (Android/iOS) have their own toggle, which means a single policy switch can bring passkeys to users' phones (official docs). Because the two are separate, you can pilot hardware keys with a small group and roll out Authenticator passkeys to a much wider audience at the same time. Attestation is a trade-off. It tells you where a key came from, but it can annoy users, particularly with older keys or browsers.

Practical tip: Begin with a short allow-list of FIDO2 keys you have tested, identified by AAGUID, and only widen it after the first rollout wave. That keeps unsupported hardware from flooding the helpdesk.

Clear user communication keeps the registration flow free of friction

For most users, the first contact with passkeys is the My Security Info portal (mysignins.microsoft.com/security-info). What I typically see: once the policy is on, the tech-savvy people find it and register within days, while less technical staff need clear, targeted communication. Have step-by-step guides and FAQs ready before you start, with screenshots showing what the Authenticator and FIDO2 setup will look like. Browser differences and vague error messages cause more trouble than you'd expect, especially with attestation enabled. The smoothest rollouts I've seen were in tenants that turned attestation off but kept a strict allow-list of hardware models.

You are always weighing user experience against security. Requiring attestation gives you more control, but it also brings frustrated users and more tickets. In practice, allowing only approved hardware with attestation switched off has worked best for me.

Authentication strengths let Conditional Access require passkeys

The bigger step forward came when passkeys were added to authentication strengths for Conditional Access (background). You can now require a "phishing-resistant" method, such as a hardware key or an Authenticator passkey, for specific apps or admin portals. The setting is under Entra admin center → Protection → Conditional Access → Authentication strengths. For critical applications this takes passwords out of the picture without touching other services. In my experience, FIDO2 plus Authenticator passkeys plus carefully scoped Conditional Access is the most realistic way to get to passwordless operations.

The diagram shows where passkeys sit in the sign-in and CA flow:

flowchart TD
  SignIn["User sign-in"] --> MFAPrompt["Multi-factor prompt"]
  MFAPrompt --> PasskeyOption["Passkey (FIDO2 or Authenticator)"]
  MFAPrompt --> OtherMethod["Other method"]
  PasskeyOption --> CAStrength["CA checks authentication strength"]
  OtherMethod --> CAStrength
  CAStrength --> Access["Access granted/denied"]

Figure: How passkey sign-in and Conditional Access authentication strengths interact.

Temporary Access Pass makes onboarding possible

Any real passkey rollout needs a way to get users started, and that is Temporary Access Pass (TAP). This time-limited one-time code lets users register their first passkey without falling back to legacy authentication. That matters a lot when passwords are already disabled or when onboarding happens remotely. In every production rollout I've been part of, TAP quietly did the heavy lifting and kept the helpdesk out of chicken-and-egg situations. I covered TAP in more detail in Temporary Access Pass in Entra ID: Onboarding and Recovery.

The helpdesk faces new kinds of problems that need prepared fixes

Preparing the helpdesk is the part people tend to forget. Most users find passkeys easy, yet the rollout brings support cases you haven't handled before. FIDO2 keys won't register because of odd browser issues, Android and iOS behave differently, users lose access to Authenticator, or they ask how to reset a key. I recommend defining clear processes for issuing TAPs, resetting keys and registering backup methods, and practising them before go-live. Keep a short FAQ listing the most frequent My Security Info portal errors and how to fix each one.

Passkeys in Entra ID work best when security, IT operations and communications teams pull together and look beyond the technical settings to process, support and clear messaging for end users. Don't try to switch everyone overnight. A staged rollout with clearly defined groups, tested policies and a helpdesk that knows what's coming is the most reliable route to adoption.