Passkey
A cryptographic credential that lives on the device and replaces the password. How it works, what changes when it syncs across devices, and what happens the day the phone is lost.
In short
A passkey is a cryptographic credential bound to a site and held by an authenticator, which replaces the password. It is a FIDO2 credential: the device keeps a private key, the site keeps the matching public key, and signing in consists of signing a challenge with the former.
To the user, all of that looks like unlocking the phone. To the site, it means it no longer holds any secret that could leak.
What happens when someone signs in with a passkey
The sequence is brief, and each step explains one property of the mechanism.
- The site sends a challenge. Random data, different on each attempt, which prevents reusing a previous response.
- The device asks to unlock. Face, fingerprint or the device PIN. That check is local: it authorizes use of the private key.
- The authenticator signs. The private key is never sent to the site, not even at this step.
- The site validates the signature with the public key it stored at registration.
From this follows what gets misunderstood most: the biometric trait does not go anywhere. It is not sent to the site, it is not stored in its database and it is not part of the protocol. All it does is unlock a key that was already on the device.
Syncing solved adoption and moved trust
Early FIDO credentials were locked to the device where they were created. Losing the device meant losing access, and that held back mass adoption for years.
Syncable passkeys solved it: the platform backs up the credential and replicates it across the same person's devices. The trade-off is that the security of access now also depends on the platform account that syncs it. Whoever recovers that account recovers the passkeys it holds.
That is why it is worth keeping the distinction in mind:
- Syncable passkey — replicates across the person's devices through the platform. It is convenient, survives losing the device and inherits the security of the platform account.
- Device-bound passkey — does not sync and never leaves the device where it was created. It is more restrictive and does not hand trust to any third party. It is the format usually required in high-risk scenarios.
A team evaluating passkeys for a regulated product has to know which of the two it is accepting, because they do not answer the same way to an auditor.
Recovery is where everything gets decided
Phishing stops working against a passkey, because the credential is bound to the domain that registered it and the browser will not offer it to a lookalike site. Credential stuffing makes no sense either: there is no password to try at scale.
The attacker then does the reasonable thing, which is to stop attacking access and attack recovery instead. And recovery is where many implementations leave a backup password, an OTP by SMS or a secret question. The real security level of access ends up being that of the weakest path, not that of the passkey.
Done well, access recovery stops being a question of credentials and goes back to being a question of identity: whoever is asking to recover has to be re-established as the account holder. That check is an identity verification, with a document and presence, not a second factor. It is the same problem sign-up solves, which is why a consolidated digital identity makes the difference: the evidence gathered at registration is what makes it possible to recognize the account holder once they no longer have their device.
Frequently asked questions
It is a cryptographic credential that replaces the password, bound to a site and held by an authenticator. The authenticator stores a private key that is never sent to the site, the site stores the public key, and signing in consists of using the private key to sign a random challenge the site sends. Technically it is a FIDO2 credential, and what the industry added on top of the standard is the option to sync it: a syncable passkey replicates in encrypted form across the same person's devices through the platform, while a device-bound passkey never leaves the device where it was created. The distinction changes the recovery model, and it is worth knowing which of the two is being registered.
No. The biometric trait is compared locally on the device, and its only function is to unlock the private key already stored there. The site never receives the biometric data: it receives a cryptographic signature. That is an important difference from the intuitive idea that a face gets sent to a server for comparison.
It depends on which type of passkey was registered. If it is syncable, the credential is backed up by the platform and is recovered by signing in to the platform account from another device. If it is device-bound, it is lost, and you have to go through the site's recovery process. That process is the part worth watching most carefully: if recovery hands back access with an SMS code or a secret question, the effective security of the account is that of that path, not that of the passkey.
