TEE + ZK: Where Trust Ends and Verification Begins

A concise description: In 2025, confidential computing (TEEs) matured and collided head‑on with zero‑knowledge verification. This guide shows decision‑makers when to trust hardware, when to demand math, and how to ship hybrid TEE+ZK systems that are fast, verifiable, and production‑ready.

TL;DR

TEEs give speed and private state; ZK gives portable, cryptographic verification. Use TEEs for fast, confidential compute and ZK for durable, on‑chain verifiability—and combine them where the trust boundary gets thin.
What’s new: GPU TEEs are real (NVIDIA H100) and composably attestable with CPUs; hyperscalers expose EAT‑style attestations; verification layers make ZK proof checks ~90% cheaper; and yes—physical interposer attacks against some server‑grade TEEs are real, so design for compromise and verification. (developer.nvidia.com)

What changed in 2024–2025 (and why your architecture should)

GPU TEEs moved to general access. NVIDIA H100 Confidential Computing added attestation via device ECC‑384 identity, OCSP revocation, and NVIDIA’s Remote Attestation Service (NRAS). It runs under a CPU TEE (TDX/SEV‑SNP) and now participates in composite attestation. This matters for confidential AI inference and training. (developer.nvidia.com)
Intel Trust Authority added composite CPU+GPU attestation: the CPU TEE evidence is verified by Intel, the GPU quote by NRAS, with a combined JWT result. Initial support targeted on‑prem H100; cloud GPU attestation is on the roadmap. (docs.trustauthority.intel.com)
Cloud TEEs standardized their outputs. Google Cloud Attestation issues RATS‑conformant EAT tokens for Confidential VM/Space (SEV, SEV‑SNP, TDX); AWS Nitro Enclaves expose COSE‑signed, CBOR attestation docs with PCRs; Azure offers TDX and SEV‑SNP Confidential VMs across regions. (docs.cloud.google.com)
New attacks raised the bar. “WireTap” and later “TEE.fail” demonstrated physical DDR bus interposer attacks that could forge SGX/TDX attestations and exploit GPU CC attestation gaps—forcing defense‑in‑depth and heterogeneous trust models. Vendors acknowledged these are out‑of‑scope physical attacks; your system shouldn’t be. (wiretap.fail)
ZK verification layers and zkVMs hit production economics. Aligned’s verification layer cut on‑chain proof verification to ~2.1k gas/proof with batchers; SP1 zkVM ships 275k‑gas EVM verifiers and sub‑cent proving with GPU acceleration; ecosystems now routinely verify Ethereum blocks in ZK. (blog.alignedlayer.com)

The modern TEE stack: 2025 buyer’s snapshot

CPU TEEs you can deploy today
- Intel TDX: confidential VMs; composite attestation supported via Intel Trust Authority. (docs.trustauthority.intel.com)
- AMD SEV‑SNP: broadly available (AWS EC2, GCP); attestation uses VLEK and launch measurements; CoRIM profiles published at IETF. (docs.aws.amazon.com)
- Arm CCA: Realms + Realm Management Monitor (TF‑RMM) define a standard model for confidential VMs on Arm; open‑source firmware at TrustedFirmware.org. (arm.com)
- AWS Nitro Enclaves: attestation documents signed by AWS Nitro PKI; KMS policies can bind to PCRs and EIF hash for least‑privilege decryption. (docs.aws.amazon.com)
GPU TEEs
- NVIDIA H100 “Confidential Computing”: device identity certs, NRAS for report validation, OCSP revocation checks, and integration with CPU TEEs for secure channel setup and composite attestation. (developer.nvidia.com)
Attestation formats and standards
- IETF RATS + EAT (Entity Attestation Token) defines standard claims in CWT/JWT; emerging KAT (Key Attestation Token) and CoRIM profiles for SEV‑SNP streamline verifier implementations. Design your verifier around EAT profiles to avoid lock‑in. (datatracker.ietf.org)
Where to run
- Azure Confidential VMs (TDX/SEV‑SNP), Google Confidential VM/Space (TDX/SEV‑SNP), AWS Nitro Enclaves (with TPM/NitroTPM PCRs). Each supports distinct attestation APIs—plan for adapters. (learn.microsoft.com)

