Researchers tested 103 live passkey deployments  a suite of 28 checks derived from the WebAuthn specification. Not one passed them all.

That comes from The State of Passkeys: Studying the Adoption and Security of Passkeys on the Web, a paper accepted at the 35th USENIX Security Symposium by a team from Ruhr University Bochum, Heilbronn University of Applied Sciences, and the University of Wuppertal. Eighteen of those sites carried a critical-severity vulnerability. Fifty-three carried a high-severity one.

If you have rolled out passkeys in the last two years, that number deserves a pause. It does not mean passkeys are a bad idea. They remain the strongest authentication most organizations can realistically deploy, and I would still tell any buyer to move toward them.

But it does expose something the market has not been asking about. So: what failed, why does it keep failing, and what belongs in your next vendor conversation?

First, a reset: the protocol is not what failed

FIDO2 and WebAuthn are sound. The cryptography works. Nobody has broken passkeys.

What the researchers measured is a different thing entirely: they measured whether the relying party (your website, your enterprise application, your identity provider) correctly performs the verification steps the standard asks of it.

Those steps are numerous, and they belong to the relying party alone. No browser enforces them. No authenticator enforces them. If you skip one, nothing complains.

There is a FIDO server certification program, and it does test conformance against the Alliance's Server Requirements specification. But look closely at what it certifies: an implementation submitted for testing, at a point in time. Not the production deployment you are actually running, and not as a required step on the way to going live. Nothing obliges a relying party to pass it before shipping.

So what did that produce in practice?

What actually broke

Among the 103 sites tested:

• 5 skipped signature verification entirely. The researchers confirmed it by signing into victim accounts. The signature is the step where the cryptographic guarantee actually lives; everything else in the flow is choreography around it.
• 22 did not properly validate the challenge, the randomized value that ties a login attempt to one specific session. Without that binding, a captured or injected response can be replayed.
• 57 ignored the signature counter, the mechanism designed to reveal a cloned authenticator.
• A novel "credential overwrite" attack worked against relying parties that mismanage the relationship between user identifiers and credential identifiers, letting an attacker register a credential that appears to belong to both attacker and victim.
• All but one site requested deprecated cryptographic algorithms. Only 90 of 208 relying parties used the recommended ones.

Not one of these is a protocol weakness. Each one is a server-side implementation choice, invisible to the user, and invisible to the buyer.

Why this keeps happening

Three reasons, and none of them is about careless engineers.

1. The specification puts the heaviest verification burden on the party least equipped to carry it. The relying party has to perform a long sequence of checks, correctly and in order, with no runtime feedback when it does not. A missing check produces no error. Authentication simply succeeds.
2. There is no conformance test in the deployment path. You can integrate passkeys, watch logins succeed, and ship. Success looks identical whether or not the signature was verified. Server certification exists, but it is optional and sits outside the normal delivery pipeline.
3. The library and platform ecosystem is uneven. Some SDKs handle validation end to end. Others expose primitives and leave the sequencing to whoever is integrating. Buyers rarely know which one they bought, because that distinction does not appear in the documentation procurement teams read.

The failure distribution backs this up. The researchers expected weaker validation on less popular sites, given how complex the standard is. They found the opposite: higher-ranked sites were more susceptible than lower-ranked and unranked ones.

That is not a story about sloppy small teams. It is what complexity looks like when it scales with integration surface: bigger sites carry more authentication paths, more legacy flows, and more places for a check to quietly go missing.

For the record, the authors disclosed critical and high-severity findings to 61 affected websites, and vendors had at least six months to remediate before publication.

What this changes for buyers, starting with me

Most passkey procurement today looks at the authenticator, the user experience, the recovery flow, and the IAM integration. All of that matters. But the highest-severity failures in this study sit in a layer nobody is currently asking about. That layer is testable.

I want to be direct here, because this lands on my own work before it lands on anyone else's. Last year I benchmarked passwordless vendors for our Leadership Compass Passwordless Authentication for Enterprises. I weighted enrollment, recovery, device trust, and IAM integration. I did not ask a single vendor to demonstrate that its relying party verifies the signature on every authentication. There was no public test artifact to assess it against.

There is one now. The tooling is public, along with the full catalog of 15 attack types and 28 detection methods. You can run these checks against your own deployment, or make your vendor show you the results.

Questions worth adding to a passkey evaluation

1. Which of the WebAuthn specification's server-side validation steps does this implementation perform, and can you show test evidence rather than a compliance statement?
2. Is signature verification performed on every authentication, and how has that been independently confirmed?
3. How is the challenge generated, bound to the session, and validated on return?
4. How does the system enforce that each credential belongs to exactly one user?
5. Is the signature counter checked, and what happens when it regresses?
6. Which cryptographic algorithms does the relying party request, and are any deprecated?
7. Can a registered passkey be deleted, and can a user hold more than one? Some sites in the study allowed neither, which is a recovery problem and not only a security one.

If a vendor answers "we are FIDO certified," they have answered a different question. The same goes for a policy setting that reads "phishing-resistant MFA enforced". That describes how a credential was enrolled, not whether the resulting authentication is checked properly.

The bottom line

Three things to take away. Passkeys are still the right direction, and if you are still on passwords you have a bigger problem than anything in this paper. The security of a passkey deployment is a property of your implementation, not of the protocol, and it does not appear on any datasheet. And because the researchers published their tooling, that property is now something you can test instead of assume.

To be unambiguous about it: nothing in this paper is a finding against WebAuthn, FIDO2, or the certification programs built on them. The specifications held. What failed is the code that implements them, one relying party at a time. That is a harder problem than a broken protocol in some ways, because there is no patch to apply centrally, but it is also the kind of problem a buyer can actually act on.

For where passkeys work and where they do not, see our Advisory Note Passkeys in Practice. To review your own deployment against these findings, talk to a KuppingerCole advisors.