A Passkey Deployment Checklist Beyond the Happy-Path Demo

Creating a passkey once on your laptop is not the same as deploying passkeys.

A production release needs evidence at three layers: public configuration, server verification, and the real user journey. A failure at any layer can produce a broken experience even when the other two look healthy.

This is part two of Passkeys in Production, adapted from our full deployment checklist. Helpers.work also provides the Passkey Deployment Checker used for the public-configuration layer.

1. Record the identity boundary

Write down the actual sign-in origin, RP ID, allowed server origins, credential store, and native app identifiers.

An illustrative setup:

Sign-in origin: https://login.example.com
RP ID:          example.com
Server policy:  explicitly allow https://login.example.com

The RP ID is not necessarily the hostname visible in the address bar. Read it from the options your backend produces.

Keep staging and production boundaries intentional. A parent-domain RP ID combined with overly broad server origin acceptance can expose production authentication to weaker environments.

2. Check public HTTPS

Verify the real login hostname, not only the marketing site:

• DNS resolves to the intended service.
• The certificate covers that hostname.
• The server sends a complete chain.
• HTTPS redirects stay on HTTPS.
• Renewal and expiry monitoring are working.

The SSL Certificate Checker can help identify certificate problems. A valid certificate on the apex domain is not proof that every login subdomain is configured correctly.

Localhost development exceptions do not make HTTP production suitable. A public checker also should not be used to scan private infrastructure.

3. Publish only the files you need

Deployment feature	Relevant configuration
Ordinary single-domain web sign-in	HTTPS, eligible RP ID, server verification
Cross-domain use of one RP ID	/.well-known/webauthn
Credential-manager discovery	Optional /.well-known/passkey-endpoints
Native Apple app	Associated Domains and webcredentials
Native Android app	Digital Asset Links and release signing identity

Sibling subdomains using an eligible common parent RP ID do not normally need Related Origin Requests. They still need explicit server origin validation.

4. Inspect the deployed response

A reverse proxy can turn a well-known request into a redirect or an HTML application shell. Inspect status, headers, and body together:

curl --proto '=https' --max-time 15 --silent --show-error --include \
  https://example.com/.well-known/passkey-endpoints

Replace the example domain with your RP ID. This command leaves redirects visible instead of following them.

An illustrative discovery document:

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

The JSON should be publicly retrievable. The account pages themselves can require authentication and must enforce your enrollment policy.

These are user-facing discovery links, not WebAuthn verification APIs. An absent passkey-endpoints document does not by itself break sign-in.

5. Verify mobile release identity

For Apple, the public association file and the app's entitlement must agree. Check webcredentials, not just applinks, and preserve existing association sections.

For Android, compare the package name and signing-certificate fingerprint for the build users actually install. A debug certificate or upload certificate can differ from the distribution certificate.

The credential-sharing relation is delegate_permission/common.get_login_creds. Follow the Android prerequisites for the surrounding configuration.

A public file scanner cannot inspect your installed binary or force platform association caches to refresh. Test the distributed app.

6. Exercise the backend rejection paths

Use a maintained verifier, then test your own wiring:

• Unexpected, expired, and replayed challenges are rejected.
• Unapproved origins are rejected.
• The RP ID context must match.
• Required presence and verification flags are enforced.
• A credential cannot authenticate a different account.
• Revoked credentials cannot start a new session.

Challenges should be bound to the intended operation and consumed reliably. Do not allow concurrent requests to make a completed challenge reusable.

Be careful with signature counters. Some authenticators and synced credentials do not supply a useful monotonic counter. Apply the library's documented policy rather than treating every non-increase as definitive evidence of cloning.

7. Test the lifecycle

First enrollment is only the start. Test sign-out, sign-in, prompt cancellation, second-credential enrollment, revocation, device loss, and recovery.

Include the browsers, operating systems, credential providers, and mobile builds your audience actually uses. Conditional UI and related-origin support can differ from basic WebAuthn support.

Keep fallback explicit. An unsupported client should not trigger a hidden bypass of origin or verification policy.

8. Plan rollback without locking users out

Stopping new enrollments and stopping existing passkey authentication are different changes. During an incident, the second can strand users who no longer have another sign-in method.

Preserve credential records and the RP ID through an ordinary frontend rollback. Test recovery before removing passwords, and decide which recovered sessions may immediately enroll a new credential.

Track aggregate completion and failure categories without collecting raw credential payloads as routine analytics.

The release gate

Run the Passkey Deployment Checker with your actual RP ID and expected app values. Then complete server and real-device tests.

No public scan can prove your challenge storage, account mapping, session issuance, or recovery process is correct.

Continue with RP ID and related origins, or use the report interpretation guide. New to the model? Start with passkeys explained.

References: W3C WebAuthn, passkey endpoints, and Apple associated domains.