WebAuthn Level 3: What Passkey Developers Need to Change

WebAuthn Level 3 became a W3C Recommendation on 25 August 2026. That makes it a stable reference for teams building passkeys—not merely an experimental browser proposal. It adds practical APIs that reduce serialization code, improve feature detection, and support passkey experiences across related origins.

The important message is not “rewrite your passkey stack.” The core ceremony remains familiar: your server creates a challenge, the browser asks an authenticator to create or use a credential, and your server verifies the signed response. Level 3 improves how applications prepare, transport, and progressively enhance that flow.

1. Replace hand-written JSON conversion

WebAuthn objects contain binary values such as challenges and credential IDs. Applications have traditionally converted these fields between base64url strings and ArrayBuffer values with custom utility code. That code is easy to get subtly wrong.

Level 3 standardizes helpers for the common conversions:

• PublicKeyCredential.parseCreationOptionsFromJSON() prepares registration options.
• PublicKeyCredential.parseRequestOptionsFromJSON() prepares authentication options.
• credential.toJSON() creates a JSON-friendly credential response.

const optionsJSON = await fetch("/passkeys/registration/options", {
  method: "POST",
}).then((response) => response.json());
 
const publicKey = PublicKeyCredential.parseCreationOptionsFromJSON(optionsJSON);
const credential = await navigator.credentials.create({ publicKey });
 
await fetch("/passkeys/registration/verify", {
  method: "POST",
  headers: { "content-type": "application/json" },
  body: JSON.stringify(credential?.toJSON()),
});

Use the request-options equivalent during sign-in. Keep a tested compatibility adapter for browsers that do not expose these helpers yet; do not switch every user to the new path merely because one development browser supports it.

2. Detect capabilities instead of guessing

Browser version checks age badly. Embedded browsers, enterprise-managed devices, and browsers built from the same engine can expose different features. Level 3 introduces PublicKeyCredential.getClientCapabilities() so an application can ask the client what it supports.

const capabilities =
  typeof PublicKeyCredential.getClientCapabilities === "function"
    ? await PublicKeyCredential.getClientCapabilities()
    : {};
 
if (capabilities.conditionalGet) {
  // Offer passkeys through autofill when appropriate.
}
 
if (capabilities.conditionalCreate) {
  // The client can support a conditional registration experience.
}

Treat every capability as progressive enhancement. Absence means “use the established path,” not “block sign-in.” The method itself also needs feature detection because older clients will not have it.

3. Understand conditional flows

Conditional mediation lets passkeys appear inside a familiar sign-in experience without immediately displaying a disruptive modal. Level 3 expands the platform’s ability to describe conditional registration as well as authentication.

This can make passkey adoption feel natural: a user begins with an identifier field, the browser offers an available passkey, and the account can later be upgraded without a separate security-settings expedition. But the UI still needs a reliable fallback. Users may have no passkey on the current device, may dismiss the prompt, or may be inside a client that does not support the capability.

Keep password, OTP, recovery, or another approved method reachable according to your risk model. Passkeys improve phishing resistance; they do not remove the need for account recovery design.

4. Use related origins deliberately

Large products often authenticate across several domains: a main website, a regional domain, and a dedicated account domain. WebAuthn’s security model intentionally binds credentials to a relying party. Level 3’s related-origin support gives eligible sites a controlled way to declare that relationship.

That is useful, but it should not become a wildcard shortcut. Maintain an explicit list, serve the required association document securely, and review every origin as part of the authentication boundary. A forgotten marketing domain should not silently become part of a sensitive sign-in surface.

Before using related origins, document:

1. Which domains genuinely belong to the same account system.
2. Who can deploy content on each domain.
3. How domain ownership and TLS certificates are monitored.
4. What happens when a domain is sold, retired, or compromised.

5. Server-side verification does not disappear

The new browser helpers are ergonomic improvements. Your server must still verify the challenge, origin, relying-party ID, signature, and the credential’s relationship to the correct account. Registration challenges should be short-lived and single-use. Authentication counters and authenticator signals should be evaluated according to your threat model rather than treated as universal proof of compromise.

Store the minimum credential data needed for verification and lifecycle management. Protect enrollment with an authenticated session, notify users when a passkey is added, and provide a way to inspect and revoke registered credentials.

Our broader passkeys guide for Indian applications covers the complete ceremony and rollout choices.

A safe upgrade plan

Inventory your custom conversion utilities first. Add conformance tests using real server responses, then introduce Level 3 JSON helpers behind capability checks. Measure registration completion, sign-in success, fallback use, and recovery requests separately. Only remove the compatibility code after your supported-client data shows it is safe.

NamoID is building passkey and standards-based authentication for teams that do not want to own every protocol edge case. If you are planning a Level 3 rollout, join the NamoID Slack community for an early implementation review and share the browsers, devices, and domain model you need to support.

Sources

• Web Authentication: Level 3 — W3C Recommendation
• W3C Recommendation announcement