Passkeys are phishing-resistant, but a passkey deployment is only as strong as the weakest sign-in or recovery path left beside it. Many organisations announce passkeys, see registrations climb, and still get phished, because the password, the SMS code and the help desk reset all keep working. This page ranks the ten passkey deployment mistakes we see most often, with why each matters, the evidence from standards and incidents, how to detect it and the fix. It is for identity architects, IAM engineers and service desk leads running a workforce rollout, and for product teams adding passkeys to customer sign-in. It assumes you have read the Passkey Rollout Guide; this page is the list of what most often goes wrong.
The Top 10 at a glance
- Leaving phishable sign-in methods enabled beside passkeys
- Recovery and help desk paths that bypass the passkey
- Bootstrapping the first passkey with a password
- Treating synced and device-bound passkeys as interchangeable
- Not checking user verification
- Getting the relying party ID wrong
- Skipping the device and platform readiness check
- Enforcing everywhere at once
- Not protecting or monitoring passkey registration
- Counting registrations instead of phishable sign-ins
| # | Mistake | What goes wrong | First fix |
|---|---|---|---|
| 1 | Phishable fallbacks left on | Attackers phish the password or OTP instead | Enforce phishing-resistant authentication by policy |
| 2 | Weak recovery | Help desk resets give attackers a new credential | Recovery at least as strong as enrolment |
| 3 | Password bootstrap | A phished password registers the attacker's passkey | Temporary access codes after identity verification |
| 4 | Synced and device-bound treated alike | Exportable keys protect your most privileged users | Device-bound, attested passkeys for admins |
| 5 | User verification not checked | A passkey counts as MFA when it was single-factor | Require and inspect the UV flag |
| 6 | Wrong RP ID | Passkeys fail across subdomains or after a rebrand | Plan the RP ID before launch |
| 7 | No readiness check | Users on older devices or VDI are locked out | Map user and device pairs first |
| 8 | Big-bang enforcement | Help desk overload and emergency rollback | Pilot rings by persona and platform |
| 9 | Unprotected registration | Attacker adds their own passkey silently | Strong auth to register, notify every change |
| 10 | Vanity metrics | High registration, little risk reduction | Measure phishable sign-ins remaining |
1. Leaving phishable sign-in methods enabled beside passkeys
The mistake: users register passkeys, but the password with a push or one-time code still works for the same account, so the passkey is just one option among several.
Why it matters: an attacker running an adversary-in-the-middle kit does not care that you own a passkey; the phishing page simply asks for the password and code, and the account accepts them. NIST SP 800-63B-4 recognises two ways to achieve phishing resistance, channel binding and verifier name binding, and passkeys provide the second because the credential is bound to the site's domain. That protection only applies to sign-ins that actually use the passkey.
The fix: once a user has a passkey, enforce phishing-resistant authentication by policy for that user, starting with the most sensitive resources. In Microsoft Entra ID the documented mechanism is Conditional Access with the "Require authentication strength" grant set to Phishing-resistant MFA. Then remove passwords and phishable methods from the account where your platform allows it. See the Phishing-Resistant MFA Guide and the AiTM Phishing Guide.
2. Recovery and help desk paths that bypass the passkey
The mistake: a user who has lost their phone calls the help desk, answers some questions and is given a password reset or an SMS method, which an attacker can do just as easily.
Why it matters: the weakest path sets the real strength of the account. Help desk social engineering is the signature technique of groups such as Scattered Spider: in the MGM Resorts breach, by the attackers' own account, a call to the IT help desk impersonating an employee led to Okta administrator access. NIST SP 800-63B-4 describes account recovery as repeating parts of identity proofing, using a prearranged recovery contact or presenting recovery codes, and requires that a recovery event always notifies the subscriber.
The fix: design recovery before launch: encourage a second passkey or security key, use identity verification (document and liveness checks, or a verified credential) before issuing a time-limited bootstrap code, require a second approver for privileged users, and notify the user through an independent channel on every recovery. Never "recover" to a password or SMS. See Passkey account recovery and the Account Recovery and Help Desk Security Guide.
3. Bootstrapping the first passkey with a password
The mistake: new users receive a password by email, sign in with it and are then prompted to register a passkey. Existing users register passkeys after signing in with whatever method they had.
Why it matters: whoever controls the bootstrap controls the passkey. If the password was phished, the attacker registers their passkey and now holds a phishing-resistant credential to your account. NIST SP 800-63B-4 requires that binding a new authenticator needs authentication at the level the new authenticator will provide (or the highest the account has, if lower), and that the subscriber is notified through an independent mechanism when an authenticator is added.
The fix: for new hires, verify identity and issue a short-lived, one-time bootstrap code, such as the Temporary Access Pass in Microsoft Entra ID, which Microsoft's deployment guidance recommends for onboarding without a password, optionally after identity verification with Microsoft Entra Verified ID. Make the first credential a portable one (a passkey on a phone or a security key) that can then bootstrap device-local credentials such as Windows Hello for Business. See the Microsoft Entra Verified ID guide and the Identity Proofing and KYC Guide.
4. Treating synced and device-bound passkeys as interchangeable
The mistake: one passkey policy for everyone: administrators and finance approvers use the same synced passkeys in consumer password managers as the rest of the workforce, or, the reverse, everyone is issued hardware keys when synced passkeys would do.
Why it matters: synced passkeys copy the private key to a cloud sync fabric so it can be used on the user's other devices; device-bound passkeys never leave the authenticator. NIST SP 800-63B-4 Appendix B allows synced keys at AAL2 subject to conditions (encrypted storage, AAL2-equivalent MFA to the sync fabric) but states that syncing violates the non-exportability requirement of AAL3. Microsoft's guidance follows the same split: FIDO2 security keys for highly regulated industries and elevated privileges, synced passkeys as a low-cost upgrade for most users.
The fix: define policies by persona. For administrators and other high-risk roles, allow only device-bound passkeys with attestation enforced and, where needed, an allow list of approved authenticator models by AAGUID; in Microsoft Entra ID this is done with passkey profiles targeted at groups, and enforcing attestation excludes synced passkeys. For the general workforce, allow synced passkeys. NIST adds that federal enterprise use of syncable authenticators needs managed devices and agency-controlled sync fabric accounts, which is a useful benchmark for any enterprise. See the Hardware Security Keys Guide and the NIST SP 800-63B-4 Authenticator Assurance Levels Guide.
5. Not checking user verification
The mistake: the relying party accepts any WebAuthn assertion and records it as multi-factor, without checking whether the authenticator verified the user with a PIN or biometric.
Why it matters: a WebAuthn response carries flags: User Present (UP), User Verified (UV), Backup Eligible (BE) and Backup State (BS). NIST SP 800-63B-4 says verifiers shall indicate that user verification is preferred, shall inspect the UV flag, and shall treat an authenticator without UV as single-factor. Accepting UV=0 as MFA silently downgrades the assurance you report to auditors.
The fix: request user verification on registration and authentication, inspect the UV flag on every assertion, and map UV=0 to a single-factor result in your policy engine. Use BE and BS to tell device-bound from synced credentials where policy needs it; NIST advises public-facing services not to condition acceptance on the Backup State flag because of user experience impact. See the FIDO2 and WebAuthn Internals Guide.
6. Getting the relying party ID wrong
The mistake: the relying party ID (the domain a passkey is bound to) is set to whatever host the first app ran on, such as login.app.example.com, and later the company adds subdomains, merges brands or moves sign-in to a new domain.
Why it matters: verifier name binding is the reason passkeys resist phishing, so a passkey only works for its RP ID and the domains it covers. NIST SP 800-63B-4 says that for DNS identifiers the verifier identifier is the authenticated hostname or a parent domain at least one level below the public suffix. A narrow RP ID means users must register again for every sibling service; a domain change orphans every passkey.
The fix: decide the RP ID during design, usually the registrable parent domain you control long term, and document it as a decision that needs architecture approval to change. If you must serve several domains, plan how before launch rather than registering users on each one. Test passkeys on every subdomain and native app that shares the account before general availability.
7. Skipping the device and platform readiness check
The mistake: passkeys are enforced before anyone knows which operating systems, browsers, virtual desktops and shared devices users actually sign in from.
Why it matters: users on unsupported platforms either get locked out or are given exceptions that become permanent bypasses. Microsoft's deployment guidance lists the operating systems ready for phishing-resistant enforcement as Windows 10 and later, iOS 17 and later, Android 14 and later and macOS 13 (Ventura) and later, with VDI and other platforms needing case-by-case decisions.
The fix: build a report of user and device pairs from sign-in logs before enforcing. For platforms that are not ready, choose a deliberate route: FIDO2 security keys, smart cards, cross-device sign-in with a phone passkey, or remote credentials inside RDP sessions. Shared and kiosk devices usually need security keys or a separate design. See the Windows Hello for Business Guide.
8. Enforcing everywhere at once
The mistake: a single cut-over date when phishing-resistant authentication becomes mandatory for all users and all apps.
Why it matters: the help desk is swamped, the executive who cannot sign in on a travel laptop gets a blanket exemption, and the project is rolled back. Microsoft recommends enforcing by user and device pair, for example administrators on Windows and iOS first, then administrators on macOS and Android, then other users on desktop, then other users on mobile.
The fix: roll out in rings by persona and platform, with one policy per ring (for example one Conditional Access policy per platform group requiring the phishing-resistant authentication strength). Use report-only mode first, watch help desk ticket volume, and keep the rollback simple: remove the ring's group from the policy, not the policy itself. Start with administrators, who carry the most risk and are the most capable of handling problems. See the Conditional Access Guide.
9. Not protecting or monitoring passkey registration
The mistake: any session that has signed in can add a passkey, and nobody reviews new registrations.
Why it matters: registration is a persistence mechanism. An attacker who steals a session cookie or passes a weak MFA prompt once can register their own passkey and return at will, with a credential that looks phishing-resistant in every report. ATT&CK covers adding authentication material to an account under T1098.005 (Account Manipulation: Device Registration).
The fix: require strong, recent authentication to register a passkey (NIST requires authentication at the new authenticator's level), notify the user by an independent channel on every registration, and alert when a new passkey is followed by sign-ins from a new device, location or ASN. Review AAGUIDs of newly registered authenticators against your allowed list for privileged users.
10. Counting registrations instead of phishable sign-ins
The mistake: the project dashboard shows the percentage of users with a passkey registered and declares success at 90%.
Why it matters: registration is not usage, and usage is not enforcement. If users can still sign in with passwords, the attack surface has barely moved. Microsoft's guidance frames the goal as reducing the amount of phishable authentication occurring in the environment.
The fix: measure sign-ins by method. The headline metric is the share of sign-ins (and of users) still using phishable methods, broken down by persona and platform, with privileged users reported separately.
Detecting passkey deployment gaps
| Signal | Example source | Mistakes it catches |
|---|---|---|
| Password or OTP sign-in by a user who has a passkey | Identity provider sign-in logs (authentication method field) | 1, 10 |
| Help desk reset or bootstrap code issued, followed by a new passkey | Help desk tickets joined to audit logs | 2, 3 |
| Passkey registered from a new device, country or ASN | Authentication method registration audit events | 3, 9 |
| Synced passkey on an account in a privileged group | Registration details (AAGUID, backup eligibility) | 4 |
| Assertions with UV=0 | Relying party application logs | 5 |
| Sign-in failures by platform after an enforcement ring | Sign-in logs, help desk volumes | 7, 8 |
Five measures show whether the rollout is reducing risk: phishable sign-ins as a share of all sign-ins (trend to zero), privileged users on device-bound, attested passkeys or security keys (target 100%), users with no phishable method remaining, recoveries completed with identity verification (target 100%), and help desk tickets per enforcement ring.
Lessons from incidents
- Attackers go to the side door: help desk social engineering in the MGM Resorts breach and push fatigue in the Uber breach both defeated MFA without breaking any cryptography. A passkey rollout that leaves those paths open does not stop either attack.
- Admins first: the most damaging incidents start with one administrator account. Enforcing device-bound passkeys or security keys for admins delivers most of the risk reduction early. See the Top 10 MFA Mistakes for related failures.
Mapping to OWASP
| Mistake | OWASP ASVS 5.0 | NIST SP 800-63B-4 | NIST SP 800-53 Rev. 5 |
|---|---|---|---|
| 1. Phishable fallbacks | V6.3.3 | Phishing resistance (verifier name binding) | IA-2(1), IA-2(2) |
| 2. Weak recovery | V6.4.3, V6.4.4 | Account recovery, recovery notifications | IA-5 |
| 3. Password bootstrap | Not mapped | Binding an additional authenticator | IA-5 |
| 4. Synced vs device-bound | Not mapped | Appendix B syncable authenticators; AAL3 non-exportability | IA-2(1) |
| 5. User verification | Not mapped | Appendix B UV flag | IA-2(2) |
| 6. RP ID | Not mapped | Verifier name binding | IA-2 |
| 9. Registration | V6.3.7 | Notification on authenticator binding | IA-5 (ATT&CK T1098.005) |
Mistakes 7, 8 and 10 are programme management failures with no direct control mapping. In NIST CSF 2.0 the work sits under PR.AA-03 (users, services and hardware are authenticated).
Where to start
If you can do only three things this quarter: enforce device-bound passkeys or security keys for administrators with phishing-resistant authentication strength, and remove their phishable methods (mistakes 1 and 4); replace password bootstrap and help desk resets with identity-verified, time-limited bootstrap codes (mistakes 2 and 3); and start reporting phishable sign-ins by persona instead of registrations (mistake 10).
Smaller organisations can rely on their identity provider's built-in passkey and policy features and allow synced passkeys for most users, keeping security keys for administrators. Larger organisations and those in regulated sectors should define persona-based passkey policies with attestation, plan the RP ID and multi-domain strategy centrally, and run a formal readiness and ring programme. Customer-facing services face a different balance: NIST advises against blocking synced passkeys or requiring attestation for public-facing applications, because doing so pushes users back to weaker methods. See the Passkeys for Everyone Guide.
Practitioner checklist
- Map user and device pairs from sign-in logs before setting any enforcement date.
- Define passkey policies by persona: device-bound and attested for admins, synced allowed for general staff.
- Issue first credentials with identity verification and a short-lived bootstrap code, never a password.
- Make recovery at least as strong as enrolment, notify on every recovery and never recover to SMS or password.
- Require and inspect user verification on every WebAuthn assertion.
- Fix the RP ID in the architecture before launch and test every subdomain and app.
- Enforce phishing-resistant authentication in rings, report-only first, with a group-based rollback.
- Require strong authentication to register passkeys and alert on unusual registrations.
- Remove passwords and phishable methods from accounts once enforcement is stable.
- Report phishable sign-ins by persona monthly, with privileged users separately.
Standards and references
- NIST: SP 800-63B-4 Digital Identity Guidelines: Authentication and Authenticator Management
- NIST: SP 800-63B-4 Appendix B Syncable Authenticators
- Microsoft Learn: Passkeys (FIDO2) authentication in Microsoft Entra ID
- Microsoft Learn: Enable passkeys and passkey profiles in Microsoft Entra ID
- Microsoft Learn: Plan a phishing-resistant passwordless authentication deployment
- OWASP: Application Security Verification Standard 5.0
- NIST: SP 800-53 Rev. 5
Related NHI Mgmt Group resources: Passwordless and Passkeys Guide · Passkey Rollout Guide · FIDO Credential Exchange Passkey Portability Guide · Passkey Adoption Statistics