A passkey is not your fingerprint stored on a website. It is a public-key credential, and the fingerprint prompt is one possible way to authorize its use locally.
That distinction explains both the appeal of passkeys and the engineering work that remains after adding a sign-in button.
This is part one of Passkeys in Production, adapted from the Helpers.work passkeys guide. We build the Passkey Deployment Checker, so this series also explains what a public configuration check can and cannot establish.
The smallest useful mental model
With a password, the user presents a reusable secret. With a passkey, an authenticator answers a fresh challenge using a private key, and your server verifies the response using a public key.
Your server: challenge + authentication options
Browser: asks the authenticator for a credential
Authenticator: user approval + signed response
Your server: verification + application session
The website never needs the private key. It does need a reliable mapping between credential IDs, public keys, and accounts.
Registration creates that mapping. Authentication uses it. Do not treat registration as a harmless settings change: enrolling a new credential gives someone a new way to enter the account.
What WebAuthn does
On the web, WebAuthn exposes credential creation and authentication through the browser. The browser and authenticator enforce the credential's relying party scope.
The RP ID is a domain identifier, such as example.com. It is not the same as the browser origin, such as https://login.example.com.
Your backend must verify the challenge, expected origin, RP ID context, applicable user-presence and user-verification requirements, and the appropriate cryptographic response. For authentication, that includes the assertion signature against the correct stored public key.
A signature-only implementation is incomplete. Use a maintained WebAuthn server library and test your configuration around it.
Why this is harder to phish
A lookalike domain cannot normally request credentials for your RP ID. The person does not have to inspect a convincing login page and decide where to type a reusable secret.
That is a different property from a one-time code. Someone can copy an OTP into a phishing page. A correctly scoped credential is not a code that can be pasted anywhere.
There are deliberate cross-domain mechanisms, including Related Origin Requests. They need explicit configuration, not a permissive origin wildcard.
Phishing resistance is not total account security. A stolen session, a compromised server, unsafe credential enrollment, and weak recovery can still put an account at risk.
Synced does not mean universal
Some passkeys synchronize through a credential provider. Others are bound to an authenticator, such as a hardware security key.
These models produce different support questions:
| Credential model | Question to test |
|---|---|
| Synced | Is the credential available through the user's chosen provider on the next device? |
| Device-bound | What happens if the authenticator is lost or damaged? |
| Cross-device authentication | Can the user complete the intended approval flow from another device? |
A QR-code flow does not necessarily copy a passkey to the computer. It may let another device perform authentication.
Likewise, "supports passkeys" does not promise the same autofill or cross-device experience in every browser.
Is a passkey automatically MFA?
Not every WebAuthn operation has the same assurance properties. Local user verification can combine an authenticator with a PIN or biometric check, but a touch-only interaction has different semantics.
Specify the policy you need, request the appropriate verification behavior, and verify it on the server. Do not assume that the presence of a security-key prompt satisfies every organizational MFA requirement.
The website receives a cryptographic response, not a fingerprint image. That is an important privacy distinction to explain in onboarding copy.
The part the demo usually leaves out
Before rolling out, test more than first registration:
- Sign out and authenticate with a fresh challenge.
- Cancel the prompt and recover gracefully.
- Add a second credential.
- Remove a credential and reject its future use.
- Recover after losing the only available authenticator.
- Try an unsupported browser or device.
The resulting session needs the same care as any other authenticated session. Passkeys do not fix authorization bugs or unsafe cookies.
Use user-facing labels such as "Create a passkey" instead of "Scan your fingerprint." A user's actual authenticator may use a PIN, face recognition, or a security key.
You do not need every well-known file
A web-only deployment with an eligible RP ID can work without native app association files.
Related origins matter when different domains need one RP ID. Apple and Android association files matter for the relevant native apps. Passkey endpoints are optional metadata that helps clients discover enrollment and management pages.
The Passkey Deployment Checker inspects public configuration. It cannot register a credential for your account, audit your backend verifier, or prove recovery works. A clean report is one piece of evidence, not the final release gate.
Continue the series
- Passkeys explained
- Production deployment checklist
- RP ID and related origins
- Reading a deployment checker report
For the underlying API and verification requirements, see MDN's Web Authentication overview and the W3C WebAuthn specification.
Top comments (0)