W3C Makes Web Authentication (WebAuthn) Level 3 a Recommendation: What It Means for Passkeys

On August 25, 2026, the World Wide Web Consortium (W3C) announced that Web Authentication Level 3 is now a W3C Recommendation. Web Authentication, usually shortened to WebAuthn, is the browser standard behind passkeys: signing in with a fingerprint, face scan, device PIN or security key instead of a password.

A Recommendation is the final, stable stage of a W3C standard. For any business planning a login system as part of custom web application development, it means the passkey features described in Level 3 now rest on a finished specification, not a moving draft.

This article explains what was published, what Level 3 contains that the previous version did not, and how to think about passkeys for your own product.

What W3C published

The Level 3 specification is dated August 25, 2026 and comes from the W3C Web Authentication Working Group. Its listed editors are from Okta, Microsoft, Yubico, Cisco, Apple and Google. The W3C describes it as an API that lets web applications create and use strong, attested, scoped, public key-based credentials to authenticate users.

The document states that it is the successor to Web Authentication Level 2, which became a Recommendation on April 8, 2021, and that there were no substantive changes since the Candidate Recommendation Snapshot of May 26, 2026. The W3C news item adds that new features will be developed in Level 4. So the status is clear: Level 3 is final and published now, and Level 4 is future work.

How passkeys work, briefly

With a password, your server stores a secret that can be guessed, reused on other sites, phished or leaked. With WebAuthn, the user's device creates a pair of cryptographic keys for your site. The private key stays with the user's device or password manager. Your server stores only the public key, which is of no use to an attacker on its own.

At sign-in, the browser asks the device to prove it holds the private key, and the user approves with a fingerprint, face or PIN. The credential is "scoped", meaning it is bound to your website's domain, so a look-alike phishing site cannot ask for it. The Level 3 specification includes the term passkey in its terminology section, which reflects how the industry now names these credentials.

What Level 3 adds over Level 2

We compared the tables of contents of the two Recommendations. The items below appear in Level 3 and not in the 2021 Level 2 document. The descriptions are our plain-English summaries; the specification is the authority on exact behavior.

• Backup eligibility and backup state: the specification distinguishes a multi-device credential, which may be backed up and synced, from a single-device credential, and exposes flags so a site can tell which it has.
• Related origins: a section on using Web Authentication across related origins, with a registered well-known URI, for companies that operate more than one domain.
• Signal methods: three methods (signalUnknownCredential, signalAllAcceptedCredentials and signalCurrentUserDetails) that the specification groups under signaling credential changes to the authenticator.
• Client capabilities and hints: a getClientCapabilities method and a hints list, so a site can find out what the browser supports and indicate what kind of authenticator it expects.
• JSON helpers: methods that convert the options sent by a server from JSON into the form the browser API needs.
• A hybrid transport value, a pseudo-random function (prf) extension, and a compound attestation format.

Why these additions matter in practice

This section is our interpretation. Several of these additions address problems that businesses hit when they first deployed passkeys.

Synced passkeys

Many passkeys today are synced through a platform or password manager, so they survive a lost phone. Some organizations, such as those with strict security policies, want to know whether a credential is synced or tied to one device. The backup flags give the server that information so it can apply its own policy.

Multiple domains

A passkey is bound to a domain. A company with a US site and a UK site on different domains, or a brand that changed its domain, previously had to work around that. The related origins section defines a standard way to declare that a set of domains belongs together.

Stale credentials

When a user deletes a passkey from their account on your site, their password manager may still offer it and the sign-in then fails. The signal methods give a site a way to tell the user's passkey provider about such changes, which should reduce confusing prompts.

What it means for your business

A W3C Recommendation does not change anything on your site by itself, and nothing here is a legal requirement. Its value is stability: developers, library authors and auditors can now reference a final document. That makes it easier to plan a passkey project with confidence about how the API is meant to behave.

A Recommendation also does not guarantee that every browser supports every feature today. Support for individual items, particularly the newer ones, should be confirmed for the browsers and devices your customers use before you rely on them.

For most businesses the decision is about login experience and risk. Passkeys remove the password from the most common attacks and can shorten sign-in to a single prompt. The costs are in the surrounding work: account recovery when someone loses every device, support for users who are unfamiliar with the prompt, and keeping a fallback method while adoption grows. Security or compliance obligations specific to your industry are outside the scope of this article and should be checked with a qualified adviser.

What to do next

If you do not offer passkeys yet, start by adding them as an option next to your existing sign-in, not as a replacement. Ask your developers to use a maintained WebAuthn server library for your stack instead of writing the cryptographic checks themselves, and to design account recovery before launch.

If you already support passkeys, review your implementation against Level 3. Useful questions are whether you record the backup flags, whether you operate several domains that would benefit from related origins, and whether deleted or renamed credentials are signaled to the user's passkey provider. Mobile apps should be considered alongside the website, since users expect the same passkey to work in both.

Conclusion

Web Authentication Level 3 became a W3C Recommendation on August 25, 2026, five years after Level 2. It finalizes the standard behind passkeys and adds features aimed at real deployment issues: synced credentials, multiple domains and keeping credentials up to date. Level 4 is planned as the place for further features.

If you are weighing passkeys for a new or existing application and want to talk through the options, you can contact us to discuss your requirements.