August 28, 2026
Web Authentication Level 3 Is Now a W3C Recommendation
On August 25, the World Wide Web Consortium published Web Authentication Level 3 as a W3C Recommendation. The status matters: after extensive consensus-building, W3C and its Members endorsed Level 3, Working Group members made royalty-free licensing commitments for implementations, and W3C recommended it for wide deployment. It does not mean that every Level 3 feature appeared in every browser on August 25.
W3C reports that there were no substantive changes between the Candidate Recommendation published on May 26 and the August Recommendation. The publication therefore closes a standards cycle; it does not flip a technical switch. Some Level 3 features were already shipping while the document was still a draft; others remain unevenly implemented.
What WebAuthn does
Web Authentication, usually called WebAuthn, lets a website register and use a public-key credential. During registration, an authenticator creates a key pair scoped to that relying party, and the site receives the public key. During sign-in, the site sends a fresh cryptographic challenge. After user presence or verification, the authenticator signs its authenticator data together with a hash of client data that includes the challenge and requesting origin; the site verifies that assertion with the stored public key.
The relying-party website does not receive the user’s fingerprint, face scan, or device PIN. Those can be used locally to unlock the authenticator; the site receives the signed result. The distinction matters: a biometric gesture authorizes use of a credential, but it does not by itself prove civil identity or document consent to separate legal terms.
“WebAuthn” and “passkey” are not synonyms. WebAuthn is the Web API and ceremony model for public-key credentials. In Level 3, “passkey” is another name for a client-side discoverable credential: it may be synchronized across devices or bound to one authenticator, and it can be used without the relying party first supplying a credential ID. WebAuthn also supports non-discoverable credentials.
WebAuthn is also only one boundary in the common FIDO2 model. WebAuthn connects the website to the browser or platform; the Client to Authenticator Protocol, or CTAP, connects that client to an external authenticator such as a security key or phone.
What Level 3 adds
WebAuthn Level 1 became a Recommendation in March 2019, followed by Level 2 in April 2021. Level 3’s First Public Working Draft followed on April 27, 2021. The August 2026 Recommendation gathers more than five years of work into a stable new level.
The additions fall into four practical groups:
Sign-in experience. Conditional mediation can surface credentials within familiar sign-in flows. Hybrid transport supports cross-device use, and browser hints help select appropriate authenticator and sign-in interfaces.
Developer and credential management. JSON conversion helpers reduce encoding work. Limited client-capability checks support selected workflow decisions. Signal methods let a relying party report an unknown credential, identify which credential IDs remain accepted, or update account details shown by credential managers.
Deployment across sites and frames. Related Origin Requests let a limited, explicitly declared set of origins use one relying-party ID through /.well-known/webauthn; they do not make a credential valid on arbitrary related domains. Level 3 also carries more information about embedded and cross-origin contexts.
Credential state and advanced uses. Backup-eligibility and backup-state flags describe whether a credential can be, or has been, backed up. The PRF extension can return credential-bound pseudorandom output for applications such as encryption, while compound attestation can carry more than one attestation statement.
The important limit
Recommendation status is not the same as universal product support. W3C’s June 2026 implementation snapshot reported 53 tests and 415 subtests run against development or preview versions of Chrome, Firefox, Safari, and Edge; results for some newer conditional and credential-handling features were still uneven. Those automated browser results are a dated interoperability snapshot, not a complete browser-and-authenticator support matrix.
The security promise—and the recovery problem
Correctly implemented WebAuthn is phishing-resistant because the browser binds each ceremony to the relying party, while a fresh server-generated challenge prevents an old assertion from being replayed. “Phishing-resistant” is the careful term. It is not “phishing-proof”: malicious application code, stolen sessions, compromised devices, faulty server validation, coerced approvals, and weak fallback paths remain part of the system.
Recovery is the larger elephant. A device-bound credential can be lost with a device unless another authenticator or recovery path exists. A synchronized passkey improves availability by moving protected key material through a provider’s sync fabric, but that makes the provider account, sharing rules, and recovery process part of the security boundary. NIST therefore treats sync, sharing, device management, and recovery as operational risks to evaluate rather than details that disappear behind the word “passkey.”
Accessibility and inclusion are implementation questions too. A service should not assume that every user owns a smartphone, can scan a QR code, can perform a particular biometric gesture, or can recover an account through the same device ecosystem. Services should provide accessible setup and recovery, keyboard and screen-reader support, adequate timeouts, and more than one workable authentication path where a single-device or single-modality flow would exclude users.
What changes now
For standards readers, the versioned August 25 Recommendation is now the durable reference. For implementers, the sensible next step is to compare required features with current browser and authenticator support, use the specified capability checks where available, test server-side verification and recovery, and preserve accessible alternatives. For the Web as a whole, Level 3 is an interoperability milestone—not the end of passwords, not a guarantee of secure deployment, and not the end of WebAuthn work. W3C says new features will continue in Level 4.
Further reading