The ZK stack you can deploy this quarter

zkVMs and coprocessors
- SP1 zkVM: fast STARK recursion, SNARK wrap for ~275k gas on EVM; GPU prover targets sub‑cent per average Ethereum‑block transaction. (succinct.xyz)
- Proof verification layers
  - Aligned Layer: batch verifies thousands of proofs with restaked security; ~2,100 gas/proof in mainnet beta, plus audits by multiple firms. Use it to make TEE‑to‑ZK handoffs cheap. (blog.alignedlayer.com)
Emerging practice: “verification off‑chain, result on‑chain.” Use verification layers or app‑chains to attest to proof checks and post compact receipts to Ethereum. This is the glue for TEE→ZK pipelines. (alignedlayer.com)

Five TEE + ZK patterns that actually ship

ZK‑attested TEEs: make attestation verifiable everywhere

Problem: Vendor‑native TEE attestation (SGX/DCAP, TDX, SEV‑SNP, Nitro) isn’t directly verifiable across chains and is expensive to check on L1.
Pattern: Convert the attestation to a proof once; verify cheaply anywhere. Phala integrated with zkVerify so SP1/R0 proofs of TEE attestations verify natively without Groth16 wrapping—cutting generation costs ~20% and gas >90% compared to direct Ethereum verification. (zkverify.io)

Multiprover consensus: use TEEs to cross‑check ZK provers

Pattern: Run a ZK prover and a TEE prover in parallel. ZKsync’s multi‑prover architecture uses TEE proofs to both accelerate and double‑check ZK results; public tools verify the TEE proof + attestation of block roots. If either path disagrees, halt. (zksync.mirror.xyz)

Confidential AI with composite attestation and ZK receipts

Pattern: Run inference inside a TDX/SEV‑SNP CVM with H100 CC; produce a composite attestation (CPU+GPU) via Intel Trust Authority/NRAS; post a ZK “receipt” that binds inputs/weights hashes to outputs for audit without leaking IP. GPU device certs (ECC‑384) and OCSP revocation checks underpin hardware identity; the ZK receipt makes results portable on‑chain. (docs.trustauthority.intel.com)

TEE rollups with ZK escape hatches

Pattern: Execute rollup blocks in heterogeneous TEEs for low fees and near‑instant withdrawals; backstop with a challenge mechanism and ZK fallbacks. TEERollup shows 86% lower on‑chain verification cost vs. ZK‑only and withdrawals in minutes—if TEEs fail liveness or integrity, switch to ZK proof mode. (arxiv.org)

TEE off‑chain coprocessors + ZK bridge verification

Pattern: Orchestrate off‑chain contract execution in TEEs, then prove correctness with ZK to consumer chains. Academic systems like RaceTEE decouple ordering from (TEE) execution, add key rotation for forward/backward secrecy, and remain compatible with existing chains—while still gating results behind proof checks. (arxiv.org)

Security reality check: where trust ends

Don’t assume untouchable enclaves. TEE.fail and WireTap showed that with DDR bus interposers, attackers could exfiltrate keys or forge attestations on some Intel server platforms, and highlighted weaknesses in early GPU CC attestation binding. Your design must withstand “attestation lies” and enforce heterogeneity and rotation. (wiretap.fail)
Production responses in the wild: Oasis launched a public “break the TEE” bounty on its Sapphire confidential EVM to demonstrate defense‑in‑depth; Secret Network and others documented mitigations like operator gating and seed rotation after WireTap/TEE.fail disclosures. Design for committee‑level controls and rapid key rotation at minimum. (oasis.net)

Best emerging practices for TEE + ZK in 2025

Normalize attestation to EAT and CoRIM

Build your verifier around IETF RATS EAT claims. Use CoRIM profiles (e.g., for SEV‑SNP) to manage reference values. This makes your pipeline vendor‑ and cloud‑portable. (datatracker.ietf.org)

