Researchers Attacked 103 Passkey Logins, and the Standard Wasn't the Problem
When you sign in with a passkey, the clever part happens where you can see it: a fingerprint, a face, a phone that lights up. The part that decides whether any of it means anything happens somewhere you cannot see at all. The site's server receives a signed answer to a one-time challenge, then works through a list of verifications before it opens the account: is this the right challenge, the right key, the right site? Nobody else can do that work for it, and if it skips a step, nothing breaks. The login simply succeeds.
That checklist is the price of the design. A passkey is a cryptographic key pair created for one site: the private half stays on your phone or laptop or hardware key, and the site keeps only the public half, which is useless to steal. Nothing reusable is typed, so there is nothing to phish and nothing to reuse on another site. Apple, Google and Microsoft have all built the scheme into their operating systems and browsers, and the number of sites offering it has climbed steadily. The guarantee that comes with it, though, belongs to the protocol, and only a correct implementation delivers it to a user.
That invisible half is what Louis Jannett of Ruhr University Bochum and his colleagues set out to measure. Their paper, presented at the USENIX Security Symposium in Baltimore in mid-August, won one of the meeting's Distinguished Paper Awards. By their own account, no comprehensive security analysis of passkey sites at that scale had been attempted before. The team also includes researchers at Heilbronn University of Applied Sciences and the University of Wuppertal, and it built two instruments for the job.
The first, PASSKEYS-RADAR, is a rolling census of the passkey web. It has tracked deployments since 2021 by pulling together community directories, ranked-domain lists and archived copies of old pages, and it gave the team 872 passkey-enabled sites to analyze. The second, PASSKEYS-ATTACKER, is a test harness. It emulates both the browser and the security key, which lets a researcher alter the messages a login exchanges at any point in the sequence. Fifteen attack types are built into it, ten of them not covered by any previous study.
They ran it against 103 of those sites. Two of the attacks carry critical severity scores, and the team found them on 18 of the 103: flaws that let an attacker take over an account, delete the owner's passkeys, or lock the owner out of them. A wider band of high-severity problems, the kind that expose users to phishing and session fixation, turned up on 53 sites in all.
The line that has traveled furthest is not in the published abstract at all. It comes from the researchers themselves, in the announcement of the award: not one of the sites tested meets every security check the standard requires. That is a verdict on the full checklist rather than a claim that every passkey login can be broken into. The paper's own numbers keep the two apart, because 50 of them carried no high or critical finding of any kind.
A missing check makes no noise
A clean sweep is hard to find for a structural reason. WebAuthn, the standard underneath passkeys, assigns the ordered list of verifications to the website and to nothing else. The browser does not enforce it and the security key cannot, so a step left out produces no error. The user is signed in, the page behaves normally, and only somebody deliberately bending the protocol would ever see the gap. The researchers are direct about where that leaves the blame. The technology itself is regarded as secure, their announcement says; what the results expose is faulty implementation by the operators of individual sites.
Testing a login you do not own
Running attacks against production websites is what separates this from a desk study, and it is also where the ethics live. The team registered two of its own accounts on each site, one playing the attacker and one the victim, and drove genuine logins through the tool against the live endpoints. Where a critical finding held, they confirmed it by signing into a victim account they owned themselves. No other user's account was involved, and the operators were told what had been found before any of it was published.
The softer half is what happens after you lose your phone
The census turned up a second class of problem that involves no attacker at all. Sites differ sharply in how they let a person add a passkey or delete one, and that machinery is exactly what somebody reaches for after losing a phone. The team also found sites asking authenticators to use cryptographic algorithms that have been deprecated. Neither is a break-in. Both describe an ecosystem in which every operator has made its own decisions about parts of the standard that were meant to be followed closely.
Both tools have been released free of charge, under an open license and with the data behind the census, and that is the half of the work an operator can act on today. The people who built a site can now run it through the same attack scenarios themselves, without waiting for a researcher to get around to them, and the deployment census is public alongside the harness. Maximilian Westers, the Heilbronn doctoral researcher on the team, called it a practical contribution to cybersecurity in application rather than only in research.
What the audit cannot say is how the rest of the web is doing. The 103 are the sites a small team could open accounts on and test by hand; the census behind them already holds 872, and the number keeps growing. For anyone signing in, the standard itself is not what failed here, and a passkey remains a stronger credential than a password. What the paper adds is where the remaining risk sits. It is in a checklist nobody outside the website can watch being run, and the instrument for finding out whether it is run correctly is now public.