Passkeys vs Hardware Security Keys: Phishing Resistance, Recovery and Rollout Choices

"Passkeys or hardware security keys?" is the wrong question, because a hardware security key can hold a passkey: the real choice is between synced passkeys that follow a user across devices and device-bound credentials that never leave one piece of hardware. Both use the same FIDO2 and WebAuthn protocols and both resist phishing, so the differences sit in assurance level, recovery, cost, logistics and how much control the organisation keeps over where the private key lives. NIST SP 800-63B-4 now draws a formal line between them: syncable authenticators are allowed at AAL2 but not at AAL3. This guide compares synced passkeys, device-bound platform passkeys and roaming security keys, gives rules for which users get which, and covers enrolment, recovery and the metrics that show a rollout is working. It is written for identity, IAM and security architecture teams planning workforce or customer MFA.

Key takeaways

• Same protocol, different key custody. Synced passkeys, platform passkeys and security keys all use WebAuthn; what differs is whether the private key can be copied off the device.
• Both are phishing-resistant. The credential is bound to the site it was created for, so a look-alike domain cannot use it. CISA calls FIDO/WebAuthn the only widely available phishing-resistant authentication.
• AAL3 needs device-bound keys. SP 800-63B-4 says syncable authenticators shall not be used at AAL3, because their keys are exportable.
• Recovery is the real attack surface. Synced passkeys recover themselves through the provider; security keys need a spare key or a verified re-enrolment, and a weak help desk process undoes either.
• Most organisations use both. Synced or platform passkeys for the broad workforce, hardware keys for administrators, shared workstations and the highest-risk roles.

What each one is

A passkey, in the FIDO Alliance's definition, is a FIDO cryptographic credential tied to a user's account, stored on a phone, computer or hardware security key, and unlocked with the same method that unlocks the device: biometric, PIN or pattern. The FIDO Alliance distinguishes two kinds:

• Synced passkeys: copied across a user's devices through a passkey provider's cloud service (an operating system, browser or password manager). A new device signed in to the same provider receives the passkeys.
• Device-bound passkeys: never leave the device that created them. A platform authenticator (a laptop TPM or phone secure element configured not to sync) or a hardware security key can hold them.

A hardware security key is a roaming authenticator, a separate device connected over USB, NFC or Bluetooth. Since FIDO2 (2019) security keys can store discoverable credentials, which the FIDO Alliance calls device-bound passkeys, and its passkeys page states that device-bound passkeys in modern security keys offer the highest security assurance. Security keys also support older FIDO U2F second-factor use. See the Hardware Security Keys Guide and the Passwordless and Passkeys Guide for each topic in depth.

WebAuthn Level 3, a W3C Recommendation since 25 August 2026, gives relying parties two flags to tell these apart at runtime: Backup Eligibility (BE), set when the credential is created and permanent, marks a multi-device (syncable) credential; Backup State (BS) shows whether it is currently backed up. A credential with BE unset is single-device. See the FIDO2 and WebAuthn Internals Guide.

Side-by-side comparison

Phishing resistance and assurance in detail

All three options stop credential phishing and adversary-in-the-middle relays the same way: the browser tells the authenticator which origin is asking, and a credential created for one relying party will not sign for another. SP 800-63B-4 Appendix B notes that properly configured syncable authenticators are phishing resistant because each key is constrained to the domain it was created for. See the Phishing-Resistant MFA Guide and the AiTM Phishing Guide.

The difference is what happens if the user's other accounts are compromised. A synced passkey is only as safe as the sync fabric. SP 800-63B-4 sets the rules for that fabric: keys cloned to it must be encrypted with at least 112 bits of strength, and access to the fabric shall be protected by AAL2-equivalent MFA. For federal enterprise use it adds that the fabric should have FISMA moderate or equivalent protection, devices should be managed, fabric access should go through agency-managed accounts, and authenticators should support attestation. A device-bound key cannot be pulled from a cloud account at all, which is why AAL3 requires a non-exportable key in a hardware-protected, isolated environment.

• Attestation: at registration the authenticator can supply an attestation statement identifying its make and model. Relying parties can check it against the FIDO Metadata Service (MDS), a signed registry of FIDO certified authenticators, to enforce an allow list of models or certification levels. See Hardware key attestation.
• Using the BE flag in policy: SP 800-63B-4 says verifiers may use the Backup Eligible flag in policy to tell device-bound from cloneable keys, and that public-facing applications should not refuse syncable authenticators just because attestation is unavailable.
• Session theft still applies: neither option protects a session cookie after login. Pair passkeys with session binding and short sessions. See Device-Bound Session Credentials (DBSC).

Cost and operations trade-offs

• Hardware spend versus support spend: security keys cost money per user and need stock, shipping and returns. Synced passkeys cost nothing up front, but recovery and provider account issues land on support and on the user.
• Control versus convenience: an issued key is an organisational asset you can inventory, attest and recover from a leaver. A synced passkey lives in a provider account the user may own, so its copies can outlive employment unless the relying party removes the credential.
• Cross-device use: FIDO cross-device authentication lets a phone's passkey sign in on a nearby laptop by scanning a QR code, with Bluetooth Low Energy used to confirm proximity. That helps users on unmanaged or new machines, but some locked-down environments restrict Bluetooth, where a USB or NFC key is simpler.
• Accessibility and device mix: some users cannot use biometrics, some roles cannot carry phones on the floor, and some laptops lack a suitable platform authenticator. Plan a supported option for each case rather than one authenticator for everyone.

