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, have different cost structures, and fail in different ways. This post compares the trust models, benchmark-dependent 2026 performance, and EU regulatory properties that influence 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 without revealing the selected witness data. The verifier can learn "this person is over 18" or "this computation ran correctly", plus the proof's public inputs and observable metadata. See our glossary and production deep dive.
• Fully homomorphic encryption (FHE): compute on encrypted inputs so the evaluator handles ciphertext rather than the protected plaintext. What remains hidden depends on the function, public inputs, output recipient, and key custody. Deep dive: what ships in FHE.
• Secure multi-party computation (MPC): several parties jointly compute over private inputs while each knows its own input and learns the protocol's authorized output. Privacy depends on the protocol's threshold and corruption assumptions.
• Trusted execution environments (TEE): hardware-isolated environments such as Intel TDX, AMD SEV-SNP, and NVIDIA confidential GPUs. They are designed to protect in-use code and data from the host outside the trusted boundary; attestation supplies evidence about the measured hardware and software state, subject to the platform's trust chain.

The cleanest comparison starts with what you are asked to trust. ZK depends on proof-system assumptions and the correctness of the circuit, compiler, implementation, setup, and verifier. FHE depends on scheme assumptions, parameter selection, implementation, and key handling. MPC adds a protocol-specific threshold and non-collusion assumption. A TEE adds trust in the chip, firmware, attestation chain, cloud integration, and side-channel defenses. No fixed performance multiplier follows from those assumptions. Architecture is choosing the boundary that matches the threat model, then benchmarking the concrete stack.

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, or a small model can put FHE on the table. A large data pipeline or interactive model is usually a TEE candidate first, unless an end-to-end FHE benchmark on the exact workload closes the latency and cost budget.
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, reducing integration work versus the old SGX model. Published overhead varies with virtualization, memory, I/O, attestation, and workload shape, so low-single-digit results should not be treated as a universal planning number.
• 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. Attestation can show that expected code is running on recognized hardware, subject to the platform's attestation and supply-chain assumptions. It cannot remove every vendor, physical, firmware, operator, or side-channel risk. Whether that residual risk is acceptable is architecture- and jurisdiction-specific. Legal resistance claims require counsel and a complete data-flow analysis, not only a TEE product choice.

Why is the winning pattern compose, not pick?

Some 2026 architectures stack these tools instead of choosing only 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.
• Architecture patterns to evaluate: a confidential-GPU inference service paired with verifiable model identity; an MPC consortium whose result can be checked by an external verifier; or an HE lookup inside an otherwise conventional app, similar to Apple's documented private-lookup pattern.

Projects like Nillion orchestrate MPC, HE, and ZK behind one developer surface, and hybrid designs are increasingly common. Composition can de-risk a roadmap only when interfaces, key ownership, data formats, and fallback semantics are designed for substitution from the start. Moving from a TEE to FHE is not automatically a drop-in swap.

What does EU regulation force, and when?

For EU-facing products, regulation makes the security properties mandatory reading, but usually does not mandate one of these technologies:

• eIDAS 2.0 / EUDI Wallet, availability due by the end of 2026. Every member state must provide at least one wallet within 24 months of the relevant implementing acts. Current official technical work evaluates BBS-family and circuit-based ZK paths, while July 2026 amendments show that standards, certified hardware, assurance levels, and national implementation continue to evolve. Do not infer a blanket approval or ban from an exploratory specification.
• EHDS (European Health Data Space). Secondary use of health data requires controlled access, pseudonymization or anonymization where appropriate, and secure processing environments. HE, MPC, federated learning, and TEEs may help satisfy those properties, but the regulation does not prescribe one of them as the implementation.
• 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, risk-management, evidence, and governance obligations. They do not mandate TEEs, ZK, FHE, or MPC. Select the control from the regulated process and document how it satisfies the required property.

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.

Sources and verification

1. Mopro (2026). Circuit-specific proving and verification benchmarks. zkmopro.org
2. Apple Machine Learning Research (2024). Production HE and private information retrieval. machinelearning.apple.com
3. European Union (2025). Regulation (EU) 2025/327 on the European Health Data Space. eur-lex.europa.eu
4. European Digital Identity Wallet (2026). ZK proofs from multi-message signatures. github.com/eu-digital-identity-wallet
5. W3C (2026). Data Integrity BBS Cryptosuites v1.0, Candidate Recommendation Draft. w3.org
6. European Union (2026). July 2026 amendments to EUDI Wallet standards and specifications. eur-lex.europa.eu
7. NVIDIA (2026). Supported confidential-computing GPU platforms and modes. docs.nvidia.com
8. Google Cloud (2026). Supported confidential VM and GPU configurations. docs.cloud.google.com
9. Confidential GPU research (2025). Performance analysis of confidential GPU workloads. arxiv.org