I checked 40 sites for /.well-known/passkey-endpoints. 11 of the 34 I could measure publish it

Passkeys have a small discovery problem. A password manager that wants to say "this site supports passkeys, create one now" has to guess where the enrollment page lives. The W3C WebAppSec draft "A Well-Known URL for Passkey Endpoints" fixes that: a site serves a JSON file at /.well-known/passkey-endpoints with an enroll URL and a manage URL.

I wanted to know how many large sites actually publish it, so I checked 40 of them today (31 October 2026, 17:50 UTC+1) with one curl per domain.

Method

curl -s -m 12 -L -A "<desktop Chrome UA>" \
  -o body -w "%{http_code} %{content_type}" \
  "https://$domain/.well-known/passkey-endpoints"
python3 -c "import json; print(sorted(json.load(open('body')).keys()))"

A domain counts as supporting the file only if the final response is 200 and the body parses as JSON with at least one of the two keys. A 200 that returns an HTML page is a soft 404, not support.

One caveat matters: the requests came from a datacenter server. Six domains answered with a bot wall (403) or a broken connection, so I count them as not measured, not as "no".

Result: 11 of 34 measurable domains

No file (404, or HTML on a 200): google.com, accounts.google.com, microsoft.com, login.microsoftonline.com, apple.com, github.com, facebook.com (400), x.com and linkedin.com (200 but HTML), nintendo.com, ubisoft.com, yahoo.com, proton.me, 1password.com, dashlane.com, cloudflare.com, stripe.com, walmart.com, hubspot.com, mercadolibre.com.ar, zoho.com, docusign.com, discord.com.

Not measured from a datacenter IP: gitlab.com, playstation.com, bitwarden.com, nordpass.com, reddit.com (403), bestbuy.com (HTTP/2 stream error after one redirect).

Three things I did not expect

1. The platforms that pushed passkeys hardest do not publish it on their main domains. Google, Apple and Microsoft all return 404 on the domains I tried. They ship passkeys everywhere, but this discovery file is not where they point password managers.
2. None of the password managers I could measure publish it for their own accounts. 1Password, Dashlane and Proton return 404. The tools that read this file do not serve it.
3. Four of the eleven are not served as application/json. PayPal and Coinbase send text/plain, TikTok sends application/octet-stream, Adobe sends no Content-Type at all. The JSON parses fine in all four, so a client that sniffs the body works; a strict one that checks the header first would skip them. PayPal also points enroll and manage to the same URL, and Amazon and TikTok only declare enroll.

Shopify is the only one that tags its URLs with UTM parameters (utm_source=credential_manager, utm_medium=passkey_endpoint). That is a nice idea: it means they can measure how many enrollments the file actually produces.

If you run a site with passkeys

The whole thing is a static JSON file:

{
  "enroll": "https://example.com/account/passkeys/new",
  "manage": "https://example.com/account/passkeys"
}

Serve it with Content-Type: application/json, make sure the URLs work for a logged-out user (they should go through login and land on the right page), and add UTM tags like Shopify if you want to know whether it does anything.

For background on how passkeys work and why the private key never leaves your device, I keep a plain-language explainer here: what a passkey is and how it works. It is the sibling of an earlier test on the other discovery file, /.well-known/change-password, where 11 of 40 sites also got it right. Same number, by coincidence.

The raw responses are easy to reproduce with the loop above; results will differ from a residential IP for the six blocked domains.