WebAuthn Level 3: What's New in the Passkey Standard

On 20 July 2026, W3C proposed advancing Web Authentication Level 3 to Recommendation, the last stage of the standards process. The specification has sat as a Candidate Recommendation Snapshot since 26 May 2026. The Working Group has been collecting implementation experience in the months since.

WebAuthn is the API underneath every passkey. Its versions move slowly. Level 1 became a Recommendation in March 2019. Level 2 followed in April 2021. Level 3 has been in development since 2021. Five years of browser and authenticator work is now being frozen into the document.

Level 3 does not make passkeys more phishing-resistant. Level 2 already did that. It expands what a passkey can do: derive encryption keys, work across related domains, enroll during a password autofill, and keep the provider's credential list in sync with your server.

I built LoginRadius from 2013 to more than a billion users. A credential that only signs in is a smaller primitive than one that can also encrypt, span a brand's domains, and maintain its own state. That is the shift worth taking seriously.

What WebAuthn already does

WebAuthn lets a site authenticate a user with a public-key credential instead of a shared secret. At registration, the authenticator (phone, secure enclave, hardware key, or password manager) generates a key pair. The private key never leaves the authenticator. The public key goes to the server. At sign-in, the server sends a challenge. The authenticator signs it. The server verifies the signature.

Two properties make this phishing-resistant. Credentials are scoped to a Relying Party ID, so a credential for your bank cannot be used anywhere else. Every assertion also signs over the requester's origin, so a response cannot be replayed against a different site. A phishing page cannot obtain a usable signature because the origin will not match.

Biometrics do not replace that cryptography. A fingerprint or face scan unlocks the private key on the device. The signature is what authenticates you. That distinction matters when a non-technical stakeholder assumes the biometric is the security.

The implementation mechanics are in my FIDO2 developer guide.

What Level 3 actually adds

Five additions matter if you ship authentication.

1. The PRF extension: passkeys that derive encryption keys

This is the largest new capability. The Pseudo-Random Function (PRF) extension lets an authenticator deterministically derive secret key material from a passkey.

The authenticator evaluates a PRF over its internal secret plus a salt from the Relying Party and returns 32 bytes. Same authenticator, same RP ID, same salt: same value. That determinism is what makes the output usable as encryption key material. The private key still never leaves the device.

A passkey can then protect encrypted data, not only a session. Bitwarden uses PRF to unlock the vault with a passkey. Dashlane documents hardware-key vault encryption via PRF and CTAP hmac-secret. Yubico publishes a developer guide for deriving a hardware-backed secret from a YubiKey. 1Password added PRF for stored passkeys and put the implementation in its open-source passkey library. WhatsApp added passkeys as an alternative to a password or 64-digit key for encrypted chat backups.

That removes a painful extra secret after the user has already authenticated. It also creates a data-loss failure mode. More on that below.

2. Related Origin Requests: one passkey across your domains

Passkeys are scoped to an RP ID, normally a single registrable domain. That is a security feature. It is also friction for country TLDs, brand sites, and split app domains that share one account system.

Related Origin Requests let the primary RP ID host a /.well-known/webauthn file listing authorized origins. The browser checks that allowlist. One passkey then works across the listed sites.

The spec caps how many origins can appear. That limit exists so a shared host cannot mint passkeys for every domain on the box. Treat the allowlist as a trust boundary, not a convenience dump.

3. The Signal API: keep credential lists accurate

A common support ticket: the user deleted a credential on the server, but it still sits in the password manager, so sign-in offers a key that no longer works.

Signal methods let the page tell the authenticator what the server currently believes: user details, the list of accepted credentials, and that a credential was deleted. The provider can then prune its list. Unglamorous. It removes a class of "this passkey is broken" tickets.

4. getClientCapabilities(): feature detection without heuristics

Before Level 3, detecting what the browser and authenticator supported meant one-off checks. PublicKeyCredential.getClientCapabilities() returns a capability map so you can tailor registration or authentication before you start. Extensions are queryable with an extension: prefix from the IANA registry.

Safari 17.4 shipped it first. Chrome 133, Edge 133, and Firefox 135 followed. Apple's own guidance for automatic passkey upgrades is to call this API before issuing a conditional create.

5. JSON serialization and conditional registration

JSON helpers standardize how servers send and receive WebAuthn options. Anyone who has chased a base64url mismatch between an SDK and a browser will care.

Conditional create, often called automatic passkey upgrade, lets a site request a passkey during a password autofill without a separate enrollment prompt. That is the adoption problem: not the crypto, the enrollment. Apple's WWDC 2024 session and Chrome's Conditional Create docs both build on this. Check conditionalCreate first. If it is missing, fall back to a normal create.

Where browser support actually stands

Level 3 features have been shipping ahead of the Recommendation, which is normal given Apple, Google, Microsoft, and Mozilla sit on the Working Group.

PRF, getClientCapabilities(), JSON serialization, hints, and Related Origin Requests have landed across Chromium and WebKit, with Gecko covering some. The Signal API has been Chromium-first. Support is real and uneven, which is why the capabilities query exists.

Do not assume a uniform matrix. Detect at runtime. Degrade when a feature is absent. Test current browser builds. Candidate Recommendation features still appear behind flags before they are generally available.

The caveats worth taking seriously

PRF creates a real data-loss risk. Tim Cappalli, a WebAuthn spec editor, published a warning in February 2026. Overloading an authentication credential as an encryption root means a deleted passkey can take photos, backups, and files with it. The delete UI in Apple Passwords, Google Password Manager, and Bitwarden does not tell the user they are destroying ciphertext they can never decrypt. Credential managers that use PRF to unlock a vault usually have other recovery paths, such as a master password or recovery key. Messaging backups and document encryption often do not. Any production PRF design needs multiple enrolled authenticators, a recovery key, or escrow, plus a warning before the user enables it. Shipping encryption without that story is a support catastrophe.

