Passkeys (WebAuthn)

Passwords are a weird relic, built on top of a shared secret that gets typed into random boxes on random pages, copied into password managers, reused across sites, and dumped in breaches. Then MFA was bolted on to compensate for the fact that the base is fragile.

Passkeys are the first mainstream attempt to delete the shared secret entirely, without forcing everyone to carry a hardware token.

What a passkey is

A passkey is a public key credential bound to a specific service, essentially an asymmetric key pair. The private key never leaves the authenticator (your phone, laptop, or a security key). The server stores the public key and metadata, not a password hash.

This is FIDO2, which is WebAuthn in the browser plus CTAP for talking to authenticators.

WebAuthn is the browser API. It lets a website ask the browser to register a passkey or to authenticate with one. CTAP is the device side protocol. It is how the browser talks to the authenticator that holds the private key, like a phone, a TPM-backed laptop, or a hardware security key.

The important property is origin binding, as the credential is scoped to a relying party ID (rpID). Think of rpIDs as the site's cryptographic domain lock, where the passkey will only sign for that exact domain (relying party). A phishing site on a lookalike domain cannot request a signature for the real domain because the authenticator hashes the rpID into the signed payload.

Passkeys can live in different places:

• Platform authenticator: device hardware backed storage (Secure Enclave, TPM, etc.)
• Roaming authenticator: external security key over USB, NFC, or BLE
• Synced passkeys: platform managed sync across your devices (convenience with tradeoffs)

How the protocol works

There are two main flows: registration and authentication. Both are challenge response with asymmetric cryptography.

Registration (the creation of a passkey):

1. The server generates a random challenge and sends it to the client with parameters: rpID, allowed algorithms, user handle, and whether user verification is required.
2. The client calls WebAuthn create. The authenticator generates a fresh key pair scoped to that rpID.
3. The authenticator returns an attestation object plus the public key and a credential ID. The credential ID is just a handle the server can store and later reference.
4. The server validates the response (challenge, rpId hash, flags, counters) and stores the public key and credential ID against the account.

Authentication (sign in):

1. The server generates a new random challenge and sends it to the client. It can include a list of allowed credential IDs, or it can use discoverable credentials (the passkey can be selected without pre identifying the user).
2. The client calls WebAuthn get. The authenticator performs local user verification (biometric or PIN) if required, then signs over the challenge plus rpId hash and some client data.
3. The server verifies the signature with the stored public key, checks the challenge, and updates the signature counter if used.

The important bit is that the signed data includes the relying party context. A captured response is useless elsewhere (replay fails because the challenge changes). A phish cannot redirect the signature to the real site (rpId mismatch).

What passkeys kill

Passkeys can eliminate quite a few issues we have with password authentication:

• Phishing resistance: The user can be tricked into visiting a fake site, but the authenticator will not produce a valid assertion for the wrong rpId. This is the main win.
• Credential stuffing and password reuse: There is nothing to reuse since there is no password to leak.
• MFA bypass patterns that depend on passwords: A lot of ttakeovers are password theft with weak second factors, or social engineered MFA enrollment resets. Passkeys change this as the default login path is cryptographic, not knowledge based.
• Server side risk reduction
  A password database breach forces a hash cracking arms race and a password reset run. With passkeys, the attacker gets public keys. Public keys are not secrets.

What passkeys do not solve

Passkeys secure the authentication part, but not sessions or recovery.

• Session token theft still works: If an attacker steals your session cookie or refresh token (malware, infostealer, malicious extension, device compromise, etc), they may login entirely and passkeys do not stop that. Hardening here is about cookie flags, device binding, token rotation, step up auth, and detection.
• Account recovery is still an issue: Many services keep password reset flows, email recovery links, SMS fallback, and support desk overrides so attackers will just go around passkeys and pick a weaker login process. If a platform uses passkeys but leaves recovery as email / phone number, the threat model is only partially improved.
• Device compromise: A passkey in a secure enclave is great. A passkey on a device that is already owned is not. User verification helps, but malware with remote control can still push the user through a sign in approval. Endpoints need to be treated as part of the authentication boundary.
• Shared devices: Passkeys are designed for personal devices, not shared workstations, so those need a different model (managed authenticators, security keys, or device based access with separate app level controls).

Synced and device bound passkeys

Device bound passkeys stay on one authenticator. A stolen server database does not help. A stolen device might help, depending on the endpoint's security.

Synced passkeys replicate across a user ecosystem (from phone to laptop). This fixes usability and reduces lockout risk, but it introduces an account dependency since compromise of the sync account can become a passkey compromise vector. Vendors mitigate this with hardware backed keys / encrypted sync / device approval processes, but the risk profile is different.

Cross device sign in (QR and nearby device flows) exists to bridge gaps. The login happens on a device that has the passkey, the target device acts as a client that forwards the challenge. This is how passkeys can work even when the device you are signing into does not already have the credential.

Why platforms are rolling them out now

When passkeys were a nerdy login alternative, the UX was rough for regular users. Now the OS, browsers, and password managers expose them in the autofill path and make user verification feel much more straightforward.. The success of passkeys is not the crypto, it is the UI.

Password resets, account takeovers, and fraud are taxing as every major platform has to pay support time, chargebacks, anti fraud tooling, and the ongoing pressure of credential leaks. Passkeys are one of the few changes that measurably reduce phishing and stuffing at scale.

Lastly, standards finally align across vendors. WebAuthn and FIDO2 give services a stable API surface. Apps can bind to domains via platform association mechanisms, so a passkey created in an app can be used on the web and vice versa. This interoperability made passkeys a viable default login method.

Closing take

Passkeys remove the shared secret, but it is not the finish line because attackers adapt and will still target sessions, recovery, and endpoints. The best implementation is to treat passkeys as a platform change, harden recovery to match the new login strength, reduce fallback paths, and design the full sign-in lifecycle around phishing resistance.