Prefer composite attestation for AI stacks

For GPU workloads, require composite CPU+GPU attestation; validate GPU quotes via NRAS and CPU via Intel Trust Authority (or cloud verifiers), then pin the resulting JWT/EAT in your ZK circuit or verification layer. (docs.trustauthority.intel.com)

Heterogeneous committees by default

Mix TDX, SEV‑SNP, and (where available) Arm CCA nodes; require a threshold of mutually independent TEEs to sign. TEERollup’s “heterogeneous TEE” approach is a realistic model to reduce correlated vendor failure. (arxiv.org)

Rotate keys inside enclaves and bind to measured code

Implement short‑lived, enclave‑generated signing keys sealed to measurements; bind decryption to PCRs/EIF hashes (AWS KMS conditions) or launch measurements (SEV‑SNP). Automatically invalidate on code or policy change. (docs.aws.amazon.com)

Make verification cheap and universal

Use verification layers (Aligned) or zkVerify to slash gas and enable cross‑chain consumption of TEE attestations or outputs. Plan for 2.1k–300k gas per check rather than bespoke verifiers. (blog.alignedlayer.com)

Assume patch velocity, not perfection

Track and roll OEM mitigations (e.g., AMD SEV‑SNP bulletins) and lock CI/CD to firmware baselines. Treat a TEE failure like a byzantine node: slash, rotate, and fall back to ZK mode. (amd.com)

Treat cloud verifiers as a component, not a root of truth

Google Cloud Attestation emits EAT tokens; AWS Nitro emits COSE‑signed CBOR with PCRs; Azure supports TDX/SEV‑SNP. Verify externally and then ZK‑wrap for on‑chain use. (docs.cloud.google.com)

A concrete 90‑day plan to ship a hybrid

Week 0–2: Choose your trust base

Workload: confidential AI inference or off‑chain compute? If GPU, select H100 CC. If CPU‑only, pick TDX on Azure or SEV‑SNP on AWS/GCP. Validate region/instance availability. (developer.nvidia.com)
Standardize attestation: settle on EAT for tokens and CoRIM for reference values.

Week 3–5: Build the enclave and attest

Provision Confidential VM (TDX/SEV‑SNP) and enable H100 CC if needed. Fetch the GPU device cert and verify via OCSP; integrate NRAS. For CPU, integrate Intel Trust Authority or cloud verifier to mint a composite JWT/EAT. Pin measurements in code. (developer.nvidia.com)
Add key policies: if on AWS Nitro or KMS, bind decrypt permissions to PCRs and EIF hash; otherwise, bind to launch/measurement values (SEV‑SNP). (docs.aws.amazon.com)

Week 6–8: Wrap with ZK

Pick SP1 zkVM; implement a circuit/program that checks: (a) attestation signature and chain (EAT/COSE); (b) workload input/weights hashes; (c) output digest. Output a succinct proof. Gas target: ~275k for direct EVM verify or ~2.1k/proof via Aligned. (succinct.xyz)

Week 9–12: Harden for failure and scale

Operate a heterogeneous committee (TDX + SEV‑SNP); enforce 2‑of‑3 threshold signatures for “enclave receipts.” Add telemetry and periodic liveness/attestation challenges (e.g., Automata’s TEE liveness contracts for operator gating). (github.com)
Put a “break‑glass” ZK fallback: if attestation fails or committees degrade, switch to ZK‑only verification of the computation and slow down gracefully—no downtime, just different trust/latency trade‑offs.

Example: confidential LLM inference with composite attestation + ZK receipt

