TEE + ZK: Where Trust Ends and Verification Begins

A quick rundown: By 2025, confidential computing (think TEEs) really leveled up and came together with zero-knowledge verification in an exciting way. This guide is here to help decision-makers figure out when to trust the hardware, when to lean on the math, and how to roll out hybrid TEE+ZK systems that are speedy, trustworthy, and ready to go for production.

TL;DR

TEEs are great for providing speed and a private state, while ZK allows for portable, cryptographic verification. Essentially, use TEEs when you need fast and confidential computing, and go with ZK when you want reliable, on-chain verification. They really shine when the trust boundary starts to get shaky--mix them together for the best results!
What’s the scoop? Well, GPU TEEs are officially a thing now (hello, NVIDIA H100), and they can easily work alongside CPUs for attestations. Plus, major cloud providers are rolling out EAT-style attestations. On top of that, verification layers for ZK proof checks are getting a serious price cut--about 90% less! Oh, and just a heads up--physical interposer attacks are a real concern for some server-grade TEEs. So, it’s smart to plan for potential compromises and ensure solid verification. (developer.nvidia.com)

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

GPU TEEs are now up for general access! The NVIDIA H100 Confidential Computing has added some cool new features like attestation using device ECC‑384 identity, OCSP revocation, and their own Remote Attestation Service (NRAS). It works under a CPU TEE (TDX/SEV‑SNP) and is now part of composite attestation. This is a big deal for keeping AI inference and training secure. Check it out here: (developer.nvidia.com)
Intel Trust Authority has rolled out composite CPU+GPU attestation, where Intel verifies the CPU TEE evidence and NRAS handles the GPU quote, resulting in a combined JWT. Initially, this support is aimed at on-prem H100 setups, but cloud GPU attestation is definitely in the pipeline. More details are available here: (docs.trustauthority.intel.com)
Cloud TEEs have standardized their outputs, too. Google Cloud Attestation now issues RATS‑conformant EAT tokens for Confidential VM/Space (SEV, SEV‑SNP, TDX). AWS Nitro Enclaves provide COSE-signed, CBOR attestation docs complete with PCRs. Meanwhile, Azure is rolling out TDX and SEV‑SNP Confidential VMs in various regions. You can find out more here: (docs.cloud.google.com)
On the security front, new attacks are raising the stakes. The “WireTap” and later “TEE.fail” demonstrated some pretty serious physical DDR bus interposer attacks that could trick SGX/TDX attestations and take advantage of gaps in GPU CC attestation. This underscores the need for solid defense-in-depth and heterogeneous trust models. Vendors pointed out that these types of physical attacks are technically out-of-scope, but your system should be prepared. More info can be found here: (wiretap.fail)
Finally, ZK verification layers and zkVMs are making big strides in production economics. Aligned’s verification layer has brought down on-chain proof verification to about 2.1k gas/proof with batchers. The SP1 zkVM has rolled out 275k-gas EVM verifiers and sub-cent proving with GPU acceleration. Now, ecosystems are routinely verifying Ethereum blocks using ZK technology. Get the scoop here: (blog.alignedlayer.com)

The modern TEE stack: 2025 buyer’s snapshot

CPU TEEs You Can Deploy Today
- Intel TDX: This one’s all about confidential VMs, and it’s got composite attestation backed by Intel Trust Authority. Check it out here.
- AMD SEV‑SNP: You can find this across platforms like AWS EC2 and GCP. It uses VLEK and launch measurements for attestation, plus you can find CoRIM profiles published at IETF. More info here.
- Arm CCA: This one features Realms and the Realm Management Monitor (TF‑RMM), which set a standard for confidential VMs on the Arm architecture. You can get the open-source firmware over at TrustedFirmware.org. Dive deeper here.
- AWS Nitro Enclaves: Attestation documents here are signed by AWS Nitro PKI, and you can set up KMS policies to bind to PCRs and the EIF hash, which helps with least-privilege decryption. Learn more here.
GPU TEEs
- NVIDIA H100 “Confidential Computing”: This nifty setup includes device identity certificates, NRAS for report validation, OCSP revocation checks, and works hand in hand with CPU TEEs to create secure channel setups and composite attestations. You can read more about it here.
Attestation formats and standards
- The IETF RATS and EAT (Entity Attestation Token) are shaping the way we think about standard claims in CWT/JWT. Plus, there are some exciting developments like KAT (Key Attestation Token) and CoRIM profiles tailored for SEV-SNP that really help streamline how verifiers are set up. It’s a good idea to design your verifier using EAT profiles to steer clear of being locked in. Check it out here: (datatracker.ietf.org)
Where to run
- You’ve got a few options for running your workloads: Azure Confidential VMs (TDX/SEV‑SNP), Google Confidential VM/Space (TDX/SEV‑SNP), and AWS Nitro Enclaves (with TPM/NitroTPM PCRs). Each of these comes with its own unique attestation APIs, so you'll want to think about planning for some adapters. (learn.microsoft.com)

