Overview

FIDO2/WebAuthn is now the baseline for phishing‑resistant authentication in enterprise identity stacks. The question has shifted from “should we adopt FIDO2?” to “how do we make FIDO2 credentials meaningfully protect network sessions, legacy apps and multi‑protocol traffic without breaking operations?” This updated analysis (Nov 2026) revisits four practical architectures for bringing passkey‑style, device‑bound auth into zero‑trust network access (ZTNA), summarizes what has changed since mid‑2026, and gives concrete, operational guidance for teams migrating this year.

Background — what changed since August 2026

Three practical trends accelerated through 2026:

  • Broad enterprise passkey rollouts. Most major identity providers (IdPs) completed passkey parity for SSO across desktop and mobile, reducing the friction of FIDO2 adoption for end users and contractors.
  • Emergence of turnkey certificate brokering and mTLS integrations. Several vendors now offer integrated brokers that mint short‑lived client certificates or SPIFFE identities immediately after a FIDO2 assertion, making cryptographic session binding simpler to operate.
  • Telemetry and policy fusion matured. SIEM/XDR and policy engines now routinely ingest FIDO2 assertion events, attestation results and certificate issuance telemetry, enabling risk‑based enforcement at the network data plane.

Standards and guidance that matter today include NIST SP 800‑63B for authenticator assurance, the FIDO Alliance metadata and attestation frameworks, RFC 8705 (OAuth 2.0 Mutual TLS and certificate binding) and CNCF SPIFFE/SPIRE for workload identity. These standards remain the foundation for mapping FIDO2 into network controls.

Data and evidence — adoption and operator experience (what we’re seeing in 2026)

Evidence from industry reports and operator briefings this year points to three operational realities:

  • Enterprises prefer hybrid deployments. Organizations with significant legacy applications keep gateways/connectors for translation while adopting agentless reverse proxy patterns for web and SaaS workloads.
  • Session replay is still the chief risk. Operators who stop at IdP‑level FIDO2 SSO but do not cryptographically bind the resulting session tokens report measurable replay and lateral movement incidents during red‑team drills.
  • Automation lowers PKI cost. Teams that combine short‑lived certificates (auto‑issued on login) with automated revocation and monitoring avoid most certificate‑management headaches; this pattern is now available as managed services from multiple vendors.

These trends are consistent with guidance from the FIDO Alliance on attestation and privacy, NIST on risk‑based authenticator selection, and RFC 8705 on certificate‑bound tokens.

Four architectures — updated tradeoffs and new variants

1. Agent‑based ZTNA integrated with IdP FIDO2 SSO (updated)

Pattern: A client agent on the endpoint triggers IdP FIDO2 SSO and exchanges the assertion for short‑lived access tokens and/or client certificates. The agent enforces posture and presents telemetry to the control plane.

  • What’s new: Agents increasingly act as local certificate managers, requesting SPIFFE identities or mTLS certificates after FIDO2 verification. This reduces token replay risk and improves support for non‑HTTP protocols.
  • Security: Strong — phishing‑resistant initial auth, device attestation and cryptographic session binding (when the agent receives a certificate).
  • Operational notes: Expect lifecycle management to be automated by vendor agents; prioritize agents that emit standardized telemetry (OSQuery, CEF, or OTEL).

2. Agentless reverse proxy using WebAuthn + SAML/OIDC bridge (updated)

Pattern: Reverse proxies/front doors delegate WebAuthn prompts to the browser and issue session cookies or JWTs for access.

  • What’s new: Modern gateways support DPoP or OAuth sender‑constrained tokens and integrate with browser APIs to limit session token reuse across machines. For strictly web/SaaS estates this remains the fastest path.
  • Limitations: Non‑HTTP traffic still needs protocol translators or jump hosts; ensure gateway session cookies are short‑lived and scope‑restricted.

3. Identity broker + short‑lived client certificates (certificate brokering) — now mainstream

Pattern: Post‑FIDO2 authentication, an identity broker mints ephemeral client certificates (mTLS) or SPIFFE IDs used by the data plane.

  • What’s new: Several IdPs and ZTNA vendors now include managed certificate brokering as a first‑class feature. Integration with SPIFFE lets services authenticate both users and workloads using the same identity fabric.
  • Security: Very strong — certificates provide cryptographic session binding and work across protocols that support TLS. Use RFC 8705 patterns for certificate‑bound tokens where appropriate.
  • Operational: Lower friction than prior PKI projects because issuance is automated and certificates are short‑lived; however, you must instrument issuance, revocation and attestation logs.

4. Legacy application gateway with protocol bridging and Kerberos/NTLM integration (updated)

Pattern: Gateways accept FIDO2‑backed SSO and re‑emit credentials or tokens appropriate for legacy backends.

  • What’s new: Gateways now commonly include built‑in vaults, just‑in‑time credential injection and session recording to reduce standing privileges. Vendors emphasize ephemeral connector service accounts rather than long‑lived secrets.
  • Security: Mixed — gateway hardening and vaulting practices are critical. Plan for compensating controls (microsegmentation, tight file share ACLs) for downstream systems.

