On 25 August 2026 the W3C published Web Authentication Level 3 as a Recommendation, more than five years after Level 2 (April 2021). Little in it is new to browser engineers: as the FIDO Alliance noted, most of the features have shipped "for some time", with gaps. What the Recommendation changes is that identity providers, electronic record vendors and the people who write hospital authentication policies can now rely on them. Here are the five that matter most for a workforce that signs in on shared devices, across several domains, and leaves.
1. One passkey across related domains
A passkey is bound to one relying party identifier. Hospital groups rarely have one domain: a trust, a shared service, a regional portal, a legacy brand. Level 3's related origin requests let a site list other origins that may use its passkeys in a JSON file at /.well-known/webauthn, served over HTTPS. Clients must support "at least five registrable origin labels", and in practice five labels is the ceiling (many origins can share a label). Microsoft already uses it: login.microsoft.com publishes login.live.com, login.microsoftonline.com and account.live.com as related origins. Chrome and Edge have supported it since version 128, Safari since 18.0 and Firefox since 152. The NHS has not published one for nhs.uk as of this writing.
2. A key you can derive, not just a signature
The PRF extension turns a passkey into a source of 32-byte secrets. Give it an input and the authenticator returns a stable, credential-specific output; the underlying secret never leaves the authenticator and the relying party stores nothing. The spec's motivating example is encryption of user data, and its threat model is pointed: provided the input is unpredictable, an attacker who passes user verification and has "time-limited access to the authenticator" still cannot learn the key. Password managers were first (Bitwarden uses it to unlock a vault without a master password). For a hospital the interesting case is data that should open for one clinician and nobody else. Crayonic Secure Scribe, our system for recording clinical conversations, uses PRF this way: the audio is encrypted end to end under a key derived from the clinician's Badge, so it can be decrypted for transcription only after that clinician authenticates, and not by the server that stores it. There is no backup key and no recovery path, and the encrypted audio can be wiped automatically after a period set by hospital policy. The same pattern fits a locally cached record set or an offline downtime pack on a shared device. Chrome has supported PRF since 116, Safari since 18.0 and Firefox fully since 139, and Safari 26.4 extended it to security keys in March 2026, which is where shared clinical workstations tend to live.
3. Telling the authenticator a credential is gone
Leavers are where passkeys have been quietly worse than smartcards. When an administrator deletes a credential on the server, the passkey stays on the phone or in the password manager and keeps appearing in the picker. The NHS guidance for removing a security key in Care Identity Management confirms the key has been removed from the user's profile; it says nothing about the credential on the key, because until now nothing could. Level 3's Signal API adds three one-way calls: signalUnknownCredential after a failed sign-in with an unrecognised credential, signalAllAcceptedCredentials to send an authenticated user's full list, and signalCurrentUserDetails to update the username and display name. The spec is candid that clients act "opportunistically" and never confirm success, which keeps the calls from leaking account state. Chrome shipped it on desktop in 132 and on Android in 144; Safari in 26.0. Firefox has not. The spec permits clients to achieve the same effect on security keys through CTAP's credential management command, though no browser has yet documented doing so; a returned roaming key still needs a reset or a management tool.
4. Upgrading a password to a passkey without a ticket
Conditional create lets a site ask for a passkey with mediation: 'conditional' and get one created without a prompt (the user is told afterwards) when the user has recently signed in with a saved password for that account. Chrome's guidance is explicit that no action is required of the user. For a workforce rollout this is the difference between a campaign and a background migration: staff who already sign in with a saved password acquire a passkey on their next visit. Two caveats. The passkey lands in whatever credential manager the browser uses, which in practice means a synced passkey; NHS England's CIS2 guidance treats those as AAL2 and covers the device-bound AAL3 tier separately. And Chrome's feature page dates desktop support to version 136 and Android to 142; Safari had it from 18.0; Firefox does not.
5. Hints, provider labels and the end of SafetyNet
Three smaller items help an enterprise deployment. Hints (security-key, client-device, hybrid) let a relying party that has issued security keys steer the browser's prompt to them; they take precedence over transport data but do not bind the client, and only Chromium browsers honour them so far, and not where Windows draws the prompt. The authenticator's AAGUID is "no longer zeroed when attestation preference is none", so an identity provider can label a passkey by its provider without demanding attestation (the label is unverified, but useful for inventory). And the Android SafetyNet attestation format is deprecated, along with rp.name, while the uvm extension has been dropped. Where attestation is required, Microsoft Entra ID's current documentation is the reminder that "synced passkeys do not support attestation"; attestation policy still means device-bound keys.
What Level 3 does not do
It does not include Chrome's "immediate" UI mode, which Chrome announced in May 2026 and which Apple has given a negative position. It does not define credProtect, minPinLength or credBlob; those live in CTAP 2.3, the authenticator-side protocol published as a Proposed Standard in February 2026. And it says nothing about remote desktops, which is the first item on Level 4's agenda: a remoteClientDataJSON extension for WebAuthn inside a remote session, published as a first working draft on 15 September 2026. Any hospital that signs in through Citrix or a virtual desktop should watch that one.
