Passkeys and the slow end of the password

Passkeys are the first serious replacement for passwords that ordinary people can actually use. You sign in with your face, your fingerprint or your device PIN, and there is nothing to type, reuse or leak. Most large platforms support them now. And yet the password is not going away quickly. This post explains how passkeys work, why they stop phishing so effectively, where the rough edges are, and what we think developers should build today.

How passkeys work

A passkey is a pair of cryptographic keys, created for one account on one website. The technology underneath is WebAuthn, a W3C standard for the browser side, together with the FIDO Alliance's CTAP protocol for talking to authenticators such as phones and security keys. The two together are usually called FIDO2. The WebAuthn specification is readable if you want the detail.

When you create a passkey, your device generates a new key pair. The private key stays with the authenticator: inside the phone's secure hardware, the platform's password manager or a hardware security key. The public key goes to the website, which stores it next to your account. That is all the site keeps. There is no shared secret on the server.

Signing in follows the sequence in the drawing above:

1. The website sends the browser a random challenge, a fresh value used only once, along with its identifier, called the relying party ID. This is usually the site's domain.
2. The browser checks that the page asking really is on that domain, then passes the request to the authenticator.
3. The authenticator asks you to confirm it is you with a biometric or PIN. This check happens locally. Your fingerprint or face data is not sent anywhere.
4. The authenticator signs the challenge, together with data that includes the site's identity, using the private key for that site.
5. The website verifies the signature with the public key it stored. If it checks out, you are in.

The important consequence is that a server breach no longer exposes anything useful for signing in. An attacker who steals the database gets public keys, which are by design safe to publish. Compare that with password hashes, which can be cracked offline, or with the many people who reuse the same password elsewhere.

Why passkeys stop phishing

Phishing works because a person can be tricked into typing a secret into the wrong website. A convincing copy of a bank's login page at a slightly different domain gets the password, and often the one-time code from an SMS or authenticator app as well, which the attacker relays to the real site in real time.

Passkeys remove the person from that decision. Each passkey is bound to the relying party ID it was created for. The browser, not the user, checks the origin of the page and includes it in the signed data. A phishing site at a lookalike domain cannot ask for the real site's passkey, because as far as the browser and authenticator are concerned, no passkey exists for that domain. There is nothing for the user to be tricked into handing over, and nothing for an attacker to relay.

This origin binding is the real improvement. Passkeys are convenient too, but plenty of things are convenient. Being structurally resistant to phishing is what makes them different from every password and code-based system before them.

Synced passkeys and device-bound keys

Early FIDO security keys held credentials that could never leave the device. That is very strong, and it is also why they never reached most people: lose the key and you lose access.

Passkeys as most people meet them today are synced. Apple stores them in iCloud Keychain, Google in Google Password Manager, and several third-party password managers can create and store them too. They sync between your devices with end-to-end encryption, so a new phone signed into the same account already has your passkeys. On iOS and Android you can choose a third-party password manager as the passkey provider. On Windows, passkeys created with Windows Hello have historically stayed on the device, and support for syncing and third-party providers has been arriving in stages, so behaviour depends on the version you run.

If your phone is not the device you are signing in on, there is also a cross-device flow. The browser on the laptop shows a QR code, you scan it with the phone, and the two devices check that they are physically near each other over Bluetooth before the phone signs the challenge. It works well once people have seen it once. The first time, it can be confusing.

Device-bound passkeys still matter. Hardware security keys and some managed corporate devices keep the private key in hardware that never exports it. For administrators, high-value accounts and anyone with a serious threat model, that is still the best option. A reasonable setup for a technical person is a synced passkey for daily use and a hardware key in a drawer as a backup.

The recovery problem

This is the weak point, and it is not really a passkey problem. It is an account problem. If someone loses every device and cannot get back into their platform account, they lose their synced passkeys with them. The website then needs a way to let them back in.

Whatever that way is becomes the real security of the account. If recovery is "we send a code by SMS", then the account is only as strong as SMS, which is vulnerable to SIM swaps and to phishing. Many services today keep a password plus a code as a fallback, which leaves the old attack surface in place.

There is no perfect answer, but there are better ones. Encourage people to register more than one passkey, ideally from different providers or with a hardware key. Offer recovery codes at setup and explain plainly what they are for. For higher-value accounts, require identity checks or a waiting period before recovery completes, and notify every registered device when it starts. Moving passkeys between providers has also been a gap. The FIDO Alliance has worked on standard formats for exporting and importing passkeys, and platform support started to appear in 2025, but we would check the current state before relying on it.

What developers should implement

If you run a website or an app with accounts, here is what we would do in 2026:

• Use a maintained library. WebAuthn has many details (encodings, attestation formats, counters, edge cases) that are easy to get subtly wrong. Well-maintained open-source server libraries exist for most languages.
• Create discoverable credentials. Set residentKey to "required" or "preferred" so the user does not need to type a username first, and ask for user verification.
• Support autofill sign-in. Conditional mediation lets passkeys appear in the browser's autofill menu on a normal username field. It is the easiest way to introduce passkeys without a separate button people ignore.
• Allow several passkeys per account and let people see, name and remove them in their settings.
• Treat the sign counter carefully. Synced passkeys often report zero, so do not treat a missing increment as an attack by default.
• Plan recovery first. Decide what the fallback is before launch, and make sure it is not weaker than the thing it replaces.

The autofill case looks roughly like this on the client side:

<input name="username" autocomplete="username webauthn">

const credential = await navigator.credentials.get({
  mediation: "conditional",
  publicKey: {
    challenge: challengeFromServer,   // random bytes, single use
    rpId: "example.com",
    userVerification: "preferred"
  }
});
// send credential to the server, which verifies the signature

Browser support for newer parts of the standard, such as the signal methods that let a site tell a password manager a passkey has been deleted, still varies between browsers and platforms. Feature-detect, and keep the basic flow working without them.

We think a lot about this kind of thing in our security tools, where the question is always the same: which step is a person being asked to get right, and can the software take that step off their hands. Passkeys are a good answer to that question for sign-in. The password field will stay on most login pages for a few more years, but the first time a user's browser quietly refuses to offer their passkey to a lookalike domain, it will have earned its keep.