A website can have valid passkey metadata and a broken authentication flow. It can also support passkeys while publishing none of the optional discovery files a scanner looks for.
The useful question is not "How many green checks do I have?" It is "Which conditions did this report evaluate, and which of them does my architecture require?"
This is the final part of Passkeys in Production, adapted from the full report guide. We build the Helpers.work Passkey Deployment Checker; this walkthrough describes its actual scope.
Use the origin where WebAuthn runs
Enter your public sign-in URL or domain. The tool normalizes it to an origin, so supplying /account/security does not turn the scan into a test of that page.
If the marketing site redirects to a login host, use the host where the browser actually creates or requests credentials.
The checker uses public HTTPS domains on port 443. It does not scan localhost, IP-literal targets, private networks, custom website ports, or URLs containing embedded credentials.
Those are tool restrictions. They are not a claim that every excluded environment is inherently unsupported by WebAuthn.
Enter your real RP ID
The most important advanced field is the RP ID.
Website: https://login.example.com
RP ID: example.com
This illustrative setup may be intentional. If you omit the RP ID, the tool instead uses login.example.com and marks the source as inferred.
That is a default, not reliable discovery. Read publicKey.rp.id in registration options and publicKey.rpId in authentication options from your backend.
See the RP ID guide if the domain relationship is unclear.
Know the six checks
| Check | What it evaluates |
|---|---|
| HTTPS Configuration | Public connectivity and normal certificate validation |
| RP ID Compatibility | Website-to-RP relationship for the supplied inputs |
| Related Origins | RP-host /.well-known/webauthn and applicable origins |
| Passkey Endpoints | Optional discovery metadata and URL syntax |
| Apple App Site Association | Public webcredentials declarations |
| Android Asset Links | Public credential-sharing statements and expected identity |
HTTPS and RP ID checks are always evaluated. Related origins and passkey endpoints are selected by default; mobile checks are opt-in.
An unrelated RP ID forces the required related-origin evaluation even if the optional selection is off.
For native apps, provide expected identifiers and the actual release signing-certificate fingerprint when available. Without expected values, valid JSON for another app is not proof that your app is configured.
Read statuses instead of inventing a score
| Status | Meaning |
|---|---|
passed |
The evaluated condition passed for these inputs |
warning |
A concern or compatibility limitation needs review |
failed |
The evaluated condition failed |
not_applicable |
Not selected, or optional configuration is not applicable |
unknown |
The checker could not reach a reliable conclusion |
The report-level success value means a report was produced. It does not mean all checks passed.
A required related-origin failure can block your intended cross-domain flow. A missing optional discovery document may not affect sign-in at all. A network timeout should not be relabeled as either a pass or a confirmed deployment defect.
Three examples of useful interpretation
These are hypothetical scenarios, not live scan results.
The web-only application
The site uses an eligible RP ID and has no native apps. Apple and Android association files are not relevant to that deployment.
A missing /.well-known/passkey-endpoints file is also not proof that passkeys are unavailable. It is optional metadata for helping clients find enrollment and management pages.
Focus on the actual registration and authentication ceremony.
The cross-domain application
The browser runs at https://example.co.uk and requests RP ID example.com.
Inspect https://example.com/.well-known/webauthn. Verify the calling origin is represented, the body is usable JSON, and the client supports the mechanism.
The backend still needs explicit origin acceptance and the correct credential records.
The Android release-only failure
The public file may contain a debug or upload-certificate fingerprint rather than the certificate on the distributed app.
Compare package name, credential-sharing relation, and release signing identity together. The scanner cannot inspect the installed binary or app manifest.
Some green results have important limits
A passkey-endpoints result validates advertised URLs syntactically. It does not visit those URLs or exercise enrollment.
An Apple association result does not verify the app entitlement or Apple's cached state. An Android result does not verify the manifest, resources, or installed signing certificate.
An HTTPS result is not a full TLS audit. It does not evaluate every cipher, security header, or route.
And no public configuration report verifies challenge freshness, assertion signatures, account mapping, session issuance, or account recovery.
Fix the failed layer, then test again
Work from DNS and HTTPS toward RP ID, required files, clients, and the server ceremony.
An HTML response with status 200 often points to a catch-all route, not malformed JSON. Redirect handling also differs: this checker follows bounded HTTPS redirects for related origins but treats passkey-endpoint and app-association redirects differently.
After deployment, inspect the public response rather than assuming the local file is already visible through the CDN.
Then register, sign out, sign in, cancel, revoke, and recover on your supported clients. Use the production checklist as the final release gate.
For the conceptual foundation, see passkeys explained. Technical references: W3C passkey endpoints, Apple associated domains, and Android prerequisites.
Top comments (0)