Confidential Computing, MPC, and FHE for Encrypted Analytics

Executive summary

Trusted execution environments, multi-party computation, and fully homomorphic encryption solve different versions of the same problem: how to derive value from sensitive data without exposing plaintext to an untrusted party. They are not interchangeable. TEEs protect data in use by isolating computation inside attested hardware boundaries; MPC protects data by distributing trust across multiple computing parties so that no single party sees the inputs; FHE lets an untrusted server compute directly on ciphertexts without access to the decryption key. In practice, TEEs deliver the broadest workload compatibility and the best near-term developer ergonomics, MPC delivers the strongest fit for cross-organization collaborative analytics where no single executor should be trusted, and FHE delivers the strongest "no plaintext on the server" story for carefully chosen workloads, especially private inference and arithmetic-heavy analytics, at the cost of far higher latency and engineering specialization. ^[1]

For encrypted analytics specifically, TEEs are the most natural fit for general SQL, joins, ETL, Spark-style batch processing, existing ML training code, and streaming engines because they can run largely unmodified software stacks inside enclaves or confidential VMs. MPC is strongest when multiple data owners need joint aggregates, joins, set intersection, or privacy-preserving training and inference without surrendering plaintext to a shared operator. FHE is strongest when a client wants an untrusted service to compute on its encrypted data without any hardware trust assumption, but it remains most practical for constrained inference pipelines, vectorized arithmetic, small tabular models, and specialized encrypted data-frame operations rather than arbitrary relational analytics. ^[2]

The key trade-off 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 it assumes enough parties remain honest or non-colluding according to the protocol's corruption threshold and that the implementation is correct. FHE minimizes runtime trust in the server and avoids a TEE hardware attack surface, but it still depends on careful parameter selection, key management, side-channel-safe implementations, and application-level control of output and metadata leakage. ^[3]

Technology foundations

A TEE is a hardware-backed isolated execution environment that protects code and data from the surrounding operating system, hypervisor, and other system components, while exposing attestation so that a remote party can verify what software is running before releasing secrets. Intel's current confidential-computing materials frame SGX and TDX as TEEs; AMD describes SEV-SNP as adding memory integrity protection against malicious-hypervisor attacks; Arm CCA introduces "Realms" as VM-scale isolated execution environments managed through the Realm Management Monitor. ^[5]

MPC is a family of cryptographic protocols that lets parties compute a joint function over private inputs while revealing only the output. In the classic lineage, Yao introduced secure two-party computation and GMW generalized secure computation to the multi-party setting with honest-majority guarantees. Modern frameworks such as MP-SPDZ implement a wide range of semi-honest and malicious protocols using secret sharing, homomorphic encryption, and garbled circuits, while higher-level systems such as SecretFlow and SCQL expose data-analysis and SQL-like abstractions over MPC or hybrid privacy-enhancing technologies. ^[6]

FHE is a cryptographic primitive that allows arbitrary computation on encrypted data without access to the secret key. Gentry's 2009 construction established the first plausible FHE scheme; current ecosystems such as OpenFHE, Microsoft SEAL, TFHE-rs, and Concrete ML package different schemes and APIs for integer, real-number, Boolean, and ML-oriented encrypted computation. The modern standards effort emphasizes RLWE/LWE-based schemes and standardized security parameters, reflecting that FHE has shifted from pure theory to implementable systems engineering. ^[7]

The architecture patterns below capture the dominant deployment styles used in encrypted analytics. TEEs keep plaintext inside attested hardware; MPC keeps data secret by splitting it across parties or non-colluding compute nodes; FHE keeps ciphertext encrypted end to end through server-side evaluation and only decrypts at the client or threshold decryption endpoint. ^[8]

Comparative View of Core Properties

Analytics coverage and architecture patterns

The most important practical difference is not the crypto definition but the shape of analytics each technology can support without heroic redesign. TEEs inherit the flexibility of the software they can host. Gramine emphasizes "lift and shift" for unmodified Linux applications on SGX, Opaque SQL runs encrypted Spark SQL inside hardware enclaves, and confidential-computing runtimes support attestation and secret release for containerized workloads. That makes TEEs the easiest way to protect existing SQL engines, feature pipelines, model-training jobs, and stream processors. ^[14]

