ZK vs FHE vs MPC vs TEE: How to Choose in 2026

Four technologies now compete for the same architecture slide: zero-knowledge proofs, fully homomorphic encryption, secure multi-party computation, and trusted execution environments. They are routinely presented as interchangeable "privacy tech", which they are not. They answer different questions, cost wildly different amounts, and fail in different ways. This post is the comparison we wish existed when clients ask "which one do we need": trust models, honest 2026 performance numbers, and the EU regulations that increasingly force the choice. For the full build methodology, start with our pragmatic guide to ZK and FHE.

Engineering perspective, not a vendor pitch. All figures are sourced or labeled as rules of thumb. Reference points come from Wavect's zero-knowledge and frontier-tech work.

What does each technology actually do?

• Zero-knowledge proofs (ZK): prove a statement is true without revealing the evidence. The verifier learns "this person is over 18" or "this computation ran correctly", nothing else. See our glossary and production deep dive.
• Fully homomorphic encryption (FHE): compute on encrypted data. The server processing your query never sees the query, the data, or the result. Deep dive: what ships in FHE.
• Secure multi-party computation (MPC): several parties jointly compute a result over inputs none of them reveal. Three hospitals compute a joint statistic; no hospital sees another's patients.
• Trusted execution environments (TEE): hardware-isolated enclaves (Intel TDX, AMD SEV-SNP, NVIDIA confidential GPUs) that run plaintext computation invisible even to the cloud operator, with a cryptographic attestation that the expected code is running.

The cleanest way to order them is by what you are asked to trust. ZK trusts only the soundness of a proof system. FHE trusts lattice cryptography. MPC trusts that a threshold of the participating parties does not collude. TEE trusts a chip vendor's design and supply chain, plus the ongoing absence of side-channel breaks. Each step of added trust buys you between one and four orders of magnitude in performance. Architecture is choosing your rung, not maximizing security in the abstract.

Which four questions pick the technology?

1. Who must not see the data? If the answer is "nobody outside our company", stop: access control, TLS, and encryption at rest solve this, and every technology on this page is overkill. If the answer is "the operator of the computation", keep reading.
2. Is the core need verification or computation? If a third party needs to check something (an age, a reserve, a computation's integrity), that is ZK, full stop. If an untrusted party needs to compute something on hidden data, it is FHE, MPC, or TEE.
3. How big is the hidden computation? A lookup, a score, a small model: FHE is on the table. A data pipeline, an LLM, anything a user waits on interactively: realistically TEE, because the FHE overhead of 1,000x to 10,000x does not close.
4. How many independent parties hold the inputs? One client and one server favors FHE or TEE. Multiple mutually distrusting organizations with decent network links between them favors MPC, which was built for exactly that shape and struggles across the public internet where its communication costs bite.

How do they compare side by side?

"Nobody gets fired for picking a TEE, and mostly they are right. The expensive mistakes happen when a team picks FHE for a workload a TEE should carry, or a TEE for a promise only math can keep."

How good are TEEs now, honestly?

Good enough that they are the default answer for confidential compute at scale, which is exactly why the cryptographic options need a clear justification to displace them:

• CPU enclaves matured. Intel TDX and AMD SEV-SNP moved the unit of isolation from the process to the whole VM, cutting integration cost dramatically versus the old SGX model. Overhead on typical workloads sits in the low-to-mid single-digit percent range, with memory-bound and very small workloads paying more.
• GPUs joined. NVIDIA's H100 was the first confidential-computing GPU, extended through the H200 and Blackwell generations. Confidential LLM inference is now shipping as cloud products, with fine-tuning possible on the same confidential-GPU VMs, and overhead often dominated by encrypted PCIe transfers rather than compute (arXiv 2505.16501).
• The trust catch remains. A TEE proves you are running the expected code on genuine hardware. It cannot protect you from a compromised vendor, certain physical attacks, or the steady drip of published side-channel papers. For most commercial threat models that residual risk is acceptable. For "we must be unable to comply with a subpoena for user data", it is not, and that is precisely the line where FHE and MPC earn their overhead.

Why is the winning pattern compose, not pick?

The strongest 2026 architectures stack these tools instead of choosing one:

• TEE for the bulk, cryptography for the core. Run the heavy pipeline in a confidential VM, and reserve FHE or MPC for the small, high-stakes computation where hardware trust is unacceptable.
• ZK on top for verifiability. A TEE or MPC cluster computes; a ZK proof convinces outsiders the computation was correct without re-running it. Verification stays cheap for everyone downstream.
• Real example shapes: a confidential-GPU inference service that returns a ZK attestation of which model version ran; an MPC consortium whose result ships with a proof regulators can check; an FHE lookup inside an otherwise conventional app, which is literally how Apple ships it.

Projects like Nillion orchestrate MPC, HE, and ZK behind one developer surface, and the "TEE as cheap harness around cryptographic cores" pattern shows up across serious deployments. Composition also de-risks the roadmap: you can start on a TEE this quarter and swap the core to FHE when the numbers close, without rewriting the product.

What does EU regulation force, and when?

For EU-facing products, regulation is quietly making this menu mandatory reading:

• eIDAS 2.0 / EUDI Wallet, deadline end of 2026. Every member state must offer a digital identity wallet, built around selective disclosure. That is ZK's home turf. One sharp edge: the advanced unlinkable schemes (BBS-family, ZK-SNARK credentials) are not yet SOG-IS-approved, which currently keeps them out of public-sector deployments; the details are in our ZK deep dive.
• EHDS (European Health Data Space). Secondary use of health data explicitly leans on privacy-enhancing technologies, pulling HE, MPC, and federated patterns into health-data platforms.
• GDPR. Whether FHE-processed or ZK-verified data counts as anonymized is a live legal debate, not settled doctrine. PETs strengthen your Article 25 data-protection-by-design story; they do not automatically remove data from GDPR scope. Get counsel involved before marketing claims outrun the law. Our post on EU data residency for AI apps covers the adjacent territory.
• Finance (DORA) and the AI Act add resilience and governance pressure that favors attestable, confidential infrastructure, which in practice means TEEs first and cryptographic upgrades where supervisors demand stronger guarantees.

The pattern across all of it: regulators are not mandating specific cryptography, they are mandating properties (minimization, selective disclosure, confidentiality) that this toolbox happens to be the only way to deliver at scale.

When does plain access control win?

More often than this post's existence suggests. Choose boring technology when:

• All parties handling the data already trust each other contractually (one company, one DPA, one cloud).
• The privacy promise is marketing, not architecture. Users rarely pay for cryptographic guarantees they cannot perceive; they pay for products that work.
• The sensitive computation is large, interactive, and latency-bound, and no regulation forces the issue. A TEE plus strict IAM plus audit logging is a defensible, shippable answer.
• Your team cannot yet operate the observability, key management, and audit cadence that cryptographic deployments demand. The math is the easy part; the operational maturity is the hard part.