Can Passkeys Fingerprint Users? WebAuthn Privacy Risks

Passkeys use WebAuthn to create and use public-key credentials. A browser can also expose limited information about whether some WebAuthn workflows are available. Those results can help a relying party decide which sign-in option to present. They are feature hints, not a hardware inventory, proof of a person's identity, proof that a credential exists, or proof that a later sign-in will succeed.

That distinction matters for privacy and for product design. A capability result may vary with browser support, operating-system policy, account state, available authenticators, and the current context. Treating it as a definitive statement about a device turns a compatibility input into an unsupported inference. Treating it as a credential result can lead to a confusing sign-in experience.

The WebAuthn Level 3 specification defines the relevant browser interfaces and credential ceremonies. MDN's PublicKeyCredential reference provides the browser-facing reference. Together, they support a careful model: capability availability, user verification, authenticator use, credential creation, and credential retrieval are related, but distinct, events.

Source-to-claim map

• Secure context and PublicKeyCredential (normative/API reference): MDN's PublicKeyCredential reference documents the secure-context requirement. Article recommendation: treat that prerequisite as a compatibility gate, never as evidence that an authenticator or credential exists.
• Platform authenticator availability (normative/API reference): W3C 5.1.6 and MDN's method reference define an availability check, not credential existence. Article recommendation: use the Boolean only to choose whether to offer a platform-authenticator path.
• Conditional mediation (normative/API reference): W3C client capabilities and MDN's conditional-mediation reference describe an availability indicator, not a sign-in result. Article recommendation: keep another sign-in route when the method is absent or unavailable.
• Origin, RP ID, and ceremony (normative protocol rules): W3C origin and RP ID rules scope credentials to the relying party, while the ceremony algorithms require a request, user participation, and a verified response. Article recommendation: make account, authorization, and recovery decisions only after server verification; do not infer them from a capability hint.

What A Capability Result Can Mean

The PublicKeyCredential interface is available only in secure contexts. Secure transport is therefore a prerequisite for WebAuthn use, but it does not establish that an authenticator or credential is available. A page can lack access to WebAuthn because the context is not secure, because the browser does not support the relevant interface, or because a particular optional method is absent. Each case calls for a different user experience.

WebAuthn Level 3 section 5.1.6 defines isUserVerifyingPlatformAuthenticatorAvailable(). The specification says relying parties use it to determine whether they can create a new credential using a user-verifying platform authenticator. The result is a Boolean derived from a client-platform procedure that discovers available user-verifying platform authenticators. A true result is useful when deciding whether to offer a platform-authenticator registration path. It does not name the authenticator, reveal a particular sensor, establish enrollment for a particular user, or confirm that a credential is already registered with the site; MDN documents the same method as an availability check.

The word platform is important. In WebAuthn, an authenticator's attachment and its ability to perform user verification are protocol concepts. They do not authorize a site to turn a Boolean response into a claim about a person's biometrics or hardware. A device may offer several authenticators. A user may choose a different one during a ceremony. Settings, enterprise policy, account configuration, or changes to an authenticator can affect what is usable when the ceremony begins.

Section 5.1.7 of the Level 3 specification describes client capabilities as a limited set of capability keys used to offer certain workflows and experiences. That purpose is narrower than identity or device classification. For example, a result can inform whether a sign-in screen offers a particular path alongside a username field. It should not be used to label a visitor, infer the presence of a credential, or decide that password recovery is unnecessary.

Conditional mediation needs the same care. The specification describes isConditionalMediationAvailable() as an availability indicator for conditional mediation. It can help an application choose an interface, but it does not perform a sign-in and does not show that a passkey is available for the current relying party. MDN lists it as a static PublicKeyCredential method and notes that the API is limited to secure contexts in supporting browsers. An application should handle a missing method or an unavailable result by keeping another sign-in route available.

Availability, User Verification, And Credentials

Availability is the first layer. It asks whether the browser can expose a particular WebAuthn option in the current environment. It is not a statement that a user can authenticate. User verification is another layer. It is a property requested and evaluated during a credential ceremony, where the authenticator may need to verify the user according to the request and its own policy. A capability result does not complete that verification.

Authenticator availability is also separate from credential availability. A platform authenticator can be available while no credential for a given site has been created. Conversely, a user might have a valid credential that is usable through an authenticator other than the one an application expected. The reliable way to learn whether a sign-in can complete is to run the normal WebAuthn request after the user has chosen that path and after the application has supplied the correct relying-party data.

