WebAuthn Level 4: Features, Status & Browser Outlook
WebAuthn Level 4 explained: what the first draft changes, which proposals to watch and when new passkey features can reach browsers.
- 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 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.
Passkeys Cheatsheet. Practical guidance, rollout patterns and KPIs for passkey programs.
Status checked: 15 September 2026.
2. WebAuthn Level 4 vs Level 3#
Features such as Signal API, client capability detection, credential hints and PRF already belong to the Level 3 specification.
The first draft's revision history 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 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 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 describes how recreating test credentials can produce counters inconsistent with the server's stored value. Explicit counter control makes those scenarios easier to test.
Experiment with passkey flows in the Passkeys Debugger.
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: 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 for the use case.
- Ambient UI: 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: 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, 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.
Subscribe to our Passkeys Substack for the latest news.
5. How Corbado can help#
Before prioritizing a new WebAuthn behavior, establish where today's login loses users. Corbado 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.
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.
Igor Gjorgjioski
Senior Product Lead, VicRoads
We hit 80% mobile passkey activation across 5M+ users without replacing our IDP.
See how VicRoads scaled passkeys to 5M+ users, alongside their existing IDP.
Read the case study
About Corbado
Corbado is the Passkey Intelligence Platform for large-scale CIAM teams running consumer authentication. We help you see what IDP logs and generic analytics tools can't: where passkeys, passwords, OTP, social login and fallback journeys succeed, stall or fail, which devices and browsers create friction, and when an OS update silently breaks login. Two products: Corbado Observe layers process mining and observability across authentication journeys. Corbado Connect adds managed passkeys with analytics built in alongside your IDP. VicRoads runs passkeys for 5M+ users with Corbado (+80% passkey activation). Talk to a Passkey Expert →
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.
Share this article
Related Articles
Table of Contents