On 25 August 2026, the W3C Web Authentication Working Group published Web Authentication: An API for accessing Public Key Credentials – Level 3 as a full W3C Recommendation. For those that may not know, Recommendation is the last stage of the W3C Process Recommendation Track, reached only after Working Draft and Candidate Recommendation phases have achieved wide review, interoperable implementations, and Advisory Committee support. This means WebAuthn L3 is now an endorsed and stable version of the WebAuthn specification. As you know, the WebAuthn specification and the FIDO CTAP specification together make up the FIDO2 standard that passkeys are built on.
Practically, this means WebAuthn L3 is no longer a moving target. Relying parties, browser vendors, and authenticator implementers can cite it as a stable and normative reference in RFPs, conformance statements, audits, and regulatory submissions (the same status Level 1 and Level 2 have held since 2019 and 2021, respectively). Also, since WebAuthn L2 shipped in 2021, the FIDO CTAP specification was updated to versions 2.2 and 2.3, so L3 arrives already paired with the latest version of the protocol.
The Theme Behind L3: Making Passkeys Work At Scale
WebAuthn L2 standardized the core phishing-resistant public-key authentication ceremony, and has been fundamental to how passkeys and other public-key cryptography based strong authentication mechanisms are built for the internet. The work in WebAuthn L3 built on that to formalize what the ecosystem needed to make passkeys work at scale across synced and device-bound form factors, across workforce and consumer deployments, and addressing practical considerations that developers were struggling with.
For a more detailed and technical writeup on the changes in L3, I highly recommend folks check out Tim Capalli’s blog post about WebAuthn L3 (Tim is one of the editors of the WebAuthn spec). At a high level, here are the key additions formalized in the Recommendation that are essential for anyone invested in passkeys to know:
- Conditional Mediation: Powering some serious ecosystem improvements, this covers two new features. The first is Conditional Get, which is the magic behind the passkey autofill UI that helps sites guide their users towards their existing passkey. The second is Conditional Create, which allows sites to upgrade users from a password to a passkey by opportunistically creating one in the background during their normal authentication ceremony.
- Backup Eligible (BE) and Backup State (BS) flags: These new flags in authenticator data let a credential manager tell a relying party whether a credential is a synced passkey (backup-eligible) or a device-bound passkey, and whether it is currently backed up.
- The Signals API: One of the practical challenges created by WebAuthn’s privacy-preserving architecture of intentionally separating RPs from Credential Managers is their inability coordinate around normal credential lifecycle events like passkey revocation or renaming. The new WebAuthn Signals API gives relying parties a sanctioned, one-way mechanism to tell the client that a credential is stale, to reconcile the full set of valid credentials, or to push updated account name/displayname metadata back to the credential manager, with the expectation that subsequent authentication ceremonies will let the RP know whether those updates were received and acted on.
- AAGUID without attestation: Along the same lines as the Signals API, the fact that synced passkeys in the consumer ecosystem are unattested creates a challenge for RPs that want to provide their users simple and helpful credential management in their user account settings, like listing their passkeys by the name of the credential manager. L3 now allows a credential manager to send the AAGUID without attestation so RPs can label a passkey with a helpful credential manager name and icon.
- Client Hints: Client Hints let an RP give the WebAuthn Client (the browser) a hint that can influence the UX the browser presents to the user about where a passkey should be created or used. Its primary use, purely for UX purposes and not as a security control, is in workforce/high-assurance scenarios to avoid confusing users with cross-device or QR-code options when only security keys are allowed. You can learn more about how to leverage it here.
- Related Origin Requests (ROR): The fact that passkeys are scoped to a specific origin (RP ID) can prove challenging for sites that have multiple related domains (think of something like shoppingsite.com and its country-specific sites shoppingsite.co.uk or shoppingsite.ca). Related Origin Requests (ROR) lets a single passkey, bound to one RP ID, work across a small set of related domains, by having the relying party host a JSON list of valid origins at /.well-known/webauthn for that RP ID that the WebAuthn Client can fetch at login time, and use to determine if it should proceed with passkey authentication as if the user were visiting the primary domain.
- PRF Extension: A browser-facing abstraction built on top of the hmac-secret authenticator primitive, this extension lets an RP derive stable, per-credential key material (not encryption keys) from a passkey (more on this in an upcoming blog post).
- Developer Support Features: There are a number of improvements in the spec that make things easier for developers, like native JSON (de)serialization, a dynamic and more flexible getClientCapabilities() method that discloses the full set of capabilities a client supports in a single call, cross-origin iframe support to support use cases like payments, and compound attestation (multiple attestation statements in one ceremony) needed for workforce scenarios.
What This Means For Passkeys
The significance of WebAuthn L3 reaching Recommendation status is about closing the standards gap between what has already been shipped by browsers, operating systems, and credential managers and what the spec formally sanctioned. Most L3 features (autofill UI, JSON helpers, capability detection, the BE/BS flags) have been implemented across major platforms for some time (albeit with gaps that have created issues in some regions). Getting to Recommendation status gives them a single, citable, non-draft normative, and provides RPs confidence that they can reliably detect and leverage these features (developers can test for these features using passkey developer tools like this one).
For architects and compliance teams, this means that contractual language, conformance test suites, and regulatory references can now point to WebAuthn L3 as a finished standard instead of L2 + a shifting stack of working drafts.
It also marks the point at which the Working Group’s attention formally shifts forward, having already opened a charter proposal that names Level 4 as the next normative deliverable. Work on WebAuthn Level 4 is already underway, and there will be a lot more about that at the upcoming Authenticate USA 2026 conference and FIDO Alliance Member Plenary in Carlsbad, as well as at W3C TPAC in Dublin.
Even as our focus shifts to Level 4, we must recognize the immense effort required to bring WebAuthn L3 to completion. Warmest congratulations to all contributors across the FIDO Alliance and W3C communities who made this monumental achievement possible.
