- TEEs protect data in use inside attested hardware — broadest compatibility with existing SQL, ML, and streaming stacks, and the best latency.
- MPC distributes trust across parties so none sees the inputs — best for analytics across mutually distrustful organizations.
- FHE computes on ciphertext with no key on the server — best where plaintext must never exist server-side, especially private inference.
- The deciding question is where trust sits: in the CPU vendor (TEE), a non-collusion assumption (MPC), or cryptographic hardness (FHE).
- In production, the strongest answer is often hybrid — TEE for orchestration, MPC for cross-party joins, FHE for the most sensitive client-server steps.
01 — OverviewThe three technologies at a glance
They answer the same question with fundamentally different machinery. The fastest way to internalize the difference is one column each.
Hardware-isolated execution that shields code and data from the OS, hypervisor, and peers, exposing attestation so a remote party can verify what's running before releasing secrets.
Cryptographic protocols that let parties compute a joint function over private inputs while revealing only the output, via secret sharing, garbled circuits, and homomorphic techniques.
A primitive allowing arbitrary computation on encrypted data without the secret key — the untrusted server operates on ciphertext, and only the client (or a threshold endpoint) decrypts.
For encrypted analytics specifically: TEEs fit general SQL, joins, ETL, Spark-style batch, existing ML training, and streaming, because they run largely unmodified software inside enclaves or confidential VMs. MPC is strongest when multiple data owners need joint aggregates, joins, set intersection, or privacy-preserving training without surrendering plaintext to a shared operator. FHE is strongest when a client wants an untrusted service to compute on its encrypted data with no hardware trust assumption — most practical today for constrained inference, vectorized arithmetic, small tabular models, and specialized encrypted data-frame operations.
02 — FoundationsFoundations and the core trade-off
The decisive question is where trust sits:
- TEEs trust CPU vendors, firmware, attestation roots, and the absence or mitigation of exploitable side channels.
- MPC reduces trust in any single infrastructure provider, but assumes enough parties stay honest or non-colluding per the protocol's corruption threshold — and that the implementation is correct.
- FHE minimizes runtime trust in the server and avoids a hardware attack surface, but depends on careful parameter selection, key management, side-channel-safe implementations, and control of output and metadata leakage.
The lineage is worth knowing. MPC traces to Yao's secure two-party computation and the GMW generalization to the multi-party honest-majority setting. FHE began with Gentry's 2009 ideal-lattice construction and is now realized through RLWE/LWE-based schemes with standardized security parameters. TEEs are framed by Intel (SGX, TDX), AMD (SEV-SNP, adding memory-integrity protection against malicious hypervisors), and Arm (CCA "Realms" managed 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 at runtime | 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 help |
← swipe the table →
03 — AnalyticsAnalytics coverage by workload
The decisive practical difference is not the crypto definition — it's the shape of analytics each supports without heroic redesign. TEEs inherit the flexibility of whatever they host (Gramine "lift-and-shift" of unmodified Linux apps, Opaque SQL running encrypted Spark SQL in enclaves). MPC covers a surprisingly broad surface but with workload-specific engineering (MP-SPDZ protocols, ABY3 for PPML, SCQL compiling SQL to hybrid graphs, VaultDB and SECRECY for federated SQL). FHE supports the narrowest set most economically, but that set is expanding (OpenFHE's CKKS/BFV/BGV and scheme switching; Concrete ML's encrypted inference and data-frames; TFHE-rs integer/Boolean/string ops with GPU bootstrapping).
| Workload | TEEs | MPC | FHE |
|---|---|---|---|
| Aggregation | strong Arbitrary SQL/Spark aggregation runs naturally | strong A core secure-computation primitive | good Arithmetic/vectorized; depends on circuit depth |
| SQL select / filter / group-by | strong Closest to plaintext execution | 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 hybrids. SecretFlow combines MPC, HE, and other PETs in one framework; OpenFHE supports threshold and multiparty extensions; TEEs increasingly supply the attestation and secret-release plumbing around cryptographic kernels. Hybridization is often how teams reconcile trust minimization with acceptable latency.
04 — SecuritySecurity guarantees and threat models
TEEs offer the strongest story against a compromised host OS or malicious hypervisor within the vendor's threat model — but the guarantees are only as strong as that model's exclusions and the patch posture. The caveat is not theoretical:
- 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 SEV-SNP routing-misconfiguration issue that could compromise integrity under privileged attack conditions.
The conclusion isn't that TEEs are unusable — it's that TEE security is a moving systems-security target, not a one-time cryptographic proof.
MPC has a cleaner story against a malicious cloud operator because no single executor holds the plaintext, but the guarantees hinge on protocol assumptions — two- vs three-party, honest vs dishonest majority, semi-honest vs malicious adversaries, and tolerated collusion. It is not "secure by theorem alone" at the implementation layer either: a 2025 study of SPDZ implementations found practical security issues despite the family's malicious-security design point, underscoring the need for software assurance and concurrency testing.
FHE provides the cleanest server-side confidentiality because the server never sees plaintext, rooted in LWE/RLWE hardness with parameters aligned to HomomorphicEncryption.org standards. But FHE doesn't hide everything: metadata, access patterns, model structure, and outputs can still leak at the application layer, and implementation side channels against FHE libraries have been demonstrated — so FHE often needs output filtering, model-partitioning, or threshold-decryption policies on top of the cryptography.
| 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 →
05 — PerformancePerformance, scalability, and cost
TEEs consistently win on raw workload flexibility and usually on latency. A few figures from the literature anchor the intuition:
Confidential-VM TEEs often beat SGX for "lift-and-shift" analytics because they avoid SGX's per-process enclave model and small protected-memory limits; a 2024 study reported up to ~8.5% throughput overhead for confidential VMs on streaming (NEXMark) workloads. MPC performance is dominated by communication rounds, latency, batching, and expensive nonlinear operators — SECRECY showed batching cut communication latency by two-to-four orders of magnitude, exchanging 100M 64-bit shares in ~2 seconds, while ABY3 demonstrated billions of AND gates/second in optimized honest-majority settings. FHE remains the slowest, but standardized benchmarks show the winner depends on workload shape (TFHE best for binary circuits, HElib when batching many instances), and modern FHE increasingly assumes GPU/accelerator execution rather than CPU-only.
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 →
06 — EcosystemEcosystem, tooling, and maturity
The maturity timeline is asymmetric: MPC is oldest in theory, TEEs are most mature as infrastructure, and FHE is the fastest-moving practical frontier.
- TEEs have the most mature platform ecosystem: Intel/AMD/Arm hardware stacks, 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 limiting factor is secure-ops complexity, not missing tools.
- MPC tooling is mature in research and increasingly usable: MP-SPDZ (many protocols/security models), ABY3 (PPML), SecretFlow (collaborative analysis, ML, PSI), and SCQL (a real SQL front end with column-control policies). Usability often comes from constrained workloads or policies.
- FHE is moving quickly: OpenFHE (broadest surface, threshold FHE, scheme switching), Microsoft SEAL (BFV/CKKS), TFHE-rs (production-focused Boolean/integer), HEBench (benchmarking), and Concrete ML (Python APIs, deployment, hybrid execution). It still demands more cryptographic literacy beyond canned examples.
| 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 →
07 — DispatchWhat's new in 2025–2026
The frontier moved — especially on hardware and FHE
- GPU TEEs went mainstream. NVIDIA Confidential Computing now spans Hopper (H100/H200) and Blackwell (B200/B300, RTX Pro 6000) GPUs, sealing model weights, activations, and KV-cache in encrypted VRAM. AWS, Azure, and Google Cloud all offer CPU-TEE confidential VMs, and Azure offers end-to-end NVIDIA-CC GPU CVMs.
- Composite attestation arrived. Intel Trust Authority and NVIDIA now attest a confidential VM and a confidential-computing GPU in one workflow — closing a long-standing gap for confidential AI.
- GPU-TEE overhead is small for LLM work. Hopper CC benchmarks put LLM-inference overhead typically below 7% (near-zero for larger models / longer sequences); the bottleneck is PCIe CPU↔GPU transfer, not GPU compute. A Feb 2026 survey cautions that some GPU-TEE hardware components (power management, PCIe bus) remain early-stage.
- FHE commercialized fast. Zama became the first FHE "unicorn" (June 2025), reports ~20–100× speedups since inception, and targets 500–1,000 TPS via GPU by end of 2026; TFHE-rs adds CUDA GPU and AMD Alveo FPGA acceleration. Apple shipped a production FHE feature (Live Caller ID Lookup), and dedicated accelerators (FPGA, processing-in-memory, ASICs) keep attacking the bootstrapping / off-chip-memory bottleneck.
- Scale-out TEEs are on roadmaps. Current TEEs are bound to a single physical server; industry roadmaps point to scale-out solutions, which would materially expand confidential-analytics deployments.
The net effect: the practical line between "hardware-trust" and "no-hardware-trust" privacy is blurring as confidential GPUs make TEE-based private AI cheap, while FHE acceleration narrows the cost gap for the strictest workloads.
08 — ComplianceCompliance and operational realities
All three are best viewed as risk-reducing technical measures, not scope-elimination machines. GDPR Article 32 explicitly names encryption and pseudonymisation as example safeguards for security of processing. HIPAA's Security Rule is risk-based and requires confidentiality, integrity, and availability of ePHI. PCI DSS still emphasizes retention minimization and strong cryptography. None replaces lawful-basis analysis, data-minimization decisions, auditing, retention limits, or output governance.
Operationally, each technology centers on a different discipline:
- TEEs center on attestation and secret release — reference-value management, KMS integration, certificate lifecycle, image signing, and patch-driven re-attestation. Monitoring is harder because introspection competes with confidentiality.
- MPC centers on party coordination — who hosts compute parties, who may collude, how to rotate sessions, how to handle a party going offline, and how to govern outputs. SCQL's column-control list shows why output policy isn't optional: a correctly executed query can still leak through permissive result policies or ungoverned repeated queries.
- FHE centers on key and circuit lifecycle — Concrete ML separates client-side cryptographic parameters from server-side compiled model artifacts, notes key generation can be slow and keys large, and warns compiled artifacts are architecture-specific. FHE CI/CD resembles a compiler toolchain plus crypto-parameter pipeline, not conventional model serving.
TEEs, MPC, and FHE can materially strengthen a control environment — but they do not substitute for secure software engineering, and their security posture is still moving for all three families. Treat each as one control in a layered design, not a guarantee.
09 — DecideDecision 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 | Broad engine compatibility, best latency. Use FHE only if "no plaintext on server ever" is mandatory and the query set is narrow. |
| Cross-org joins, clean rooms, collaborative aggregates | MPC | No single operator sees all data; SQL/PSI ecosystems are credible. Add TEE for orchestration; add FHE for selected client-server steps. |
| Private ML inference as a service | FHE / hybrid | Strong server-side confidentiality; concrete client/server patterns exist. Use TEE if latency or model breadth matters more than trust minimization. |
| Confidential ML training on existing frameworks | TEE | Highest software compatibility. MPC for collaborative training across distrustful parties; FHE only for narrow model classes today. |
| Streaming analytics on sensitive data | TEE | Best match to existing stream processors. MPC for specialized aggregates/sketches; FHE usually only narrow transforms. |
| Regulated sharing where hardware trust is unacceptable | MPC | Strongest trust minimization for multi-owner analytics. FHE if single client/server and far higher runtime cost is tolerable. |
| Lowest operational friction, near-term rollout | TEE | Best ecosystem support, closest to standard infra practice. Choose MPC/FHE when the trust model — not convenience — is non-negotiable. |
← swipe the table →
Boiled down: TEE-first for internal analytics modernization, regulated BI, confidential feature engineering, and confidential streaming. MPC-first for data clean rooms, federated healthcare/finance analytics, cross-company joins, and ad measurement. FHE-first for private inference services, encrypted client-server scoring, and selected arithmetic analytics where plaintext must never exist server-side. Hybrid-first when collaboration, low trust, and practical performance all matter at once.
10 — ChecklistAdoption checklist
- State the trust requirement first: what adversary must be defeated (host OS, cloud operator, collaborating party, the server itself)? This single answer narrows the field fast.
- Map the workload shape — general SQL/streaming vs cross-party joins vs client-server inference — against the analytics-coverage table.
- Pin the latency and cost budget, then sanity-check it against representative benchmarks (TEE near-native; MPC network-bound; FHE accelerator-dependent).
- Decide attestation and key management early: reference values and KMS for TEEs; party/session and secret-share lifecycle for MPC; key + compiled-circuit pipeline for FHE.
- Write the output-governance policy — thresholds, allowed columns, repeated-query limits — because even correct execution can leak through permissive results.
- Pilot one narrow workload end-to-end, validate the security review against the real threat model, and only then industrialize.
- Plan for hybrids: TEE orchestration around MPC primitives, or FHE at the most sensitive client-server edge, is often the realistic production answer.
11 — FAQFrequently 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? +
12 — SourcesSources & further reading
Synthesized from vendor documentation, foundational papers, peer-reviewed benchmarks, standards, and 2025–2026 announcements.