Recovery and lifecycle

Recovery decides real-world security more than the authenticator choice. The MGM Resorts breach is the reminder: by the attackers' account, a phone call to the help desk, using details found on LinkedIn, led to identity provider administrator access. Strong authenticators did not matter once the reset path could be talked open.

• Register two: for security keys, issue a primary and a backup kept separately. The FIDO Alliance also notes security keys can serve as a recovery option for users who lose their synced devices.
• Harden the help desk: require identity checks an attacker cannot answer from public sources, a second approver for privileged accounts, and an alert on every authenticator reset. See Passkey account recovery and How to Detect MFA Method Registration Abuse.
• Remove fallbacks: a passkey deployment that still allows SMS or a password as an alternative sign-in is only as strong as that fallback. CISA describes SMS and voice as a last resort, to be used only temporarily.

When to use each

Small organisations can usually start with synced or platform passkeys for everyone and buy security keys only for the few people with administrator rights. Large organisations should decide per group, enforce the choice with authentication strength or authenticator policy in the identity provider, and use attestation or the BE flag to keep synced passkeys away from privileged roles.

Rollout approach

1. Classify users and applications by required assurance (AAL2 or AAL3) and by device ownership and sharing.
2. Pick the authenticator per group using the table above, and decide whether synced passkeys are allowed for each group.
3. Pilot with IT and the help desk first, as CISA's fact sheet suggests, starting with services that already support FIDO such as hosted mail and SSO.
4. Configure policy in the identity provider: allowed authenticator models (by AAGUID), attestation requirements, and whether backup-eligible credentials are accepted for privileged roles.
5. Enrol in a verified session: require an existing strong factor or in-person verification to register the first passkey or key, and register the backup at the same time.
6. Remove weaker methods in stages, keeping a documented, monitored break-glass path, then disable SMS and password fallback for enrolled users.
7. Roll back safely: keep the previous MFA method available to a pilot group for a fixed period so a defect does not lock users out, and track lockout tickets daily.

See the Passkey Rollout Guide for communications and the Hardware Security Keys Buyer's Guide for procurement criteria.

Worked scenarios

Synced passkeys scenario: a 3,000-person workforce leaving SMS codes. Most staff use managed laptops and phones. The organisation enables passkeys at its identity provider, accepts credentials with the Backup Eligible flag set for ordinary users, and requires identity-verified re-enrolment for recovery. Phishing-led account takeover through relayed codes stops, help desk resets fall, and the residual risk moves to the passkey provider account, so the team requires strong protection on those accounts and monitors new authenticator registrations.

Hardware security key scenario: administrators and finance approvers. About 60 privileged users need AAL3, where SP 800-63B-4 does not allow syncable authenticators. Each receives two keys, one held as a backup, registered with attestation checked against the FIDO Metadata Service. Policy rejects any credential with BE set for these roles. When an administrator loses a key, the backup key keeps them working while the lost key is revoked, and the replacement is enrolled in person.

Detection and measurement

• Log: authenticator registrations and removals, the AAGUID and BE flag of each new credential, authentication method per sign-in, fallback use, and help desk resets.
• Alert: new authenticator added outside an enrolment window or soon after a reset; a backup-eligible credential registered on a privileged account; sign-ins using a fallback method by enrolled users. Relevant ATT&CK techniques are T1556.006 Multi-Factor Authentication (modifying MFA to persist) and T1111 Multi-Factor Authentication Interception.

Common failure patterns

• Passkeys added, passwords kept: users can still sign in with a password and SMS code, so phishing simply targets the fallback.
• Synced passkeys on admin accounts in personal provider accounts: the organisation's most powerful credential is now protected by a personal cloud account it does not manage.
• One security key per person: the first lost key becomes a help desk reset, which becomes the weakest link.
• No attestation or model policy: any authenticator can register, including ones that do not meet the organisation's assurance needs.
• Reset by phone call: a recovery process that relies on knowledge an attacker can find publicly defeats every authenticator choice, as the MGM case shows.

Framework mapping

Practitioner checklist

• Decide, per user group, whether synced passkeys, device-bound platform passkeys or security keys are required.
• Issue two hardware security keys to every administrator and help desk operator.
• Block backup-eligible credentials on privileged accounts using the BE flag or attestation policy.
• Maintain an authenticator allow list by AAGUID, refreshed from the FIDO Metadata Service.
• Require a verified session or in-person check for first enrolment and for every reset.
• Remove SMS, voice and password fallback for enrolled users on a published timeline.
• Alert on authenticator registration and reset events, especially on privileged accounts.
• Report phishing-resistant sign-in share by group monthly.

Standards and references

• NIST: SP 800-63B-4 Authentication and Authenticator Management
• W3C: Web Authentication Level 3
• FIDO Alliance: Passkeys
• FIDO Alliance: Metadata Service
• CISA: Implementing Phishing-Resistant MFA
• MITRE ATT&CK: T1111 Multi-Factor Authentication Interception

Related NHI Mgmt Group resources: Passwordless and Passkeys Guide · Hardware Security Keys Guide · Device-Bound Passkeys · Phishing-Resistant MFA Guide · Passkey Providers