As Zero Trust Network Access (ZTNA) matures in 2026, relying solely on user identity and posture signals is no longer sufficient. Cryptographic device attestation—proof that a specific hardware or platform state exists and that a key is bound to that platform—lets you enforce access decisions with higher assurance. This guide walks ZTNA practitioners through a pragmatic, auditable implementation using TPM2.0, FIDO2 attestation, and remote-attestation frameworks, showing how to enroll devices, issue short‑lived credentials, verify claims, integrate with a policy engine, and operate at scale.

Why device attestation matters for ZTNA in 2026

  • TPM2.0 is on virtually every enterprise laptop and many servers; firmware attestation reduces risk from compromised OS or bootkits.
  • FIDO2 (WebAuthn) provides standardized, privacy-respecting attestation for authenticators—useful when tying users to trustworthy devices without passwords.
  • Cloud vendors and ZTNA providers increasingly accept cryptographic device claims (short-lived certs, OIDC claims, mTLS), enabling stronger enforcement.
  • Attestation hardens ZTNA policies against credential theft, lateral movement, and supply-chain tampering by proving device provenance and runtime integrity.

High-level architecture

The recommended reference architecture has four logical components:

  • Device agent / attester: code on the endpoint that interacts with TPM/FIDO/key-store to produce attestation evidence.
  • Attestation Verification Service (AVS): server-side verifier that validates evidence, maps results to claims, and issues a short‑lived credential or SAML/OIDC claim.
  • Policy Decision Point (PDP): evaluates user identity, attestation claims, and contextual inputs to produce allow/deny decisions.
  • Policy Enforcement Point (PEP): ZTNA gateway or client that enforces PDP decisions (e.g., issue short-lived certs, open tunnels, or deny access).

Typical flow

  1. Device boots and measures platform state (PCRs), or key material is generated in secure element (TPM or authenticator).
  2. Client collects attestation evidence: TPM quote, FIDO attestationObject, or vendor-supplied measurement report.
  3. Client sends evidence to AVS over TLS. AVS validates signatures, certificate chains, PCR values or metadata statements.
  4. If validation passes, AVS issues a short-lived device certificate or an OIDC assertion containing device claims (device_id, trust_level, measured_boot).
  5. PDP takes the device claim plus user identity and contextual signals to produce an access decision. PEP enforces it.

Step-by-step implementation

1) Plan your trust model and acceptable evidence

Decide what "trusted device" means for your organization. Examples of concrete policies:

  • Device must have TPM2.0 endorsement key (EK) and pass measured boot PCRs 0, 2, 4 within expected values.
  • Device must present a FIDO2 attestation from a known authenticator vendor indicating a hardware-backed key.
  • Virtual machine workloads must attest via hypervisor-based attestation (Azure Attestation, AWS Nitro) and present an AVS-signed claim.

Document required evidence types, acceptable attestation formats (TPM quote, WebAuthn attestation, vendor-signed JSON Web Token), and revocation/expiry rules (prefer short‑lived tokens).

2) Choose the attestation primitives and tooling

  • TPM2.0: tpm2-tools (Linux), Windows TPM APIs and Device Health Attestation. Use TPM for binding keys, quotes, and measured boot.
  • FIDO2/WebAuthn: Use authenticators for user+device binding; verify attestationObject via server libraries.
  • Remote attestation frameworks: Keylime (open source) for fleet attestation, and RATS (IETF) concepts for formats like EAT (Entity Attestation Token).
  • Cloud services: Azure Attestation, AWS Nitro Enclaves attestation, and vendor attestation services to offload verification when possible.

3) Build or deploy an Attestation Verification Service (AVS)

The AVS is the security-critical service that validates raw evidence and maps it into policy claims. Key AVS responsibilities:

  • Validate signature chains (EK certificates, FIDO metadata statements, vendor root certificates).
  • Parse PCR values and compare against expected baselines or allowlists.
  • Check revocation lists and metadata (authenticator metadata from FIDO Metadata Service).
  • Return structured claims (JSON Web Token or OIDC claims) with a short expiry (e.g., 5–15 minutes).

Open-source starting points: Keylime (for TPM attestation and continuous checks) and sample RATS/EAT verifier libraries. For many organizations, integrating Azure Attestation or a cloud vendor’s attestation service speeds deployment.

4) Onboard devices: enrollment and provisioning

Enrollment should be secure and automated:

  • Initial device registration uses an out-of-band proof—MDM enrollment, corporate Wi‑Fi onboarding, or physically present provisioning.
  • During enrollment, create an Attestation Key (AK) bound to the TPM or register a FIDO2 credential. Capture EK public key if needed for later chain validation.
  • Issue a bootstrap credential that allows the device to call AVS. Immediately exchange that for short-lived certificates after successful attestation.

Practical example (Linux TPM2 CLI):