Credential creation and assertion are active operations. During registration, the browser and authenticator can create a new public-key credential after the relying party requests it. During authentication, they can produce an assertion for an existing credential. These operations can succeed, be declined by the user, be cancelled, be unavailable, or fail for other request-specific reasons; the WebAuthn ceremony algorithms define these request-and-response steps. A capability check cannot substitute for either operation.

The Level 3 specification's PublicKeyCredential interface description makes this separation visible. A returned credential has a response after a new credential is created or an assertion is requested. A capability method, by contrast, returns information used to guide a possible workflow. Applications should model these as separate states in their interface and telemetry. “Can offer this option” is not the same state as “the user approved it,” “a credential was created,” or “an assertion was verified.”

Cancellation deserves explicit handling. A person can close or decline an authenticator prompt. That outcome is not evidence about the person's identity, their hardware, or their willingness to use passkeys in every context. It is an interaction result. Present a clear return path to password, recovery, or another supported method, and avoid retrying a ceremony without a new user action. A considerate interface describes the choice before it opens an authentication flow and gives the user a clear way back afterward.

The same principle applies to errors. An unavailable authenticator, an expired server challenge, an RP mismatch, a changed account, and a browser policy can produce different outcomes. Product teams should record only the diagnostic detail needed to support a user and should avoid converting a failure category into a persistent profile. The browser permission fingerprinting overview gives related context for treating browser-exposed states as limited signals rather than identity facts.

Origin And Relying-Party Boundaries

WebAuthn is intentionally scoped. The Level 3 specification's origin and RP ID rules state that operations are scoped to a particular origin and that the full requester origin is included and signed in attestation objects and assertions. It also states that each credential is scoped to a relying-party identifier, or RP ID. An authenticator restricts credentials created for one RP ID to operations requested by that RP ID.

These boundaries explain why a capability result cannot establish cross-site credential access. A site receives an assertion only through a ceremony for its own origin and RP ID, subject to the browser's validation and the authenticator's processing. It cannot use a general capability hint as a substitute for the protocol's origin and relying-party checks. The secure-context requirement is part of the same security model.

For an application, the practical rule is straightforward. Start a registration or sign-in ceremony only for the site's intended origin and RP ID. Let the browser and authenticator enforce their roles. Verify the server-side response according to the WebAuthn protocol before treating a login as complete. Do not base account discovery, authorization, or recovery decisions on a client capability response.

Related origins need deliberate configuration, not assumptions. The specification includes rules for using WebAuthn across related origins. A shared organization name or a similar hostname is not by itself a credential relationship. Teams that operate several sites should define their RP ID and origin policy before launching a passkey flow, test it on their supported domains, and document the fallback behavior when that relationship does not apply.

The origin boundary also improves privacy. It limits the ability of a relying party to use WebAuthn credentials issued for another relying party. That protection does not mean a site's own collection choices are automatically privacy-preserving. A site should still minimize what it logs, explain why it offers an authentication option, and avoid using compatibility information for unrelated profiling.

Privacy Limits Of WebAuthn Hints

Capability information can contribute to a broader set of browser-exposed details. A result may be useful in combination with other information for compatibility decisions, and it can change as software, policy, or account state changes. It is therefore neither a stable identifier nor a reliable description of a physical device. It cannot prove that a visitor owns a particular device, has a specific biometric method, or has an account at a relying party.

That limitation is especially relevant when an application decides what to retain. A Boolean or a small capability record can be enough to choose between visible sign-in options for the current visit. It does not need to become an account attribute, an analytics dimension, or a long-lived identifier. Retaining it for those unrelated purposes increases the chance that a transient compatibility condition will be misunderstood later. If diagnostic logging is necessary, define a short retention period, restrict access, and document the operational reason for collecting it.

Sites should also distinguish information that the user intentionally provides from information inferred from browser support. An account identifier entered into a form, an explicit selection of a sign-in method, and a completed credential ceremony have different meanings and different privacy expectations. A feature hint belongs in none of those categories. Showing a passkey option is not consent to start a ceremony, and a declined prompt is not consent to store a preference about the person.

Accessibility and recovery depend on the same distinction. Some people use external authenticators, shared devices, assistive technology, or account-recovery paths that do not resemble a typical platform-authenticator flow. A capability result must not remove the routes those people need. Keep labels focused on the action offered, avoid assumptions about the user's device, and make it possible to leave the flow without losing progress. These choices make the sign-in screen more useful even when WebAuthn is fully supported.

