--- title: "ZK vs FHE vs MPC vs TEE: How to Choose in 2026" canonical: https://wavect.io/blog/zk-vs-fhe-vs-mpc-vs-tee/ language: en description: "Four privacy technologies, four trust models, four price tags. A 2026 decision framework for architects, with honest performance numbers." image: "https://wavect.io/img/blog/headers/header_zk-vs-fhe-vs-mpc-vs-tee.png" --- [**Back**](/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/team/kevin-riedl/) [Kevin Riedl](/team/kevin-riedl/) https://linkedin.com/in/wsdt 10 min read · 5 Jul 2026 Last reviewed August 7, 2026 [**Next**](/blog/building-real-applications-zero-knowledge-fhe-2026/) # ZK vs FHE vs MPC vs TEE: How to Choose in 2026 TL;DR ZK, FHE, MPC, and TEEs protect different statements and expose different trust boundaries. No fixed performance multiplier follows from choosing one: circuit, parameters, implementation, threshold, network, hardware, and attestation all matter. Benchmark the concrete system. EU rules usually mandate properties such as selective disclosure, controlled access, resilience, and confidentiality, not a specific cryptographic technology. EUDI technical work continues to evaluate BBS and hybrid ZK approaches. Reviewed against primary sources on 2026-08-07. 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](/blog/building-real-applications-zero-knowledge-fhe-2026/). Engineering perspective, not a vendor pitch. All figures are sourced or labeled as rules of thumb. Reference points come from Wavect's [zero-knowledge](/services/zero-knowledge/) and [frontier-tech](/services/bleeding-edge/) 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](/glossary/zero-knowledge/) and [production deep dive](/blog/zero-knowledge-proofs-production-2026/). - 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](/blog/fully-homomorphic-encryption-practical-2026/). - 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 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? | | ZK | FHE | MPC | TEE | | --- | --- | --- | --- | --- | | You trust | Proof assumptions plus circuit and implementation | Scheme, parameters, implementation, and key handling | A protocol-specific threshold of parties | Hardware, firmware, attestation, and side-channel defenses | | Performance cost | Usually prover-heavy; verifier cost varies by system | Large and operation-specific | Protocol-, threshold-, and network-dependent | Often near-native, but workload- and platform-dependent | | 2026 cost signal | Real-time block proving demonstrated; price the exact proof | Fast primitives exist; full applications need end-to-end benchmarks | Measure rounds and transferred data across the intended network | Include confidential-compute premium and attestation operations | | Maturity | Production (L2s, Google Wallet, World ID) | Production for narrow lookups (Apple, Microsoft) | Production in finance and key management | Production everywhere, incl. confidential GPUs | | Hidden from operator | The witness (evidence) | Everything | Everything (split across parties) | Everything, if you trust the hardware | | Killer use case | Selective disclosure, verifiable compute | Private lookups, small private ML | Cross-organization analytics | Confidential AI at scale | | Main failure mode | Under-constrained circuits, trusted-setup mistakes | Misapplied to interactive workloads | Collusion, network latency | Side-channel attacks, vendor trust | ![Kevin Riedl](/img/team/kevin.webp) "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)](https://arxiv.org/abs/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, deadline end of 2026. Every member state must offer a digital identity wallet, with selective disclosure central to the design. Current official technical work evaluates BBS-family and hybrid ZK constructions, while standardization, certified hardware, assurance levels, and national implementation continue to evolve. Do not infer a blanket approval or ban from one architecture document. - 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](/blog/eu-data-residency-ai-apps-2026/) 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. ## Frequently Asked Questions ### What is the difference between ZK, FHE, MPC, and TEE in one sentence each? ZK proves a fact without revealing the evidence; FHE computes on data that stays encrypted; MPC lets several parties compute jointly without sharing inputs; a TEE runs plaintext computation inside hardware isolation you have to trust. ### Which is most secure: ZK, FHE, MPC, or TEE? There is no universal ranking because they secure different statements and expose different implementation boundaries. ZK and FHE still depend on correct software, parameters, circuits, setup, and key handling. MPC adds protocol-specific threshold assumptions, while TEEs add hardware, firmware, attestation, and side-channel assumptions. Compare the concrete systems against the threat model and benchmark them. ### Is a TEE good enough for GDPR compliance? Often yes, as part of a data-protection-by-design story: confidential VMs or GPUs with attestation materially reduce operator access. But TEEs do not make data anonymous, and whether even FHE output escapes GDPR scope is legally unsettled. Compliance comes from the whole processing design, with legal review, not from any single technology. ### Can these technologies be combined? Yes. A TEE can carry a bulk workload, FHE or MPC can cover a smaller computation where hardware trust is unacceptable, and ZK can make a defined result verifiable. Future substitution still requires explicit interfaces, key ownership, data formats, and fallback semantics; it is not automatically a drop-in upgrade. ### What should an EU company do before the 2026 eIDAS wallet deadline? If you handle identity, age, or credential checks, prototype against current EUDI selective-disclosure flows and isolate the credential-format adapter. Check the current assurance level, certified-hardware requirements, national rollout, and relying-party rules before launch. Current technical work includes BBS-family and hybrid ZK approaches, but implementation status is still evolving. ## Sources and verification 1. Mopro (2026). Circuit-specific proving and verification benchmarks. [zkmopro.org](https://zkmopro.org/docs/performance/) 2. Apple Machine Learning Research (2024). Production HE and private information retrieval. [machinelearning.apple.com](https://machinelearning.apple.com/research/homomorphic-encryption) 3. European Union (2025). Regulation (EU) 2025/327 on the European Health Data Space. [eur-lex.europa.eu](https://eur-lex.europa.eu/eli/reg/2025/327/oj) 4. European Digital Identity Wallet (2026). ZK proofs from multi-message signatures. [github.com/eu-digital-identity-wallet](https://github.com/eu-digital-identity-wallet/eudi-doc-standards-and-technical-specifications/blob/main/docs/technical-specifications/ts14-zkps-from-mms.md) 5. W3C (2026). Data Integrity BBS Cryptosuites v1.0, Candidate Recommendation Draft. [w3.org](https://www.w3.org/TR/vc-di-bbs/) 6. Confidential GPU research (2025). Performance analysis of confidential GPU workloads. [arxiv.org](https://arxiv.org/abs/2505.16501) ## Final thoughts The four technologies are not interchangeable. ZK answers verification questions and is production-ready for selected workloads. FHE answers blind-computation questions where the operation mix and latency budget close. MPC covers multi-organization computation under a defined threshold and network model. TEEs carry large confidential workloads with a different hardware and attestation trust boundary. Pick by threat model, not fascination: name who must not see the data, decide whether you need verification or computation, size the workload honestly, and benchmark the concrete stack. Keep the cryptographic surface small, design hybrid boundaries explicitly, and map EU rules to required properties rather than claiming that a regulation mandates a particular technology. ## You may also like.. [**Fully Homomorphic Encryption in 2026: What Ships and What Is Still Hype** Apple's production FHE, Zama's mainnet, the honest overhead numbers, and the LLM-under-FHE reality check.](/blog/fully-homomorphic-encryption-practical-2026/) [**Wavect vs a generalist dev agency** Generalists sell capacity; we sell product judgment plus the engineering to ship frontier tech safely.](/compare/wavect-vs-dev-agencies/) Privacy and cryptography ## Continue through this cluster Zero knowledge, FHE and privacy-preserving computation beyond the hype. [Start with the cornerstone**Zero-Knowledge Proofs in 2026: What Is Actually Production-Ready**](/blog/zero-knowledge-proofs-production-2026/) - [zkTLS for AI Agents: Prove Web Data Without Exposing Secrets](/blog/zktls-ai-agents/) - [Building Real Applications With ZK and FHE in 2026: A Pragmatic Guide](/blog/building-real-applications-zero-knowledge-fhe-2026/) - [Zero-Knowledge Proofs in 2026: What Is Actually Production-Ready](/blog/zero-knowledge-proofs-production-2026/) - [Fully Homomorphic Encryption in 2026: What Ships and What Is Still Hype](/blog/fully-homomorphic-encryption-practical-2026/) - [Zero-Knowledge Outside Crypto](/blog/zero-knowledge-use-cases-outside-crypto/) Inbox, without the noise ## Follow the work that matters to you Get a short email when we publish something new. Follow the whole blog or only the problems you care about. [**Back**](/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/team/kevin-riedl/) [Kevin Riedl](/team/kevin-riedl/) https://linkedin.com/in/wsdt 10 min read · 5 Jul 2026 Last reviewed August 7, 2026 [**Next**](/blog/building-real-applications-zero-knowledge-fhe-2026/) New posts by email × × Get new posts by email A short email when we publish. Free, no tracking. ## Structured Data ```json { "@context": "https://schema.org", "@graph": [ { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ], "employee": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "founder": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "legalRepresentative": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "name": "Wavect GmbH", "subjectOf": { "@id": "https://wavect.io/verified-claims.json#dataset", "@type": "Dataset", "creator": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "description": "A machine-readable registry of quantitative and qualitative claims published by Wavect, with review dates, localized page appearances and public third-party citations where available.", "inLanguage": "en", "isAccessibleForFree": true, "license": "https://creativecommons.org/licenses/by/4.0/", "name": "Wavect verified publication claims", "url": "https://wavect.io/verified-claims.json" }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "sameAs": [ "https://www.wikidata.org/wiki/Q139796367", "https://www.linkedin.com/in/jocr77/", "https://github.com/jo-chris" ], "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/#website", "@type": "WebSite", "inLanguage": [ "en", "de", "es", "zh" ], "name": "Wavect", "potentialAction": { "@type": "SearchAction", "query-input": "required name=search_term_string", "target": { "@type": "EntryPoint", "urlTemplate": "https://wavect.io/search/?q={search_term_string}" } }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/blog/zk-vs-fhe-vs-mpc-vs-tee/#webpage", "@type": "WebPage", "dateModified": "2026-07-07", "inLanguage": "en", "isPartOf": { "@id": "https://wavect.io/#website", "@type": "WebSite" }, "lastReviewed": "2026-07-07", "url": "https://wavect.io/blog/zk-vs-fhe-vs-mpc-vs-tee/" } ] } ``` ```json { "@context": "https://schema.org", "@type": "BlogPosting", "abstract": "ZK, FHE, MPC, and TEEs protect different statements and expose different trust boundaries. No fixed performance multiplier follows from choosing one: circuit, parameters, implementation, threshold, network, hardware, and attestation all matter. Benchmark the concrete system. EU rules usually mandate properties such as selective disclosure, controlled access, resilience, and confidentiality, not a specific cryptographic technology. EUDI technical work continues to evaluate BBS and hybrid ZK approaches. Reviewed against primary sources on 2026-08-07.", "articleBody": " Blog overview/Web3 and privacy/Privacy and cryptography ZK vs FHE vs MPC vs TEE: How to Choose in 2026 TL;DR ZK, FHE, MPC, and TEEs protect different statements and expose different trust boundaries. No fixed performance multiplier follows from choosing one: circuit, parameters, implementation, threshold, network, hardware, and attestation all matter. Benchmark the concrete system. EU rules usually mandate properties such as selective disclosure, controlled access, resilience, and confidentiality, not a specific cryptographic technology. EUDI technical work continues to evaluate BBS and hybrid ZK approaches. Reviewed against primary sources on 2026-08-07. 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 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 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? 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. 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. 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. 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? ZKFHEMPCTEE You trustProof assumptions plus circuit and implementationScheme, parameters, implementation, and key handlingA protocol-specific threshold of partiesHardware, firmware, attestation, and side-channel defenses Performance costUsually prover-heavy; verifier cost varies by systemLarge and operation-specificProtocol-, threshold-, and network-dependentOften near-native, but workload- and platform-dependent 2026 cost signalReal-time block proving demonstrated; price the exact proofFast primitives exist; full applications need end-to-end benchmarksMeasure rounds and transferred data across the intended networkInclude confidential-compute premium and attestation operations MaturityProduction (L2s, Google Wallet, World ID)Production for narrow lookups (Apple, Microsoft)Production in finance and key managementProduction everywhere, incl. confidential GPUs Hidden from operatorThe witness (evidence)EverythingEverything (split", "articleSection": "Engineering", "author": { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/" }, "citation": [ { "@type": "WebPage", "name": "zkmopro.org", "url": "https://zkmopro.org/docs/performance/" }, { "@type": "WebPage", "name": "machinelearning.apple.com", "url": "https://machinelearning.apple.com/research/homomorphic-encryption" }, { "@type": "WebPage", "name": "eur-lex.europa.eu", "url": "https://eur-lex.europa.eu/eli/reg/2025/327/oj" }, { "@type": "WebPage", "name": "github.com/eu-digital-identity-wallet", "url": "https://github.com/eu-digital-identity-wallet/eudi-doc-standards-and-technical-specifications/blob/main/docs/technical-specifications/ts14-zkps-from-mms.md" }, { "@type": "WebPage", "name": "w3.org", "url": "https://www.w3.org/TR/vc-di-bbs/" }, { "@type": "WebPage", "name": "arxiv.org", "url": "https://arxiv.org/abs/2505.16501" } ], "dateModified": "2026-08-07", "datePublished": "2026-07-05", "description": "ZK, FHE, MPC, and TEEs protect different statements and expose different trust boundaries. No fixed performance multiplier follows from choosing one: circuit, parameters, implementation, threshold, network, hardware, and attestation all matter. Benchmark the concrete system. EU rules usually mandate properties such as selective disclosure, controlled access, resilience, and confidentiality, not a specific cryptographic technology. EUDI technical work continues to evaluate BBS and hybrid ZK approaches. Reviewed against primary sources on 2026-08-07.", "headline": "ZK vs FHE vs MPC vs TEE: How to Choose in 2026", "image": "https://wavect.io/img/blog/headers/header_zk-vs-fhe-vs-mpc-vs-tee.svg", "inLanguage": "en", "mainEntityOfPage": { "@id": "https://wavect.io/blog/zk-vs-fhe-vs-mpc-vs-tee/", "@type": "WebPage" }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/blog/zk-vs-fhe-vs-mpc-vs-tee/", "wordCount": 2243 } ``` ```json { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "item": "https://wavect.io/", "name": "Home", "position": 1 }, { "@type": "ListItem", "item": "https://wavect.io/blog/overview/", "name": "Blog overview", "position": 2 }, { "@type": "ListItem", "item": "https://wavect.io/blog/topics/web3-privacy/", "name": "Web3 and privacy", "position": 3 }, { "@type": "ListItem", "item": "https://wavect.io/blog/clusters/privacy-cryptography/", "name": "Privacy and cryptography", "position": 4 }, { "@type": "ListItem", "item": "https://wavect.io/blog/zk-vs-fhe-vs-mpc-vs-tee/", "name": "ZK vs FHE vs MPC vs TEE: How to Choose in 2026 | ", "position": 5 } ] } ``` ```json { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "ZK proves a fact without revealing the evidence; FHE computes on data that stays encrypted; MPC lets several parties compute jointly without sharing inputs; a TEE runs plaintext computation inside hardware isolation you have to trust." }, "name": "What is the difference between ZK, FHE, MPC, and TEE in one sentence each?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "There is no universal ranking because they secure different statements and expose different implementation boundaries. ZK and FHE still depend on correct software, parameters, circuits, setup, and key handling. MPC adds protocol-specific threshold assumptions, while TEEs add hardware, firmware, attestation, and side-channel assumptions. Compare the concrete systems against the threat model and benchmark them." }, "name": "Which is most secure: ZK, FHE, MPC, or TEE?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Often yes, as part of a data-protection-by-design story: confidential VMs or GPUs with attestation materially reduce operator access. But TEEs do not make data anonymous, and whether even FHE output escapes GDPR scope is legally unsettled. Compliance comes from the whole processing design, with legal review, not from any single technology." }, "name": "Is a TEE good enough for GDPR compliance?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Yes. A TEE can carry a bulk workload, FHE or MPC can cover a smaller computation where hardware trust is unacceptable, and ZK can make a defined result verifiable. Future substitution still requires explicit interfaces, key ownership, data formats, and fallback semantics; it is not automatically a drop-in upgrade." }, "name": "Can these technologies be combined?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "If you handle identity, age, or credential checks, prototype against current EUDI selective-disclosure flows and isolate the credential-format adapter. Check the current assurance level, certified-hardware requirements, national rollout, and relying-party rules before launch. Current technical work includes BBS-family and hybrid ZK approaches, but implementation status is still evolving." }, "name": "What should an EU company do before the 2026 eIDAS wallet deadline?" } ] } ```