Passkey Deployment Checker

1. Enter the website where users sign in, such as login.example.com.
2. Open Advanced settings and enter the RP ID your server uses. Without it, the checker assumes the RP ID equals the hostname.
3. Enable the Apple and Android checks if your native apps share passkeys with the website, and add the expected App ID, package name or fingerprint for exact matching.
4. Select Check Configuration . Each item in the report includes the exact endpoint, the HTTP status, what was wrong and how to fix it.

A passkey is a sign-in credential based on public-key cryptography. When a user registers, their device or password manager creates a key pair for your site: the private key never leaves the authenticator, and your server stores only the public key. To sign in, the authenticator signs a fresh challenge from your server after the user unlocks it with a fingerprint, face scan or device PIN.

Passkeys are built on the W3C WebAuthn standard and the FIDO2 protocols. Because every passkey is bound to one domain — the Relying Party ID — it cannot be phished on a look-alike site, and there is no shared secret that can leak from your database.

The checker makes read-only HTTPS requests to public endpoints and validates what it finds:

HTTPS configuration

Passkeys only work in secure contexts. The checker opens a TLS connection with standard certificate verification, follows up to three HTTPS redirects and reports DNS, certificate, timeout and connection problems. For a full certificate breakdown use the SSL Certificate Checker.

RP ID compatibility

WebAuthn requires the RP ID to equal the page's hostname or be a registrable parent of it. example.com is valid on login.example.com; co.uk (a public suffix) and another-domain.com are not — unless Related Origins authorize the website.

Related Origins — /.well-known/webauthn

Lets one RP ID work across different domains. The file must be served as application/json with HTTP 200 and contain an origins array. The checker applies the WebAuthn Level 3 matching rules, including the five-label minimum browsers must support.

Passkey Endpoints — /.well-known/passkey-endpoints

An optional W3C draft that advertises enroll, manage and prfUsageDetails URLs. Redirects are not allowed. Advertised URLs are validated but never visited.

Apple App Site Association and Android Asset Links

apple-app-site-association needs a webcredentials.apps list, and assetlinks.json needs a statement with delegate_permission/common.get_login_creds plus the app's package name and full SHA-256 signing-certificate fingerprint. Both are read from the RP ID domain — the domain your apps associate with — and must be served without redirects.

Browser capabilities

A separate panel queries the browser you are using with PublicKeyCredential.getClientCapabilities() and related methods. That describes your device, not the scanned site.

• Passed — the configuration matches the specification.
• Warning — it works, but something is fragile, deprecated or likely to cause problems.
• Failed — browsers or operating systems will reject the configuration, or an expected value is missing.
• Not applicable — an optional feature is not configured or not selected. That is not a problem by itself.
• Unknown — the server could not be reached or answered ambiguously, so the item could not be evaluated.

There is no overall score: a clean report means the public configuration is consistent, not that your sign-in flow is secure.

Incorrect RP ID

Registering passkeys with rp.id = "www.example.com" locks them to that host, so they will not work on app.example.com. Use the registrable domain ( example.com ) if subdomains must share passkeys — and never change the RP ID after launch, because existing passkeys stay bound to the old one.

Related-origin misconfiguration

The file must live on the RP ID host, not on the related site. Typical errors are a text/html content type from a catch-all route, listing hostnames instead of origins (example.co.uk instead of https://example.co.uk), or more than five distinct brand labels.

Missing mobile app associations

If an iOS or Android app should use the same passkeys, the website must vouch for the app. A missing webcredentials section or a missing get_login_creds relation is a common reason passkeys created on the web don't appear in the app.

Invalid .well-known JSON files

Trailing commas, comments, a byte-order mark or a wrong content type make strict parsers reject the file. Validate the document with the JSON Formatter before deploying it.

Incorrect deployment assumptions

A redirect from example.com to www.example.com breaks files that must not be redirected; CDNs may cache an old version; and a valid file on the web does not prove the app's entitlement or manifest is configured. Also check DNS with the DNS Lookup tool and domain ownership with WHOIS Lookup.

/.well-known/webauthn

{
  "origins": [
    "https://example.com",
    "https://example.co.uk",
    "https://login.example.net"
  ]
}

/.well-known/passkey-endpoints

{
  "enroll": "https://example.com/settings/passkeys/create",
  "manage": "https://example.com/settings/passkeys",
  "prfUsageDetails": "https://example.com/help/passkeys"
}

/.well-known/apple-app-site-association

{
  "webcredentials": {
    "apps": ["TEAMID1234.com.example.app"]
  }
}

/.well-known/assetlinks.json

[
  {
    "relation": ["delegate_permission/common.get_login_creds"],
    "target": {
      "namespace": "android_app",
      "package_name": "com.example.app",
      "sha256_cert_fingerprints": ["14:6D:E9:83:…:A5"]
    }
  }
]

The fingerprint above is shortened for readability; a real SHA-256 fingerprint has 32 colon-separated bytes. WebAuthn payloads use base64url — decode them with the Base64 decoder, and inspect ID tokens from your identity provider with the JWT Decoder.

• It does not register, use or simulate a passkey, and never contacts your WebAuthn API endpoints.
• It cannot see your server-side rp.id, origin verification or attestation settings.
• It cannot verify an iOS Associated Domains entitlement, Apple's CDN cache, or an Android app's manifest and signing key.
• Only public hostnames on port 443 are checked. Private networks, IP addresses and local names are refused.