Beyond the password · 5 min read

Passkeys explained: public keys instead of passwords

What a passkey actually is, how a login works step by step, why a look-alike site gets nothing, and what NIST says about passkeys that sync.

A passkey is a login credential made of a key pair instead of a shared secret. Your device keeps a private key that never leaves it in usable form; the website keeps only the matching public key. To sign in, your device proves it has the private key by signing a fresh challenge. There is nothing for you to type and nothing secret stored on the server.

“Passkey” is the everyday name. Technically, a passkey is a discoverable public key credential as defined by the W3C Web Authentication specification (WebAuthn), which browsers implement, working with authenticators that follow the FIDO Alliance’s CTAP protocol. Together these are often called FIDO2.

How a login works

Registration happens once per account:

1. The site asks the browser to create a credential and passes its Relying Party ID (RP ID), essentially its domain, for example example.com.
2. The authenticator (the phone, the computer’s secure hardware, a password manager, or a USB or NFC security key) asks you to confirm, usually with a fingerprint, face or device PIN.
3. It generates a new key pair just for this site and account, stores the private key with the RP ID, and returns the public key.
4. The site stores the public key against your account.

Authentication happens at each login:

1. The site sends a random challenge.
2. The browser adds the page’s actual origin, such as https://example.com, and passes the request to the authenticator along with the RP ID.
3. The authenticator finds the private key for that RP ID, asks you to confirm, and signs the challenge together with the site data.
4. The site checks the signature with the stored public key, checks that the challenge is the one it just issued, and checks that the origin is its own.

The fingerprint or face check in step 3 stays on your device. It unlocks the private key locally; the site never sees it. NIST counts this as multi-factor: something you have (the device with the key) activated by something you are or know.

Why phishing fails

The WebAuthn specification states the rule plainly: “A public key credential can only be used for authentication with the same entity (as identified by RP ID) it was registered with.” By default the RP ID is the domain of the page that asked, and a page may only claim its own domain or a parent of it.

Suppose a phishing email leads to examp1e.com (digit one), a perfect copy of the real login page. When that page calls WebAuthn, the browser sets the RP ID to examp1e.com. Your authenticator has no credential for examp1e.com, so there is nothing to offer. Even if the page tried to relay a challenge from the real site, the browser would write https://examp1e.com into the signed data, and the real site would reject it.

No step depends on you noticing the wrong address. That is the property NIST calls phishing resistance, and it names WebAuthn as its example of “verifier name binding”: the authenticator chooses “an authenticator secret based on the authenticated domain name of the verifier.” Typed codes, by contrast, can be relayed (see two-factor authentication explained).

What a server breach exposes

Because the site stores only public keys, a stolen database contains nothing to guess.

Worked example: password database versus passkey database

Take a password made of 4 random EFF words, 51.70 bits. If the site stored it with a fast unsalted hash and the database leaked, the site’s fast-hash illustration (10^11 guesses per second) puts the average time to crack it at about 5.1 hours. With a slow, salted hash it is about 5,800 years at 10,000 guesses per second. Either way, the attacker has something to work on offline (see how breaches expose passwords).

A leaked passkey database holds public keys. A public key does not let anyone sign as you, and there is no guessable secret behind it to attack offline.

What about recording a valid signature and replaying it later? NIST requires the challenge to be at least 64 bits and unique or random. A recorded signature matches only its own challenge, so a replay works only if the server happens to issue that exact challenge again: a chance of 1 in 2^64, about 1 in 1.8 × 10^19, or 5.4 × 10^-20 per attempt.

Synced and device-bound passkeys

WebAuthn distinguishes credentials that may be backed up from those that may not. The specification calls them multi-device credentials (“commonly referred to as synced passkeys”) and single-device credentials (“commonly referred to as device-bound passkeys”).

• Synced passkeys are copied, encrypted, through a sync service to your other devices. Lose a phone and the passkey is still on your other devices.
• Device-bound passkeys live in hardware that will not export them, such as a dedicated security key. Lose the device and the credential is gone, so you need a second key or another way in.

The authenticator reports which kind it is through two flags in the data it signs: Backup Eligible (the credential can be synced) and Backup State (it currently is).

What NIST says about syncing

NIST SP 800-63B-4 added an appendix on syncable authenticators. Its main requirements for keys stored in a “sync fabric” (for example, cloud storage):

• Synced keys “SHALL only be stored in an encrypted form using a key with the minimum security strength” of 112 bits, and “SHOULD be encrypted using a method that employs a user-controlled secret.”
• Signing happens on the local device, with keys “generated on-device or recovered from the sync fabric.”
• Access to the keys in the sync fabric “SHALL be protected by AAL2-equivalent MFA.”

Its conclusion: synced passkeys can support NIST’s middle assurance level, AAL2, but “syncing violates the non-exportability requirements of AAL3,” the highest level. Device-bound keys in non-exportable hardware are what AAL3 requires.

NIST is also candid about a trade-off: some sync systems let people share passkeys with others, and NIST advises public-facing services to “assume that all syncable authenticators may be subject to sharing.” It adds that the same is true of passwords and codes.

Practical edges

• Account recovery still matters. If every device holding a passkey is lost and nothing else is set up, the account falls back to whatever recovery path the site offers. See recovery codes and backups.
• Passwords often remain. Many sites keep a password as an alternative sign-in method. While it exists, it can still be phished or reused, so it still needs to be unique and random.
• Cross-device sign-in lets a phone approve a login on a nearby computer, usually by scanning a QR code. NIST describes how this works: a QR code starts the connection and a short-range wireless link such as Bluetooth Low Energy confirms the phone is physically nearby, which “reduces the potential for phishing attacks that might otherwise associate the authenticator with an attacker endpoint.”

Passkeys and password managers are not rivals. Many managers can store passkeys alongside passwords, and the same domain matching that limits autofill also governs which passkeys a page can request.

General explanation, not advice for a particular situation. Updated 2026-10-31.