Passkeys

A passkey is a FIDO credential: a public/private key pair created for one website or app, used to sign in by unlocking it the way you unlock your device. Passkeys replace passwords rather than adding a factor to them, and they are phishing-resistant by design. This page covers the facts: what the term means in the FIDO Alliance's and W3C's usage, synced versus device-bound passkeys, what NIST SP 800-63B-4 says about syncable authenticators and which assurance level they can reach, and what passkeys change for account recovery and for enterprises.

What a passkey is

The FIDO Alliance describes a passkey as an authentication credential based on FIDO standards. It can be stored on a phone or computer, or in a hardware security key, and the user signs in with the same gesture used to unlock the device: biometric, PIN or pattern. FIDO notes that passkeys are built on the FIDO2 specifications and treats "passkey" as a common noun, not a feature of any one platform.

The W3C Web Authentication Level 3 specification uses the term too. It defines a discoverable credential and lists "passkey" as one of its names. It calls backup-eligible credentials multi-device credentials, "commonly referred to as synced passkeys", and credentials that cannot leave their authenticator "device-bound passkeys". It also describes "passkey platform authenticators" and "passkey roaming authenticators" as enabling passwordless multi-factor authentication: possession of the private key is one factor, and user verification by PIN or biometric is the second.

In practice, a passkey is:

• A WebAuthn credential, so it is scoped to one relying party's domain (its RP ID). That scoping is what makes it phishing-resistant.
• Discoverable: the authenticator can find it given only the RP ID, so the site does not need a username first.
• Usually created and used with user verification, which makes it a multi-factor cryptographic authenticator in NIST's terms.

Synced versus device-bound

WebAuthn exposes the difference through two flags in the authenticator data. The BE (backup eligibility) flag is fixed when the credential is created. The BS (backup state) flag can change over time.

The SP 800-63B-4 note on BE is worth repeating: "just because an authenticator can be synced does not mean that it has been synced." BE tells you the credential is capable of syncing. BS tells you its current state.

What SP 800-63B-4 says about syncable authenticators

SP 800-63B-4 adds syncable authenticators in section 3.1.7.4 and a normative Appendix B. The key rules:

Which assurance level

• Section 2.3.2: "Since syncable authenticators (described in Appendix B) require the private key to be exportable, syncable authenticators SHALL NOT be used at AAL3."
• Appendix B.2: "Authentication at AAL2 may be supported subject to the above requirements." Appendix B.4 describes syncable authenticators as an option for applications that "seek to implement up to AAL2".

Requirements on the keys and the sync fabric (B.2)

• Keys SHALL be generated using approved cryptography.
• Keys exported to a sync fabric SHALL be stored only in encrypted form, with a key of at least 112 bits of security strength. They SHOULD be encrypted using a user-controlled secret.
• Private-key operations SHALL happen on the local device.
• Only the authenticated user SHALL be able to access their keys in the sync fabric, and that access SHALL be protected by AAL2-equivalent MFA.
• Authenticators SHOULD let users see which services they have syncable keys for and where they have been synced. The UI SHALL NOT expose the key itself.

Reading the WebAuthn flags (B.3)

Discoverable credentials and username-less sign-in

Because a passkey is discoverable, the relying party can call navigator.credentials.get() with an empty allowCredentials list. The authenticator offers the passkeys it holds for that RP ID. The response includes a userHandle that tells the server which account is signing in. WebAuthn's verification steps require the server to look up the account by that user handle and confirm the credential belongs to it.

Browsers can also offer passkeys in the username field's autofill ("conditional mediation"). That lets a site add passkeys without redesigning its sign-in page.

Account recovery implications

Passkeys move the weak point rather than removing it:

• Synced passkeys survive a lost phone, because the new device pulls them from the sync fabric. That makes the sync account's own sign-in and recovery the path an attacker will try. SP 800-63B-4 Table 5 lists "Unauthorized access to sync fabric and recovery" as a threat. Its mitigations include recovery consistent with SP 800-63B, notifying the user of any recovery activity, and using a secret unknown to the sync provider to encrypt keys.
• Device-bound passkeys do not survive device loss. WebAuthn's section on backup state says relying parties SHOULD ensure that each account has additional authenticators registered or an account recovery process in place.
• Sharing. Appendix B.4 notes that some syncable implementations let users share passkeys with other people. For public-facing services, NIST advises assuming that any syncable authenticator may be shared. Enterprises can limit sharing with device management.

Your own account recovery must not be weaker than the passkey. If "lost your passkey?" sends an email link that resets everything, an attacker phishes the email, not the passkey.

Enterprise considerations

• Know which kind you are accepting. Use BE at registration to tell synced from device-bound credentials. Record it (WebAuthn RECOMMENDS storing the latest BE/BS values), and apply policy, such as device-bound only for privileged roles that need AAL3.
• Attestation. Attestation lets the relying party learn the make and model of the authenticator. SP 800-63B-4 says federal enterprise verifiers SHOULD use attestation, and that agencies SHOULD implement it for syncable authenticators "based on the functionality offered by their platform providers". WebAuthn's enterprise attestation conveyance can identify individual authenticators in controlled deployments.
• Managed sync fabrics. For federal enterprise use, Appendix B.2 requires sync fabrics with FISMA moderate protections or equivalent, device management that prevents syncing or sharing to unauthorized devices or fabrics, and agency-managed accounts controlling access to the fabric (all SHALL).
• Revocation. There is no central revocation list for WebAuthn credentials. Table 5 recommends managing authenticators centrally and using SSO and federation so fewer per-site keys need revoking after an incident.
• Public-facing services. Missing attestation SHOULD NOT block syncable authenticators for broad public-facing applications. NIST's reasoning is that demanding attestation pushes users back to weaker, phishable options.

Checklist for relying parties

• Offer passkeys alongside existing methods, then make them the default for new accounts.
• Request user verification, and treat a response without UV as single-factor (SP 800-63B-4 B.3).
• Store BE and BS with each credential, and decide which roles accept synced passkeys.
• Require device-bound, non-exportable authenticators where you need AAL3.
• Let users register several passkeys and see and remove them in account settings.
• Notify users when a passkey is added or removed, and make recovery at least as strong as sign-in.

Sources

1. FIDO Alliance: Passkeys, FIDO Alliance. Cited for facts; not reproduced.
2. Web Authentication: An API for accessing Public Key Credentials, Level 3 (W3C Recommendation, 25 August 2026), W3C. W3C Document License (cited, brief quotations).
3. NIST SP 800-63B-4: Authentication and Authenticator Management, NIST. Public domain (U.S. government work).