Compute: TDX CVM on Azure with H100 CC.
Attestation:
- CPU: TDX evidence → Intel Trust Authority (ITA).
- GPU: NRAS validates the H100 quote.
- ITA returns a composite JWT with CPU+GPU claims. (docs.trustauthority.intel.com)
Policy: Only workloads with the expected MRENCLAVE/MRCONFIGID (or CVM launch measurements) and GPU firmware baseline can fetch model weights from KMS; OCSP must show device cert not revoked. (developer.nvidia.com)
ZK: SP1 program checks (1) composite JWT signature and claim set; (2) SHA‑256 of input prompt and model hash; (3) final token logits hash. Publish proof via Aligned to cut verification gas ~90% vs. raw verifier. (succinct.xyz)
Outcome: Sub‑second inference off‑chain; on‑chain receipt proving “this output came from the attested H100+TDX stack running model X on input Y,” portable across L1/L2s.

Hidden gotchas (learned the hard way)

“Attested garbage” is still garbage. Your verifier must pin exact image/measurement IDs and policy versions. Don’t accept “debug‑mode” attestation or stale CRLs/OCSP. Nitro debug PCRs zero out; treat them as invalid. (docs.aws.amazon.com)
Composite isn’t a magic word. Ensure the CPU enclave actually binds GPU identity (session keys, channel binding) and that your claims include GPU serial and measurement digests—otherwise a “borrowed GPU report” style attack can slip through. (developer.nvidia.com)
Key rotation is a feature, not a risk. Rotate enclave keys per boot and seal new keys to measurements. Several academic designs (e.g., RaceTEE) enforce forward/backward secrecy after breaches—mirror that in prod. (arxiv.org)
Firmware drift breaks proofs. Embed CoRIM‑managed reference values into CI and fail builds if measurements change without policy updates. (ietf.org)

When to use what (a simple decision rule)

You need private state and speed (sub‑second): start in a TEE; add a ZK receipt so results can be verified anywhere, cheaply.
You need long‑lived, cross‑chain guarantees: start ZK‑first; add TEEs to accelerate proving or for privacy during preprocessing.
You need both: deploy a multi‑prover/heterogeneous committee with a ZK escape hatch and composite attestation for accelerators.

A few real‑world touchpoints to emulate

zkSync’s multi‑prover: ZK + TEE validators and open‑source attestation verification for block roots. Emulate this defense‑in‑depth for rollups. (zksync.mirror.xyz)
Phala x zkVerify: ZK‑verifying TEE attestations directly (SP1/R0) without Groth16 wrapping; a template for turning vendor‑specific reports into universal receipts. (zkverify.io)
GPU CC in prod: H100 CC with NRAS + composite attestation via Intel Trust Authority—blueprint for confidential AI stacks. (docs.trustauthority.intel.com)
Research‑backed designs: TEERollup (heterogeneous TEE committees + challenges), RaceTEE (key rotation + inter‑contract interactions) to build “TEE‑first, ZK‑secured” systems. (arxiv.org)

The 7Block Labs take

The line between trust and verification is now an engineering choice, not a binary. The winning architectures in 2025 treat TEEs as fast, private execution substrates and use ZK—and increasingly, verification layers—to make results universally checkable and cheap to consume on‑chain. If you’re building confidential AI, financial infrastructure, or verifiable off‑chain compute, design as if attestations can lie, proofs can be delayed, and hardware can drift. Then combine composite attestation, heterogeneous committees, and ZK receipts to keep shipping through any of it.

Want a second set of eyes on your roadmap, or a hands‑on build for a pilot in 90 days? That’s what we do.

References and sources cited

NVIDIA H100 Confidential Computing and NRAS, GA details and device identity. (developer.nvidia.com)
Intel Trust Authority composite CPU+GPU attestation with NRAS. (docs.trustauthority.intel.com)
Cloud attestation: GCP EAT tokens; AWS Nitro COSE/CBOR PCRs; Azure Confidential VMs (TDX/SEV‑SNP). (docs.cloud.google.com)
IETF RATS EAT, KAT, CoRIM for SEV‑SNP. (datatracker.ietf.org)
TEE.fail and WireTap attacks and vendor acknowledgments. (wiretap.fail)
ZK verification economics and zkVM performance (Aligned, SP1). (blog.alignedlayer.com)
ZK + TEE in practice (zkSync TEE proofs; Phala x zkVerify). (zksync.mirror.xyz)
TEERollup, RaceTEE. (arxiv.org)