Independent academic researchers tested 103 live passkey deployments against security checks derived from the WebAuthn specification. Not one passed every check. Nobody broke passkeys, the protocol, or the cryptography. Every failure was an implementation error on the website's own server, which is the real story here: deploying passkeys correctly is specialist work, and 103 teams just got graded on doing it alone.
Download the full security report for the scorecard, the findings register, and the vendor checklist.
Already shipped passkeys, or evaluating them now? Book a demo and bring the hardest questions from the checklist. Answering them is the job.
The study, "The State of Passkeys: Studying the Adoption and Security of Passkeys on the Web," was accepted at the 35th USENIX Security Symposium. Researchers from Ruhr University Bochum, Heilbronn University of Applied Sciences, and the University of Wuppertal tested 103 live deployments against 28 checks derived from the WebAuthn specification.
None of that reflects a weakness in passkeys, FIDO2, or WebAuthn. Industry commentary, including Nishant Kaushik at Talking Identity, has been careful on exactly this point: an implementation flaw is not a protocol flaw, and the paper itself reinforces that the specifications and the cryptography underneath them are sound. The protocol held. The deployments didn't.
WebAuthn splits the work three ways: the authenticator on the user's device, the browser, and the relying party, meaning your server. The first two are built by platform vendors. The third is yours, and the specification hands it a long list of mandatory validation work. Verify the signature. Validate the origin. Confirm the challenge is fresh and matches the one you issued. Bind the credential to exactly one account.
Nothing enforces any of it, though. No browser blocks a registration your server should have rejected. No certification program audits your backend logic. Skip a check and everything still works. Users enroll, users sign in, demos go well. A deployment that works and a deployment that is secure are indistinguishable from the inside.
None of this makes those 103 teams careless. The tested deployments were live production systems, many at companies with strong security teams. Passkey implementation just looks like a feature and behaves like a discipline. The happy path is a small fraction of the work, the validation checks are the rest, and none of them produce a visible product change or a failing test in a standard CI pipeline. For a platform team, passkeys are one feature among forty. The research measured what that ratio produces.
The researchers published their check catalog and testing tooling, so when the paper landed, we ran that battery against our own Passkeys+ deployment, exercised through live tampered-message testing against a running system.
The result was zero critical findings and zero high-severity findings. Every authentication-phase verification passed: signature, origin, challenge, relying party ID, and counter handling.
We didn't score perfectly, and we'd be suspicious of any team that claims it did. Our testing surfaced a handful of lower-severity items, and every one of them is in the report with its severity and fix status. A scorecard you can't inspect isn't a scorecard, and how a vendor handles its own findings tells you more than a clean summary does. Even a team that does this full time finds things to tighten when it looks hard enough.
We pass for a boring reason. Passkeys+ is built and operated by a team whose full-time job is authentication done correctly, and the architecture reflects it.
The foundation is ZSM, Ideem's multi-party computation (MPC) based device binding. With MPC, the key material is never assembled in one place. It is split between the user's device and Ideem's infrastructure, both parties have to participate in every signature, and there is no single key for malware to extract or for a breach to steal. The credential ends up cryptographically inseparable from the device it was enrolled on. On that foundation, Passkeys+ delivers phishing-resistant, cryptographic passkeys, with the server-side verifications the study found missing across the market delegated to an audited library at strict settings our application code cannot override. The headline failure classes are exactly where hand-rolled verification breaks down, so we took hand-rolling out of the equation.
Keep going on passkeys. They remain the strongest phishing-resistant authentication available to banks and fintechs, and the research proves the standard is sound.
Implementation is where the risk lives, and it deserves to be treated that way on your roadmap. One hundred and three teams shipped it themselves and all of them missed something; eighteen missed something critical. Budget doesn't change those odds, and neither does engineering talent. What changes them is whether passkey correctness is a side project or the entire practice. That's the argument for deploying with a specialist, and it now comes with a public academic record attached.
The tooling the researchers used is public, so you no longer have to accept assurances from any vendor or internal team. Ask for results.
The gated report goes where a blog post can't:
Download the full security report for the scorecard, the findings register, and the vendor checklist.
Already shipped passkeys, or evaluating them now? Book a demo and bring the hardest questions from the checklist. Answering them is the job.
USENIX Security researchers tested 103 live passkey deployments. None passed every WebAuthn check. The report covers the findings, how Passkeys+ measured up on the same criteria, and a framework for vetting any passkey vendor.
Download the Report →Built by Ideem
Device-bound passkeys and A2A payment authentication. One SDK. No OTPs, no redirects.
We ran the researchers' own tests against Passkeys+ and published everything that came back. Read the findings, our results, and the questions to ask your vendor.
Get the Security Report →