Two zero-permission WebAuthn checks that gate passkey logins also reveal device class, OS floor, and browser engine — a weak but telling fingerprint signal.
In August 2026, Google's Android Developers blog described how WhatsApp upgraded to passkeys for 1 billion users — proof that passkeys have crossed from early-adopter feature to mainstream default. WhatsApp is a native Android app, but the same shift is happening on the web, where a login page has to ask the browser "can this device do a passkey?" before it offers the option. This post is about what that question's answer reveals — to the site asking it, and to any other script running on the same page.
Key Takeaways
- Two capability checks gate passkey UI, and neither needs permission.
PublicKeyCredential.isUserVerifyingPlatformAuthenticatorAvailable()andisConditionalMediationAvailable()are promise-returning checks with no permission prompt, no user gesture, and no visible UI — see the WebAuthn Level 3 spec and MDN's reference. - The true/false answer correlates with device class, OS floor, and browser engine. A platform authenticator means built-in user verification — Face ID, Touch ID, Windows Hello, or an Android screen lock — tied to specific OS versions and engines, so one boolean splits visitors more sharply than you'd expect.
- It's low entropy, honestly. Even with the newer
getClientCapabilities()bundle, the answers mostly overlap with what the User-Agent already discloses, so on their own they barely narrow anyone down. - Its real value is as a contradiction check, not an identifier. A User-Agent claiming a modern flagship phone with no platform authenticator available is the interesting case — the classic anti-detect or emulator profile.
- The probe reveals capability only. It cannot tell a script whether you have a passkey for this site, any site, or who you are — that requires an explicit, user-verified credential ceremony scoped to one relying party.
The Two Checks Behind Every "Use a Passkey?" Button
A login page that wants to offer a passkey option first has to find out whether the device can produce one. WebAuthn gives it two static methods on PublicKeyCredential, both defined in the WebAuthn Level 3 spec maintained by the W3C:
isUserVerifyingPlatformAuthenticatorAvailable()answers one question: does this browser, on this device, have access to a built-in authenticator that can verify the user — Face ID or Touch ID, Windows Hello (face, fingerprint, or PIN), or an Android device's biometric or screen-lock check? MDN documents it as a static method returning aPromise<boolean>.isConditionalMediationAvailable()answers a narrower, adjacent question: can this browser show a conditional passkey autofill option in a regular username field, without a modal dialog interrupting the page?
Newer browsers add a third, broader method: PublicKeyCredential.getClientCapabilities(), which returns a whole record of booleans in one call — conditional get and create, hybrid (cross-device) transport, passkey platform authenticator support, Related Origin Requests, the newer "signal" methods, and supported extensions. Like the two older checks, it needs only a secure (HTTPS) context.
Both share the same three properties that matter for this article: they require no permission prompt, no user gesture, and produce no visible UI of their own. A page can call either one the instant it loads, get an answer in milliseconds, and the visitor never sees anything happen. That is by design — a login page is supposed to decide, silently, whether "Sign in with a passkey" is worth showing at all. The same silence is exactly what makes the answer readable by any script running on the page, not only the login code that needed it.
What a True/False Pair Actually Correlates With
A single boolean sounds like almost nothing — one bit. But that bit is not independent noise; it is downstream of real hardware and software facts, and it partitions visitors more sharply than the bit count suggests:
- Device class. A platform authenticator usually sits on hardware-backed key storage — a secure enclave, a TPM, or Android's hardware keystore. Older desktops, many virtual machines, and some Linux setups can't offer one, and on phones the answer also depends on whether a screen lock is actually set.
- OS version floor. Each OS shipped platform-authenticator support at a specific release; a
trueanswer implies the device is at or above that floor, which is more precise than most other passive signals get you. - Browser engine. Not every engine wires up the API the same way at the same time, so the answer also brackets which rendering engine — and roughly which version — is in play.
- Managed or virtualized status, in some configurations. A device without hardware-backed secure storage — some VMs, some locked-down managed images — can come back
falseeven when the reported OS and browser would normally support the check.
Put those together and a pair of booleans behaves less like two bits and more like a coarse classifier over device generation, OS floor, and engine — read the mechanics behind those signals in our browser fingerprinting guide — but it is still just a classifier, not a lookup. Treat the correlation as real and useful, not as proof of anything about a specific device.
Entropy Honesty: A Few Bits, Not an Identifier
It would be easy to oversell this. Don't. On its own, isUserVerifyingPlatformAuthenticatorAvailable() returns one bit, and isConditionalMediationAvailable() adds at most one more. getClientCapabilities() returns more fields, but they aren't independent: most of them flip together with browser brand and version, because each vendor ships these features in batches. Worse for anyone hoping to use this as a standalone identifier, nearly all of it correlates with what the User-Agent string already discloses about OS and browser version. Added to an existing fingerprint, this signal narrows very little that wasn't already narrowed.
Where it earns its keep is different: as a contradiction check, not an identifier. A detector isn't asking "what value did this return?" in isolation — it's asking whether the value agrees with everything else the page already knows. A User-Agent that claims a current flagship phone, paired with isUserVerifyingPlatformAuthenticatorAvailable() returning false, is a mismatch worth flagging: real flagship phones ship with a platform authenticator, and almost all of them have a screen lock set. Likewise, a UA claiming a recent Chrome or Safari whose getClientCapabilities() method is missing entirely doesn't add up. That exact mismatch pattern shows up in anti-detect browser profiles and spoofed automation, where one claimed attribute (a modern UA string) doesn't line up with another (no platform authenticator, no TPM, no secure enclave) because the profile was assembled from parts rather than measured off a real device.
This is the same idea behind media devices fingerprinting and other zero-permission hardware probes: no single check identifies you, but each one is another place a fabricated profile has to get its story straight, and consistency is harder to fake than any one value.
The Irony: Built for Privacy, Becomes a Small Signal Itself
Here's the part worth sitting with. Passkeys were designed to replace passwords — phishable secrets that people reuse across sites — with key pairs that are scoped to a single site and can't be correlated across sites. And yet the very API that offers that improvement leaks a small, passive signal of its own, just by existing and answering true or false.
Two caveats keep this honest rather than alarmist. First, software and virtual authenticators exist for testing — browser DevTools and CI environments can register a virtual platform authenticator that returns true on a machine with no real biometric hardware at all, so the check is not a hardware guarantee in every context. Second, the probe cannot distinguish "no authenticator exists" from "it isn't set up." A phone with a fingerprint sensor but no screen lock configured, or a PC where Windows Hello was never enrolled, can look identical, from this API, to a device that never had the hardware in the first place. Both caveats push the same direction: treat this as a weak, corroborating signal, not a strong one — a contradiction check earns its value from being cheap to run, not from being decisive on its own.
What This Probe Does Not Reveal
This is the section worth being precise about, because it's where overclaiming does the most damage to a reader's trust:
- It does not reveal whether you have a passkey for this site, or any site. Capability ("can this device do passkeys at all?") and enrollment ("does a specific credential exist for this relying party?") are entirely separate questions, and this API answers only the first.
- It does not reveal your identity. A WebAuthn credential is scoped to one relying party by design — a passkey created for one site cannot be read, enumerated, or correlated by a different site, and each site gets its own key pair rather than a shared identifier like a third-party cookie.
- It requires an explicit user-verification step to do anything with a real credential. Checking capability is silent; actually using a passkey to sign in still requires the user to complete a biometric or PIN prompt. Nothing about the capability check itself moves you closer to that.
That scoping is a deliberate design choice, and it's a stronger privacy boundary than most passive fingerprinting signals get: compare it with device attestation, which asserts a much stronger, cryptographically signed claim about a specific device rather than a soft, low-entropy capability bit. Passkey capability checks and anonymous credentials sit closer together on that spectrum — both are built to prove a narrow property without exposing identity — while device attestation is a fundamentally stronger and more identifying claim. If your interest is in how sites infer which of your accounts you're logged into rather than what your hardware can do, that's a different mechanism entirely — see cross-site login detection.
Where This Leaves You
A passkey capability check is a clean example of the consistency-checking idea that runs through this blog: individually weak signals, cross-checked against each other, catch more than any single strong signal would. It is not a fingerprint on its own, and it is not a privacy risk in the way a tracking cookie or an attestation token is — but it is one more place where "what you claim to be" and "what your device can actually do" either agree or don't.
Our tools don't probe passkey support today, but they show the signals a passkey answer would be cross-checked against: run the fingerprint check to see the User-Agent, platform, and hardware attributes your browser exposes, or try bot detection to see how contradictions between those attributes get flagged.
Frequently Asked Questions
Does checking passkey support require my permission?
No. isUserVerifyingPlatformAuthenticatorAvailable(), isConditionalMediationAvailable(), and getClientCapabilities() are silent, promise-based checks — no permission prompt, no user gesture, and nothing visible happens on the page.
Can a website tell if I have a passkey saved?
No. These checks report device capability — whether a platform authenticator exists at all — not whether a passkey has been enrolled for that site or any site. Credential enrollment is scoped per relying party and isn't exposed by this API.
Is a false result from this check always meaningful?
Not on its own. It can mean the device genuinely lacks a platform authenticator, or that one exists but isn't set up (for example, no screen lock or Windows Hello enrollment), or — in a testing context — that no virtual authenticator has been registered. Treat it as one weak, corroborating signal rather than a definitive answer.
How is this different from device attestation?
Very different in strength. This capability check is a soft, low-entropy boolean that correlates with device class and OS/browser version. Device attestation is a cryptographically signed, hardware-backed claim about a specific device — a much stronger and more identifying assertion.
Recommended Reading:
- Browser Fingerprinting Explained: How to Protect Your Privacy
- Device Attestation Explained: Play Integrity vs. App Attest
- Anonymous Credentials: Proving Humanity Without Being Tracked
- Media Devices Fingerprinting: What enumerateDevices Leaks
- Login Detection: How Sites Know Which Services You Use
- Impossible Fingerprints: GPU/OS/Font Combinations That Flag You
