The Conventional Wisdom
With WebAuthn Level 3 now a W3C Recommendation, you might think it's time to roll out passkeys at scale. The standard is stable, features are robust, and major platforms have implemented it. It seems like the right moment to move beyond passwords.
Why Your Architecture Isn't Ready
However, just because WebAuthn L3 is stable doesn't mean your architecture is prepared for its capabilities. Many IAM teams see passkeys as a simple password replacement, but L3 introduces features that require significant architectural changes.
The issue isn't with the standard itself. It's that L3 formalizes features that disrupt the assumptions your current authentication flows rely on.
Consider Conditional Create, which allows passkey registration during a normal login. This isn't just a UX tweak; it's a credential lifecycle event outside your usual provisioning workflow. If your Identity Governance and Administration (IGA) system tracks credential registration as part of user onboarding or manual upgrades, you're now dealing with passkeys your governance tools don't recognize.
The Signals API is another example. It lets you inform credential managers when a passkey is revoked, but it's one-way and asynchronous. You can't force deletion or get immediate confirmation. If your security model assumes instant credential revocation, this API introduces a gap your incident response plans haven't covered.
The Backup Eligible and Backup State flags present yet another challenge. They indicate whether a passkey is synced to a cloud provider or bound to a single device. This information is valuable, but it raises questions. Do you allow synced passkeys for workforce access, or only device-bound ones? If both, do they have different privilege levels? L3 provides the data, but not the policy framework.
The Evidence
WebAuthn L3 was published as a W3C Recommendation on August 25, 2026. Its features, like Conditional Mediation and the Signals API, are implemented across major platforms, but with regional variations. This inconsistency makes treating L3 as a simple go-ahead risky.
Related Origin Requests (ROR) is a case in point. ROR allows a single passkey to work across multiple domains by hosting a JSON list at /.well-known/webauthn. For multi-domain enterprises, this solves a problem, but it also means your authentication flow depends on a network request to a well-known endpoint. If that endpoint is misconfigured or unreachable, authentication fails, potentially unnoticed until users report issues.
The AAGUID (Authenticator Attestation GUID) without attestation feature is another example. L3 allows credential managers to send the AAGUID for unattested synced passkeys, improving user experience by labeling passkeys with the credential manager's name and icon. However, this requires updates to your credential data model and UI, which you may not have planned for.
What to Do Instead
Start by mapping L3's new features to your existing authentication and governance architecture. This isn't just a compliance task; it's an integration project.
For Conditional Create, decide if you'll allow opportunistic passkey registration and how you'll reconcile these with your IGA system. You might need a post-authentication hook to log passkey creation events and trigger entitlement reconciliation. If your governance model requires manager approval for new credentials, Conditional Create might not fit.
For the Signals API, outline your credential revocation process. When you revoke a passkey, what follows? Do you send a revocation signal to the credential manager? How do you confirm receipt? What's your fallback if a user authenticates with a revoked passkey? Implement a monitoring layer to track signal delivery and flag discrepancies.
For the BE/BS flags, establish a policy before checking them. In a workforce environment, you might restrict high-privilege access to device-bound passkeys. Your Policy Decision Point (PDP) should evaluate the BE flag and deny access if the passkey is backup-eligible and the resource requires device-bound credentials.
For Related Origin Requests, treat the /.well-known/webauthn endpoint as critical infrastructure. It should be versioned, monitored, and tested as part of your deployment pipeline. Ensure correct caching if using a CDN and set up synthetic monitoring to check endpoint availability and JSON validity.
For AAGUID support, update your credential data model to store the AAGUID and add UI components to display credential manager names and icons. This is straightforward but easy to overlook if you treat passkeys as just another credential type.
When the Conventional Wisdom Is Right
The conventional wisdom is correct that WebAuthn L3's Recommendation status is a milestone. The standard is stable enough for RFPs, conformance statements, and regulatory submissions. If you've been waiting for stability to commit to passkeys, now's the time.
L3 also addresses deployment challenges from earlier passkey rollouts. Conditional Get improves user adoption by making passkeys visible and easy to use. The Signals API, despite its limitations, provides a coordination mechanism between relying parties and credential managers. The Client Hints feature helps avoid confusing cross-device prompts when only security keys are allowed.
Moreover, L3's alignment with FIDO CTAP versions 2.2 and 2.3 ensures browser-side and authenticator-side protocols are in sync, which is crucial for interoperability.
But stability doesn't mean simplicity. WebAuthn L3 is a mature standard for a complex problem. It offers powerful tools, but you need an architecture that uses them effectively.
