Passkeys in the Wild: Native, Delegated, and Invisible
Passkeys are no longer only a protocol promise; websites now expose them in different forms, with different owners and different degrees of visibility. This chapter interprets the large-scale deployment evidence without confusing a site that appears to support passkeys with a user who has adopted one or a service that has secured every recovery path. It also separates native relying-party authentication from identity-provider delegation so readers can identify who actually owns the fallback and recovery decisions.
What the census means by “support”
The census paper measures whether a website appears to offer passkey authentication, not whether its users have enrolled or routinely use passkeys. That distinction is central. A service can expose a passkey option that few people select. A user can have a passkey stored in a platform credential manager but visit a site that does not offer a compatible login. Neither fact can be inferred from the other.
For its top-100K Tranco snapshot, the paper reports 9,397 detected passkey-supporting sites and states in its conclusion that 11.3% of scanned sites support passkeys. It also reports a strong popularity gradient: 20% of the top 100 sites support passkeys, compared with 6.9% of sites ranked 50K–100K. These figures describe service-side availability in the population the study could analyze. They do not measure the number of passkeys created, the number of successful sign-ins, user understanding of synchronization, or the quality of any site’s recovery process.
The popularity pattern has a practical interpretation without needing a grand prediction about the future. High-traffic services have more reason and more resources to expose a new authentication option, and their users encounter the option more often. Lower-ranked services may have login systems but no passkey support. The paper notes that passkeys are commonly offered alongside passwords and traditional multi-factor authentication rather than replacing them. Availability is therefore an additional capability in much of the measured web, not evidence that the password has disappeared as a fallback or that the passkey is already the only route into an account.
The census also finds that manually curated directories capture only a small portion of the deployments detected at scale. That finding matters because a directory is not a neutral sample of the web. Prominent brands are more likely to be listed, while smaller regional services, niche software platforms, and less visible commerce sites can remain undocumented. Automated measurement can reveal a broader deployment landscape, but its broader reach does not make it a security audit.
The measurement method explains why the word “detected” needs to remain attached to the result. Passkey options may be rendered only after JavaScript executes, revealed after a user enters an identifier, or placed inside a browser’s conditional mediation interface rather than a visible “Sign in with passkey” button. A static request for the initial HTML can miss an option that a real browser would display after interaction. Localized labels and menus can create similar blind spots.
Fidentikit, the crawler used in the study, combines 43 heuristics across several signal types, including user-interface and accessibility text, document structures, WebAuthn API calls, network patterns, known libraries, and external identity-provider integrations. The paper reports API instrumentation as a detection category present for 82.3% of passkey sites, while login-page text accounted for 4.5%; the categories can overlap. The contrast is not a claim that one number is the universal accuracy of the tool.