103 Websites Had Passkeys. None Got Implementation Right

Passkeys are fast becoming the norm. Microsoft recently made them the default authentication method with Entra, with Google and Apple also continuing to push them heavily.

Louis though decided to investigate another side of passkeys that he felt was being ignored.

The technology can be incredibly strong, but it doesn't really matter how strong it is if companies aren't implementing it properly.

Louis and his team analysed 103 real-world websites drawn from some of the most visited sites and tested whether their passkey implementations actually worked the way the WebAuthn specification says they should.

The results were pretty shocking. From the 103 implementations they found:

• 18 critical vulnerabilities

• 53 high-severity vulnerabilities

• Not one website passed every check in the team's test suite

Louis was clear that not every failure meant somebody could take over an account. In fact he wasn't especially surprised that no website passed every check as they were testing around 30 different things.

But he was surprised by some of the major critical mistakes websites were still making. For example, some websites weren't even correctly checking the cryptographic signature.

And that really summed up his research. The passkey itself can be completely secure. But if the application sitting behind it hasn't implemented it properly, you can lose a lot of the security benefit you thought you had in the first place.

The really interesting problems were around account management

A lot of the issues Louis' team found were fairly straightforward such as not validating a challenge, but he found the most interesting issues were around passkey management.

Passkey management is everything that happens when a passkey gets connected into a user's account including how it is stored, how it gets linked to the right user, what happens when another passkey with the same identifier appears, how it gets deleted, and how a new one gets added.

This is often where a breakdown occurs as companies have their own account management systems sitting behind the WebAuthn standard, which is often where the issues were.

Louis found cases where they could overwrite another user's passkey, delete another user's passkey or link that passkey to the wrong account. They even found cases where they could register their own passkey against somebody else's account and use that to log in.

This is probably the biggest takeaway from the research. We talk a lot about whether passkeys are phishing resistant, synced or device bound and how strong the authentication itself is. But there is still an account management application sitting behind all of this. If that gets the identity logic wrong, the strong authentication at the front isn't going to save you.

More resources didn't equal better implementation

This was probably the finding I found most surprising. You would assume the biggest websites with more developers, bigger security teams and more resources would be much less likely to have an implementation issue.

Louis' team actually found the opposite.

Louis was very clear that he can't say for certain why. They are testing these websites from the outside so they can't see exactly how each company built its authentication. But his theory was pretty interesting.

So larger companies potentially have the resources to do more engineering themselves versus a smaller organisation using an established, well-trusted library. More custom authentication code can also mean there are more places something can go wrong.

Should you actually be building this yourself?

I asked Louis what he would do if he was responsible for identity inside a large organisation. His first decision would be pretty simple: am I going to build the passkey implementation myself, or am I going to get an identity provider to do it?

If you are going to build it yourself you need a proper team with deep WebAuthn knowledge who understand passkeys enough that they could decode one by hand. A high benchmark, but if you don't have the resources to do this, why not leave the implementation to experts like Okta or Microsoft whose whole life is identity.

His point was that a lot of the people who helped write these standards work inside the big identity and technology companies anyway, so these teams are naturally going to have much deeper expertise than what you could build yourself in a normal application development team.

Tips for those building themselves

Louis' number one tip for people building themselves was to use the vast amount of resources that already exist. He recommended FIDO Design Guidelines, UX Principles and rollout guides, Passkey Central's example code and design templates as well as seeking guidance from the Web Identity & Credentials Adoption Community Group and passkeys.dev.

He also strongly recommended using a mature passkey library rather than trying to build things like decoding and key management yourself.

So overall his advice when building yourself was:

• Use mature libraries

• Follow the FIDO guidance

• Look at best practice from other companies

• Security test what you have built

It's not anything groundbreaking but it's the basics that need to happen.

You can test your own implementation

The good news is that Louis has made all of his security testing tools open source through passkeys.tools.

You can use these tools to inspect and modify passkey requests, decode what is happening and recreate the different types of attacks they tested during the research.

They have also built a training environment where developers can deliberately switch on one of the vulnerabilities the researchers found and then try to exploit it. You learn how the attack works there and can then use the same tooling to look at your own environment. Basically a small passkey security lab.

So unlike a lot of research where the conclusion is basically that companies need to be more secure, there is actually something practical here teams can go away and use.

Vulnerability disclosure is broken

Another really interesting part of the interview was how hard it was to actually tell the companies tested about their vulnerabilities. The biggest gap was a lack of information about who exactly to tell.

The researchers sent emails, filled in website forms and tried general support, often with no response. At the beginning of the year only 13 companies had confirmed they had fixed the vulnerabilities, although others had acknowledged the issues and said they were working on them.

His biggest piece of advice for any security leader was pretty simple:

His approach for best practice would be having a dedicated security contact or inbox for disclosures, a security.txt file and ideally a public bug bounty program.

Because the alternative is pretty crazy. A researcher has found a critical authentication vulnerability and is trying to explain it to a general support team. Louis summed this up well:

That really shouldn't be the process for reporting a critical authentication vulnerability.

Implementation problems aren't going away

When asking Louis if he repeated the same research in three years' time whether he thought he would have the same results, his answer wasn't overly optimistic.

Something that isn't making things easier is the increasing size of the standards with WebAuthn already over 200 pages. His example was pretty relatable. By the time you've reached page 200, there's a good chance you've forgotten something you read on page 100.

On whether AI could make implementation better, Louis wasn't convinced either. Maybe an LLM can keep the entire specification in context and actually reduce mistakes. Maybe it just creates a different set of mistakes.

One big takeaway though that Louis wanted to make clear was that none of this makes him anti-passkey. It is actually the opposite of his view. His ideal world is one where passkeys keep growing and passwords eventually disappear.

My own takeaway from the interview was that passkeys are the future but moving to passkeys isn't a golden solution to all problems. You need to always think about how that credential is enrolled, how it gets associated with an identity, how it gets managed and what happens when something goes wrong. And if you are building the actual implementation yourself, whether the team doing it really understands what they are building.

So for identity teams rolling out passkeys, I think there are probably three questions worth asking:

1. Are we building this ourselves because we genuinely need to, or because we can?

2. How are we security testing the implementation beyond just checking that it works?

3. Who internally really understands WebAuthn well enough to spot when something isn't right?

Passkeys themselves are probably not the problem here, it's the architecture around them that causes problems.

Research and Resources

Louis shared the following resources after our conversation.

The Research

• The State of Passkeys: Studying the Adoption and Security of Passkeys on the Web, USENIX Security 2026

• Passkeys adoption measurement

• Research data and artifacts

Testing

• Passkeys.tools

• Source code

Implementation Guidance

• FIDO Design Guidelines

• FIDO Passkey Roll-Out Guides

• Web Identity & Credentials Adoption Community Group

• Passkeys.dev

• Passkey developer tools