WebAuthn Level 3 (2026): What's New for Passkeys

WebAuthn Level 3 is the latest major version of the Web Authentication API. As of May 26, 2026 it sits at W3C Candidate Recommendation status, and it builds on Level 2 with a clear theme: keep the strict cryptographic phishing resistance, make passkeys dramatically easier to deploy and live with day-to-day.

This is the “passkey maturity” release. If Level 2 made passkeys possible, Level 3 makes them practical for big consumer apps and for enterprises.

Why this matters for scam protection

Origin binding is the single feature that defeats real-time MFA interception attacks — a passkey created for google.com simply refuses to sign a challenge from g00gle-login.com. Level 3 keeps that default strict, then adds controlled flexibility, better credential hygiene, and smoother UX so more sites actually ship passkeys to real users.

In short: more sites with passkeys → fewer accounts a phishing kit can take over with a stolen password and a copy-pasted SMS code.

What's new in Level 3 (vs Level 2)

### Client Capabilities — getClientCapabilities()

Browsers now expose a checklist of supported features (conditional mediation, hybrid transport, PRF, etc.). Developers can read that list and adapt flows dynamically instead of guessing, which means fewer broken sign-in pages on older browsers.

### Conditional Create & Conditional Get

The browser can offer to create or use a passkey inline during normal sign-in / sign-up — no separate “set up a passkey” detour. This is the single biggest UX upgrade for passkey adoption: most users will create their first passkey without ever clicking a button labelled “passkey”.

### Related Origin Requests (ROR)

Allows controlled use of one passkey across explicitly related domains (e.g. example.com and shop.example.com). Strict origin binding is still the default; ROR is opt-in, scoped, and verified, so it does not weaken phishing resistance for sites that don't use it.

### Signal API

Three new methods — signalAllAcceptedCredentials, signalUnknownCredential, signalCurrentUserDetails — let sites tell the authenticator which credentials are valid, which were deleted, and which user metadata changed. Synced passkeys stay clean across devices, and stale credentials don't linger as attack surface.

### Hybrid Transport

Better support for cross-device sign-in (phone authenticator approving a desktop login via QR + Bluetooth). Less brittle than Level 2's first pass, and better fallbacks when one channel is blocked.

### PRF extension (Pseudorandom Function)

Lets sites derive cryptographic keys from a passkey for additional use cases — end-to-end encrypted storage, encrypted local data, password-manager-style key derivation — without storing a separate secret.

### Hints & embedded origin context

Better guidance for authenticators and better support for legitimate iframe sign-in flows.

### Compound attestation

More flexible attestation formats, useful for enterprise device management where IT needs to verify the authenticator class without locking everything to one vendor.

Browser and password-manager support (mid-2026)

• Chrome / Edge — strong support from v133+.
• Safari — 17.4+ ships the core Level 3 features.
• Firefox — coverage growing through 2026.
• Password managers — 1Password, Bitwarden, Dashlane already implement key Level 3 features (conditional mediation, Signal API).

Always feature-detect with PublicKeyCredential.getClientCapabilities() before relying on a specific Level 3 capability.

What changes for end users

Mostly invisible — and that's the point.

• Sign-in pages start asking “use your saved passkey?” automatically instead of requiring a separate setup step.
• Lost or rotated devices no longer leave orphan credentials your account page can't see.
• Large multi-brand sites can finally use one passkey across their main domain and their checkout subdomain without security trade-offs.

What changes for site operators

If you ship login, plan a Level 3 pass in your 2026 roadmap:

1. Detect capabilities with getClientCapabilities() and progressively enable conditional create/get.
2. Wire the Signal API so credential lifecycle events stay in sync with your authenticator records.
3. If you run multiple related domains, evaluate Related Origin Requests instead of duplicating credentials per origin.
4. Offer a hardware-key option for high-value accounts on top of synced passkeys — Level 3 doesn't change the recommendation to back critical accounts with a YubiKey-class device.

How this fits into the GACS scam-protection stack

Passkeys remain the strongest consumer-grade defense against phishing and MFA interception. WebAuthn Level 3 just makes them more likely to actually be there when users need them. Combine that with a habit of running unfamiliar URLs through the free GACS Safe Scanner, bookmarking high-value sites instead of clicking sponsored ads, and reading our broader “Is this website a scam?” guide, and the 2026 attack playbook stops working on you.

GACS is advisory-only and free forever. If anyone claiming to be from GACS asks you for a seed phrase, recovery fee, or passkey export, report them — that's the scam.