Passkeys replace the password with a cryptographic key pair that is created on your device and never leaves it. The website keeps only the matching public key, so there is no shared secret for a phishing page to steal, and a server breach yields nothing an attacker can sign in with. That single change reshapes the sign-in step and also the way accounts are recovered.
What a passkey actually is
A passkey is a credential built on the FIDO2 set of standards. FIDO2 has two halves: WebAuthn, the browser API standardised by the W3C, and CTAP, the protocol that a browser or operating system uses to talk to an external authenticator such as a USB security key. The FIDO Alliance, which runs the certification programme, describes a passkey as a credential that can live on a phone, a computer or a hardware key (fidoalliance.org).
Two roles matter. The authenticator is whatever holds the private key: the secure chip in a phone, a laptop security module, a password manager, or a separate security key. The relying party is the website. At registration, the authenticator generates a fresh key pair for that site and returns only the public key. Because each site gets its own pair, the same device signing in to many services does not link those accounts together.
What happens when you sign in
Sign-in is a challenge and response exchange. The site sends a random challenge, the authenticator signs it with the private key after a local check such as a fingerprint, face scan or PIN, and the site verifies the signature against the public key it stored earlier. The WebAuthn specification requires the browser to bind that signature to the page’s real origin (w3.org), so a credential created for one domain will not produce a valid result on a lookalike domain.
That binding is where the phishing resistance comes from. A fake login page never receives a password to harvest, and a captured response cannot be replayed because every challenge is new. It also limits the damage of a database leak: the server holds public keys, and public keys cannot be used to sign in.
Synced passkeys or a hardware key
Passkeys come in two practical flavours, and the difference decides what happens when a device is lost.
| Type | Where the private key lives | Survives device loss | Main trade-off |
|---|---|---|---|
| Synced passkey (platform keychain or password manager) | Copied to your other devices through the provider’s sync service | Yes | The provider account becomes part of your login security |
| Device-bound key (hardware security key) | Inside the key, never exported | No, unless a spare key is enrolled | Strong for high-value accounts, but you must carry it and plan for loss |
Most consumer accounts are a good fit for the synced kind, because losing one phone does not lock you out. Infrastructure and administrative accounts usually suit a device-bound key, since the credential cannot be copied by malware that reads the disk.
Where the model is still weak
NIST’s digital identity guidance treats verifier impersonation resistance and a genuine user-verification step as the properties that matter for authenticators (pages.nist.gov). The login itself is strong, but it is only one path into an account, and the other paths stay open.
- Recovery flow. If the “add a new device” or “forgot password” route is guarded only by an email link, attackers aim there instead of at the login screen.
- Password fallback. Many services keep password sign-in switched on next to passkeys. The account stays phishable through the route that still accepts a typed secret.
- Compromised device. A passkey signs what the browser asks it to sign, so malware already running on the enrolled device can ride an authenticated session.
- Sync provider account. A synced passkey is only as strong as the account that controls the sync store.
Two habits follow from that list. Enrol more than one authenticator so a single loss is not a lockout, and treat the recovery route as part of the security model rather than an afterthought bolted on later.
Bottom line: passkeys take the shared secret out of sign-in and replace it with a key pair that a phishing site cannot copy or replay. They do not remove recovery, fallback logins or device security from the picture, so the strongest setup pairs two enrolled authenticators with a hardened recovery path.