Passkeys explained: replacing passwords for good
Most account takeovers still begin the same way: someone types a password into a page that was not what it appeared to be. Passkeys remove that step entirely. There is nothing to type, and nothing stored on the server that is worth stealing. Support now ships by default across Apple, Google and Microsoft accounts, and the option is appearing on ordinary consumer sites, which makes it worth understanding before you are asked to switch.
What a passkey actually is
A passkey is a cryptographic key pair that your device creates for one specific website. The private half stays on the device, or inside the credential manager that syncs it. The public half goes to the website, which stores it roughly where a password hash used to sit, except this stored value is useless to anyone who steals it.
Signing in is a challenge and response. The site sends a random challenge. Your device asks you to confirm, usually with a fingerprint, a face scan or a device PIN, then signs that challenge with the private key. The site checks the signature against the public key it already holds. No secret crosses the network in either direction.
The underlying standards are WebAuthn, the browser API published by the W3C, and CTAP, which handles communication with security keys and phones. Together they sit under FIDO2, maintained by the FIDO Alliance. “Passkey” is simply the consumer-facing name for a discoverable WebAuthn credential, chosen because the technical vocabulary was doing the adoption no favours.
How it differs from a password
A password is a shared secret. You know it, the server holds a hash of it, and anything positioned between the two can potentially capture it. That single design choice produces most of the failures people already recognise: reuse across dozens of sites, credential stuffing after somebody else’s breach, and the fact that a leaked database has resale value.
Passkeys break the pattern in three specific ways.
Nothing is typed, so keyloggers, clipboard scrapers and someone reading over your shoulder lose their target. Nothing reusable is stored on the server, so a stolen table of public keys is not a shortcut into anything. And each credential is unique to one site by construction, which means reuse is not merely discouraged, it is impossible.
One detail is worth stating plainly because it is widely misread. Your fingerprint or face scan is not sent to the website. It unlocks the private key locally, on hardware built for that purpose. The site receives a signature and nothing else. Biometric data never leaves the device.
Why phishing stops working
This is the part that changes the security maths, and it deserves more attention than the convenience angle usually gets.
Every passkey is bound to the domain it was created for, recorded as the relying party identifier. A convincing lookalike domain cannot trigger a signature for the real one, because the browser checks the binding before anything is signed. The user does not have to notice the misspelling. The refusal happens without them.
Contrast that with the second factors most people currently use. A six-digit code from an authenticator app, or worse from SMS, can be relayed by an attacker running a proxy in real time: you enter the code on a fake page, the attacker forwards it to the real site within the validity window, and the session is theirs. This is not theoretical, it is the standard playbook for phishing kits sold as a service.
Passkeys resist that class of attack structurally, because correctness is enforced by software rather than by human judgment under time pressure.
Set the three approaches against the attacks that actually occur:
| Attack | Password alone | Password plus authenticator code | Passkey |
|---|---|---|---|
| Phishing page harvests credentials | Succeeds | Succeeds if the code is relayed in time | Fails, the credential is bound to the real domain |
| Server database is breached | Hashes exposed, crackable, reusable elsewhere | Same exposure, second factor still helps | Only public keys stored, useless to the attacker |
| Adversary-in-the-middle proxy | Succeeds | Succeeds, code forwarded in real time | Fails, the browser refuses to sign |
| Keylogger on the device | Succeeds | Captures both if on the same device | Nothing is typed to capture |
| Reuse across many sites | Common, and the basis of credential stuffing | Still possible | Impossible by construction |
The third column has one “succeeds” fewer than people expect, and the reason is the same in every row: the check is performed by the browser against the domain, not by a person against their own memory of what the site looked like.
Where passkeys still fail
The technology is genuinely better. It is not finished, and the gaps are worth knowing.
Recovery is the weakest link. If losing your device means recovering the account through an emailed link or an SMS code, then the real security ceiling of that account is the email inbox or the phone number, not the passkey. Any honest assessment starts there.
Sync and ecosystem friction. Passkeys are typically synced by a credential manager tied to a platform account or a password manager. Moving a set of credentials between ecosystems has improved but remains clumsy, and the experience differs enough between vendors to confuse people who use more than one.
Hardware-bound credentials can be lost outright. A passkey stored only on a physical security key, with no sync, disappears with the key. That is sometimes the point, for high-risk accounts, but it demands a deliberate backup plan.
Coverage is uneven. Many sites still do not offer passkeys. More importantly, many that do keep the password active as an alternative, which quietly preserves the entire attack surface you were trying to remove. A passkey alongside a password is a convenience upgrade, not a security one.
Shared and delegated access is awkward. Household accounts, team logins and anything involving handing access to someone temporarily fit the password model uncomfortably well and the passkey model badly.
How to start using them
Begin with the account that controls the others. For most people that is email, because it sits at the root of every password reset and recovery flow. Securing it first changes the outcome of everything downstream.
From there, a workable order: enable passkeys on the high-value accounts that support them, decide deliberately where they sync so you are not surprised on a new device, store recovery codes somewhere offline, and then, on sites that permit it, remove the password entirely. That last step is the one most people skip and the one that delivers most of the benefit.
If you use a password manager, check whether it stores passkeys as well. Keeping credentials in one place you already trust is usually better than spreading them across three platform accounts you have not thought about carefully.
The transition will be gradual, and for a few years you will hold both kinds of credential at once. That is fine. The direction is clear enough that learning the model now costs very little, and the phishing resistance alone justifies moving the accounts that would hurt most to lose.
Sources
- W3C, Web Authentication (WebAuthn) Level 2 — the specification behind passkey registration and authentication
- FIDO Alliance, FIDO2 — the standards body defining CTAP and the passkey model
- Apple, about the security of passkeys — how one platform stores and syncs the private key, which is the part users most often misunderstand