Passkeys and Second-Factor Location
Passkey security involves several different locations and claims: where a cryptographic credential is used, whether it is synchronized, where biometric processing occurs, and what user verification establishes. Recovery mechanics, a complete taxonomy of second factors, and legal-compulsion rules require separate evidence.
Not legal advice. This page is research, not compliance guidance.
How does a passkey authenticate, and what is established about recovery?
Passkeys are FIDO credentials that replace passwords with cryptographic key pairs used from an end-user device for phishing-resistant authentication; this mechanism does not establish account-recovery behavior or recovery-key custody.
From a technical standpoint, passkeys are FIDO credentials for passwordless authentication. They replace passwords with cryptographic key pairs, and those keys are used from end-user devices such as computers, phones, or security keys for phishing-resistant authentication.
Authentication and recovery are different mechanisms. The passkey evidence establishes how the credential authenticates; it does not establish an account-recovery process, where a recovery key is held, or who can use a recovery path.
Keeping that boundary intact avoids turning a credential description into a recovery promise. A recovery claim requires its own evidence even when the authentication credential is well defined.
- Credential: a FIDO passkey replaces a password with a cryptographic key pair.
- Use location: the cryptographic keys are used from an end-user device.
- Authentication property: the passkey provides phishing-resistant authentication.
- Unresolved boundary: account-recovery mechanics and recovery-key custody are not established by the same evidence.
What is the difference between a synced and device-bound passkey?
A synced passkey is synchronized among a user's devices through a cloud service, while a device-bound passkey stays on one device; in the documented passkey flow, biometric information and processing stay on the device and the remote server sees only assurance that the check succeeded.
The distinction concerns whether the credential can leave one device. A synced passkey is synchronized among a user's devices through a cloud service. A device-bound passkey never leaves a single device, including when that device is a FIDO security key.
Biometric processing is a separate data flow. In the documented passkey flow, biometric information and processing stay on the device and are not sent to a remote server. The server sees only an assurance that the biometric check succeeded.
A synchronized credential and local biometric processing can therefore coexist. Synchronizing the passkey does not, by itself, state that biometric information is synchronized, and local biometric processing does not make every passkey device-bound.
- Synced passkey: synchronized among a user's devices through a cloud service.
- Device-bound passkey: remains on one device, including a FIDO security key.
- Biometric processing: remains on the device in the documented passkey flow.
- Remote server: receives assurance that the biometric check succeeded, not the biometric information.
Figure 1. Authentication is separated from recovery, synced credentials from device-bound credentials, and factor location from account location, ending at the coercion-limits boundary.
Source: none (concept)
Where do the credential and biometric processing live?
In the documented passkey flow, cryptographic keys are used from an end-user device, synced passkeys are synchronized through a cloud service, device-bound passkeys remain on one device, and biometric processing stays on the device; this does not supply a complete taxonomy of second factors.
Factor location is not one undifferentiated place. The passkey's cryptographic keys are used from an end-user device. A synced passkey is synchronized among a user's devices through a cloud service, while a device-bound passkey stays on one device.
The biometric check has its own boundary. Biometric information and processing remain on the device in the documented flow, while the remote server receives assurance that the check succeeded. Credential location, synchronization, biometric processing, and the server's assurance are distinct parts of the flow.
These facts do not establish a complete location taxonomy for SMS codes, authenticator apps, push approvals, or every hardware factor. No broader taxonomy is asserted without separate evidence.
- End-user device: the cryptographic keys are used from the device for authentication.
- Cloud service: synchronizes a synced passkey among a user's devices.
- Single device: retains a device-bound passkey.
- Device-local process: keeps biometric information and processing on the device while sending only success assurance to the server.
- Scope limit: SMS, authenticator-app, push, and broader hardware-factor locations are not classified by this evidence.
What does WebAuthn user verification establish?
WebAuthn user verification does not give the relying party a concrete identification of a natural person: repeated ceremonies can indicate the same user, but multiple natural persons may share access to one authenticator; this technical limit does not establish a legal rule about compelled unlocking.
WebAuthn separates user verification from concrete identification. When two or more ceremonies with user verification occur with a credential, the result can express that the same user performed them. The same user may not always be the same natural person if multiple natural persons share access to the authenticator.
That is a technical identity limit. It does not establish whether a biometric or passcode can be compelled, what legal protection applies, or how a border authority may treat a device. Those are legal and jurisdiction-specific questions rather than conclusions supplied by the WebAuthn standard.
This page does not turn a technical verification property into legal advice or a promise about compelled access.
- WebAuthn limit: user verification does not concretely identify a natural person to the relying party.
- Credential continuity: repeated verified ceremonies can indicate the same user performed them.
- Shared-authenticator limit: the same user may not always be the same natural person.
- Legal boundary: no compelled-unlocking rule follows from the technical verification statement.