WebAuthn Level 3 Is a Recommendation: Is Your Passkey Login Production-Ready?

On August 25, 2026, Web Authentication Level 3 became a W3C Recommendation. For product teams, that is less a signal to rush out one more passkey button and more a reason to ask a deeper question: Is the authentication boundary designed cleanly, or does the passkey merely work on the happy path?

Passkeys are compelling because they do not send a reusable password to the server and because browsers, operating systems, and authenticators help enforce that credentials are used for the intended service. That same strength makes implementation details such as RP ID, origin validation, and credential mapping security-critical.

A sign-in can work perfectly in Chrome on a developer laptop and still be fragile in production. The application may span several subdomains, staging may share production authentication settings, the server may accept too many origins, conditional UI may be treated as the only login route, or device-loss recovery may quietly fall back to a much weaker process.

WebAuthn Level 3 is therefore a good moment to review passkeys not as a UI feature but as an authentication architecture.

1. RP ID is a trust boundary, not an arbitrary configuration string

WebAuthn binds credentials to a Relying Party. The RP ID is central to that binding. According to the W3C specification, it is normally the effective domain of the calling origin or an eligible registrable parent-domain suffix. It contains neither scheme nor port.

That sounds abstract until it meets a real deployment.

If sign-in lives at https://login.example.com, the RP ID might be login.example.com or, where the architecture deliberately requires the broader scope, example.com. Choosing example.com creates a wider organizational trust boundary than choosing login.example.com.

The audit question is therefore not only: What works today? It is: Which hosts should belong to the same authentication domain over the life of the product?

Review at least:

• the main application, admin area, and customer portal,
• www versus application subdomains,
• legacy login hosts,
• preview and staging environments,
• white-label or customer domains,
• planned domain migrations.

An overly broad RP ID is not just a convenience setting that can be narrowed later without consequences. It is part of credential scope. An overly narrow RP ID can make later host changes unnecessarily difficult.

The right RP ID is an architecture decision, not a tutorial value to copy and paste.

2. RP ID never replaces server-side origin validation

A common misconception is that because the browser already binds a credential to the RP, the server can be relaxed about the origin.

It cannot.

The WebAuthn specification requires multiple server-side checks during authentication. They include the expected challenge, the operation type, the expected origin, the RP ID hash, and authenticator flags. An unexpected origin must not simply be accepted.

This becomes especially important when several frontends use the same authentication backend.

For an application with one login origin, exact comparison against that origin is easy to reason about. If several origins are legitimately allowed, use an explicit allowlist or an equally strict validation rule.

Red flags include:

• origin.endsWith("example.com"),
• substring checks,
• trusting every preview subdomain by default,
• sharing one origin list across development and production,
• ignoring scheme or port,
• reverse-proxy configuration that mixes internal and public hosts.

RP ID and origin answer different questions. RP ID determines the Relying Party namespace for the credential. Origin tells the server which concrete web context initiated the ceremony. Both belong in the trust decision.

3. The challenge must be fresh, transaction-bound, and verified on the server

Passkey cryptography helps only when the server verifies the exact operation it initiated.

The challenge exists for that purpose. It should be random, sufficiently strong, short-lived, and bound to the specific registration or authentication attempt. When the response returns, the server needs to verify that this exact challenge was expected.

A robust flow can answer:

• Who generated this challenge?
• Was it for registration or sign-in?
• Which account or pending browser transaction does it belong to?
• How long is it valid?
• Can it be replayed?
• What happens when the user opens two login tabs in parallel?

A WebAuthn assertion is not a free-standing statement that “this user signed something at some point.” The server must establish that it belongs to this current authentication transaction.

4. Discoverable credentials change account mapping

Passkeys are discoverable credentials. That allows sign-in without asking for a username first. The authenticator can offer credentials that match the RP; after selection, the application receives a credential identifier and, depending on the flow, a user handle.

That is excellent passwordless UX. It also changes backend assumptions.

When allowCredentials is empty or omitted, the server must map the incoming credential ID to a stored credential and then to the correct local user account. The specification uses the user handle as a stable RP-assigned user reference for these flows.

Red flags include:

• an account can store only one passkey,
• credential IDs are not uniquely indexed,
• mapping depends on email address or display name instead of a stable internal identifier,
• removing one credential accidentally locks or deletes the account,
• there is no clean model for several devices or security keys on one account.

A healthy data model treats a passkey as one of several possible authenticators for an account, not as the account itself.

5. userVerification needs to match the actual security requirement

WebAuthn supports user-verification preferences including required, preferred, and discouraged. This is not merely a cosmetic UX choice.

If the product genuinely requires the local authenticator to verify the user for an action—using a device PIN or biometric, for example—the request needs to express that requirement and the server needs to validate the result. Under required, the specification requires the operation to fail when user verification cannot be performed.

That does not mean every site should blindly use required everywhere. It means the policy should be explicit.

Ask:

• Is the selected verification level appropriate for ordinary sign-in?
• Do especially sensitive actions need a fresh high-assurance check?
• Does the server actually enforce the UV result or ignore it?
• Does the team understand the differences between platform authenticators, security keys, and cross-device use?

“The browser showed something that looked like Face ID” is not a server-side security policy.

6. Conditional UI is progressive enhancement, not a reason to hide fallback

Conditional mediation lets WebAuthn integrate passkeys directly into an existing sign-in form. The browser or credential manager can offer a passkey in the autofill experience without immediately forcing a modal authenticator prompt.