The ZK stack you can deploy this quarter

zkVMs and coprocessors
- SP1 zkVM: It’s all about super-fast STARK recursion! This one's got a SNARK wrap that runs at roughly 275k gas on the EVM. Plus, the GPU prover is aiming for those sub-cent costs per average Ethereum block transaction. Check it out here: (succinct.xyz)
- Proof verification layers
  - Aligned Layer: This bad boy is capable of batch verifying thousands of proofs while keeping security restaked. We’re talking about around 2,100 gas per proof in the mainnet beta, and it’s been audited by several firms. Use this to keep your TEE-to-ZK handoffs nice and affordable! More details can be found here: (blog.alignedlayer.com)
Emerging practice: “verification off‑chain, result on‑chain.” Use verification layers or app‑chains to confirm proof checks and then post compact receipts to Ethereum. This acts as the connective tissue for TEE→ZK pipelines. (alignedlayer.com)

Five TEE + ZK patterns that actually ship

1) ZK‑attested TEEs: Making Attestation Verifiable Everywhere

The Problem: If you’re dealing with vendor-specific TEE attestation like SGX/DCAP, TDX, SEV‑SNP, or Nitro, you know it’s a hassle. These attestations aren’t easily verifiable across different chains, and checking them on Layer 1 can really cost a pretty penny.
The Solution: Here’s a neat approach: transform the attestation into a proof just once, and then you can verify it affordably anywhere. Phala has teamed up with zkVerify, so now SP1/R0 proofs of TEE attestations can verify natively without all that Groth16 wrapping. This partnership slashes generation costs by about 20% and gas fees by over 90% compared to direct Ethereum verification. Check out more details here.

2) Multiprover Consensus: Using TEEs to Cross-Check ZK Provers

Pattern: Here’s how it works: you run a ZK prover alongside a TEE prover at the same time. ZKsync’s nifty multi-prover setup harnesses TEE proofs to speed things up and verify the ZK results. Public tools then take on the task of verifying both the TEE proof and the block root attestation. If there’s any disagreement between the two, everything stops in its tracks. You can read more about it here.

3) Confidential AI with Composite Attestation and ZK Receipts

Pattern: Run inference in a TDX/SEV-SNP CVM using H100 CC. You'll want to generate a composite attestation (that’s CPU + GPU) through Intel Trust Authority/NRAS. After that, you can post a ZK “receipt” that connects the hashes of inputs and weights to the outputs. This way, you can audit everything without spilling any proprietary info. Plus, GPU device certs (ECC-384) and OCSP revocation checks really help establish the hardware identity. The cool part? The ZK receipt makes it easy to carry your results on-chain. Check it out here: (docs.trustauthority.intel.com)

4) TEE Rollups with ZK Escape Hatches

Pattern: Here’s the deal: you can run rollup blocks in different trusted execution environments (TEEs) to enjoy super low fees and almost instant withdrawals. Plus, there’s a challenge mechanism and ZK fallbacks to keep everything secure. TEERollup brings down on-chain verification costs by an impressive 86% compared to just using ZK, and you can get your withdrawals processed in just minutes. If the TEEs ever have issues with liveness or integrity, you can easily switch to ZK proof mode. Check out the research here.

TEE Off-Chain Coprocessors + ZK Bridge Verification

Here's the deal: we're talking about running off-chain contract executions within Trusted Execution Environments (TEEs) and then using zero-knowledge proofs (ZK) to confirm everything checks out for the consumer chains. There are some smart academic models out there, like RaceTEE, that really break things down. They separate the order of operations from what’s happening in the TEE, incorporate key rotation for both forward and backward secrecy, and ensure everything works seamlessly with existing chains. And don’t worry, results are still gated behind proof checks. You can dive deeper here: (arxiv.org)

Security reality check: where trust ends

Don't think that there are safe spaces out there. TEE.fail and WireTap showed us that with DDR bus interposers, attackers can sneak in to steal keys or even fake attestations on certain Intel server platforms. Plus, they highlighted some flaws in early GPU CC attestation binding. So it’s super important that your design can handle “attestation lies” and make sure to enforce diversity and rotation. Check it out here: (wiretap.fail)
Real-world responses are happening: Oasis kicked off a public “break the TEE” bounty challenge on its Sapphire confidential EVM to really put defense-in-depth to the test. Meanwhile, Secret Network and a few others have come up with strategies like operator gating and seed rotation after the WireTap/TEE.fail revelations. It’s wise to design for committee-level controls and ensure quick key rotation at the very least. For more details, head over to (oasis.net).

Best emerging practices for TEE + ZK in 2025

Normalize attestation to EAT and CoRIM