tpm2_createprimary -C o -g sha256 -G rsa -c prim.ctx
tpm2_create -C prim.ctx -g sha256 -G rsa -u ak.pub -r ak.priv
tpm2_load -C prim.ctx -u ak.pub -r ak.priv -c ak.ctx
tpm2_quote -c ak.ctx -l sha256:0,2,4 -o attestation.bin -q nonce

Send attestation.bin and nonce to your AVS for verification. (Replace with platform-specific APIs on Windows and macOS.)

5) Mapping attestation results into ZTNA claims

AVS should return an assertion that your PDP understands. Two common patterns:

  • Short‑lived client certificate (mTLS) minted by a private CA after attestation. ZTNA gateways use mTLS to authenticate the device and enforce rules.
  • OIDC/SAML assertion: AVS acts as an identity-provider-like service and issues an OIDC token containing device_claims. ZTNA PDP consumes the token.

Use short lifetimes (minutes) and require re-attestation for sensitive operations or long-lived sessions.

6) Policy engine integration and enforcement

Use a policy engine (Open Policy Agent, enterprise PDP) that consumes user identity, device claims, and context (location, time, risk signals). Example Rego policy (conceptual):

package ztna

allow {
  input.user.is_authenticated
  input.device.trust_level == "hardware-backed"
  input.device.measured_boot == "known-good"
  input.request.resource in data.allowed_resources[input.user.role]
}

PEP examples: ZTNA client enforces PDP decisions locally, ZTNA gateway uses certificate check (mTLS), or network micro-segmentation flows based on device_id tags.

Edge cases, fallbacks and interoperability

  • Non-TPM devices: allow a degraded trust tier (software attestation) with restricted access. Mark these devices in claims and apply stricter policies.
  • Bring‑Your‑Own Device (BYOD): use FIDO2 attestation to bind user authenticator to the device and limit BYOD access to low-risk resources.
  • Virtual machines and containers: use vendor attestation services (Azure Attestation, AWS Nitro) or enclave attestation (SEV/TDX) for workload identity.

Operational concerns: scale, revocation, privacy

  • Scale: cache verification results for the configured short-lived period, and use horizontal scaling for AVS. Use asynchronous reevaluation for continuous attestation where feasible.
  • Revocation: EK or authenticator revocation is rare; instead, revoke device certificates and require re-attestation when compromise is suspected. Maintain strong logging and SIEM integration.
  • Privacy: FIDO attestation may expose vendor info; use privacy-preserving attestation modes when required and minimize persistent identifiers in claims.

Testing, monitoring and metrics

Key metrics to instrument:

  • Attestation success/failure rate and failure reasons (PCR mismatch, invalid chain).
  • Time to attestation (latency), average certificate issuance time.
  • Number of re-attestations and policy enforcement outcomes.

Test scenarios: device firmware updates (PCRs change), OS patch cycles, and hardware replacement. Simulate attacker models: credential theft without device attestation, and replayed attestation evidence (nonce usage prevents replay).

Real-world integration examples (conservative)

  • Microsoft: Entra ID Conditional Access integrates device compliance (Intune) and Azure Attestation for confidential compute. Use device claims in Conditional Access policies.
  • Cloud ZTNA vendors (examples: Cloudflare Access, Zscaler, Okta): support device posture via client certificates or OIDC claims; consult vendor docs for attestation token ingestion.
  • Open-source: Keylime for fleet TPM attestation and continuous checking; tpm2-tools for proof-of-concept on Linux.

Common pitfalls and mitigation

  • Overly strict baselines: PCRs change with legitimate updates. Allow controlled update windows and use measured-boot allowlists tied to signed firmware/OS releases.
  • Long‑lived attestations: they undermine the model. Use short expirations and continuous or on-demand attestation for critical assets.
  • Complex onboarding: automate with MDM, zero-touch provisioning, or enrollment portals to reduce human error.

Next steps and roadmap

Start with a pilot: pick a high-value application, enroll a small fleet, and implement AVS + short-lived mTLS issuance. Iterate policies and logging, and expand to more device classes and cloud workloads. Consider these roadmap items:

  • Phase 1: Proof‑of‑concept with TPM quotes and short-lived certs for corporate-managed laptops.
  • Phase 2: Add FIDO2 attestation for BYOD and integrate with identity provider for user-device binding.
  • Phase 3: Extend to confidential compute, VMs, and containers with vendor attestation services; deploy continuous attestation for high-risk assets.

Conclusion

Device attestation is a practical, high-value enhancement to ZTNA that raises assurance from "device looks compliant" to "device cryptographically proves its identity and state." In 2026, widespread TPM2.0 deployment, growing FIDO2 adoption, and cloud attestation services make it feasible for organizations of all sizes. Start small, automate enrollment, use short‑lived tokens, and integrate attestation claims into your PDP so that ZTNA decisions become truly cryptographically grounded.