Why Passkeys Are Not Just Prettier Passwords
Passkeys spent two years as a spec most engineers skimmed. They are now a default login option on Apple, Google, and Microsoft accounts. Marketing says passwordless authentication that cannot be phished. Fine, as far as it goes. Engineers building login still need to know what is on the wire. Passkeys are W3C WebAuthn Level 3 sitting on the FIDO2 stack: they throw out shared secrets and replace them with asymmetric public keys bound to one 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
WebAuthn is a challenge-response protocol using public key cryptography. There is no shared secret between the user and the server, ever, which is the whole point. A passkey login looks like this.
- 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. Almost every live deployment uses ES256: 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. That is a lot of 2015-era account takeover, gone, without a user-training slide.
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 decision that actually bites during a rollout: do you accept synced passkeys, or do you 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
WebAuthn is not hard to implement. The libraries are fine. These details still wreck first deployments:
- 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.
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 are the first password replacement that actually shipped to hundreds of millions of accounts. The cryptography holds up. Origin binding kills phishing in a way SMS codes and TOTP never did. SimpleWebAuthn, webauthn4j, and py_webauthn are boring enough to put in production this quarter. Synced versus device-bound, and the platform walled gardens, are the tradeoffs you have to design for, not reasons to wait another year.
Stop building new password flows. Implement WebAuthn, allow more than one credential per user, and treat the relying party ID as a long-term identifier you will still be stuck with in five years. The jump from passwords is not a percentage point on a phishing-rate slide. It is a different attack surface, and it is available now.
Frequently asked questions
Are passkeys really more secure than passwords?
For the attacks that dominate account takeover today, yes. A passkey private key never leaves the authenticator, so a breached server database yields only public keys, which cannot be used to impersonate anyone. Origin binding also means the credential will not sign for a lookalike domain, which removes phishing and credential stuffing from the picture. Passwords fail on all three counts.
What happens if I lose the device holding my passkey?
It depends on whether the passkey is synced or device-bound. A synced passkey lives in a cloud keychain such as iCloud Keychain or Google Password Manager, so it reappears on the next device you sign into that provider with. A device-bound passkey created on a YubiKey, TPM, or locked-down secure enclave is gone with the hardware. That is why relying parties should let every account enroll more than one credential.
Can passkeys be phished?
Not through the usual routes. The browser includes a hash of the relying party ID in the data the authenticator signs, and it enforces that the ID matches the site serving the login page. A signature produced at examp1e.com will not validate at example.com, so lookalike domains and reverse proxy frameworks like Evilginx get nothing usable. The weak point during a rollout is any non-passkey fallback you leave enabled, since that path is still phishable.
Do passkeys work across Apple and Google?
The WebAuthn protocol itself is cross-platform, so any compliant site accepts a passkey from any compliant authenticator. Syncing is the part that does not cross vendor lines yet: an iCloud Keychain passkey does not sync to a Google phone. Work on the FIDO Credential Exchange Format aims to fix that, but it is not universal today. Until it is, assume users need a separate credential per ecosystem.
Is a passkey the same thing as two-factor authentication?
Not quite, though it covers similar ground. A passkey authentication combines something you have, the authenticator, with something you are or know, the biometric or PIN it demands before signing, so a single passkey prompt already carries two factors. It is not a second step bolted onto a password, and it is not a one-time code that can be relayed to an attacker.
Can passkeys be stolen by malware?
The private key itself is very hard to steal, since it stays inside the authenticator. What malware takes instead is the session. Infostealer families such as Lumma and StealC pull authenticated cookies straight out of the browser, and a stolen session token works no matter how strong the login was. Passkeys do not solve device compromise, so endpoint hygiene and short session lifetimes still matter.
Revealer.US is an OSINT and people-search platform. One search across breach data by email, username, phone number, name, or address checks 800+ platforms, public records, and known breach datasets, which is useful when you want to know whether an old password of yours is already exposed. Free tier available, paid self-serve from $12.99/mo, with custom Enterprise plans. Revealer.US is not a consumer reporting agency and its results may not be used for employment, tenant, or credit decisions.