Passkeys Explained: Why Passwords Are Finally Being Replaced

0 14 8 minutes read

Key takeaway: A passkey is a private key on your device that never transmits anywhere and is cryptographically bound to a specific website. Phishing fails not because users detect it, but because the credential mathematically cannot be used on the wrong domain.

Why Passwords Cannot Be Fixed

Every password problem traces to one structural fact: authentication requires sending a secret to the party verifying it.

That single property generates the entire catalogue of failures. The secret can be intercepted in transit. It can be stolen from the server’s database. It can be captured by a convincing replica of the login page. It can be reused across sites, so a breach anywhere becomes a breach everywhere. And because humans must remember it, it will be simple enough to guess or stored somewhere insecure.

Decades of mitigation have addressed symptoms without touching the cause. Complexity requirements produced predictable substitutions and a note in a desk drawer. Rotation policies produced incrementing numbers. Hashing protects the database but not the login form. Password managers genuinely help and still transmit the secret. Multi-factor authentication adds a second secret, which is a real improvement and still a transmitted secret.

Passkeys change the property rather than the mitigation. The secret never leaves your device — not to the server, not to anyone. What travels is a proof that you hold it.

What a Passkey Actually Is

Underneath the branding, a passkey is a public-private key pair generated on your device for one specific website.

Registration works like this. Your device generates a fresh key pair for example.com. The private key stays on the device, protected by hardware and unlocked by biometric or PIN. The public key goes to the server, which stores it against your account. Public keys are not secrets — a breached database of public keys gives an attacker nothing usable.

Authentication works like this. The server sends a random challenge. Your device asks you to confirm with fingerprint, face, or PIN, then signs the challenge with the private key. The server verifies the signature against the stored public key. The private key never moves.

Registration
  device: generate key pair for example.com
  device: store private key in secure hardware
  device -> server: public key
  server: store public key for user

Authentication
  server -> device: random challenge
  device: verify user presence (biometric / PIN)
  device: signature = sign(challenge, private_key)
  device -> server: signature
  server: verify(signature, stored_public_key)

Three consequences follow immediately. A server breach exposes public keys, which are useless to an attacker. There is no shared secret to intercept in transit. And there is nothing for you to remember, type, or reuse.

The underlying standards are WebAuthn and FIDO2, which predate the passkey branding. “Passkey” primarily names the version of this technology with usable cross-device syncing — the change that made it viable for ordinary users rather than security specialists with hardware tokens.

The Anti-Phishing Property

This is the most important part and the part most explanations understate.

When your device creates a passkey, the key pair is bound to the site’s domain. That binding is enforced by the browser or operating system, not by the user’s judgement.

Consider a phishing attempt. You receive a convincing email and click through to examp1e-secure-login.com, a pixel-perfect replica. With a password, you type it and the attacker has it. With a one-time code, you type it and the attacker relays it within its validity window. With a passkey, your device looks for a credential registered to examp1e-secure-login.com, finds none, and offers nothing. There is no field to fill in, no code to relay, and no decision for you to get wrong.

The attacker cannot request the example.com passkey either, because the browser will not release a credential to a domain that does not match. This is not a warning the user can click through. It is a refusal at the protocol layer.

That distinction — protection by construction rather than by vigilance — is what makes passkeys categorically different from previous improvements. Every prior anti-phishing measure depended on the user noticing something. This one does not require the user to notice anything at all.

Why This Beats Every Form of MFA

Multi-factor authentication is a genuine improvement over passwords alone and remains vulnerable to a specific, widely-used attack.

Method	Phishable	Server breach exposes	Effort per login
Password	Yes	Hashes (crackable)	Type it
Password + SMS code	Yes (relay)	Hashes + phone number	Type both, wait
Password + authenticator app	Yes (relay)	Hashes + seed	Type both
Password + push approval	Yes (fatigue)	Hashes	Tap approve
Passkey	No	Public keys (useless)	Biometric

The relay attack applies to every code-based method. An attacker proxies the real login page, you enter your password and your one-time code into their replica, and they forward both to the genuine site within the code’s validity period. The code being time-limited and single-use does not help, because the attacker uses it immediately. Real-time phishing kits automating exactly this are widely available and inexpensive.

Push approval fails differently. Repeated approval prompts sent at inconvenient hours produce eventual approval from fatigue. Number matching mitigates this and does not eliminate it.

Passkeys are immune to both because there is nothing to relay. The signature is computed over a server-provided challenge and is bound to the domain. A signature obtained by a phishing site is worthless to it and cannot be replayed elsewhere.

The secondary benefit is that a passkey is simultaneously both factors — possession of the device and a biometric or PIN. This is why login is a single biometric prompt rather than a password plus a code, and why passkeys tend to be faster than passwords in practice.

Synced Versus Device-Bound

Two variants exist, with a meaningful trade-off between them.

Synced passkeys replicate through a platform keychain across your devices. Register on your phone, sign in on your laptop. The private key is end-to-end encrypted in transit and at rest, with the platform vendor unable to read it. This is what most consumer passkeys are, and the syncing is precisely what made adoption viable — a credential that exists on exactly one device is a credential you lose with that device.