Multiple perspectives — what vendors, security teams and standards bodies advise

  • IdP vendors: Encourage using FIDO2 as primary SSO factor, then layering session binding (certs or DPoP) for critical flows.
  • Network/SASE vendors: Recommend hybrid models where reverse proxies protect web apps while brokers or agents secure non‑HTTP protocols.
  • Security architects: Emphasize telemetry fusion — ingest FIDO assertion, attestation verdicts and certificate issuance events into SIEM/XDR for continuous policy decisions.
  • Standards/consortia: NIST still prioritizes authenticator assurance and risk‑based policies (SP 800‑63B). CNCF SPIFFE/SPIRE is the de‑facto pattern for workload identity if you need to authenticate services and users uniformly.

Implications — what this means for your program

Operationally, teams should assume a hybrid landscape for the near term. Specific implications:

  • Do not treat FIDO2 as a single‑step solution. Without cryptographic session binding or short‑lived credentials at the data plane, attackers can replay stolen session tokens.
  • Invest in telemetry now. FIDO2 assertion events, attestation outcomes, certificate issuance and token exchanges must be observable and correlated with endpoint posture.
  • Automate certificate lifecycles. Managed brokers and SPIFFE integrations remove much of the PKI burden; plan to use them for high‑assurance flows.
  • Plan for legacy translation. Gateways that use vaulting and ephemeral credential injection reduce long‑term risk and enable phased modernization.

Updated migration checklist — practical steps for Nov 2026

  1. Inventory applications and classify by protocol and sensitivity (web/SaaS, API, non‑HTTP, legacy). Include owner, criticality and compliance constraints.
  2. Pilot passkey SSO (agentless) on a low‑risk SaaS portfolio to validate UX and attestation policies. Measure adoption and failure rates.
  3. Run a controlled pilot issuing short‑lived client certificates or SPIFFE identities after FIDO2 auth for a set of high‑assurance apps. Validate revocation and telemetry ingestion.
  4. For legacy apps, deploy gateways with vaulting and ephemeral credential injection. Monitor for protocol edge cases that require app changes.
  5. Instrument: log every FIDO2 assertion, attestation verdict, token exchange and certificate issuance to your analytics stack. Create alerts for anomalous assertion patterns and unexpected certificate revocations.
  6. Define risk‑based policies: require attestation (TPM or verified device) for elevated data access; allow roaming keys for low‑risk tasks but enforce step‑up for sensitive operations.

Operational pitfalls — updated cautions

  • Assurance creep: Overly strict attestation (requiring hardware keys for all users) slows adoption. Use risk‑based tuning and progressive enforcement.
  • Token binding gaps: IdP assertions are necessary but not sufficient. If your enforcement plane cannot validate a certificate or sender‑constrained token, replay remains possible.
  • Telemetry blind spots: Agentless setups must be augmented with endpoint signals (network telemetry, browser signals, EDR) to see device posture.
  • Legacy translation risk: Gateways that persist downstream credentials are single points of failure; prefer ephemeral injection and frequent rotation.

Outlook — what to watch for in 2027

Expect continued consolidation of certificate brokering into IdP and ZTNA products, tighter browser‑level support for sender‑constrained tokens, and more standardized FIDO attestation claims for enterprise telemetry. Watch these developments:

  • Broader adoption of SPIFFE identities for user‑to‑service scenarios.
  • Improved browser APIs for constrained token binding (reducing reliance on proprietary proxy behavior).
  • More managed services offering integrated attestation + certificate issuance to lower operational cost.

Conclusion

FIDO2 is no longer the experimental layer of authentication — it is the expected baseline for phishing resistance. The remaining engineering work is mapping that assurance into the data plane so that sessions are cryptographically bound, telemetry informs policy decisions, and legacy systems are protected without requiring a forklift rewrite. The four architectures — agent, agentless reverse proxy, certificate brokering, and legacy gateways — remain valid. The updated guidance for 2026 is practical: automate certificate issuance where you need session binding, ingest FIDO attestation and issuance logs into security telemetry, and apply risk‑based attestation policies to balance security and adoption.

FAQ

Do I need TPM attestation for every user?

No. Require TPM or platform attestation for high‑risk access (sensitive data, privileged sessions). For routine access, allow roaming or platform passkeys and use risk‑based step‑ups. This balances security and adoption.

Is certificate brokering worth the operational cost?

Yes if you need cryptographic session binding across non‑HTTP protocols or require stronger proof of possession for compliance. Modern brokers automate issuance and revocation, reducing traditional PKI overhead. If your estate is web‑only and low‑risk, sender‑constrained tokens via gateway may suffice.

Can agentless ZTNA be secure for unmanaged devices?

Agentless is usable for BYOD and contractors when paired with short‑lived, strongly bound session tokens and tight gateway controls. However, it offers less posture visibility than agent‑based solutions, so augment with browser signals and network telemetry.

What telemetry should I collect after enabling FIDO2?

Log FIDO2 assertion events (time, relying party, user ID), attestation verdicts (TPM/hardware vs roaming), certificate issuance and revocation events, and token exchanges. Correlate these with endpoint posture, IP context and application access logs in your SIEM/XDR.