Rolling out FIDO2 passkeys in Entra ID: approach, pitfalls and recovery planning
Passkeys are now the most accessible way to deliver phishing-resistant authentication in Microsoft 365. Rolling them out still raises practical questions: which kind of passkey to accept, how to onboard users, what to do when someone loses their device. Here is a proven approach.
Why passkeys change the game
A passkey relies on a cryptographic key pair bound to the sign-in domain. A phishing site, however convincing, cannot obtain a valid signature: that is what makes the method resistant to adversary-in-the-middle attacks, unlike one-time codes or push notifications.
Device-bound or synced
| Type | Where the key lives | Watch out for |
|---|---|---|
| FIDO2 security key | In hardware, non-exportable | Cost, logistics, physical loss |
| Passkey in Microsoft Authenticator | On the phone, device-bound | Depends on your mobile estate |
| Synced passkey | In a password manager or the platform keychain | Security depends on the sync account |
Support for synced passkeys in Entra ID is evolving; check the current scope and status before settling your policy. For privileged accounts, prefer device-bound passkeys.
Restricting accepted authenticators
In the authentication methods policy, the Passkey (FIDO2) method lets you enforce attestation and restrict allowed models by AAGUID, the authenticator model identifier. An allow list ensures that only models approved by the organisation can be registered. Remember to include the Microsoft Authenticator AAGUIDs if you use it, otherwise registration will fail.
A four-step rollout
- Pilot: IT staff and administrators, across several operating systems and browsers, to surface incompatibilities.
- Onboarding: a Temporary Access Pass (TAP) lets a new starter register a passkey without ever having a password. Keep its lifetime short and make it one-time use where possible.
- Enforcement: a "phishing-resistant MFA" authentication strength in Conditional Access, first for admin roles, then for sensitive applications.
- Broad rollout: department by department, while monitoring sign-in logs.
Recovery plan. Encourage every user to register at least two passkeys, and document how the service desk issues a TAP, including identity verification. A TAP handed out without checks becomes an impersonation vector in its own right.
Common pitfalls
- Requiring phishing-resistant methods without excluding emergency access accounts.
- Leaving weak methods enabled: an attacker will simply pick the weakest.
- Forgetting edge cases: shared workstations, machines without Bluetooth for cross-device sign-in, legacy applications.
- Allowing too many administrators to create TAPs.
What an audit checks
- Whether the passkey method is enabled, and its attestation and restriction settings.
- TAP configuration: lifetime, one-time use, roles allowed to issue it.
- Conditional Access policies requiring a phishing-resistant strength.
- The share of privileged accounts that actually have a passkey registered.