Device-bound passkeys never leave the hardware they were created on. Hardware security keys work this way. Higher assurance, because extraction requires physical possession and defeating the hardware. Less convenient, because you need that specific object, and losing it without a registered backup means losing access.

For most people and most accounts, synced passkeys are the right choice — the security improvement over passwords is enormous, and the residual risk of platform account compromise is manageable with a strong platform account. For high-assurance contexts, device-bound keys remain appropriate, typically two of them so one can be lost without lockout.

The trade-off is honest and worth stating plainly: synced passkeys move your trust to the platform vendor’s keychain security and to your platform account. That is a real dependency. It is also a dramatically better position than reused passwords, which is the realistic alternative.

The Recovery Problem

This is where passkeys are genuinely less mature, and pretending otherwise does readers no favours.

Password recovery is well-understood: a reset email, security questions, support intervention. It also happens to be how a large share of account takeovers occur, since the recovery path is frequently weaker than the login path.

Passkey recovery is less settled. If you lose access to your platform account, you may lose access to every passkey it held. And critically, if a service permits email-based recovery for passkey accounts, the phishing resistance is undermined at the weakest point — an attacker who compromises your email can register a new passkey and never needs to defeat the cryptography.

Current practices, none complete:

Register multiple passkeys per account. Phone plus laptop plus hardware key. Losing one is inconvenient rather than catastrophic. This is the best available answer and depends on services supporting multiple credentials, which not all do.

Protect the platform account rigorously. Since it holds the keychain, it becomes the highest-value target. A hardware key on the platform account itself is well-justified.

Retain recovery codes offline. Printed, stored physically. Unfashionable and effective.

Keep a password as fallback initially. Weakens the security model, since the account is only as strong as its weakest authentication path, and remains a pragmatic transition step for critical accounts.

An honest summary: passkeys substantially improve the login path and shift the residual risk to recovery and to platform account security. That is a favourable trade and not a complete solution.

What Adoption Looks Like in Practice

For someone implementing this, a sequence that works:

Offer passkeys alongside existing methods first. Do not remove passwords immediately. Let willing users register a passkey and observe the adoption rate and support load.

Prompt after successful login. The moment after a user authenticates with a password is the highest-conversion opportunity to offer a passkey, because the value proposition — never type this again — is immediately concrete.

Support multiple passkeys per account from the start. This is the primary recovery mechanism. Services allowing only one credential force users into a fragile position.

Do not weaken recovery to accommodate passkeys. If your recovery path is a single email link, phishing resistance on the login path buys less than it appears.

Detect platform support and degrade gracefully. Support is broad now and not universal, particularly on older devices and in managed enterprise environments.

Explain it without cryptography. “Sign in with your fingerprint instead of a password, and it cannot be phished” communicates the value. Public key cryptography does not.

Common Pitfalls

Calling passkeys “biometric login.” The biometric unlocks the local key. It never transmits and is not the credential. This misunderstanding drives most user resistance, because people reasonably object to sending their fingerprint to a website.

Allowing only one passkey per account. Guarantees eventual lockout complaints.

Leaving email recovery unhardened. The weakest path defines the account’s real security.

Assuming universal support. Retain a fallback for users whose environment cannot support passkeys.

Requiring device-bound keys for consumers. The support burden and lockout rate will exceed the security benefit for most consumer services.

Conclusion

Passkeys are the first authentication improvement in a long time that fixes a cause rather than a symptom. By never transmitting the secret and cryptographically binding credentials to domains, they eliminate phishing, credential stuffing, database-breach exposure, and password reuse simultaneously — not through user education but through protocol design.

The remaining weakness is recovery, which is real and being worked on. Register several passkeys per account, protect the platform account holding your keychain as the high-value target it is, and keep offline recovery codes for anything critical.

The genuinely notable part is that the more secure option is also the faster and easier one. That alignment is rare in security, and it is the reason this transition will actually happen rather than remaining a recommendation nobody follows.

Frequently Asked Questions

Does a website receive my fingerprint? No. The biometric unlocks the private key stored locally on your device. It never leaves the device and is never transmitted. The site receives only a cryptographic signature.

What happens if I lose my phone? With synced passkeys, they are available on your other devices signed into the same platform account. With device-bound passkeys, you need a previously registered backup credential or the service’s recovery process.

Can passkeys be stolen by malware? The private key lives in secure hardware and is not extractable by ordinary software. Malware on an unlocked device could potentially trigger authentication, but it cannot exfiltrate the key for use elsewhere — a substantially better position than a stolen password.

Do passkeys work across different platforms? Yes, though syncing does not cross ecosystems. Cross-device authentication uses a QR code and Bluetooth proximity check to sign in on a device that lacks the passkey. Registering a passkey per ecosystem is smoother in daily use.

Should I delete my password after adding a passkey? Eventually, though not immediately. Keep it until you have several passkeys registered and are confident in your recovery position. An account with both is only as strong as the weaker path, so removing the password is where the full benefit lands.

Is a hardware security key still worth buying? For high-value accounts, yes — particularly the platform account that holds your synced passkeys. That account has become the highest-leverage target in your setup and deserves the strongest available protection.

Why do some sites still not support passkeys? Implementation requires backend changes, recovery flow redesign, and support process updates. The standards are mature; organisational adoption is the bottleneck. Coverage has expanded considerably and remains uneven.