Why Passkeys Are Not Just Prettier Passwords
Passkeys have spent the last two years moving from a spec document most engineers skimmed to a default login option on Apple, Google, and Microsoft accounts. The marketing pitch is simple: passwordless authentication that cannot be phished. The technical reality is more interesting, and for engineers building authentication systems it matters to understand what is actually happening on the wire. Passkeys are an implementation of the W3C WebAuthn Level 3 specification on top of the FIDO2 stack, and they replace shared secrets with asymmetric public key cryptography anchored to a specific relying party.
That single architectural decision kills entire classes of attacks that have haunted the password era. It also introduces new tradeoffs around device binding, cloud sync, and vendor lock-in that any team deploying passkeys needs to think through before the migration plan goes out.
The Core Cryptographic Handshake
At the heart of WebAuthn is a challenge-response protocol using public key cryptography. There is no shared secret between the user and the server, ever. Here is what happens during a passkey login.
- The server, acting as the relying party, generates a random challenge, typically 32 bytes of entropy, and sends it to the browser along with the relying party ID, which is a domain like example.com.
- The browser invokes the WebAuthn API, which asks the authenticator to sign the challenge. The authenticator can be a platform device like a phone or laptop secure enclave, or a roaming device like a YubiKey.
- The authenticator looks up the private key it stored during registration, verifies the user with a biometric or PIN, and produces a signature over a structure that includes the challenge, the relying party ID hash, a counter, and client data.
- The signature is returned to the server, which verifies it using the public key it stored during registration.
The important property here is that the private key never leaves the authenticator. The server only ever sees signatures and public keys. If an attacker compromises the server database, they get a list of public keys, which are useless for impersonation. Contrast that with password hashes, where a stolen database yields material an attacker can crack offline.
COSE Keys and Signature Formats
Passkey public keys are encoded using the CBOR Object Signing and Encryption format defined in RFC 8152, commonly called COSE. The WebAuthn spec supports multiple algorithms, but in practice almost every deployment uses ES256, which is ECDSA over the P-256 curve with SHA-256. Some ecosystems, particularly Windows Hello, also support RS256 for legacy TPM compatibility, and newer deployments are beginning to add Ed25519.
Relying parties should accept a small set of algorithms and reject anything weaker. Misconfigured servers that happily accept RS1 or other deprecated algorithms have been a source of real vulnerabilities.
Why Phishing Dies
The most important security property of passkeys is origin binding. When the browser asks the authenticator to sign a challenge, it includes a hash of the relying party ID in the signed data. The relying party ID is the domain the user is visiting, and the browser enforces that it matches the site actually hosting the login page.
This means a convincing phishing site at examp1e.com cannot trick a passkey into signing a challenge that will validate at example.com. The hashes do not match, and the signature is useless. No amount of social engineering, lookalike domains, or reverse proxy phishing frameworks like Evilginx can bypass this, because the authenticator simply will not produce a valid signature for the wrong origin.
Credential stuffing dies for the same reason. There is no password to reuse across sites, and every passkey is bound to exactly one relying party ID. Replay attacks die because every challenge is fresh and the server rejects anything it has seen before. A huge slice of the modern attack surface simply vanishes.
Attestation: Trust but Verify the Authenticator
WebAuthn includes an optional attestation mechanism that lets a relying party verify the make and model of the authenticator at registration time. When attestation is requested, the authenticator returns a statement signed by a manufacturer key, which a relying party can validate against the FIDO Metadata Service.
Attestation matters in high-assurance environments. A bank or government agency might require that only FIDO-certified hardware authenticators be used, excluding software-only or synced passkeys. Consumer services generally skip attestation because it adds friction and privacy concerns, and because the phishing-resistance property holds even without it.
Attestation Formats
The spec defines several attestation formats including packed, tpm, android-key, android-safetynet, fido-u2f, apple, and none. Most platform authenticators use packed or apple, and most security keys use packed or fido-u2f. Relying parties that care about attestation should parse the format carefully and validate certificate chains against the FIDO MDS rather than trusting blobs blindly.
Synced Versus Device-Bound Passkeys
The biggest practical decision for any team rolling out passkeys is whether to accept synced passkeys or require device-bound credentials.
- Synced passkeys, also called multi-device credentials, live in a cloud keychain like iCloud Keychain, Google Password Manager, or a third-party manager like 1Password. Users can sign in from any device where they are logged into the sync provider.
- Device-bound passkeys never leave the authenticator hardware. They are created on a YubiKey, a TPM, or a locked-down secure enclave, and if the device is lost the credential is gone.
Synced passkeys are dramatically better for consumer usability. Users do not lose access when they upgrade phones, and recovery flows are much simpler. The tradeoff is that the security of the credential now depends on the security of the sync provider. If an attacker compromises a user's iCloud or Google account, they can potentially access synced passkeys.
Device-bound passkeys are the right choice for administrator accounts, high-value enterprise workflows, and regulatory contexts that demand hardware-backed keys. They are harder to use, require backup authenticators, and create real support burden, but they raise the assurance level meaningfully.
The Ecosystem Lock-In Problem
Synced passkeys currently live inside platform walled gardens. An iCloud passkey does not sync to a Google phone. Cross-platform sync through the FIDO Credential Exchange Format is in progress but not yet universal. Relying parties should not build flows that assume a user's passkey from one device will always be available on another, and should always support enrolling multiple credentials per account as a recovery path.
What Developers Need to Get Right
Implementing WebAuthn correctly is not difficult, but several details routinely trip up teams. A practical checklist for a first deployment:
- Serve over HTTPS on a stable relying party ID. Changing your domain or subdomain structure will orphan every passkey in production.
- Store challenges server-side with expiration, not in cookies. A five-minute TTL is reasonable.
- Validate the full clientDataJSON, not just the signature. Check the origin, type, and challenge fields.
- Reject known-bad algorithms and pin to ES256 plus optionally RS256 and Ed25519.
- Increment and check the signature counter where the authenticator provides one, to detect cloned credentials.
- Support multiple credentials per user so a lost device does not lock anyone out.
- Provide a non-passkey fallback during rollout, but do not leave it enabled forever or you are still phishable.
- Log registration and authentication events with credential IDs so incident response can pivot on them later.
Good libraries exist in every major language, including SimpleWebAuthn for Node, webauthn4j for Java, and py_webauthn for Python. Use them rather than hand-rolling CBOR parsing. If you want to see how passkeys integrate with identity monitoring, our platform docs walk through the full enrollment and verification flow.
Where Passkeys Do Not Save You
Passkeys kill phishing, credential stuffing, and replay. They do not kill every authentication attack. Session hijacking through malware that exfiltrates authenticated cookies is still a real threat, because once you are logged in, the session token is what matters. Infostealer malware families like Lumma and StealC harvest cookies directly from browsers regardless of how the login happened. Device compromise remains a problem passkeys cannot solve.
They also do not help against authorization bugs, server-side vulnerabilities, or social engineering that convinces a user to perform actions while legitimately logged in. Passkeys authenticate users. They do not authenticate intent.
Conclusion
Passkeys and WebAuthn represent the first genuine replacement for passwords that works at internet scale. The underlying cryptography is sound, the origin binding property eliminates phishing in a way no other mainstream mechanism has achieved, and the ecosystem is mature enough to deploy in production today. The tradeoffs around synced versus device-bound credentials and platform lock-in are real but manageable with careful design.
For engineers, the message is simple: stop building new password flows. Implement WebAuthn correctly, support multiple credentials per user, and treat your relying party ID as a stable long-term identifier. The security improvement over passwords is not incremental. It is categorical.
Want to monitor whether any of your users are still relying on exposed passwords? Start a free trial of Revealer.US and see credential risk across your identity stack.