Somewhere in your users table is a bcrypt hash that will eventually leak, get cracked, and be replayed against every other site its owner reused it on. That's not pessimism; it's the operating history of the password. Phishing, credential stuffing, database breaches — every major account-takeover vector traces back to the same root cause: a shared secret that users must remember and type.

1. Why passwords lost

We spent two decades patching the password: complexity rules (users appended "!1"), rotation policies (users incremented a number), TOTP codes (phishable in real time), SMS codes (SIM-swappable). Each patch added friction without removing the core flaw — anything the user can type, an attacker can trick them into typing somewhere else.

2. How passkeys actually work

A passkey is a public/private key pair, created per site, stored by the user's device or password manager, and exercised through the WebAuthn browser API.

  1. Registration: your server sends a challenge; the authenticator (phone, laptop, security key, password manager) generates a key pair scoped to your domain, keeps the private key, and returns the public key for you to store.
  2. Sign-in: your server sends a fresh challenge; the authenticator signs it with the private key after local user verification (Face ID, fingerprint, PIN); your server verifies the signature with the stored public key.

Three properties fall out of this design, and they're the whole story:

  • Nothing secret on your server. A breach of your database yields public keys — useless to an attacker.
  • Unphishable by construction. The credential is bound to your origin. A pixel-perfect fake site on a lookalike domain receives nothing, because the browser won't offer the passkey there.
  • Nothing to remember. Biometric unlock is the entire user ceremony — faster than typing a password, which is why conversion data keeps favouring passkeys.

Synced passkeys (iCloud Keychain, Google Password Manager, 1Password, Bitwarden) solved the "I lost my phone" problem that killed earlier hardware-bound schemes; cross-device sign-in via QR + Bluetooth covers the borrowed-laptop case.

3. Shipping passkeys without a big bang

You don't migrate to passkeys; you grow into them. The staged rollout that works:

  1. Add, don't replace. Offer "Create a passkey" after a successful password sign-in — the moment of highest trust and lowest friction.
  2. Prefer at sign-in. Support conditional UI (passkey autofill) so returning users get one-tap sign-in. Password remains a fallback.
  3. Harden the fallbacks. A passkey account with password reset via email is only as strong as the email account. Progressively gate resets for passkey users behind stronger verification.
  4. Measure. Track passkey adoption, sign-in success rate and support tickets. Expect sign-in success to rise — forgotten-password resets are usually your worst funnel step.

On the backend, don't hand-roll WebAuthn verification — use a maintained library (simplewebauthn, webauthn4j, fido2-net-lib) or your identity provider's built-in support. The protocol has real cryptographic sharp edges (challenge reuse, origin validation, counter handling) that libraries get right for you.

4. Gotchas from real deployments

  • Name your credentials. Users create passkeys on multiple devices; show them a management screen with device names and creation dates or support tickets follow.
  • Enterprise edge cases. Some corporate-managed browsers disable passkey sync; keep an alternative strong factor for that population.
  • Account recovery is now your weakest link. Decide deliberately what "I lost everything" looks like — typically two independent factors or a delay-plus-notification flow. Don't let a support agent become the bypass.

5. The questions your team will ask

"Is it a biometric database?" No — biometrics never leave the device; they only unlock the local key.

"What if Apple/Google lock a user out?" Multiple passkeys from independent ecosystems (plus a password manager) mitigate platform lock-in; encourage registering more than one.

"Is it worth it for a small product?" If you have accounts worth stealing, yes — and since every major browser, OS and password manager now ships support, the implementation cost has collapsed to roughly "one good sprint".

The password had a fifty-year run. Its replacement is finally both safer and easier — the combination that actually changes user behaviour.