· deepdives · 7 min read
Beyond FIDO2: The Next Steps for WebAuthn in the Cybersecurity Landscape
A forward-looking exploration of how WebAuthn will evolve after FIDO2: API improvements, biometric integration, privacy-preserving attestation, and what implementers should do today to prepare for a passwordless future.

Outcome first: after reading this you’ll be able to assess what WebAuthn can realistically deliver next, what to plan for as an implementer or security leader, and how to balance stronger authentication with user privacy and regulatory requirements.
WebAuthn isn’t hypothetical anymore. It’s shipping in browsers, embraced by platform vendors, and powering passkeys across ecosystems. But FIDO2 was just the start. This article maps the near-term and medium-term evolution of WebAuthn: API enhancements, tighter biometric integration, privacy trade-offs - and the hard engineering and policy choices that follow.
Quick primer: what WebAuthn solved and what remains
WebAuthn (the W3C API) together with the FIDO2 work (CTAP + authenticators) moved the web from passwords to public-key cryptographic credentials. It made phishing-resistant passwordless possible and standardized how browsers and authenticators talk to relying parties (RPs).
If you want a concise spec reference, see the W3C WebAuthn spec and Level 2 roadmap: https://www.w3.org/TR/webauthn/ and https://www.w3.org/TR/webauthn-2/. The FIDO Alliance provides ecosystem guidance and initiatives like passkeys: https://fidoalliance.org/passkeys/.
But adoption reveals new needs: smoother multi-device experiences, better enterprise controls, richer attestation models, and clearer privacy guarantees. The API and surrounding ecosystem must adapt.
Current trends shaping WebAuthn’s next steps
Passkeys and cross-device credentials. Platform vendors (Apple, Google, Microsoft) are pushing passkeys - resident credentials that can sync across devices - making passwordless the user-friendly default. See Google’s developer passkeys docs: https://developers.google.com/identity/passkeys.
Platform authenticators and Secure Enclaves. Modern devices increasingly store keys in hardware-backed secure elements (TPM, Secure Enclave). This raises expectations for stronger attestation and tamper-resistance, and for APIs that can express those expectations to RPs.
Richer extensions and use cases. Implementations are expanding with extensions (for example, largeBlob storage, credProps, and enterprise attestation patterns). Developer guides like https://webauthn.guide/ catalog these extensions and patterns.
Privacy and regulatory scrutiny. Attestation and device identifiers can leak metadata that undermines user privacy or runs afoul of regulations (GDPR). Organizations are asking: how do we get strong device signals without creating cross-site correlation vectors?
API-level enhancements to expect (and why they matter)
Better attestation control and standardized policies
- Problem: Attestation can prove device model and provenance - useful for risk-based decisions - but it can also identify users across sites.
- Likely evolution: richer, standardized attestation options (more attestation formats, attestation CA ecosystems, and standardized RP preferences), combined with privacy-preserving attestation modes. The WebAuthn spec already has attestation types and guidance; expect more prescriptive patterns in Level 2 and FIDO guidance: https://www.w3.org/TR/webauthn/.
Extensions to support per-credential metadata and larger client blobs
- Example: largeBlob and credProps-like features let RPs store small server-encrypted blobs or query credential properties. These support features like per-credential display names, policy flags, or small state needed for UX without server-side user stores.
- Impact: smoother account recovery flows, richer UX on multi-credential accounts, and less server-side state complexity.
Conditional UI and discovery improvements
- Problem: Discovering the right credential for a given RP without interrupting users is still tricky.
- Evolution: more advanced conditional mediation APIs and discoverable credential improvements so browsers can offer seamless “sign-in with device” experiences without modal pop-ups.
Native multi-factor and continuous authentication hooks
- Beyond single-factor passkeys, WebAuthn will expand to better express multi-factor policies (e.g., require platform authenticator + external token) and integrate with continuous authentication signals (trusted sensors, environmental context) while providing standardized privacy controls.
Biometrics: integration without sacrificing privacy
Biometrics are a natural fit for local user verification (UV) in WebAuthn. But they must remain local. The model that works is “match-on-device”: biometric templates never leave the secure element, and the authenticator merely reports a local verification result to the WebAuthn flow.
- Technical principles to enforce
- Match-on-device only. Biometric templates must be stored and matched locally in hardware or in an OS-protected store.
- No raw biometric export. The authenticator should never expose templates or raw biometric signals via the API.
- Strong liveness detection and anti-spoofing. For high-assurance use cases, attestations should indicate anti-spoofing or liveness capabilities.
NIST guidance (SP 800-63B) is useful when designing biometric assurance levels and deciding when biometrics are acceptable for authentication: https://pages.nist.gov/800-63-3/sp800-63b.html.
Biometrics will be packaged as a local user verification mechanism rather than as a networked identity. The UX gains are huge. The privacy risk is minimal when vendors stick to match-on-device and use the authenticator to attest to verification without revealing biometric data.
Privacy and data protection: design patterns and pitfalls
Minimize cross-site signals. Unique device attestation or persistent hardware identifiers create correlation risk. Use privacy-preserving attestation or anonymized attestation flows when RPs don’t need device model fidelity.
Principle of data minimization. Only request the attestation and metadata you need for risk decisions. For many consumer scenarios, “platform authenticator present” and “user verification succeeded” suffice.
Consent and transparency. Make attestation choices transparent in UX and document retention and processing of any metadata to satisfy GDPR/CCPA obligations.
Server-side protections. Treat attestation certificates and credential metadata as sensitive. Limit retention, encrypt at rest, and apply strict access controls.
Backup and recovery implications. Passkey sync (cloud-backed credentials) improves UX but transfers trust from device hardware to cloud providers. Evaluate where credential backups are stored, how they’re encrypted, and who controls the recovery process.
Interoperability with emerging identity frameworks
Decentralized Identifiers (DIDs) and Verifiable Credentials (VCs). Expect experiments integrating WebAuthn keys with DID controllers and using WebAuthn-produced assertions as proofs for VCs. Standardization and tooling are still early, but the cryptographic foundations are compatible.
OAuth/OIDC synergy. WebAuthn will increasingly be used as an upstream authentication method inside OIDC flows. Expect clearer best practices and standardized claims that express attestation context.
Operational realities for Relying Parties (RPs)
Planning for multi-device: design onboarding flows that accept device migration and recovery. Offer account recovery alternatives that are phishing-resistant (for example, trusted out-of-band verification) rather than reverting to passwords.
Risk-based adaptive policies: combine attestation, device posture, and contextual signals (location, device type) for access decisions.
Enterprise controls: enterprises will demand admin-friendly attestation and policy channels (e.g., throwing enterprise attestation into the mix for managed keys). Expect vendor APIs that let IT set attestation/policy constraints.
Testing for accessibility: WebAuthn UX must work for users with disabilities. Ensure fallback flows and clear UX messaging.
Predictions (3–5 years)
Widespread passkey adoption becomes the baseline for consumer authentication, with fewer users falling back to passwords.
WebAuthn Level 2 stabilizes around a set of extensions for largeBlob, conditional UI, and finer-grained attestation preferences. Browsers and platform vendors will standardize common patterns.
Privacy-preserving attestation options will be mainstream: RPs will choose between minimal (anonymous) attestation for general auth and rich attestation for high-risk operations.
Biometric verification will be universally match-on-device and normalized as a local UV method, accompanied by attestations indicating liveness and hardware protections where needed.
Enterprise and regulatory pressure will produce hardened patterns for backup, recovery, and auditability - and possibly new legal frameworks around credential portability and provider responsibilities.
Practical recommendations - what to do now
Start with passkeys where possible. Implement WebAuthn-based passwordless flows now to reduce phishing risk and prepare for customer expectations.
Implement tiered attestation policies. Default to privacy-preserving attestation for consumer logins and require richer attestation only for high-risk actions.
Design recovery carefully. Avoid password-only fallbacks. Use strong out-of-band recovery flows and document recovery UX to customers.
Store minimal attestation metadata. Encrypt what you must keep, and log access.
Test cross-platform: verify how credentials migrate between vendor ecosystems (Apple <-> Google <-> Microsoft) and how UX differs.
Monitor standards and vendor guidance. Watch W3C WebAuthn Level 2 and FIDO Alliance announcements for new extensions and recommended patterns: https://www.w3.org/TR/webauthn/ and https://fidoalliance.org/.
Final thought
WebAuthn is already changing authentication. The next steps will make it more seamless, more privacy-respecting, and more integrated with biometrics and identity frameworks - but only if implementers intentionally design for privacy, recovery, and interoperability. The technology can replace passwords; now we must replace the risky operational choices that once came with them. That shift - from just stronger authentication to thoughtfully secure, private, and usable identity - is the real agenda for the next era.