MPC supports a surprisingly broad analytic surface, but usually with more workload-specific engineering. MP-SPDZ spans multiple MPC protocols and security models; ABY3 explicitly targets privacy-preserving machine learning in a three-party setting; SecretFlow exposes data analysis and ML; SCQL translates SQL into a hybrid MPC-plaintext execution graph; and systems such as VaultDB and SECRECY show that federated SQL, joins, group-by, and aggregate queries are feasible over private data silos. ^[15]

FHE supports the narrowest set of analytics most economically, but that set is expanding. OpenFHE supports CKKS, BFV, BGV, FHEW/TFHE-style operations, threshold FHE, proxy re-encryption, and scheme switching for functions such as comparison and lookup tables. Concrete ML exposes encrypted inference, some encrypted training support for selected models, client/server deployment APIs, hybrid model execution, and encrypted data-frame operations. TFHE-rs adds integer, Boolean, and string operations and aggressively optimized programmable bootstrapping, including GPU benchmarks on H100 systems. This makes FHE credible today for private inference, arithmetic-heavy tabular analytics, encrypted transforms, and some custom string or data-frame operations, but still far from a drop-in substitute for full SQL warehouses or arbitrary streaming engines. ^[16]

Analytics Feature Comparison

A second pattern worth highlighting is the growing role of hybrids. SecretFlow explicitly combines MPC, HE, and other privacy-enhancing devices in one framework, OpenFHE supports threshold and multiparty extensions, and TEEs increasingly provide attestation and secret-release plumbing around cryptographic kernels. In practice, hybridization is often how teams reconcile trust minimization with acceptable latency. ^[25]

Security guarantees and threat models

TEEs offer the strongest story against a compromised host OS or malicious hypervisor within the vendor's threat model, but their guarantees are only as strong as that model's exclusions and the operational patch posture. AMD states that SEV-SNP adds protection against malicious-hypervisor attacks such as replay and memory remapping, and Arm CCA protects Realm VMs from the host hypervisor and other VMs. Intel's SGX/TEE materials emphasize attestation and enclave integrity, yet SGX's deployment history also shows the importance of side-channel exclusions and firmware/microcode updates. ^[26]

That caveat is not theoretical. Foreshadow broke core SGX confidentiality assumptions through speculative execution, Plundervolt showed enclave-integrity compromise through undervolting, Intel's own guidance documents acknowledge the need for software-side mitigations against side-channel methods, and 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 right conclusion is not that TEEs are unusable, but that TEE security must be treated as a moving systems-security target rather than a one-time cryptographic proof. ^[27]

MPC has a cleaner story against a malicious cloud operator because no single executor holds the plaintext, but its guarantees depend on protocol assumptions: two-party or three-party settings, honest or dishonest majority, semi-honest or malicious adversaries, and the extent of tolerated collusion. GMW's classic honest-majority framing and MP-SPDZ's support for both semi-honest and malicious settings illustrate this spectrum. SECRECY's outsourced analytics model, for example, keeps data private as long as the adversary does not compromise a majority of the non-colluding cloud providers. ^[28]

MPC is also not "secure by theorem alone" at the implementation layer. A 2025 study on SPDZ implementations found practical security issues despite the protocol family's malicious-security design point, underscoring that modern MPC stacks still need rigorous software assurance, concurrency testing, and deployment discipline. ^[29]

FHE provides the cleanest server-side confidentiality guarantee of the three because the server need not see plaintext at all. Modern FHE security guidance is rooted in LWE/RLWE hardness assumptions and parameter selection; OpenFHE explicitly aligns with HomomorphicEncryption.org post-quantum security standards. But FHE does not automatically hide everything. Metadata, access patterns, model structure, and outputs can still leak information at the application layer, and implementation side channels against FHE libraries have been demonstrated. As a result, FHE often needs output filtering, model-partitioning, or threshold decryption policies in addition to cryptography. ^[30]

Security Comparison

Performance, scalability, and costs