That is excellent UX when implemented deliberately.

passkeys.dev describes this bootstrapping pattern clearly: conditional UI can wait for a matching credential in the background. If a passkey is available and selected, the site completes WebAuthn authentication. If not, the user can continue with the established legacy login path.

WebAuthn Level 3 also adds a way to inspect client capabilities with getClientCapabilities(). Capability names include conditionalGet, conditionalCreate, hybridTransport, and indicators for passkey-capable platform authenticators.

That leads to an important product rule: capability detection can improve the interface; it must not replace the security model.

And do not hide passwords, magic links, or another intended fallback merely because the browser supports conditional UI in principle. Browser support does not prove that this user has an available credential on this device.

7. Cross-device use is a normal part of the passkey model

A user may be on a desktop while the passkey is on a phone. Another account may use a device-bound security key. A third may have several passkeys synchronized through a credential provider.

FIDO explicitly describes cross-device authentication as a supported path: a passkey on another device can be used through a browser- and authenticator-mediated flow. WebAuthn Level 3 also exposes hybridTransport as a client capability.

Testing therefore needs to go beyond “passkey on the same laptop.”

At minimum, cover:

• a platform passkey on the current device,
• a synced passkey available on another device,
• desktop sign-in using a phone through cross-device authentication,
• a device-bound security key when relevant to the audience,
• a browser without the preferred polished passkey UI,
• a user with multiple registered credentials.

Testing only on the developer's Mac validates one vendor path, not the product.

8. Credential management belongs in account settings

A production passkey rollout needs more than “Add passkey.” Users should be able to understand which credentials belong to the account, add more, and revoke ones they no longer need.

The interface should not pretend the server knows facts that it does not. A relying party cannot necessarily identify the exact physical device that holds a synced passkey. Prefer metadata the application genuinely knows, such as:

• creation date,
• last-used timestamp,
• a user-assigned label,
• a coarse credential or authenticator category where reliably available,
• active or revoked status.

Removing one credential should not accidentally destroy every other authentication path. Conversely, a credential revoked on the server must no longer be accepted simply because its private key still exists on a device.

9. Recovery is part of passkey design—or the weakest path wins

Passkeys remove many traditional password problems. They do not remove the need for account recovery. Devices are lost, credential providers change, employees misplace security keys, and users can remove their last available passkey.

A service with strong passkey authentication and a weak support reset therefore still has a weak account boundary.

Design explicitly for:

• multiple passkeys per account,
• encouraging users to register another viable authenticator where appropriate,
• a recovery method when no passkey remains available,
• preventing support from bypassing authentication based only on easily obtained personal facts,
• session handling after recovery,
• revoking lost credentials,
• monitoring and auditing recovery as seriously as normal login.

The useful question is not “Are passkeys phishing-resistant?” The technical answer is strongly established. The product question is: Can an attacker simply bypass the passkey by taking a weaker recovery route?

10. Domain and login migrations need a credential strategy

Because WebAuthn credentials are scoped to the RP ID, a domain move is not just a DNS or redirect project.

If a product moves from one unrelated domain to another, the authentication team should plan how existing credentials will be handled. An HTTP redirect working correctly does not make a credential suddenly belong to a different RP ID.

Before a relaunch, document:

• the RP ID in use today,
• origins currently accepted by the server,
• new hosts that will be introduced,
• whether existing credentials can continue to be used,
• how users will register replacement credentials if needed.

This is exactly the kind of dependency a visual redesign can overlook.

A pragmatic passkey audit

A useful test goes far beyond successful registration. Exercise at least these states:

1. A new account registers its first passkey.
2. An existing account adds a second passkey.
3. Username-less sign-in with a discoverable credential.
4. Conditional UI when an eligible passkey exists.
5. Conditional UI with no available passkey and a clean fallback path.
6. Authentication from a disallowed origin.
7. A modified or replayed challenge.
8. Cross-device authentication.
9. Revocation of one credential.
10. Sign-in afterwards with another valid credential.
11. Loss of the last available passkey and the recovery flow.
12. An old session after recovery or a security-relevant credential change.
13. Staging and preview hosts against production configuration.
14. A planned domain or login-host migration.

That turns “the passkey button works” into a testable authentication model.

What Website-Pflichtencheck would inspect

Not every WebAuthn server check can be proven from the public website. Challenge storage, credential data modelling, and internal recovery rules require test access, staging, or code/configuration review. A useful audit should state that boundary clearly.

Depending on access, Website-Pflichtencheck can inspect:

• HTTPS and real sign-in origins,
• RP ID configuration and intended host boundaries,
• the allowed-origin policy,
• challenge generation, lifetime, and single-use behaviour,
• validation of clientDataJSON, origin, RP ID hash, and authenticator flags,
• user-verification policy,
• discoverable credentials and account mapping,
• multiple passkeys per account,
• conditional UI and capability detection,
• cross-device and fallback behaviour,
• credential management and revocation,
• recovery and session invalidation,
• staging, preview, and domain-migration risks,
• regression testing across browsers and devices.

The value of a passkey audit is not another modern checkbox in the feature list. It is a precise answer to the question: Which combination of domain, browser context, credential, and server-side state is actually allowed to open this account?

WebAuthn Level 3 is now a stable W3C reference point. That makes this a good time to stop treating passkeys as an experiment—and also to stop treating them as magic authentication where the browser will somehow make every surrounding decision safe.

The cryptography is a strong boundary only when the RP, origin, recovery, and account logic do not quietly weaken it.