Passkeys Explained: Killing the Password for Good

The password has had a remarkable run for something nobody likes. It is the default way we prove who we are online, and it is also the single most reliable way attackers break in. The numbers are grim in a boringly consistent way: year after year, stolen or reused credentials sit at the top of the breach-cause charts, and “the user was phished” remains the entry point behind a huge share of successful account takeovers. Passkeys are the industry’s serious attempt to retire the password, and unlike most “the password is dead” headlines of the past decade, this one is actually shipping — Apple, Google and Microsoft all support it, and thousands of sites now offer it. Here is what a passkey is, why it is so much harder to steal than a password, and, honestly, where it still falls short.

Why Passwords Fail

Passwords fail for reasons that have nothing to do with how clever you are at choosing them. The first problem is phishing. A convincing fake login page asks for your password, you type it in, and the attacker now has it. No amount of length or special characters helps, because you handed it over willingly to the wrong door.

The second problem is reuse. There are too many accounts and only one human memory, so people recycle the same password across dozens of sites. When one of those sites is breached, attackers take the leaked password and try it everywhere else, a tactic called credential stuffing. The third problem is breaches themselves: every password you have ever set is stored somewhere, and “somewhere” gets hacked with depressing regularity. Even hashed passwords can be cracked offline given enough time and a weak choice.

The common thread is that a password is a shared secret. Both you and the server know it, which means it can be intercepted, guessed, leaked, or tricked out of you. Passkeys break that pattern entirely.

What a Passkey Actually Is

A passkey is built on public-key cryptography, standardised under the names FIDO2 and WebAuthn. Instead of one shared secret, your device generates a pair of keys when you register with a site: a private key and a public key.

The public key is mathematically linked to the private key, but you cannot derive one from the other. So the split of duties is simple. The website keeps your public key. Your device keeps the private key. The crucial property is this: the private key never leaves your device. It is not transmitted, not stored on the server, and never typed into a form. There is no shared secret to steal, because the only secret lives in one place and never moves.

1
2
3
4

Registration
  device  →  generates (private_key, public_key)
  device  →  sends public_key to website
  device  →  keeps private_key, locked in secure hardware

If a website storing passkeys is breached, the attacker walks away with a pile of public keys, which are useless on their own. A breach that once leaked millions of crackable passwords now leaks the cryptographic equivalent of a list of padlocks with no keys to fit them.

How a Passkey Login Works

Logging in with a passkey is a challenge-and-response. The site does not ask “what is your secret?” but rather “prove you hold the matching private key”, without the key ever being revealed.

1
2
3
4
5
6

Login
  website →  sends a random challenge
  device  →  signs the challenge with private_key
  device  →  returns the signature
  website →  verifies the signature using public_key
            ✓ signature valid → you are who you claim

Because the challenge is random and different every time, a signature captured from one login is worthless for the next. There is nothing to replay, nothing to phish, and nothing on the server worth stealing. The whole exchange happens in a fraction of a second, and from your point of view you simply tap a prompt.

Biometrics Are a Local Unlock, Not a Transmission

A persistent misconception is that passkeys “send your fingerprint to the website”. They do not. Your face or fingerprint is used locally, on your own device, purely to unlock the private key so it can sign the challenge. The biometric data never travels across the network and the website never sees it.

Think of the fingerprint as the way you open your own safe at home. The bank you are logging into never receives the fingerprint, never stores it, and would not know what to do with it if it did. This separation matters: even an organisation you do not fully trust gains nothing biometric about you. The face unlock is between you and your hardware; the cryptography is what crosses the wire.

Synced Versus Device-Bound Passkeys

Passkeys come in two flavours, and the difference is mostly about convenience versus assurance.

Synced passkeys are backed up to a cloud keychain, Apple’s, Google’s, a password manager’s, and encrypted end-to-end so the provider cannot read them. Buy a new phone, sign in to your account, and your passkeys reappear. This is what makes passkeys usable for ordinary people: lose your device and you have not lost your logins.

Device-bound passkeys never leave the single piece of hardware that created them, often a physical security key. They offer the highest assurance, because there is exactly one copy in the world, but they put the burden of backup squarely on you. Most consumers will, and should, use synced passkeys. High-security environments may prefer device-bound. Both use the identical underlying cryptography; they differ only in where the private key is allowed to live.

Phishing Resistance, by Design

