Explainer · 7 June 2026

How passkeys and WebAuthn work

A passkey is a modern login credential built on public-key cryptography instead of a reusable password. When you sign in with Face ID, Touch ID, or a hardware security key, your browser or phone runs a WebAuthn ceremony defined by the FIDO2 standards. The website never sees your private key — only a signature proving you control a keypair registered to that exact origin. That design closes the phishing hole that still defeats passwords, SMS codes, and many authenticator apps. Passkeys are not a replacement for self-custody crypto keys — see our Solana wallet security guide for why a seed phrase is a different threat model — but they are the best mainstream fix for account takeover on banks, email, and exchanges.

Why passwords keep failing

Passwords are shared secrets. You type the same string on every login, so any fake login page that looks convincing can harvest it. Users reuse passwords across sites, so one database breach unlocks dozens of accounts. SMS two-factor helps until attackers SIM-swap your phone number or trick you into typing a one-time code into a phishing site in real time.

Passkeys flip the model: authentication uses asymmetric cryptography. The server stores a public key; your device holds the private key inside a secure enclave (Apple Secure Enclave, Android StrongBox, TPM on Windows, or a FIDO hardware token). Login becomes "prove you can sign this challenge with the private key" — not "repeat a secret string the attacker can copy."

WebAuthn in two ceremonies

Browsers expose WebAuthn through navigator.credentials.create() (registration) and navigator.credentials.get() (authentication). Both are called ceremonies because the browser, operating system, and authenticator coordinate steps the web page cannot shortcut.

Registration (creating a passkey)

You choose "Create passkey" on a site that supports WebAuthn.
The server sends a challenge (random bytes) plus your account id and the site's relying party ID (usually the registrable domain, e.g. example.com).
The OS prompts for biometrics or PIN, then generates a new keypair bound to that relying party.
The authenticator returns the public key and an attestation (optional proof of authenticator model) to the browser, which forwards it to the server.
The server stores the public key and a credential id. Your private key never leaves the secure module.

Authentication (signing in)

You enter a username or the site offers passkey autofill from a saved credential.
The server sends a fresh challenge and lists acceptable credential ids.
The OS unlocks the matching private key after biometrics/PIN.
The authenticator signs the challenge; the server verifies the signature with the stored public key.

Each login uses a one-time challenge, so a recorded signature cannot be replayed on another session. That is a meaningful upgrade over static passwords and over TOTP codes that phishers can relay within the 30-second window.

Platform passkeys vs roaming authenticators

Platform authenticators are built into the device you already use — iPhone Face ID, Mac Touch ID, Windows Hello. The passkey lives in Apple's iCloud Keychain, Google's Password Manager, or Microsoft's sync vault when you enable cross-device backup. Convenience is high: scan a QR code to sign in on a laptop with your phone, or autofill from the same ecosystem.

Roaming authenticators are separate hardware — YubiKey, Feitian, or similar FIDO2 keys. They plug in via USB or tap over NFC. They do not sync through a cloud backup by default; you carry the key or keep spares. Enterprises and high-risk individuals often require roaming keys because compromise of a synced platform passkey vault (rare but catastrophic) is a single point of failure.

Both types speak the same WebAuthn protocol. Sites can allow multiple credentials per account — for example a platform passkey on your phone plus a hardware backup key in a drawer. That redundancy mirrors the cold/hot split in wallet security hygiene, but with vendor-mediated recovery instead of a paper seed phrase.

Phishing resistance: origin binding

The property that makes passkeys resist credential phishing is origin binding. During registration, the authenticator records the relying party id. During authentication, the browser only offers credentials that match the current site's origin. If you land on examp1e.com instead of example.com, the ceremony fails — there is no password to type anyway, and the wrong site's challenge will not unlock your real credential.

This does not stop every attack. Malware on your device, a stolen unlocked phone, or social engineering that tricks you into approving a real login on a legitimate site you did not intend to use are still risks. Passkeys also do not fix server-side breaches of session cookies or OAuth tokens after you are already logged in. They specifically harden the initial authentication step that passwords and SMS mishandle.

Synced passkeys and recovery

Apple, Google, and Microsoft market synced passkeys — credentials encrypted end-to-end and replicated across your devices when you are signed into the same account. Lose one phone, sign in on a new one with your Apple ID, and passkeys reappear after restore. That feels like magic compared to memorizing passwords, but the recovery root is now your cloud account password plus its 2FA, not a hardware token alone.

Practical recovery checklist:

Register at least two credentials on important accounts — phone plus hardware key, or two phones in different ecosystems if the service allows.
Print or store backup codes where the service still offers them; passkeys do not eliminate account-recovery codes for every provider yet.
Know whether your passkeys sync through iCloud/Google — losing that cloud account without backup can lock you out even if individual devices are fine.
For work accounts, follow IT policy on managed devices; corporate MDM can wipe passkeys with the device.

Crypto wallets deliberately avoid this model: a BIP-39 seed has no "forgot password" vendor. Passkeys trade absolute self-custody for recoverability through big-tech identity platforms — a trade most web users want for email, not for on-chain savings.

Passkeys vs crypto wallet keys

It is easy to conflate passkeys with blockchain wallets because both use keypairs. They are not interchangeable:

Who holds the key? Passkey private keys stay in OS secure hardware; wallet seeds are often exported to paper or typed into software — you custody them directly.
What does the signature mean? WebAuthn signs an authentication challenge for a website. A Solana transaction signature authorizes token transfers on a public ledger — see verify Solana payments for reading those on-chain.
Recovery: Passkeys can sync via Apple/Google; wallet recovery is only your seed phrase or hardware backup — no help desk.
Phishing: Passkeys bind to web origins; wallet drains use malicious transaction previews — defense is simulation and skepticism, not WebAuthn.

Some products experiment with passkeys to protect exchange logins or to wrap cloud backup of wallet keys. Treat those as layered products with their own vendor risk, not as a change to on-chain custody rules.

Adoption limits in 2026

Passkeys work well on modern Chrome, Safari, Edge, and Firefox with platform authenticators. Friction remains on shared computers, legacy enterprise apps that only accept passwords, cross-ecosystem moves (Android phone to Windows PC without QR hybrid transport), and international users on older devices without secure enclaves.

Developers integrate via server libraries (SimpleWebAuthn, java-webauthn-server, etc.) and must store public keys, count sign-in failures, and offer fallback factors during migration. Users should enable passkeys on high-value accounts first — email, password manager, exchange, bank — because those are the keys that reset everything else.