Support teams benefit from precise language, too. A report can say that a passkey option was offered, that a person cancelled it, or that the server did not verify an assertion. It should not say that a person lacks biometric hardware or that a browser is definitively a particular environment based on one feature result. Narrow descriptions preserve useful troubleshooting context without turning a protocol state into an identity claim.

Private browsing deserves qualified language as well. Browsers may apply different storage, account, permission, and credential behavior in private contexts. The WebAuthn specification does not say that every private window must return the same capability values or complete the same ceremonies as a regular window. Applications should test the browsers and modes they support and preserve a fallback when WebAuthn is unavailable. Users should not be told that private browsing makes a WebAuthn response identical, anonymous, or predictable.

Display mode also does not justify a universal conclusion. A headed or headless environment may differ by browser build, operating system, policy, available authenticators, and test configuration. The standard defines WebAuthn semantics, not a guaranteed equality between display modes. Teams that need compatibility across environments should test their own supported matrix and report observed support narrowly. They should not use a single result to characterize every headless browser or every desktop browser.

Removing an interface, replacing a browser method, or attempting to force a result is not a reliable privacy control. It can make an application's compatibility decision inaccurate or interrupt an authentication flow. More importantly, a public-facing account flow should not promise that any configuration is invisible to a site or immune from additional inferences. Privacy claims need to stay within what a user can observe and what the product documentation can support.

For users, the useful questions are concrete: Does the site explain what the passkey option does? Can the user choose a different sign-in method? Does the site request a credential only after the user selects that path? Does the site retain only the information it needs to operate the account securely? These questions are more actionable than attempting to read identity or hardware certainty into a feature hint.

The navigator properties and fingerprinting guide covers the broader principle. Individual browser values can be compatibility inputs, but their meaning depends on context. Privacy decisions should focus on data minimization, understandable choices, and testing supported behavior, not on treating one API response as a conclusive profile.

Designing A Respectful Sign-In Flow

Offer passkeys as an explicit sign-in or registration choice. A capability hint can help determine whether to show an option prominently, but the user should still decide whether to continue. Keep a password, recovery, or other supported route visible when the capability is absent, optional functionality is not supported, the person declines, or an operation does not complete. This follows the MDN Web Authentication API flow, where registration and authentication are user-mediated operations. The fallback is part of the sign-in experience, not an exceptional afterthought.

Use concise, specific interface text. Say that a passkey can be created or used for the current account. Do not say that a credential is already available until an authentication ceremony has produced a result the server verifies. Do not imply that the user must have a particular kind of hardware. A person may use a supported external authenticator, a different device, or another sign-in method.

Keep compatibility checks and credential ceremonies separate in product logic. The first can influence presentation. The second requires a relying-party request, browser and authenticator processing, and user participation. After a cancellation or failure, return the person to an understandable choice rather than inferring a permanent preference. Rate limits, fraud controls, and account-security policies should use their own documented inputs rather than repurposing WebAuthn availability as a risk score.

When testing a flow, cover outcomes rather than trying to derive a device profile. Include a browser where the optional capability is unavailable, a user who chooses another sign-in method, a cancellation, a registration that completes, and a sign-in that the server verifies. Test the supported origin and RP ID combinations. Repeat these checks after browser or operating-system updates, because optional support and error handling can change.

Document the service boundary. A browser authenticator and a relying party have separate responsibilities. The relying party creates the request and verifies the response on its server. The browser coordinates the interaction. The authenticator performs its protocol role. A capability response does not transfer credentials to a site, and a site should not describe it as consent to create, retrieve, or share a credential. Any account change or transfer of data outside the expected service boundary needs a clear user choice.

BotBrowser documents profile-controlled WebAuthn client capabilities. If you are an authorized privacy or compatibility tester, this lets you repeat a documented browser configuration and check that your sign-in page still offers a fallback when passkey options differ. It cannot prove or create physical authenticator hardware, credential enrollment, or a verified sign-in, and it does not control your relying party's origin and RP ID rules, server-side verification, or retention policy. Validate your supported configuration against the public WebAuthn definitions and your own account flow. The profile management guide has general guidance on managing browser profiles without turning a profile setting into an identity claim.

Sources

• W3C Web Authentication: WebAuthn Level 3: section 5.1.6 defines the user-verifying platform authenticator availability method; section 5.1.7 defines client capabilities; section 5.1 and the security model describe secure contexts, origins, responses, and RP ID scoping.
• MDN: Web Authentication API: browser-facing overview of registration, authentication, and passkeys.
• MDN: PublicKeyCredential: secure-context notice and the PublicKeyCredential static methods, including conditional mediation and user-verifying platform authenticator availability.