WebAuthn Level 3 is a W3C Recommendation, and it standardises the parts everyone already shipped
W3C published WebAuthn Level 3 as a Recommendation on August 25, 2026. Conditional create, the Signals API, Related Origin Requests, and the PRF extension stop being working drafts and become a citable normative reference.
The W3C published Web Authentication Level 3 as a Recommendation on August 25, 2026, with the FIDO Alliance announcing it at the end of the month. Level 3 formalises capabilities browsers and platforms had already deployed against working drafts. Conditional create lets a site silently upgrade a user from a password to a passkey during an ordinary sign-in, and conditional get drives the autofill picker. The Backup Eligible and Backup State flags let a relying party distinguish a synced passkey from a device-bound one, and see its current backup status. The Signals API gives sites a way to coordinate lifecycle events, notably revocation and renaming, which credential managers previously had no way to learn about. Related Origin Requests allow one passkey to work across related domains, the PRF extension derives stable per-credential key material, and AAGUID without attestation lets a site label a passkey by the manager that holds it.
Why it matters
Recommendation status does not change what your browser can do this week. It changes what you can build a policy on. Until now, an enterprise writing a passkey standard had to cite working drafts that could still move, which is a poor foundation for an authentication policy and an actively bad one for an auditor.
Two items matter more than the rest in practice. The Signals API is the first standard answer to the revocation problem that has dogged every passkey rollout: when an account is closed or a credential is removed server-side, the passkey previously sat in the user's credential manager forever, offering to sign them in to something that no longer exists. And conditional create is the migration lever, because it converts passkey adoption from a task a user has to choose into a by-product of a login they were doing anyway. Given that enrollment is where the attacks moved once the cryptography held, a standardised enrollment path with defined semantics is worth more than it looks.
Source: FIDO Alliance
Related on Start with Identity
- BlogW3C publishes Verifiable Credentials Data Model 2.0 as a Recommendation
VC Data Model 2.0 reached W3C Recommendation on 15 May 2025, moving verifiable credentials from a promising draft to a standard the W3C recommends for wide depl
- BlogPass-the-Passkey: a Black Hat researcher found the WebAuthn implementation bugs, not the standard
At Black Hat USA 2026, DSInternals researcher Michael Grafnetter presented a family of passkey attacks including cleartext YubiKey signatures readable by any au
- Blog94 percent of enterprises say they can revoke access in 24 hours. 35 percent found out they couldn't.
FIDO Alliance and HID surveyed 500 IT and security decision-makers for The State of Physical and Digital Identity in the Enterprise. The headline gap: near-univ
- RecipeAdd passkeys with WebAuthn
Implement passkey registration and authentication with the WebAuthn ceremonies: generate and verify challenges on the server, call navigator.credentials on the
- GuideAuthentication vs Authorization: The Difference That Trips Everyone Up
Authentication and authorization sound alike and are often shortened to the same "authZ/authN," but they answer different questions. Getting them straight is fo
- GlossaryAuthenticator Assurance Level (AAL)
NIST 800-63B levels describing authentication strength. AAL1: single factor. AAL2: multi-factor. AAL3: multi-factor with phishing-resistant cryptographic authen