Design your verifier based on IETF RATS EAT claims. Utilize CoRIM profiles (like the one for SEV‑SNP) to handle your reference values. This approach keeps your pipeline flexible and portable across different vendors and clouds. (datatracker.ietf.org)

Go for composite attestation for your AI stacks

When dealing with GPU workloads, make sure to use composite CPU+GPU attestation. You’ll want to validate the GPU quotes through NRAS and the CPU via Intel Trust Authority (or cloud verifiers). After that, don’t forget to pin the resulting JWT/EAT in your ZK circuit or verification layer. Check out this link for more details: (docs.trustauthority.intel.com)

3) Heterogeneous Committees by Default

Combine TDX, SEV‑SNP, and, where possible, Arm CCA nodes, and set a threshold for a minimum number of mutually independent TEEs needed to sign. TEERollup’s “heterogeneous TEE” strategy offers a practical way to minimize the risk of correlated vendor failures. (arxiv.org)

4) Rotate keys inside enclaves and bind to measured code

Use short-lived signing keys that are generated by the enclave and sealed to specific measurements. Ensure that decryption is linked to PCRs/EIF hashes (just like with AWS KMS) or launch measurements (think SEV-SNP). Make sure these keys automatically become invalid if there’s any code or policy change. Check out the details here!

Keep verification affordable and accessible

Leverage verification layers like Aligned or zkVerify to significantly cut down on gas fees and allow for cross-chain use of TEE attestations or outputs. Aim for around 2.1k to 300k gas per check instead of creating custom verifiers. (blog.alignedlayer.com)

Assume patch velocity, not perfection

Keep an eye on OEM mitigations (like those AMD SEV‑SNP bulletins), and make sure to tie your CI/CD to firmware baselines. If a TEE fails, think of it as a byzantine node: cut it off, rotate it out, and switch over to ZK mode. (amd.com)

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

Google Cloud Attestation dishes out EAT tokens, while AWS Nitro rolls out COSE-signed CBOR with PCRs. Azure’s got your back with TDX/SEV-SNP support. It’s best to verify everything externally and then ZK-wrap it for on-chain use. Check out the details in the official docs.

A concrete 90‑day plan to ship a hybrid

Week 0-2: Pick Your Trust Base

Workload: Are you leaning towards confidential AI inference or off-chain compute? If you’re going with GPU, make sure to choose the H100 CC. If you’re sticking to CPU-only, go for TDX on Azure or SEV-SNP on AWS/GCP. Don’t forget to check the availability of your chosen region and instance. (developer.nvidia.com)
Standardize Attestation: Let’s get on the same page with EAT for tokens and CoRIM for reference values.

Week 3-5: Build the Enclave and Attest

First off, let's get that Confidential VM up and running (TDX/SEV-SNP) and turn on H100 CC if it's needed. Grab the GPU device certificate and check it out with OCSP; don’t forget to integrate NRAS. For the CPU side of things, connect with Intel Trust Authority or a cloud verifier to create a composite JWT/EAT. Make sure to pin those measurements right in your code. You can read more about it here.
Next, let’s set up some key policies. If you’re using AWS Nitro or KMS, you’ll want to tie those decrypt permissions to PCRs and the EIF hash. If not, just bind them to the launch and measurement values (SEV-SNP). You can find detailed guidance on this here.

Week 6-8: Wrap with ZK

Choose the SP1 zkVM and get started on a circuit/program that verifies: (a) the attestation signature and chain (EAT/COSE); (b) the workload input/weights hashes; (c) the output digest. Make sure to generate a succinct proof. Aim for a gas target of around 275k for direct EVM verification or about 2.1k/proof with Aligned. Check out more at succinct.xyz.

Week 9-12: Getting Ready for Failure and Scaling Up

Set up a mix-and-match committee (think TDX + SEV-SNP); make sure to enforce a 2-of-3 threshold for those “enclave receipts.” It’s also time to add some telemetry and implement periodic liveness/attestation challenges. You could check out Automata’s TEE liveness contracts for operator gating right here.
Introduce a “break-glass” ZK fallback: If we hit issues with attestation or if the committees start to fall apart, we can seamlessly switch to ZK-only verification for the computation. This way, we can scale back a bit without any downtime--just adjusting our trust and latency trade-offs.

Example: confidential LLM inference with composite attestation + ZK receipt

