--- url: 'https://www.corbado.com/blog/webauthn-level-4' title: 'WebAuthn Level 4: Features, Status & Browser Outlook' description: 'WebAuthn Level 4 explained: what the first draft changes, which proposals to watch and when new passkey features can reach browsers.' lang: 'en' author: 'Vincent Delitz' date: '2026-09-21T14:41:18.318Z' lastModified: '2026-09-21T14:41:18.318Z' keywords: 'webauthn level 4, webauthn level 4 features, webauthn level 4 browser support, webauthn level 4 release date, webauthn level 3 vs level 4' category: 'WebAuthn Know-How' --- # WebAuthn Level 4: Features, Status & Browser Outlook ## Key Facts - **WebAuthn Level 4** entered its first public working draft on 15 September 2026. - Its first changes address remote desktops, PRF security and automated testing. - Browser adoption happens feature by feature; UI proposals have separate development timelines. ## 1. Introduction **WebAuthn Level 4** is the next revision of the browser API behind passkeys. Its [first public working draft](https://www.w3.org/TR/2026/WD-webauthn-4-20260915/) starts public review, following Level 3's Recommendation on 25 August 2026. It remains work in progress. A W3C specification moves through fixed stages, and the stage tells you how much a draft can still change: | Stage | What it means | | --- | --- | | First Public Working Draft | The draft becomes public and the review period starts. Content can still change substantially. | | Working Draft | The working group keeps revising the text while it resolves open issues. | | Candidate Recommendation | The feature set is considered stable and the group asks for implementations and feedback. | | Proposed Recommendation | The draft goes to the W3C membership for a final review. | | Recommendation | The final stage, and what most people mean when they call something a standard. | Level 4 sits at the first of these stages. Level 3 reached the last one on 25 August 2026, so the gap between the two versions is wide. Browser vendors do not wait for it to close, which is why the practical question is per feature rather than per level. **Status checked: 15 September 2026.** ## 2. WebAuthn Level 4 vs Level 3 Features such as [Signal API](https://www.corbado.com/blog/webauthn-signal-api), [client capability detection](https://www.corbado.com/blog/webauthn-client-capabilities), [credential hints](https://www.corbado.com/blog/webauthn-public-key-credential-hints) and [PRF](https://www.corbado.com/blog/passkeys-prf-webauthn) already belong to the [Level 3 specification](https://www.w3.org/TR/2026/REC-webauthn-3-20260825/). The first draft's [revision history](https://www.w3.org/TR/2026/WD-webauthn-4-20260915/#sctn-changes-since-l3) identifies three substantive changes: | Area | Change in the first draft | Main audience | | --- | --- | --- | | Remote desktop | `remoteClientDataJSON` extension with permission restrictions | Remote desktop and browser implementers | | PRF security | Cleartext PRF outputs excluded from authenticator extension outputs | Authenticator and client implementers | | Automated testing | Explicit `signCount` handling for virtual authenticators | Test framework and authentication engineers | ### 2.1 Remote Desktop Authentication An employee's remote desktop requests a passkey held on their local device. Reconstructing the authentication's client data locally can change its bytes and break signature verification. As [Microsoft's explainer](https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/WebAuthnRemoteClientDataJSON/explainer.md) describes, `remoteClientDataJSON` lets an authorized remote desktop web client preserve the original data. Permission restrictions control which clients may do this. ### 2.2 PRF and Test Reliability The [PRF hardening change](https://lists.w3.org/Archives/Public/public-webauthn/2026Jul/0190.html) keeps secret PRF results out of authenticator extension outputs that could travel to the server with an assertion. PRF remains available to applications through its client extension results. The testing change helps reproduce signature-counter edge cases. The [virtual authenticator discussion](https://github.com/w3c/webauthn/issues/2363) describes how recreating test credentials can produce counters inconsistent with the server's stored value. Explicit counter control makes those scenarios easier to test. ## 3. WebAuthn Level 4 Proposals to Watch Three proposals could have more visible effects on everyday sign-in. They are outside the September snapshot and their inclusion in a later version is not guaranteed: - **[Immediate UI](https://github.com/w3c/webauthn/pull/2291):** offer locally available credentials or promptly return control to the website for another sign-in path. The specification pull request remains open. See our [immediate mediation guide](https://www.corbado.com/blog/webauthn-immediate-mediation) for the use case. - **[Ambient UI](https://github.com/w3c/webauthn/blob/main/explainers/ambient-sign-in.md):** show a lightweight sign-in prompt without requiring a login form. A returning reader could sign in directly on a news article by interacting with the browser prompt. - **[Challenge URL](https://github.com/w3c/webauthn/blob/main/explainers/challenge-url.md):** fetch the challenge during authentication, potentially avoiding unnecessary challenge generation when a user never selects a credential. Server-side verification remains necessary. ## 4. WebAuthn Level 4 Browser Support and Timing Browser vendors can ship individual features before a specification becomes a Recommendation. A concrete precedent is the Signal API, included in [Chrome 132's release notes](https://developer.chrome.com/release-notes/132), well before Level 3 reached Recommendation status. We did not find a confirmed cross-browser availability schedule for the first draft's additions. A prototype, an experimental browser feature and a stable release are different milestones. Start limited rollouts once the required behavior is documented and tested in your target environments. Check the browser, operating system, credential provider and relevant enterprise policies together. Use documented feature detection and test actual behavior: accepting an options object does not prove that every option took effect. ## 5. How Corbado can help Before prioritizing a new WebAuthn behavior, establish where today's login loses users. [Corbado Observe](https://www.corbado.com/observe) connects that decision to the authentication journeys you already operate. - **Client Capabilities** sizes the web audience for existing features such as conditional creation. - **Funnel** shows where users drop out, providing a baseline for changes to prompts and fallback paths. [Video: Login funnel](https://www.corbado.com/videos/features/login-funnel.mp4) ([See Login Funnel in Corbado Observe](https://www.corbado.com/observe/login-funnel)) ## 6. Conclusion: Our Assessment Our assessment is that Level 4's first draft matters most to teams operating remote desktops or maintaining authentication infrastructure. For consumer services, the UI proposals are worth watching because they address when and where users encounter passkeys. Prioritize by that distinction. Investigate remote-desktop support with your platform vendor; improve existing consumer flows with autofill and credential maintenance. As new behavior becomes available, evaluate the complete journey: a faster passkey prompt helps little if more users abandon its fallback. ## Frequently Asked Questions ### Is WebAuthn Level 4 final? No. As of 15 September 2026, it is a first public working draft and can change during review. ### When will browsers support WebAuthn Level 4? Availability must be checked per feature, browser and platform. The sources reviewed do not establish a confirmed cross-browser release schedule for the draft's additions. ### Should we wait for Level 4 before deploying passkeys? Our recommendation is to deploy supported capabilities that improve your current login, while evaluating new proposals separately. Keep fallback paths and measure user outcomes.