The standout property of passkeys is that they are phishing-resistant by design, not by user vigilance. During registration and login, the passkey is bound to the website’s actual domain. The browser and operating system enforce this binding behind the scenes.

So if you land on a lookalike site at a near-identical address, your device simply will not offer the passkey. There is no matching credential for the fraudulent domain, so there is nothing to hand over, and nothing for you to fat-finger into the wrong box. The entire category of “user was tricked into entering credentials on a fake page” disappears. You cannot give away what the system refuses to release.

This domain-binding is enforced through the browser’s WebAuthn API, and it inherits the same same-origin thinking that governs the rest of the web platform — the browser is the referee that knows which origin it’s actually on. If you’ve ever wrestled with how the browser scopes credentials and state to a domain, the mechanics will feel familiar from how cookies work on the internet: both hang on the browser’s authoritative view of the current origin, and both fall apart for an attacker precisely because they can’t fake it. It’s also why implementing passkeys on your own site is more pleasant than the old password dance — the heavy cryptography lives in the browser and OS, and your front-end code mostly orchestrates a couple of async calls. That said, the WebAuthn JavaScript API has enough sharp edges and inconsistent browser behaviour to earn a chapter in any honest good, bad and ugly tour of JavaScript; the promise-based navigator.credentials flow is elegant on paper and fiddly in practice.

Where Passkeys Still Fall Short

Passkeys are excellent, not perfect, and pretending otherwise helps nobody.

Recovery is the hard problem. If your secret is bound to hardware, what happens when the hardware is lost, stolen, or bricked? Synced passkeys lean on your cloud account, which means the security of your entire login estate can collapse back to the strength of that one account’s recovery process. Many services still keep a password or SMS code as a fallback, quietly reintroducing the very weakness passkeys were meant to remove.

Account sharing is awkward. Households that cheerfully share one streaming password find passkeys, which are tied to individual devices and biometrics, distinctly uncooperative. The model assumes one identity, one person.

Ecosystem lock-in is real. Moving passkeys between an Apple keychain, a Google account, and a third-party manager has improved but is still not seamless. There is a genuine risk of finding your keys comfortably trapped inside one vendor’s walled garden.

Coverage is uneven. Not every site supports passkeys yet, so for now you will run both systems side by side rather than deleting the password manager.

When It Goes Wrong: The Practical Snags

Passkeys are largely invisible when they work, which makes the failure modes disorienting. A few worth knowing before they catch you out.

“There’s no passkey for this site” on the right domain. Usually a sync gap: you created the passkey on one device and the keychain hasn’t propagated it yet, or you’re signed into a different account on the current device than the one that holds it. Check which cloud account is active before assuming the passkey is gone.

Cross-device sign-in that won’t connect. When you use a passkey on a laptop by scanning a QR code with your phone, the two talk over Bluetooth (the hybrid transport). If it stalls, it’s almost always Bluetooth being off, or the two devices being too far apart. It is deliberately a proximity check — inconvenient, but that’s the anti-relay design doing its job.

A shared family device. Passkeys tie to individual accounts and biometrics, so the household laptop that everyone logs into becomes awkward. The clean answer is separate OS user profiles, though that’s more discipline than most families want. Weighing that kind of “is the upgrade actually worth the friction” trade-off is a recurring homelab theme — the same judgement I apply in the home-lab upgrade trap, where newer is not automatically better if it complicates the humans using it.

Losing the phone with no fallback. This is the one that genuinely hurts. If your only passkey lived on a single device with no synced backup and no recovery codes, you’re locked out. Which is exactly why the next section exists.

How to Start Using Them

You do not need to convert your entire digital life overnight. Begin with the accounts that matter most: email, banking, and your primary cloud account, since these are the ones that unlock everything else.

Visit the security settings of each, look for “passkeys” or “sign in without a password”, and follow the prompt to create one. Your device handles the cryptography; you just confirm with a tap or a glance. Keep a sensible recovery method in place, a hardware key in a drawer, or trustworthy backup codes, so that a lost phone is an inconvenience rather than a lockout. Then add passkeys to other services as they offer them.

The Bottom Line

Passwords fail because they are a secret you share, and anything shared can be stolen. Passkeys replace that shared secret with a private key that never leaves your device and a public key that is worthless to thieves, wrapped in a login flow that simply refuses to work on a fake site. The remaining rough edges, recovery, sharing, and lock-in, are real and worth watching, but they are problems of polish rather than principle. For the first time, “the password is dead” looks less like a slogan and more like a forecast.