Compute: We're kicking things off with TDX CVM on Azure using H100 CC.
Attestation:
- For the CPU, we gather TDX evidence and send it to the Intel Trust Authority (ITA).
- On the GPU side, NRAS steps in to validate the H100 quote.
- After all that, ITA gives us back a composite JWT that includes both CPU and GPU claims. You can dive deeper into this here.
Policy: Now, only the workloads that match the expected MRENCLAVE/MRCONFIGID (or CVM launch measurements) along with the GPU firmware baseline are allowed to snag model weights from KMS. Plus, we need to make sure that the OCSP indicates the device certificate hasn't been revoked. Check out more on this link.
ZK: The SP1 program runs a few checks: (1) it verifies the composite JWT signature and claim set; (2) it hashes the input prompt and models using SHA‑256; (3) it hashes the final token logits. We publish the proof via Aligned, which helps cut down verification gas costs by about 90% compared to a raw verifier. If you're curious, read about it here.
Outcome: In the end, we achieve sub-second inference off-chain, and we get an on-chain receipt that says, “this output came from the attested H100+TDX stack running model X on input Y,” and it’s portable across both L1 and L2s.

Hidden gotchas (learned the hard way)

Let’s be real: “attested garbage” is still garbage. Make sure your verifier pins down the exact image/measurement IDs and policy versions. Don't buy into “debug-mode” attestations or rely on outdated CRLs/OCSP. Nitro debug PCRs zero out, so just toss those as invalid. (docs.aws.amazon.com)
Remember, "composite" isn’t a magic term. You’ve got to check that the CPU enclave is really linking to the GPU identity (session keys, channel binding) and ensure your claims cover the GPU serial and measurement digests. If you skip this, you might fall victim to a sneaky “borrowed GPU report” style attack. (developer.nvidia.com)
Key rotation? Totally a feature, not a risk! Rotate those enclave keys every time you boot and seal the new keys with the measurements. Some academic designs, like RaceTEE, keep things secure by enforcing both forward and backward secrecy after breaches--definitely something to replicate in production. (arxiv.org)
Firmware drift? That can really mess up your proofs. Make it a habit to embed CoRIM-managed reference values into your CI, and make sure to fail builds if measurements change without policy updates. (ietf.org)

When to use what (a simple decision rule)

If you want private state and super quick speed (we're talking sub-second here): kick things off in a TEE, then throw in a ZK receipt to make sure results are easily verifiable no matter where you are.
Looking for long-lasting, cross-chain guarantees? Start with a ZK-first approach and then incorporate TEEs to speed up the proving process or keep things private during that preprocessing phase.
Need a mix of both? Go for a multi-prover/heterogeneous committee that includes a ZK escape hatch and composite attestation for those accelerators.

A few real‑world touchpoints to emulate

zkSync’s multi‑prover: This combines ZK + TEE validators along with open-source attestation verification for block roots. Think of it as a defense-in-depth approach tailored for rollups. Check it out here!
Phala x zkVerify: They’re taking ZK-verifying TEE attestations straight to the next level (SP1/R0), skipping over Groth16 wrapping. It’s like a playbook for transforming vendor-specific reports into universal receipts. Read more about it here!
GPU CC in production: We’ve got the H100 CC with NRAS plus composite attestation through Intel Trust Authority--this sets up a solid framework for confidential AI stacks. Dive deeper into the details here!
Research-backed designs: Take a look at TEERollup, which features heterogeneous TEE committees and challenges, and RaceTEE, focusing on key rotation along with inter-contract interactions. These efforts are paving the way for “TEE-first, ZK-secured” systems. More info is available here!

The 7Block Labs take

The distinction between trust and verification has shifted; it’s more about engineering choices now than a simple yes-or-no. By 2025, the best architectures will see TEEs as quick and private execution environments, leveraging ZK technology--and more frequently, verification layers--to ensure that results are easy to verify and cost-effective to access on-chain. If you’re diving into building confidential AI, financial systems, or reliable off-chain computations, approach it with the mindset that attestations could be misleading, proofs might take a while, and hardware could become unreliable. To navigate these challenges, mix in composite attestations, diverse committees, and ZK receipts to keep your projects rolling, no matter what.

Need someone to take a look at your roadmap, or want us to help you create a pilot in just 90 days? That's exactly what we’re here for!

References and sources cited

Check out NVIDIA's H100 for Confidential Computing, which dives into the details of NRAS, GA, and device identity. You can read more about it here.
Intel's got a cool thing going with their Trust Authority, combining CPU and GPU attestation alongside NRAS. If you want to dig deeper, hit up their documentation here.
When it comes to cloud attestation, don’t miss out on GCP EAT tokens, AWS Nitro COSE/CBOR PCRs, and Azure's Confidential VMs (TDX/SEV‑SNP). Check out the full scoop here.
IETF has some interesting stuff with RATS EAT, KAT, and CoRIM specifically for SEV‑SNP. Learn more about it here.
Don't forget to look into TEE.fail and WireTap attacks along with the vendor responses. It's all laid out here.
If you're curious about ZK verification economics and zkVM performance, check out what Aligned has to say about it here.
For a practical take on ZK + TEE, look into zkSync TEE proofs and the collaboration between Phala and zkVerify. More info is available here.
Lastly, you might want to check out TEERollup and RaceTEE for some fresh insights. Find the details here.