TEEs consistently win on raw workload flexibility and usually on latency. SGX-era enclaves can still suffer heavily from enclave exits and protected-memory limits, but newer runtimes and confidential-VM approaches substantially improve the picture for many workloads. Opaque's SGX study showed that exceeding the EPC size by even a little incurred roughly 50–60% overhead for sort microbenchmarks, with average I/O-encryption overhead of 7.46% and average end-to-end overhead of 31.7% in the cited setup. In broader query tests, Opaque's encryption mode ranged from a 52% performance improvement to a 3.3x slowdown relative to Spark SQL, while its oblivious mode added about 1.2x–46x overhead. Separate 2023 Gramine+SGX HPC work found 4–17% overhead on compute- and bandwidth-sensitive workloads but up to 170% on memory-latency-sensitive workloads. ^[36]

Confidential-VM TEEs frequently look better than SGX for "lift-and-shift" analytics because they avoid SGX's per-process enclave model and small EPC constraints. Recent comparative evaluations emphasize the paradigm shift from process-based SGX toward VM-based SEV/TDX, and a 2024 stream-processing study reported up to 8.5% throughput overhead for confidential VMs on NEXMark query workloads. That is precisely why TEEs are often the default answer for encrypted streaming analytics and legacy SQL engines. ^[37]

MPC performance is dominated by communication rounds, network latency, batching strategy, and expensive nonlinear operators such as comparison and join. SECRECY's results are especially useful because they are directly in the relational-analytics setting: batching reduced communication latency by two to four orders of magnitude compared with eager messaging, 100 million 64-bit shares could be exchanged in about 2 seconds in the published setup, and million-row secure analytics were feasible, though some join-heavy queries still ran for tens of minutes to hours. At 2 million rows, SECRECY reports about 20 minutes for a password-reuse query and about 1.2 hours for a recurrent C. diff. query; it can process up to 10 billion equality and inequality comparisons within the reported experiment-duration limit. ABY3 also demonstrates that honest-majority MPC can be extremely fast on its own terms, citing processing rates in the billions of AND gates per second in optimized settings. ^[38]

FHE remains orders of magnitude slower than plaintext, but the slope of improvement is real. Standardized benchmarks from the FHE-library SoK show that relative winners depend strongly on workload shape: TFHE had the best single-instance latency for binary-oriented circuits, while HElib could win when many instances are parallelized through batching, and PALISADE led some arithmetic benchmarks in that study. Recent TFHE-rs documentation shows production-oriented benchmarking on H100 GPUs and 8xH100 systems, underscoring that modern FHE increasingly assumes hardware acceleration rather than CPU-only execution. Concrete ML's published examples also show that very small linear and generalized linear models can execute in around 1 ms in FHE, though this should not be extrapolated to tree ensembles, deep models, or general SQL logic. ^[39]

Performance, Scalability, and Costs

Ecosystem, tooling, and maturity

TEEs have the most mature "platform" ecosystem for general infrastructure teams. Intel, AMD, and Arm all publish confidential-computing hardware stacks; Open Enclave provides a cross-TEE SDK; Gramine makes SGX integration simpler for Linux workloads; Enarx targets WebAssembly-based portability across TEEs; and Confidential Containers brings attestation and secret delivery into Kubernetes-oriented orchestration. The limiting factor is less the lack of tooling than the complexity of secure operations, patch management, and side-channel-aware workload design. ^[49]

MPC tooling is mature in research and increasingly usable in practice, but still less standardized than the TEE stack. MP-SPDZ is the canonical "many protocols, many security models" engine; ABY3 remains influential for PPML; SecretFlow packages collaborative data analysis, ML, PSI, and SQL-adjacent systems; and SCQL offers a genuine SQL front end with MySQL-like syntax and explicit column-control policies. The trade-off is that usability often comes from carefully constrained workloads or security policies rather than the free-form execution model common in TEE deployments. ^[50]

