WebAuthn Level 3 changes hospital sign-in governance across domains

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Crayonic's blog post: WebAuthn Level 3 standardises related origins, PRF-based secrets, credential signalling and conditional creation in ways that change how hospital sign-in policies can be governed.

Why it matters: IAM and IAM governance teams need to understand where passkeys now support cross-domain enrolment, leaver handling and controlled rollout without relying on brittle password-era assumptions.

By the numbers:

• Chrome has supported PRF since 116, Safari since 18.0 and Firefox fully since 139, according to Crayonic.
• Chrome shipped the Signal API on desktop in 132 and on Android in 144, according to Crayonic.
• Chrome added conditional create on desktop in 136 and on Android in 142, according to Crayonic.

Context

WebAuthn Level 3 matters because hospital sign-in is rarely confined to one cleanly owned domain. Trusts, regional portals, legacy brands and shared services all create identity boundaries that password-era workflows handled poorly, especially on shared devices and in clinician-heavy environments.

The standard gives identity teams a more reliable basis for cross-domain passkey use, credential lifecycle signalling and controlled migration without depending on custom glue code. That shifts the problem from whether the browser can technically support the flow to how policy should govern it.

For hospital programmes, the real question is whether access policy, leaver handling and device posture are aligned with the new browser and authenticator capabilities. Workforce identity security becomes the governance frame, not just the sign-in mechanism.

Key questions

Q: How should organisations govern passkeys across multiple domains?

A: They should treat cross-domain passkey use as a formal trust boundary, not a convenience feature. That means approving which origins may share credentials, assigning ownership for the related origins file, and reviewing changes as part of identity governance. If the organisation cannot explain why two domains should trust the same passkey, they should not share one.

Q: Why do passwordless programmes still need strong lifecycle governance?

A: Passwordless shifts risk from passwords to issuance, recovery, and revocation. If those lifecycle steps are slow or unclear, users lose access, request exceptions, or reuse weaker paths to keep working. Strong lifecycle governance keeps the credential trusted throughout its usable life, not just at initial enrolment.

Q: When should teams use authenticator-derived secrets instead of normal sign-in?

A: Use them when the goal is to unlock specific data only after user verification, especially on shared devices or in mixed-trust clinical workflows. The key decision is whether the secret should exist only inside the authenticator and never be recoverable by the server. If recovery is required, PRF is usually the wrong pattern.

Q: What should security teams check before enforcing passkey policy on shared devices?

A: They should confirm browser support, authenticator capabilities and whether the workforce is using synced or device-bound credentials. Shared devices expose weak assumptions quickly, especially when policy relies on features that only certain browsers or key types support. If the rollout target is a hospital workstation, the client mix matters as much as the identity policy.

Technical breakdown

Related origins and cross-domain passkey reuse

A passkey is still bound to a relying party identifier, but WebAuthn Level 3 allows a site to declare related origins in a well-known JSON file so that multiple domains can share the same credential family. This matters for organisations with fragmented brand, portal and service domains because it reduces the need for separate sign-in journeys while keeping verification bound to the browser and authenticator ceremony. The practical constraint is not user convenience alone. It is whether the relying party can enumerate legitimate origins without widening the trust boundary beyond what the identity programme can defend. See the Passwordless and Passkeys Guide.

Practical implication: Treat cross-domain passkey reuse as an explicit trust-bounding exercise, not a convenience feature.

PRF-derived secrets and clinician-bound encryption

The PRF extension turns a passkey into a source of stable, credential-specific output without exposing the underlying secret. That enables per-user or per-session encryption patterns where data can be opened only after user verification and with no server-held recovery key. In healthcare, that changes the governance question from password replacement to conditional data access. If a clinician-authenticated secret can unlock locally stored or server-stored data, then the identity layer becomes part of the confidentiality design, not just the login experience.

Practical implication: Align data access rules with authenticator-derived secrets when you need one authenticated clinician to unlock data and nobody else.

Signal API and lifecycle-aware passkey offboarding

The Signal API gives browsers a one-way way to learn that a credential is gone, accepted credentials have changed, or user details have been updated. The point is not confirmation. It is reducing stale entries and stale prompts without leaking account state. This addresses a common leaver problem in passkey programmes: a credential may be removed server-side while still persisting on the device or in a password manager. The control value is lifecycle hygiene, not revocation in the classic token sense. See the Passkey Rollout Guide.

Practical implication: Use credential signalling to keep passkey inventories and device prompts aligned with server-side account lifecycle changes.

NHI Mgmt Group analysis

WebAuthn Level 3 turns passkey governance from a device problem into a lifecycle problem. The article shows that browser support is now sufficiently stable for enterprises to rely on related origins, conditional create and credential signalling across common platforms. That moves the governance burden away from one-off implementation decisions and toward policy, inventory and lifecycle consistency. Practitioners should now decide whether their identity programme can govern passkeys as a managed access primitive rather than a pilot feature.