The specification is not a Recommendation yet. As of this writing it has been proposed for that status. Advisory Committee review is the current stage. Implementations can still move before the final document.

Capability detection leaks fingerprinting bits. The Working Group's own security and privacy reviews note that getClientCapabilities() exposes multiple tri-state flags. Correlation between flags reduces the unique space, and the API is first-party only. It is still a tradeoff, not a free query.

Build against WebAuthn, or buy a platform?

Level 3 makes the build-versus-buy question sharper. Building directly gives you control and no vendor lock-in. For a single-domain product with a simple flow, open-source server libraries handle verification well. You then own credential lifecycle, recovery, cross-device UX, fallbacks, and the tax of tracking each browser as it ships new Level 3 pieces. Teams underestimate that last cost.

If you buy, match the product to the job. I keep current vendor notes in CIAM Compass, because this layer changes by quarter.

Passwordless-first providers treat passkeys as the product, not a checkbox. That is usually the fastest path from zero to a working flow with the edge cases handled. See MojoAuth, Corbado, Stytch (Twilio, as of October 2025), and Hanko. They differ on hosted versus embedded UI, how much of the surrounding identity stack they cover, and price.

Full CIAM and IAM suites add passkeys to a broader platform. That is the right shape when customer or workforce identity is the purchase and passkeys are one requirement among many. Auth0 (Okta), Microsoft Entra External ID, and Ping Identity sit here.

B2B SSO providers solve enterprise connections, SAML, OIDC, and directory sync. Passwordless and enterprise SSO are complementary. Most B2B products eventually need both. SSOJet and WorkOS are the two I see in that lane.

Hardware keys and password managers are often where Level 3, especially PRF, shows up first, because vault encryption is the natural use. Yubico, 1Password, Bitwarden, Dashlane, and Enpass are the names to watch. They are not CIAM vendors. Do not evaluate them as if they were.

The questions that matter in a Level 3 world: which of these capabilities does the provider support in generally available code, not a blog post? How do they handle account recovery, which is still the hardest passwordless problem? Will they cover the enterprise SSO you will be asked for next year? How fast do they ship after a browser adds a WebAuthn feature?

What to do with this

If you already run passkeys, Level 3 is friction reduction, not a forced migration. Replace ad-hoc detection with getClientCapabilities(). Evaluate conditional create for existing password users. If you operate multiple domains, Related Origin Requests removes a real pain. Add Signal methods so deleted credentials disappear from the provider list.

If you are still on passwords, the case has not changed. Verizon's 2026 DBIR found vulnerability exploitation overtook credential abuse as the most common initial access vector (31% versus 13%). Stolen credentials still appear later in many incidents. Passkeys remove the phishing and reuse version of that path. They do not patch your edge devices. Pair the rollout with the recovery and fallback work in CIAM Compass's passkey adoption notes, and keep a hashing baseline for anything that remains a password during the cutover. I compared those algorithms here.

If you are considering PRF for encryption, design recovery first. The capability is powerful. The failure mode is silent and permanent. That order is not optional.

WebAuthn started as a way to replace passwords at login. With Level 3, a passkey is a broader cryptographic credential: it authenticates, it can encrypt, it can span related domains, and it can maintain its own state. That is a different primitive than 2019, and it is what the next decade of authentication will sit on.

Key takeaways

• W3C proposed WebAuthn Level 3 as a Recommendation on 20 July 2026. It has been a Candidate Recommendation Snapshot since 26 May 2026. It is not final yet.
• Level 3 does not add phishing resistance. It adds PRF encryption-key derivation, Related Origin Requests, the Signal API, getClientCapabilities(), JSON helpers, and conditional create.
• PRF is in production at Bitwarden, 1Password, Yubico-backed flows, and WhatsApp backups. It needs a recovery design before you encrypt user data with it.
• Browser support is real and uneven. Detect capabilities at runtime. Do not hard-code a matrix.
• Build if your flow is simple and you will staff the ongoing browser tax. Buy if you need recovery, SSO, and Level 3 features without owning the lag.

Frequently Asked Questions

Is WebAuthn Level 3 a finished standard?

Not yet. W3C proposed it as a Recommendation on 20 July 2026. Advisory Committee review is in progress. Browsers have already shipped large pieces of it. Treat the document as late-stage, not as law.

Does Level 3 make passkeys safer against phishing?

No. Origin-bound public-key credentials already were. Level 3 expands what you can do with that credential: encryption keys, related domains, quieter enrollment, and list sync.

Should I use PRF to encrypt user data?

Only if you have a recovery path that survives a deleted or lost passkey: extra authenticators, a recovery key, or escrow, plus a warning in the enablement UI. Using PRF to unlock a vault that already has other unlock methods is a different, safer pattern than using it as the sole key for backups or files.

What is the highest-return Level 3 feature to ship first?

Conditional create, if your users still have passwords. It enrolls a passkey during autofill without a second prompt. Then getClientCapabilities(), so you stop guessing at support. Related origins if you run more than one domain. Signal methods if credential-list drift is already generating tickets.

Do I need a CIAM vendor to use Level 3?

No. You can call WebAuthn yourself. You then own recovery, lifecycle, and browser lag. A passwordless-first or CIAM vendor is worth it when those costs exceed the control you get from building. Compare current profiles in the CIAM Compass vendor index.

Related reading

• FIDO2 implementation guide: the protocol mechanics Level 3 extends
• Passkeys vs passwords: why the underlying case has not changed
• CIAM Compass vendors: current passkey and CIAM profiles, including the names above