FHE's open-source ecosystem is moving quickly. OpenFHE offers the broadest academic-library surface, including threshold FHE and scheme switching; Microsoft SEAL remains a foundational library for BFV/CKKS-oriented work; TFHE-rs is increasingly production-focused, especially for Boolean/integer workloads; HEBench provides a benchmarking framework; and Concrete ML gives Python-facing APIs, deployment classes, hybrid execution, and concrete examples for ML engineers. Relative to TEEs and MPC, however, FHE still demands more cryptographic literacy or framework lock-in when teams move beyond canned examples. ^[51]

Compliance, operations, and deployment realities

From a compliance perspective, all three technologies are best viewed as risk-reducing technical measures, not scope-elimination machines. GDPR Article 32 explicitly identifies encryption and pseudonymisation as examples of appropriate technical and organizational measures for security of processing. HIPAA's Security Rule is explicitly risk-based and requires covered entities and business associates to ensure the confidentiality, integrity, and availability of ePHI. PCI DSS defines a baseline of technical and operational requirements to protect payment account data, and PCI guidance around stored card data still emphasizes retention minimization and strong cryptography. In other words, TEEs, MPC, and FHE can materially strengthen a control environment, but they do not replace lawful basis analysis, data-minimization decisions, auditing, retention limits, or output governance. ^[57]

Operationally, TEEs center on attestation and secret release. Open Enclave, Gramine, Confidential Containers Trustee, and NVIDIA's attestation flow all treat attestation as the gate that must succeed before secrets are provisioned. That means production teams need reference-value management, KMS integration, certificate lifecycle management, image signing, and patch-driven re-attestation workflows. Monitoring is also harder because debugging and introspection compete directly with confidentiality objectives. ^[58]

Operationally, MPC centers on party coordination. Teams must decide who hosts compute parties, who is allowed to collude with whom, how to rotate or rebootstrap sessions, how to handle failures when one party goes offline, and how to govern allowed outputs. SCQL's column-control list is a good example of why output policy is not optional: even a correctly executed privacy-preserving query can still leak sensitive information if result policies are too permissive or if repeated queries are not governed. ^[59]

Operationally, FHE centers on key and circuit lifecycle. Concrete ML's deployment model separates client.zip cryptographic parameters from server.zip compiled model artifacts, explicitly notes that key generation can be time-consuming and produce large keys, and warns that compiled artifacts are machine-architecture-specific. In practice this means CI/CD for FHE often resembles a compiler toolchain plus crypto-parameter-management pipeline, not a conventional ML model-serving pipeline. ^[60]

Case studies, benchmarks, and decision framework

The TEE case studies are the most directly analogous to conventional analytics. Opaque showed how Spark SQL workloads can run over encrypted data inside SGX with encryption-mode performance competitive with Spark SQL on some queries and significant overhead only when stronger obliviousness is required. Secure XGBoost demonstrated enclave-protected collaborative training and inference, adding data-oblivious algorithms to reduce access-pattern leakage. MC² positioned TEEs as a platform substrate for secure analytics and ML on encrypted data. These are strong indicators that TEEs are the nearest-term answer when the workload is "a real analytics engine, but confidential." ^[61]

The MPC case studies are strongest where data ownership is distributed. VaultDB was deployed across three healthcare institutions in the Chicago area for SQL-based clinical research, showing that privacy-preserving federated SQL can move beyond lab demos. Meta's Private Lift Measurement uses MPC so neither Meta nor the advertiser must entrust the other with both datasets. SECRECY and SCQL show the state of the art in outsourced or federated relational analytics, with SQL support, joins, aggregation, and explicit security-policy controls. ^[62]

Public FHE case studies are less dominated by large enterprise disclosures and more by productized pilots, benchmarks, and packaged demos. Concrete ML publishes end-to-end client/server deployment patterns, encrypted data-frame support, encrypted sentiment analysis, credit scoring, tree-model examples, and hybrid neural-network and LLM examples; TFHE-rs documents string operations and GPU-backed integer/bootstrapping benchmarks. The practical reading is that FHE is operationally real, but public evidence is still concentrated in focused workloads rather than broad warehouse-style production analytics. That is one reason many teams use FHE at the edges of systems rather than as the system's universal execution model. ^[63]

Decision Framework