WebAuthn Level 4: Features, Status & Browser Outlook

1. Introduction#

WebAuthn Level 4 is the next revision of the browser API behind passkeys. Its first public working draft was published on 15 September 2026, 21 days after Level 3 became a Recommendation. Seven editors from Okta, Microsoft, Yubico, Cisco, Apple, Google and Ping Identity maintain it. The W3C is clear about its status: "It is inappropriate to cite this document as other than a work in progress".

A W3C specification moves through fixed stages, and the stage tells you how much a draft can still change:

Level 4 sits at the first of these stages. Level 3 reached the last one on 25 August 2026. The W3C publication history of Level 2 and Level 3 gives a sense of the pace. At Level 2's pace of 22 months, a Level 4 Recommendation would arrive around mid-2028. At Level 3's pace of 64 months, it would take until early 2032. Browser vendors do not wait that long. The practical question is therefore when each single feature ships.

Status checked: 28 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 lists three substantive changes and two editorial ones. The working group still has 92 open issues on GitHub (29 September 2026), so more changes will follow. The three substantive changes:

2.1 Remote Desktop Authentication#

An employee's remote desktop requests a passkey held on their local device. The browser rebuilds the client data locally. Even small differences in the rebuilt bytes break signature verification. The Microsoft explainer by Akshay Kumar, Zach Dixon and Mo Jamal describes the fix: the extension allows "an authorized remote desktop web client to provide the complete clientDataJSON string, which the browser passes through verbatim without modification". A permissions policy with a default allowlist of 'none' decides which clients are allowed to do this.

The feature shows how slow standardization can be. The original issue was opened on 24 February 2021. The spec pull request was merged on 29 April 2026, more than five years later.

2.2 PRF and Test Reliability#

The PRF hardening change keeps secret PRF results out of authenticator extension outputs. Otherwise those outputs travel to the server with an assertion. Applications still get PRF through the 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.

3. WebAuthn Level 4 Proposals to Watch#

Three proposals would change everyday sign-in more visibly. They are outside the September snapshot and their inclusion in a later version is not guaranteed:

• Immediate UI: Ken Buchanan opened the spec pull request on 6 May 2025 and it is still open. Chrome 148 shipped the feature a year later, on 5 May 2026. The Chrome 148 release notes describe it as a mode that shows sign-in UI "if there is a passkey or password for the site that is immediately known to the browser, or else rejects the promise with NotAllowedError". 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 can sign in directly on a news article by interacting with the browser prompt.
• Challenge URL: the browser fetches the challenge during authentication. In the explainer, Ken Buchanan notes it "can also reduce the number of challenges that the RP has to generate, since no challenge will be fetched for a conditional UI call in which the user does not select a credential". Server-side verification remains necessary.

4. WebAuthn Level 4 Browser Support and Timing#

Browser vendors ship individual features before a specification becomes a Recommendation. The Signal API is a good precedent. It shipped in Chrome 132 on 14 January 2025, about 19 months before Level 3 became a Recommendation.

The matrix below tracks where each of the new behaviors stands per engine. We keep it current, so treat it as the starting point for your own feature detection rather than as a release plan.

Edge is Chromium-based, so its behavior follows Chrome unless an enterprise policy changes it. The draft's other two changes are not in the matrix because they are not browser-facing features: the PRF hardening tightens an extension that Chrome, Safari and Firefox already ship, and the signCount change only affects virtual authenticators in test setups.

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#

Immediate UI and Ambient UI only help users whose browser already knows a passkey or a password for the site. So the first question for any Level 4 feature is how many of your returning users are in that position today, and where the current login loses the rest. Corbado Observe answers both from 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.

See Login Funnel in Corbado Observe →

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 change when and where users see passkeys. Timing depends on browsers, not on the W3C. Immediate UI reached Chrome stable one year after its pull request opened, while Level 3 as a whole took 64 months.

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.

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. Since 15 September 2026 it is a first public working draft and can change during review. Level 2 needed 22 months and Level 3 needed 64 months to go from this stage to Recommendation.

When will browsers support WebAuthn Level 4?#

Browser support comes feature by feature. Immediate UI has been stable in Chrome 148 since 5 May 2026. Safari and Firefox have not published a position yet, and no cross-browser schedule exists 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.