Cross-domain sign-in without explicit origin governance creates a new trust boundary. Related origins make one passkey usable across multiple domains, but the security meaning of that convenience depends on who is allowed to publish and maintain the origin list. If the list grows faster than the governance model, the identity boundary stops matching the organisation boundary. The implication is that cross-domain credential reuse now needs explicit approval, change control and periodic review, not just technical enablement.

Leaver handling is the clearest example of the passkey lifecycle gap. The standardised Signal API addresses a control failure that smartcard-era processes handled poorly: the server can remove a credential while the client continues to display it. That is not a sign-in issue alone. It is a state-consistency problem across directories, browsers and authenticators. Organisations that treat offboarding as account deletion only will keep leaving stale credentials visible to users and administrators.

Shared-device environments make authenticator-derived secrets materially more valuable than password substitutes. PRF changes the meaning of the passkey because it can derive a stable secret without exposing a reusable key to the server. In hospital workflows, that creates a practical pattern for conditional data access on shared workstations, but it also raises the bar for policy design. The identity programme has to distinguish between authenticating the user and authorising what the authenticator-derived secret may unlock.

WebAuthn Level 3 validates a stronger identity assumption: the browser is now part of governed authentication, not just transport. That assumption matters because hospital sign-in increasingly depends on the browser mediating related origins, conditional create and signalling behaviour. The governance conclusion is simple: teams should stop treating browser support as a compatibility note and start treating it as an architectural dependency for identity assurance.

From our research library:

• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
• Read next: Passwordless and Passkeys Guide

What this signals

Origin governance is now part of passkey governance. Cross-domain credential reuse only works safely when the organisation can prove which domains belong together and who controls the list. That is a governance boundary, not a browser feature, and it should be managed with the same discipline as federation trust.

State consistency is the hidden operational issue in passwordless programmes. A removed credential that still appears in the client is not a cosmetic problem, it is a lifecycle mismatch that can confuse users and weaken offboarding confidence. The programme signal is clear: lifecycle automation must extend to browsers and authenticators, not stop at the directory.

Shared clinical workstations sharpen the value of authenticator-bound data access. When access depends on a derived secret rather than a reusable password, policy can separate who authenticated from what data they may unlock. That distinction becomes important wherever shared devices, downtime packs or locally cached records are part of the operating model.

For practitioners

• Define an origin governance model List every domain that may legitimately share a passkey, approve the related origins file process, and assign ownership for change control and review.
• Separate sign-in success from data access design If you use PRF-derived secrets, document exactly which data a clinician-authenticated secret may unlock and where server-side recovery is intentionally disallowed.
• Align offboarding with credential signalling Update leaver workflows so browser-side passkey prompts and server-side account state are reconciled after deletion, not left to user memory.
• Review shared-device rollout assumptions Check whether your passkey deployment depends on synced credentials, device-bound keys or local authenticator capabilities before you enforce policy across clinical workstations.
• Inventory browser support before changing policy Confirm which browsers and versions your workforce actually uses for related origins, PRF and conditional create so policy changes match real client behaviour. See the FIDO2 and WebAuthn Internals Guide.

Key takeaways

• WebAuthn Level 3 shifts passkey governance toward explicit control of cross-domain trust, lifecycle state and authenticator-dependent access.
• The strongest operational change is not sign-in convenience but the ability to manage shared-device workflows with clearer policy boundaries.
• Teams should rework offboarding, origin approval and rollout planning together, because passwordless controls fail when those decisions are treated separately.

Related NHI Mgmt Group resources: Passwordless and Passkeys Guide · Passkey Rollout Guide · Workforce Identity Security Guide · FIDO2 and WebAuthn Internals Guide

Key terms

• Related Origins: A related origins set lets one passkey be accepted across multiple approved domains that belong to the same relying party family. In practice, it shifts trust from a single hostname to an explicitly governed list, which makes ownership and change control part of authentication design.
• PRF Extension: The PRF extension allows a passkey to derive a stable secret from an authenticator without exposing the underlying credential. That makes it useful for encrypting data or unlocking local state after user verification, but only when the programme can tolerate no server-side recovery path.
• Signal API: A Signal API is an interface that exposes security or identity signals for consumption by other systems. In practice, it delivers structured events, risk indicators, or status data, such as authentication anomalies, device posture, or policy outcomes, so downstream controls can make faster, context-aware decisions across identity and security workflows.
• Conditional Create: Conditional create is a WebAuthn flow that can create a passkey after a recent password sign-in without a separate prompt. It supports background migration from passwords to passkeys, which makes rollout easier but also means policy must account for whatever credential manager the browser uses.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.