Two leading identity standards bodies — the FIDO Alliance and the OpenID Foundation — today published a jointly developed draft specification designed to operationalize continuous device attestation within zero‑trust access architectures. The "Continuous Attestation Profile" (CAP) aims to make short‑lived, privacy‑preserving attestations a first‑class input to access decisions across ZTNA, IAM and SASE products.

What the CAP spec does

The CAP draft defines a lightweight, interoperable format and lifecycle for ephemeral attestation tokens that assert device posture in near‑real time. Key elements include:

  • Short‑lived attestation tokens (minutes-long TTL) signed by trusted attesters so access gates evaluate current device state rather than stale, long‑lived claims.
  • Privacy-preserving attestation modes that avoid exposing device identifiers by using pseudonymous keys or tokenized attestations compatible with existing FIDO privacy models.
  • Interoperable validation rules mapped to OpenID Connect and OAuth 2.1 flows so attestation results can be consumed by standard IAM and ZTNA brokers.
  • Revocation and freshness checks based on short revocation windows and lightweight transparency logging to limit the window for compromised device attestations.
  • Reference integrations for platform attesters (TPM/TEE/secure enclave) and cloud‑based attestation services to accommodate heterogeneous device fleets.

Why this matters for zero‑trust

Zero‑trust architectures rely on continuous verification of identity, device posture and session context. Many zero‑trust deployments today still depend on periodic scans or stale inventory snapshots for device trust evaluations, which increases the risk window for lateral movement after device compromise.

By specifying how devices can produce short‑lived, verifiable attestations that are both privacy conscious and easy to validate in OAuth/OpenID flows, the CAP draft removes a friction point that has slowed broad adoption of continuous authorization. In practice, this enables policy engines to require a freshly signed attestation at every session establishment or privilege elevation, aligning device attestations with other real‑time signals such as behavioral telemetry and threat intelligence.

Immediate use cases

  • Step‑up authentication: require a fresh device attestation for high‑risk operations (admin consoles, financial transactions).
  • ZTNA session renewal: revalidate device posture during long sessions or before sensitive resource access without demanding full re‑auth.
  • Third‑party access: give short‑term, posture‑gated access to contractors or supply‑chain partners, reducing standing privileges.

Industry reaction and vendor plans

In their joint announcement, the two organizations positioned CAP as a pragmatic bridge between hardware‑rooted attestation and cloud‑native access control. Several identity and security vendors signaled early interest in implementing CAP reference libraries and validators to tie attestation input into existing policy engines and SIEM/XDR workflows.

For buyers, the practical benefits are twofold: stronger guarantees about device state at decision time, and a path to reduce reliance on wide network segmentation by making more granular, context‑aware decisions at the application layer.

Technical and operational challenges

Adoption will not be frictionless. The draft acknowledges several real‑world constraints:

  1. Hardware availability: not all endpoints have hardware attestation roots (TPM, Secure Enclave, TEE). CAP includes provisions for software attestation fallbacks, but those carry higher risk and require compensating controls.
  2. Scale and latency: validating fresh attestations at scale can add verification overhead. The spec recommends local caching of signed attestations with tight TTLs and batched validation for performance‑sensitive flows.
  3. Privacy and enterprise policy: some organizations will need to reconcile CAP's pseudonymous modes with regulatory or audit requirements that mandate identifiable logs; the draft suggests separate audit hooks that preserve user privacy in primary attestations while enabling de‑anonymized logging under strict governance.
  4. Supply chain and attester trust: CAP relies on an ecosystem of trusted attesters and attestation authorities. Organizations must define who they trust and how attestation keys are managed across device manufacturers and MDM/EMM providers.

What zero‑trust practitioners should do now

For practitioners managing migration plans or upgrades, the announcement creates an actionable roadmap:

  • Inventory device attestation capabilities: catalogue which endpoints support hardware attestation, where software fallbacks are required, and where upgrades are planned.
  • Run pilot integrations: deploy CAP validators in a test environment tied to high‑value apps to measure latency and policy effectiveness before wide rollout.
  • Update access policies: define policy rules that require fresh attestations for sensitive operations while avoiding over‑strict requirements that break remote workers or third‑party access.
  • Plan telemetry and audit practices: ensure attestation events feed your telemetry pipeline, and design audit processes that respect the spec's privacy modes.

Where the standard goes from here

The draft is positioned for community review and interoperability testing. If the pilot implementations proceed as anticipated, CAP could be incorporated into broader OpenID Connect profiles within 12‑18 months, offering a standardized input for continuous authorization across cloud and enterprise stacks.

For the zero‑trust community, the CAP draft is significant because it operationalizes a key piece of the “continuous” part of zero trust — enabling policies to rely on current, verifiable device posture without compromising user privacy or scaling poorly. The next months of interoperability tests and vendor adoption will determine how quickly it moves from draft to widely supported control in ZTNA and IAM solutions.

Zero‑trust architects should track the CAP working group, evaluate vendor roadmaps for CAP support, and prepare pilots that exercise short‑lived attestations in real‑world access flows. If successful, continuous attestations could become a standard control for reducing standing risk across large, hybrid device fleets.