Today the FIDO Alliance has earned its applause. Over a decade of effort, and the world is finally taking the death of the password seriously. That is not a small thing, and I do not want to start by being grudging about it. Passwords were never the right primitive for the online world, and the people who built the passkey did real work to replace them.
I want to use the rest of this note to say something the celebration is not yet making room for: the passkey is a waypoint, not a destination. There are three reasons, and they connect to an argument I have been making in print for some time.
The first reason is cryptographic. A passkey ceremony produces an authentication assertion — a one-time cryptographic statement that a user touched a sensor. It does not produce a session key. Whatever happens after the assertion is a separate mechanism, usually a cookie or a bearer token, with no cryptographic continuity from the login that created it. This is not a flaw in any one product. It is a property of the protocol. FIDO2 was designed to replace the password, and it does. It was not designed to protect the session that follows, and it does not.
The industry has now noticed. Device Bound Session Credentials, DPoP, channel binding — all three are serious, well-engineered efforts to bind the session to the device that created it. I welcome them. But I would ask the reader to notice what their existence implies. If every request after the login can be cryptographically tied to a verified device, then the login itself is no longer load-bearing. The session fix and the login fix converge. The gesture becomes ceremony.
This is the second reason, and it is the one I care about most. The passkey verifies the wrong thing.
In the published work I have called this the Wrong Identity Tax and the Three Wrongs. The wrong identity is verified — a gesture, instead of the real composite of user, device, and conditions, bound together. The wrong timing is used — login is treated as one problem and session as another, when they are the same continuous problem. The wrong method is applied — a procedural human gesture, where machine-to-machine cryptography would do the job without the human having to perform anything at all.
A passkey is a beautiful expression of the procedural model. But the online world is, at its core, a machine world. Every interaction travels as traffic between machines. The right architecture lets the machines do the work. The user logs in once at the start of the day, and the endpoint carries the proof from there — silently, continuously, inside the encrypted channel itself.
The third reason is the most practical. The hardware to do this is already deployed. Almost every business laptop sold in the last decade has a Trusted Platform Module. Mutual TLS has been a standard for twenty-five years. Server-side TLS has been doing its half of the job — proving the server to the client — since before most of today’s security architects entered the field. What has been missing is the client-side half: a properly protected, long-lived, user-bound, policy-bound key inside the user’s endpoint, used in the TLS handshake itself.
We call ours the Live Key. It is, in the architectural sense, what comes after the passkey: device-bound and user-bound, available without a gesture because user verification has already been established at the start of the session, governed by policy, and continuous rather than momentary. It rides inside the secure channel. There is no token to steal because there is no token. There is no login to phish because the proof is not produced by a login event.
I am not asking the industry to invent something new. I am observing that half of this architecture already exists, has existed for a long time, and that finishing it is a smaller step than the celebration today might suggest. WinMagic submitted this argument formally to the W3C in March, with a threat model following RFC 3552, and the conversation is part of the public record. The reference implementation is open-source.
So, on World Passkey Day, two things are true at once. The passkey is real progress and the people who built it deserve the credit they are receiving today. And the passkey is a waypoint — the architecture it sits inside has three structural problems, and the industry’s own next set of fixes will, if they succeed, make the gesture itself optional.
The test is the one engineers use on each other: ten seconds after a passkey ceremony succeeds, what is protecting the session? If the answer is a cookie, we have raised the bar at one moment and left it flat for the rest of the day.
The path forward is not to defend the passkey. It is to follow the logic where it leads — to continuous identity verified at the source, carried inside the secure channel, with no moment-of-login left for an attacker to target. I think we will get there. I think the people building the current stack will help us get there. Today, I am glad to celebrate what they have already done.
Tomorrow, the work continues.
