- TEEs protect data in use within proven hardware :: ideal for wide compatibility with current SQL, ML, and streaming frameworks, as well as optimal latency.
- MPC spreads trust among multiple parties to prevent any one from viewing the inputs :: ideal for analytics across mutually distrustful organizations.
- FHE Performs calculations directly on encrypted data without the need for a decryption key on the server, making it ideal for highly secure tasks that require no access to plaintext data on the server, such as private inference operations.
- The real question is where trust sitswithin the CPU provider (TEE), under a non-collusion assumption (MPC), or due to cryptographic hardness (FHE).
- In production, the best answer is often hybrid TEE is used for orchestration, MPC is utilized for cross-party joins, and FHE is employed for the most sensitive client-server operations.
The three technologies at a glance
Both provide differing answers using distinct mechanisms. The quickest way to grasp this contrast is by examining just one card each.
Hardware-based isolation ensures that code and data are protected from the OS, hypervisor, and other components, allowing for attestation to verify the running environment before disclosing sensitive information.
Cryptographic protocols that allow parties to calculate a shared function on private inputs without revealing the inputs themselves, using secret sharing, garbled circuits, and homomorphic methods.
A basic function enabling unrestricted processing of encrypted data without the need for the secret key, ensuring that only the client (or a designated endpoint) can decrypt while an untrustworthy server works on the ciphertext.
For encrypted analytics specifically: TEEs are ideally suited for general SQL, joins, ETL, Spark-style batch processing, existing ML training, and streaming, as they can execute unmodified software within enclaves or confidential VMs. MPC is most effective when multiple data owners require collective aggregates, joins, set intersections, or privacy-preserving training without compromising plaintext to a third party. FHE is most effective when a client requires an untrusted service to perform computations on encrypted data without relying on hardware trust assumptions :: currently most suitable for limited inference tasks, vectorized arithmetic operations, small tabular models, and specific encrypted data-frame operations.
Foundations and the core trade-off
The decisive question is where trust sits:
- TEEs rely on CPU vendors, firmware, attestation roots, and the prevention or reduction of vulnerable side channels.
- MPC diminishes reliance on a single infrastructure provider, relying instead on the honesty and non-collusion of multiple parties up to the corruption threshold defined by the protocol, assuming the implementation is flawless.
- FHE Reduces reliance on server trust and eliminates vulnerability to TEE hardware attacks, but requires meticulous parameter selection, secure key management, implementation free from side-channel attacks, and strict control over data leakage.
Understanding the history of these technologies is valuable. MPC has its roots in Yao's two-party computation and GMW's extension to multi-party scenarios with honest majority. FHE originated from Gentry's ideal-lattice construction in 2009 and has evolved to use RLWE/LWE-based schemes with standardized security parameters. TEEs are developed by Intel (SGX, TDX), AMD (SEV-SNP with memory-integrity protection against malicious hypervisors), and Arm (CCA 'Realms' overseen by a Realm Management Monitor).
A useful mental model
Core properties side by side
| Property | TEEs | MPC | FHE |
|---|---|---|---|
| Protection mechanism | Hardware isolation + attestation | Secret sharing / garbled circuits / HE across parties | Ciphertext-level computation |
| Trust anchor | CPU vendor, firmware, attestation chain | Corruption threshold & non-collusion | Cryptographic hardness & parameter correctness |
| Plaintext visible during execution | Yes :: inside enclave/CVM memory | No single party sees full plaintext | No :: server sees ciphertext only |
| Best fit | General analytics on existing stacks | Cross-party collaborative analytics | Client-server private compute on narrow circuits/models |
| Hardware requirement | Special CPU support (SGX, SEV-SNP, CCA) | None intrinsic | None intrinsic; accelerators increasingly helpful |
← swipe the table →
Analytics coverage by workload
The key practical distinction lies not in the crypto definition, but rather in the shape of analytics each can support without heroic redesignTEE technology can host a variety of software, from unmodified Linux apps running encrypted Spark SQL to workload-specific engineering like MP-SPDZ protocols and ABY3 for PPML. FHE technology, while initially supporting a narrow set, is expanding with schemes like CKKS/BFV/BGV and encrypted inference capabilities. TFHE-rs also offers a range of operations with GPU bootstrapping.
| Workload | TEEs | MPC | FHE |
|---|---|---|---|
| Aggregation | strong Arbitrary SQL/Spark aggregation runs naturally | strong Core secure-computation primitive | good Arithmetic/vectorized; depends on circuit depth |
| SQL select / filter / group-by | strong Closest to plaintext execution | strong, costlier SCQL, VaultDB, SECRECY, SMCQL | limited Specialized data-frames, not general SQL |
| Joins | strong Large equi-joins via existing engines | supported Often the dominant cost center | weak Replaced by equality circuits, PSI, narrow flows |
| ML inference | excellent General models | strong Common PPML settings | strong Client-server private inference, some hybrid deep models |
| ML training | strong Enclave XGBoost, broader confidential stacks | good Linear, trees, collaborative; deep is costly | selective Only some models; far narrower than inference |
| Streaming analytics | good Existing stream processors in confidential envs | specialized Aggregate/sketch settings | weak today Better for narrow encrypted transforms |
| Private set ops / entity resolution | possible But hardware trust stays central | excellent PSI & private joins are mature | possible Specialized; less turnkey than MPC |
← swipe the table →
A second pattern worth highlighting is the growing role of hybridsSecretFlow integrates MPC, HE, and other PETs within a single framework, while OpenFHE offers support for threshold and multiparty extensions. TEEs are playing a growing role in providing attestation and secret-release mechanisms around cryptographic kernels. Hybridization is frequently used by teams to balance trust minimization with acceptable latency.
Security guarantees and threat models
TEEs provide the most compelling narrative against a compromised host OS or malicious hypervisor within the vendor's threat model However, the level of guarantee is contingent on the model's limitations and the effectiveness of the patching strategy. This is not just a theoretical concern.
- Foreshadow broke core SGX confidentiality through speculative execution; Plundervolt compromised enclave integrity via undervolting.
- Recent confidential-VM research demonstrated interrupt-based attacks against SEV-SNP and TDX.
- Even in 2026, AMD issued bulletin AMD-SB-3034 for a routing misconfiguration vulnerability in SEV-SNP that could jeopardize integrity during privileged attacks.
not that TEEs are unusable, but rather that TEE security is a crucial factor. moving systems-security target, not a one-time cryptographic proof.
MPC The story of having a cleaner record against a malicious cloud operator is based on the fact that no single executor possesses the plaintext. However, its effectiveness depends on various factors such as the type of parties involved, the majority being honest or dishonest, the nature of adversaries, and the level of collusion allowed. The security of the system is not solely reliant on theoretical guarantees but also on the implementation layer. A study conducted in 2025 on SPDZ implementations revealed practical security vulnerabilities despite the system's design for withstanding malicious attacks, highlighting the importance of software assurance and concurrency testing.
FHE provides the cleanest server-side confidentiality As the server is never exposed to plaintext, it relies on the robustness of LWE/RLWE hardness with parameters in accordance with the HomomorphicEncryption.org standards. However, it's important to note that while FHE provides a high level of security, certain information such as metadata, access patterns, model structure, and outputs can still be vulnerable at the application layer. Additionally, there have been instances of implementation side channels being exploited against FHE libraries. To address these concerns, additional measures such as output filtering, model partitioning, or threshold decryption policies are often necessary on top of the cryptographic protections.
| Dimension | TEEs | MPC | FHE |
|---|---|---|---|
| Protects vs compromised OS / hypervisor | Yes, by design | Yes, if protocol assumptions hold | Yes :: server runs without plaintext |
| Side-channel exposure | High relative concern (microarch, interrupt/fault) | Lower hardware dependence; output leakage remains | Avoids TEE boundary; impl & metadata can leak |
| Trust in hardware vendor | High | Low | Low |
| Trust in non-collusion | Low to none | Central | Usually none (threshold decryption may add it) |
| Attestation / proof of environment | Core requirement | Not hardware-based; correctness from protocol | Circuit & cryptographic evaluation dependent |
← swipe the table →
Performance, scalability, and cost
TEEs Consistently outperform in terms of raw workload flexibility and typically lead in latency. The data from various sources provide valuable insights:
Confidential-VM TEEs are frequently more effective than SGX for 'lift-and-shift' analytics due to their avoidance of SGX's per-process enclave model and restricted protected-memory limits; a 2024 study found that confidential VMs experienced approximately an 8.5% throughput overhead on streaming (NEXMark) workloads. MPC Batching in SECRECY reduced communication latency significantly, allowing for the exchange of 100 million 64-bit shares in about 2 seconds. Additionally, ABY3 showcased the ability to process billions of AND gates per second in settings where honest majority is optimized. FHE continues to be the slowest; however, standardized benchmarks indicate that the optimal choice varies based on the type of workload (TFHE excels with binary circuits, while HElib is preferred for batching multiple instances). Moreover, contemporary FHE implementations are shifting towards utilizing GPU or accelerator processing in addition to CPU-only execution.
Cost & operational burden
| Burden area | TEEs | MPC | FHE |
|---|---|---|---|
| Compute cost | Lowest premium of the three | Higher :: multiple parties + protocol overhead | Highest; acceleration often needed |
| Network / egress | Moderate | Often high :: protocol messages dominate | Moderate, but ciphertexts/keys are large |
| Key management | Attestation-bound secret release + KMS | Multi-party key & secret-share lifecycle | Client keygen, eval keys, threshold decryption |
| Orchestration | Attestation, container policy, enclave/CVM scheduling | Party coordination, fault handling, sessions | Compilation pipeline, circuit packaging, accelerators |
| Monitoring / debugging | Hard :: introspection breaks trust boundary | Hard :: transcripts distributed & sensitive | Hard :: compiled, encrypted execution is opaque |
← swipe the table →
Ecosystem, tooling, and maturity
The maturity timeline is asymmetric: MPC is the oldest conceptually, TEEs are the most established in terms of infrastructure, and FHE is advancing rapidly as a practical frontier.
- TEEs The platform with the most advanced ecosystem includes hardware stacks from Intel, AMD, and Arm, along with the cross-TEE Open Enclave SDK, Gramine for Linux SGX workloads, Enarx for WebAssembly portability, and Confidential Containers for Kubernetes attestation and secret delivery. The main challenge lies in managing secure operations complexity, rather than a lack of tools.
- MPC Research has led to mature tools that are becoming more accessible, such as MP-SPDZ, ABY3, SecretFlow, and SCQL. Usability improvements are often tied to specific workloads or policies.
- FHE requires a fast pace: OpenFHE (broadest surface, FHE threshold, scheme switching), Microsoft SEAL (BFV/CKKS), TFHE-rs (Boolean/integer for production focus), HEBench (benchmarking), and Concrete ML (Python APIs, hybrid execution, deployment). It necessitates a deeper understanding of cryptography beyond
| Dimension | TEEs | MPC | FHE |
|---|---|---|---|
| Hardware / platform maturity | High | Not hardware-dependent | Moderate, improving; accelerator ecosystem emerging |
| Developer abstraction | Strong via enclaves/CVMs/containers | Moderate; improving with SQL/ML frameworks | Moderate for packaged ML; lower for custom analytics |
| Production readiness (general analytics) | Highest | Moderate | Lowest for arbitrary analytics; stronger for focused inference |
← swipe the table →
What's new in 2025–2026
The frontier moved :: especially on hardware and FHE
- GPU TEEs went mainstream. NVIDIA Confidential Computing now covers Hopper (H100/H200) and Blackwell (B200/B300, RTX Pro 6000) GPUs, securely encrypting model weights, activations, and KV-cache in VRAM. AWS, Azure, and Google Cloud provide CPU-TEE confidential VMs, while Azure offers complete NVIDIA-CC GPU CVMs.
- Composite attestation arrived. Intel Trust Authority and NVIDIA have now introduced a confidential VM and a confidential-computing GPU in a single workflow, bridging a longstanding gap in confidential AI.
- GPU-TEE overhead is small for LLM work. According to the Hopper CC benchmarks, the LLM-inference overhead is usually under 7%, with larger models or longer sequences experiencing near-zero overhead; the bottleneck is the transfer between the CPU and GPU via PCIe, rather than GPU compute. A survey conducted in February 2026 warns that certain GPU-TEE hardware components, such as power management and the PCIe bus, are still in
- FHE commercialized fast. In June 2025, Zama achieved unicorn status as the first FHE company, showing speedups of around 20-100 times since its founding. The company aims to reach 500-1,000 TPS using GPU technology by the end of 2026. TFHE-rs has incorporated CUDA GPU and AMD Alveo FPGA production FHE feature such as Live Caller ID Lookup and specialized FHE accelerators like FPGA, processing-in-memory, and ASICs are continuously addressing the bootstrapping and off-chip
- Scale-out TEEs are on roadmaps. Current TEEs are limited to one physical server, but future industry plans suggest scale-out solutions that could significantly increase the deployment of confidential analytics.
Resulting from the emergence of confidential GPUs and FHE acceleration, the distinction between 'hardware-trust' and 'no-hardware-trust' privacy in private AI is becoming less defined, making TEE-based solutions more affordable for a wider range of workloads.
Compliance and operational realities
All three are best viewed as risk-reducing technical measures, not scope-elimination machinesGDPR Article 32 and HIPAA's Security Rule both highlight encryption and pseudonymisation as key security measures for processing data, while PCI DSS places a strong emphasis on retention minimization and robust cryptography. However, it is important to note that these safeguards do not negate the need for thorough lawful-basis analysis, data-minimization practices, regular auditing, adherence to retention limits, and effective output governance.
Operationally, each technology centers on a different discipline:
- TEEs center on attestation and secret release Managing reference values, integrating with KMS, overseeing certificate lifecycles, signing images, and conducting patch-driven re-attestation can be challenging. Monitoring is particularly difficult due to the conflict between intros
- MPC centers on party coordination Hosting compute parties, potential collusion, rotating sessions, managing offline parties, and governing outputs are all important considerations. SCQL's column-control list highlights the necessity of implementing stringent output policies to prevent data leaks from properly executed queries or unregulated repeated queries.
- FHE centers on key and circuit lifecycle Concrete ML distinguishes between client-side cryptographic parameters and server-side compiled model artifacts, acknowledging that key generation may be time-consuming and keys may be lengthy, and cautioning that compiled artifacts are dependent on architecture. FHE CI/CD is akin to a compiler toolchain combined with a crypto-parameter pipeline, rather than traditional model serving.
TEE, MPC, and FHE can enhance a control environment significantly, but they are not a replacement for secure software engineering. The security status of all three families is continuously evolving. Consider each as just one layer in a comprehensive design, rather than a foolproof solution.
Decision framework by use case
The strongest overall mapping for most analytics programs:
| Use case | First choice | Why · when to differ |
|---|---|---|
| Single-org confidential SQL / ETL / BI | TEE | For optimal latency, ensure broad engine compatibility. Only use FHE if 'no plaintext on server ever' is required and the query set is limited. |
| Cross-org joins, clean rooms, collaborative aggregates | MPC | Not all data is visible to a single operator; SQL/PSI ecosystems are reliable. Incorporate TEE for coordination; implement FHE for specific client-server processes. |
| Private ML inference as a service | FHE or hybrid FHE+TEE | Robust confidentiality on the server side; specific client/server patterns are in place. Consider utilizing TEE if prioritizing latency or model diversity over minimizing trust. |
| Confidential ML training on existing frameworks | TEE | Most software is compatible with MPC for collaborative training among parties with distrust; FHE is currently limited to specific model classes. |
| Streaming analytics on sensitive data | TEE | Top choice for current stream processors. MPC tailored for specific aggregates/sketches; FHE typically limited to specific transforms. |
| Regulated sharing where hardware trust is unacceptable | MPC | Most secure trust reduction for multi-owner analytics. Consider FHE for single client/server setups with higher runtime costs. |
| Lowest operational friction, near-term rollout | TEE | For optimal ecosystem support that aligns with standard infrastructure practices, opt for MPC/FHE when prioritizing trust over convenience. |
← swipe the table →
Boiled down: TEE-first for updating internal analytics, complying with regulations for BI, developing confidential features, and implementing confidential streaming. MPC-first for clean data rooms, federated analytics for healthcare and finance, inter-company joins, and advertising measurement. FHE-first for confidential inference services, encrypted client-server scoring, and specific arithmetic analytics where plaintext must never be stored on the server. Hybrid-first When collaboration, trust issues, and practical performance become equally important.
Adoption checklist
- State the trust requirement What opponent needs to be overcome (host OS, cloud operator, collaborator, the server itself)? This one response quickly narrows down the options.
- Map the workload shape - Comparing general SQL/streaming with cross-party joins and client-server inference in relation to the analytics-coverage table.
- Pin the latency and cost budgetAfter that, verify it against typical benchmarks (TEE close to native performance; MPC limited by network; FHE reliant on accelerator).
- Decide attestation and key management early: reference values and key management systems for trusted execution environments; party/session and secret-sharing lifecycle for multiparty computation; pipeline for fully homomorphic encryption combining key generation and compiled circuit execution.
- Write the output-governance policy :: thresholds, permitted columns, limits on repeated queries :: as even accurate execution can result in information leakage.
- Conduct a pilot of a limited workload from start to finish, verify the security review with the actual threat model, and proceed to implementation.
- Plan for hybridsUtilizing TEE orchestration with MPC primitives, or FHE at the critical client-server edge, is frequently the practical solution for production environments.
Frequently asked questions
What's the difference between TEEs, MPC, and FHE? +
Which is best for encrypted analytics? +
Is FHE fast enough for production in 2026? +
Are TEEs secure given side-channel attacks? +
Do these technologies remove GDPR or HIPAA obligations? +
What is a confidential GPU and why does it matter? +
Primary sources
This tutorial compiles vendor documentation, foundational papers, peer-reviewed benchmarks, standards, and recent announcements for 2025-2026. Key references: