A passkey is a FIDO credential that uses public-key cryptography instead of a password. A site stores the public key at registration. The assertion signature does not sign the challenge string by itself: the authenticator signs authenticatorData || clientDataHash with the credential private key, where clientDataHash is the SHA-256 hash of the serialized clientDataJSON. The challenge and origin are in clientDataJSON; the RP ID hash is in authenticatorData. The server validates those values separately and verifies the signature with the registered public key. The private key itself is not sent to the service. See the signing-data description in W3C WebAuthn Level 3. The FIDO Alliance passkey guide explains synced and device-bound experiences.

The assertion signs data that binds the challenge

During registration, the relying party asks the browser to create a credential. An authenticator generates a key pair and returns a public-key credential. The service stores the credential ID, public key, and account association needed for later verification. At sign-in, the server issues a fresh challenge; after user verification, the authenticator returns a signed assertion. The server checks the challenge, origin, relying-party ID, and signature against the stored public key. This is not a login flow in which the website receives a fingerprint or PIN.

Sync status and discoverability are separate properties

A synced passkey can be made available on other devices connected to the same passkey provider. A device-bound credential remains tied to its authenticator, so losing that device can mean losing access unless another credential was registered. FIDO Alliance deployment guidance notes that syncing can ease device replacement and recovery, but provider-account access and device compatibility can still affect restoration.

In WebAuthn, a discoverable credential is one the authenticator or client can find without the relying party first supplying its credential ID. “Resident key” is the historical term for this discoverability property. By contrast, backup-eligible/multi-device versus single-device describes whether a credential can be backed up or synchronized. A discoverable (formerly resident) credential is therefore not necessarily device-bound.

What the service must verify

Issue a fresh, unpredictable challenge for each ceremony and reject reuse. Check that the response’s origin and relying-party ID match the expected site, then verify the signature using the public key registered for that account. Store the credential identifier and public key with the account; a user-facing label and registration date can help people recognize and manage multiple credentials. Follow a maintained WebAuthn implementation and browser documentation rather than treating signature parsing alone as sufficient verification.

Plan recovery during enrollment

If people may replace devices or switch provider ecosystems, offer a second passkey or a documented account-recovery route before they need it. A synced passkey may still be inaccessible if the user loses access to the provider account or moves to a device that does not support that provider. A service that relies on device-bound credentials should explain how to add another authenticator and what happens after device loss. FIDO guidance recommends considering alternate authentication and recovery whether the passkey is synced or device-bound.

Sources