What Passkeys Actually Change, and What They Don't

The pitch versus the mechanism

Passkeys are usually introduced with a single word ('passwordless'), which is true but tells you almost nothing about what actually changed. The mechanism underneath is WebAuthn: at registration, the authenticator (a phone, a security key, a platform credential store) generates a public-private key pair specific to that account and that relying party. The private key never leaves the authenticator. The server stores only the public key. At login, the server sends a challenge, the authenticator signs it with the private key after the user unlocks it (biometric, PIN, or physical presence), and the server verifies the signature with the public key it already had. Nothing resembling a shared secret ever crosses the network or lives on the server.

It's worth being precise about what 'the user unlocks it' actually means, because this is the part most often glossed over. A fingerprint or a face scan never leaves the device and is never transmitted anywhere: it's used locally to release the private key for a single signing operation, the same way a PIN would be. A relying party never receives biometric data, never stores it, and has no way to reconstruct it even if it wanted to. That's not a policy choice a vendor is making on your behalf; it's a structural property of how the standard works, which is exactly why passkey biometrics don't inherit the breach concerns that centralized biometric databases do.

What changes: the attack surface that disappears

That mechanism removes entire categories of attack, not by making them harder but by making them structurally unavailable. Phishing a passkey is not a matter of a more convincing fake page, because the credential is bound to the actual origin at registration; a fake site at a different domain cannot obtain a signature for the real one, no matter how good the impersonation looks. Credential reuse across sites (the reason a breach at one unrelated service leads to account takeovers everywhere a user reused a password) is impossible by construction, because each relying party gets its own keypair; there is no shared secret to reuse. A server-side database breach of stored passkey data is worthless to an attacker on its own, because what's stored is a public key, and a public key doesn't let anyone authenticate as the user. None of this requires the user to behave more carefully. It's true regardless of how attentive they are, which is the actual security improvement: removing reliance on user vigilance rather than asking for more of it.

What doesn't change: everything around the credential

Passkeys authenticate one moment (proving who's signing in), and it's worth being precise about how much of the system that moment doesn't touch. Account recovery is still an open problem: if a user loses their only enrolled authenticator, something has to let them back in, and whatever that something is becomes the new weakest link. A recovery flow that falls back to a security question or an unauthenticated email link can quietly reintroduce every weakness passkeys were meant to remove, just one step later in the flow. A serious passkey implementation treats recovery with the same rigor as enrollment, not as an afterthought bolted on to handle the awkward case.

Session management is a separate concern entirely. A passkey proves identity at the moment of login; it says nothing about how long the resulting session lives, whether that session is bound to the device that created it, or what happens if a token issued after that login is stolen from the browser or a proxy afterward. Authorization is untouched as well: a passkey answers 'who is this,' not 'what are they allowed to do,' and a system that conflates the two is making a mistake that has nothing to do with the credential type. And device compromise still matters: if the device is unlocked and compromised while a session is active, a strong login credential upstream does not protect a live session from being hijacked downstream. Passkeys harden one link in a chain; they don't replace the chain.

The trade nobody puts on the slide

There's an honest trade-off inside 'passkeys' that most explanations skip. Platform passkeys (the ones that sync across a user's devices through their platform account) are convenient because losing one device doesn't lock a user out, but that convenience extends the trust boundary to include the sync mechanism itself. Hardware-bound credentials, tied to a single physical security key, don't sync at all, which is a tighter boundary at the cost of exactly the convenience that makes the synced version popular. Neither option is simply 'more secure' in the abstract; they trade differently, and a vendor that presents passkeys as one uniform, solved feature is skipping the part of the conversation that actually matters for a security-sensitive account. Binding a session to the specific hardware that authenticated it, so a stolen token is useless outside that hardware, is a meaningfully stronger property than passkey login alone provides. That's exactly why we treat hardware-bound session binding as a roadmap capability rather than something to claim today. Overstating what's shipped is worse than being plain about what's planned.

Attestation tells you about the authenticator, not the login

WebAuthn supports attestation at registration time: a signed statement from the authenticator about its own make, model, and security properties, which a relying party can request and evaluate before accepting the new credential. This is genuinely useful for an enterprise that wants a policy like 'only hardware security keys from an approved list may be registered for administrator accounts,' because attestation is what makes that policy enforceable rather than aspirational. It's also frequently misunderstood as a stronger guarantee than it is. Attestation describes the authenticator at the moment of enrollment; it says nothing about every subsequent login, and many authenticators (including most platform ones) either don't provide it or provide a form deliberately limited to protect user privacy. A vendor that supports passkeys but has never built anything around attestation is offering convenience; a vendor that lets you write policy against it is offering a control an enterprise buyer can actually govern.

Why 'we support passkeys' is a weak claim on its own

Most identity vendors will now say yes when asked if they support passkeys, which makes the claim close to meaningless without follow-up. The questions that actually differentiate: is a passkey a first-class credential a user can register as their only method, or is it bolted onto a password-based flow as an optional extra that still leaves the password path fully intact and just as attackable? If passkey authentication fails or isn't available, what does the fallback look like: does it quietly step back down to something weaker than what it's replacing, undoing the entire benefit for any attacker patient enough to force the fallback? And has account recovery actually been redesigned around passkeys, or does it still assume a password exists somewhere as a safety net, which just means the weakest credential in the system is still a password wearing a passkey's reputation.

It's also worth asking what happens to a passkey when the relationship with the relying party ends: when an employee is offboarded, or an account is deactivated. A credential that isn't explicitly revoked at that moment, on the server side, independent of whatever the user's device still holds, leaves a valid keypair sitting on a device that may no longer be trusted. Passkeys removed the shared-secret problem; they didn't remove the need for the server to actively manage the lifecycle of every credential it has ever accepted.

Evaluate the credential, then evaluate the chain

Passkeys are a genuine, structural improvement to one specific step in authentication, and they deserve to be adopted for exactly that reason. They are not, on their own, a complete answer to account security, and any vendor implying otherwise is selling the headline instead of the mechanism. Evaluate the credential, then evaluate everything still standing around it: recovery, session handling, authorization, and what happens the one time it doesn't just work.