Executive summary
, MPC, and FHE each address unique aspects of the common challenge: extracting value from confidential data while safeguarding it from unauthorized access. These technologies are distinct and cannot be used interchangeably. TEEs ensure data security. in use securing data by distributing trust among multiple computing parties, allowing no single party to access the inputs, while FHE allows an untrusted server to perform computations on ciphertexts without the decryption key. TEEs offer the most extensive workload compatibility and the most user-friendly experience for developers, while MPC provides the most robust data protection. cross-organization Collaborative analytics require a shared trust among multiple executors, and fully homomorphic encryption (FHE) offers the most secure solution for select tasks like private inference and arithmetic-heavy analytics, though at the expense of increased latency and specialized engineering. [1]
TEE technology is well-suited for encrypted analytics tasks such as general SQL queries, joins, ETL processes, Spark-style batch processing, ML training, and streaming engines. It allows software stacks to run in enclaves or confidential VMs with minimal modifications. On the other hand, MPC is most effective when multiple data owners require joint aggregates, joins, set intersections, or privacy-preserving training and inference without revealing plaintext to a third party. FHE excels when a client needs an untrusted service to perform computations on encrypted data without relying on hardware trust assumptions. However, it is best suited for constrained inference pipelines, vectorized arithmetic, small tabular models, and specialized encrypted data-frame operations rather than complex relational analytics. [2]
The primary trade-off involves the placement of trust. Trusted Execution Environments (TEEs) rely on CPU vendors, firmware, attestation roots, and the prevention of exploitable side channels. On the other hand, Multi-Party Computation (MPC) reduces trust in any one infrastructure provider, assuming enough parties abide by the corruption threshold outlined in the protocol. Fully Homomorphic Encryption (FHE) limits trust in the server during runtime and eliminates the risk of TEE hardware attacks, but it necessitates precise parameter selection, secure key management, side-channel resistant implementations, and control over output and metadata leakage at the application level. [3]
Strategic Recommendation
If the requirement is fast adoption of encrypted analytics over existing SQL/ML/streaming stacks, start with TEEs. If the requirement is joint analytics across mutually distrustful organizations MPC should carefully scope the output in accordance with the requirement. Computation is outsourced without exposing server plaintext or making hardware trust assumptions.In various production systems, a hybrid approach is often the ideal solution: TEE for stateful orchestration and software compatibility, MPC for cross-party primitives like joins or aggregation, and FHE for highly sensitive client-server inference or threshold-decryption workflows. [4]
Technology foundations
A TEE Intel's SGX and TDX, AMD's SEV-SNP, and Arm's CCA introduce hardware-backed isolated execution environments that protect code and data from the operating system, hypervisor, and system components, while allowing remote attestation for verifying running software before releasing secrets. [5]
MPC A group of cryptographic protocols allows multiple parties to compute a shared function using private inputs and only revealing the output. Initially introduced by Yao for secure two-party computation and later adapted by GMW for multi-party scenarios with honest-majority guarantees. Modern frameworks like MP-SPDZ utilize secret sharing, homomorphic encryption, and garbled circuits to implement various semi-honest and malicious protocols. Higher-level systems such as SecretFlow and SCQL offer data-analysis and SQL-like abstractions over MPC or hybrid privacy-enhancing technologies. [6]
FHE A cryptographic primitive enabling computation on encrypted data without needing the secret key was first established by Gentry in 2009, paving the way for feasible Fully Homomorphic Encryption (FHE) schemes. Today, various ecosystems like OpenFHE, Microsoft SEAL, TFHE-rs, and Concrete ML offer different schemes and APIs for encrypted computation involving integers, real numbers, Booleans, and machine learning. Current standards focus on RLWE/LWE-based schemes and standardized security parameters, showcasing the evolution of FHE from theoretical concept to practical system engineering. [7]
The following architecture patterns represent the primary deployment styles for encrypted analytics: TEEs store plaintext within trusted hardware, MPC ensures data confidentiality by distributing it among parties or non-colluding compute nodes, and FHE maintains end-to-end encryption of ciphertext through server-side evaluation, decrypting only at the client or threshold decryption endpoint. [8]
Deployment Architectures for Encrypted Analytics
FHE
MPC
TEE
Comparative View of Core Properties
| Property | TEEs | MPC | FHE |
|---|---|---|---|
| Main protection mechanism | Hardware isolation plus attestation | Secret sharing / garbled circuits / HE across multiple parties | Ciphertext-level computation [9] |
| Trust anchor | CPU vendor, platform firmware, attestation chain | Corruption threshold and non-collusion assumptions | Cryptographic hardness and parameter correctness [10] |
| Plaintext visible during execution | Yes, inside enclave/CVM memory | No single party sees full plaintext | No, server operates on ciphertext only [11] |
| Best fit | General-purpose analytics on existing stacks | Cross-party collaborative analytics | Client-server private computation on narrow circuits/models [12] |
| Hardware requirement | Specialized CPU support such as SGX, SEV-SNP, CCA | None intrinsic | None intrinsic; accelerators increasingly helpful [13] |
Analytics coverage and architecture patterns
The primary practical distinction lies not in the crypto definition but in the shape of analytics each technology can support without heroic redesignTEE inherit the adaptability of the software they support, making them the most convenient option for safeguarding SQL engines, data pipelines, training tasks, and real-time processors. Gramine prioritizes 'lift and shift' for unaltered Linux applications on SGX, Opaque SQL executes encrypted Spark SQL within hardware enclaves, and confidential-computing runtimes offer attestation and secret release for containerized workloads. [14]
MPC offers a wide range of analytic capabilities, often requiring specialized engineering for different workloads. MP-SPDZ covers various MPC protocols and security models, while ABY3 focuses on privacy-preserving machine learning in a three-party scenario. SecretFlow enables data analysis and machine learning, SCQL converts SQL into a hybrid MPC-plaintext execution graph, and tools like VaultDB and SECRECY demonstrate the feasibility of federated SQL operations on private data silos. [15]
FHE offers a limited range of analytics at a low cost, but its capabilities are growing. OpenFHE supports various operations such as CKKS, BFV, BGV, FHEW/TFHE-style, threshold FHE, and more. Concrete ML allows for encrypted inference, training for specific models, client/server APIs, hybrid model execution, and encrypted data-frame operations. TFHE-rs includes integer, Boolean, and string operations with optimized bootstrapping, including GPU benchmarks. While FHE is suitable for private inference and arithmetic-heavy analytics, it is not yet a complete replacement for SQL warehouses or streaming engines. [16]
Analytics Feature Comparison
| Analytics workload | TEEs | MPC | FHE |
|---|---|---|---|
| Aggregation | Excellent; arbitrary SQL and Spark-style aggregation work naturally inside enclaves/CVMs | Aggregation is a fundamental secure computation primitive that is widely utilized in SQL systems. | Beneficial for arithmetic and vectorized aggregations; actual effectiveness varies based on the design and complexity of the circuit. [17] |
| SQL select / filter / group-by | Strong; closest to plaintext execution model | Powerful yet more expensive; SCQL, VaultDB, SECRECY, and SMCQL all provide | Restricted access only through specialized encrypted data frames or compiled pipelines, not general SQL engines. [18] |
| Joins | Strong, including large equi-joins through existing engines | Supported and increasingly optimized, but often the dominant cost center | Weak for general joins, often substituted with custom equality circuits, PSI, or narrow tabular workflows. [19] |
| ML inference | Excellent for general models | Strong for common PPML settings | Strong for client-server private inference and some hybrid deep models [20] |
| ML training | Strong, including enclave-protected XGBoost and broader confidential training stacks | Linear models, trees, and collaborative training are all beneficial, while deep models still come with a high cost. | Limited to specific models; narrower than inference but available for a select few. [21] |
| Streaming analytics | Good fit when existing stream processors run in confidential environments | Primarily focused on specialized systems and composite/schematic configurations rather than traditional full-stack streaming services. | Not strong for general stream processing today; improved for specific encrypted transformations. [22] |
| Private set ops / entity resolution | Possible, but hardware trust remains central | Excellent; PSI and private joins are mature subfields | Possible in specialized constructions, but generally less turnkey than MPC [23] |
Mental Model
One helpful mental model is that TEEs are a close representation of 'encrypted analytics by. confidential execution," MPC approximates "encrypted analytics by distributed trust," and FHE approximates "encrypted analytics by encrypted algebraThis discrepancy impacts almost every subsequent decision in security evaluation, performance enhancement, and operations. [24]
A second pattern worth highlighting is the growing role of hybridsIn a practical sense, teams often blend MPC, HE, and other privacy tools in SecretFlow, leverage threshold and multiparty capabilities in OpenFHE, and utilize TEEs for attestation and secret-release functions to balance trust reduction with latency concerns. [25]
MPC for collaboration
TEE for orchestration
FHE for sensitive inference
Security guarantees and threat models
TEE's provide the most robust defense against a compromised host OS or malicious hypervisor within the vendor's threat modelAMD claims that the strength of their guarantees depends on the model's exclusions and patch posture, with SEV-SNP providing defense against malicious-hypervisor attacks and Arm CCA protecting Realm VMs. Meanwhile, Intel's SGX/TEE materials focus on attestation and enclave integrity, highlighting the significance of side-channel exclusions and firmware/microcode updates in their deployment history. [26]
The caveat is not merely theoretical. Both Foreshadow and Plundervolt have exposed vulnerabilities in core SGX confidentiality assumptions, with Intel's own guidance acknowledging the need for software-side mitigations against side-channel methods. Recent research on confidential-VMs has also demonstrated interrupt-based attacks against SEV-SNP and TDX. Even as late as 2026, AMD issued a bulletin for a SEV-SNP routing-misconfiguration issue that could compromise integrity under privileged attack conditions. The takeaway is not that TEEs are unusable, but that TEE security should be viewed as a continuously evolving systems-security target rather than a one-time cryptographic proof. [27]
MPC offers a more secure narrative compared to a malevolent cloud operator, as no individual executor possesses the plaintext. However, its assurances are reliant on various protocol assumptions such as party settings, adversary types, and collusion levels. GMW's traditional approach with an honest majority and MP-SPDZ's flexibility for both semi-honest and malicious scenarios highlight the wide range of possibilities. For instance, SECRECY's outsourced analytics framework maintains data confidentiality unless a majority of non-colluding cloud providers are compromised by the adversary. [28]
A 2025 study on SPDZ implementations revealed that even though MPC is not 'secure by theorem alone' at the implementation layer, practical security issues were still present. This highlights the importance of rigorous software assurance, concurrency testing, and deployment discipline in modern MPC stacks. [29]
FHE provides the cleanest server-side confidentiality The server can be guaranteed of the security of the system without needing to see plaintext at all, thanks to modern FHE security guidance based on LWE/RLWE hardness assumptions and parameter selection. OpenFHE is designed to align with HomomorphicEncryption.org post-quantum security standards. However, it is important to note that FHE does not completely conceal all information. Metadata, access patterns, model structure, and outputs can still potentially reveal information at the application layer, and there have been demonstrations of side channels against FHE libraries. Therefore, additional measures such as output filtering, model-partitioning, or threshold decryption policies may be necessary in addition to cryptography to enhance security. [30]
Security Comparison
| Dimension | TEEs | MPC | FHE |
|---|---|---|---|
| Protects against compromised OS / hypervisor | Yes, by design | Yes, if protocol assumptions hold; no single host is trusted | Yes, server can operate without plaintext [31] |
| Side-channel exposure | High relative concern; microarchitectural and interrupt/fault channels are operationally central | Decreased reliance on hardware side channels, however, vulnerabilities in software and data leakage through outputs persist. | Steers clear of TEE hardware limitations, yet implementations and metadata may still be exposed. [32] |
| Trust in hardware vendor | High | Low | Low [9] |
| Trust in non-collusion assumption | Low to none | Central | Usually none for single-server evaluation; threshold decryption may add it [33] |
| Attestation / proof of correct environment | Core requirement | Usually not hardware-attestation-based; correctness comes from protocol | Not environment-based; correctness is circuit and cryptographic evaluation dependent [34] |
| Main leakage channel after deployment | Side channels, enclave exits, model/output leakage | Output leakage and access-pattern leakage are dependent on the system, as well as the potential for collusion or active cheating | Output leakage, metadata, application design, implementation side channels [35] |
Performance, scalability, and costs
TEE's consistently outperform in terms of workload flexibility and often in terms of latency as well. However, SGX-era enclaves can be heavily impacted by enclave exits and protected-memory limits. Thankfully, newer runtimes and confidential-VM approaches have significantly improved the situation for many workloads. In a study conducted by Opaque on SGX, it was found that exceeding the EPC size by even a small amount led to roughly a 50-60% overhead for sort microbenchmarks, with an average I/O-encryption overhead of 7.46% and an average end-to-end overhead of 31.7%. In broader query tests, Opaque's encryption mode showed performance improvements ranging from 52% to a 3.3x slowdown compared to Spark SQL, while its oblivious mode added approximately 1.2x to 46x overhead. A separate study on 2023 Gramine+SGX HPC work revealed a 4-17% overhead on compute- and bandwidth-sensitive workloads, but up to 170% overhead on memory-latency-sensitive workloads. [36]
Confidential-VM TEEs are often preferred over SGX for 'lift-and-shift' analytics due to their avoidance of SGX's per-process enclave model and small EPC constraints. Recent evaluations highlight the transition from process-based SGX to VM-based SEV/TDX, with a 2024 study showing up to 8.5% throughput overhead for confidential VMs on NEXMark query workloads. This is why TEEs are commonly chosen for encrypted streaming analytics and legacy SQL engines. [37]
The performance of MPC is heavily influenced by factors such as communication rounds, network latency, batching strategy, and costly nonlinear operators like comparison and join. SECRECY's results are particularly valuable as they pertain directly to relational-analytics scenarios: batching significantly reduces communication latency compared to eager messaging, enabling the exchange of 100 million 64-bit shares in around 2 seconds. While million-row secure analytics are achievable, some join-heavy queries still take tens of minutes to hours to run. For instance, SECRECY reports approximately 20 minutes for a password-reuse query and 1.2 hours for a recurrent C. diff. query with 2 million rows. The system can handle up to 10 billion equality and inequality comparisons within the specified experiment-duration limit. ABY3 also illustrates the impressive speed of honest-majority MPC, achieving processing rates in the billions of AND gates per second under optimized conditions. [38]
FHE is still significantly slower than plaintext, but there is real progress being made. According to benchmarks from the FHE-library SoK, the best choice depends on the type of workload: TFHE performs best for binary circuits, HElib excels in parallel instances, and PALISADE leads in arithmetic benchmarks. Recent TFHE-rs documentation demonstrates benchmarking on H100 GPUs and 8xH100 systems, highlighting the trend of FHE relying on hardware acceleration. Concrete ML's examples show that small linear models can execute in around 1 ms in FHE, but caution is needed when extrapolating to more complex models or SQL logic. [39]
Performance, Scalability, and Costs
| Performance & Scalability | |
|---|---|
| Latency profile | TEEs: Near-native to moderate. MPC: Network-sensitive, slower. FHE: Slowest, circuit dependent. [40] |
| Bottlenecks | TEEs: Memory limits, attestation. MPC: Comms rounds, joins. FHE: Bootstrapping, key sizes. [41] |
| Hardware Accel | TEEs: CVMs/GPUs. MPC: Standard compute + network. FHE: Crucial (GPUs/ASICs). [43] |
Ecosystem, tooling, and maturity
TEE platforms offer a mature ecosystem for infrastructure teams, with Intel, AMD, and Arm all releasing confidential-computing hardware stacks. Open Enclave offers a cross-TEE SDK, Gramine simplifies SGX integration for Linux workloads, Enarx focuses on WebAssembly-based portability across TEEs, and Confidential Containers brings attestation and secret delivery to Kubernetes orchestration. The main challenge lies in the complexity of secure operations, patch management, and side-channel-aware workload design, rather than a lack of tooling. [49]
While MPC tooling has matured in research and become more practical, it still lacks the standardization seen in the TEE stack. MP-SPDZ is known for its versatility with multiple protocols and security models, ABY3 is respected in the field of PPML, SecretFlow combines collaborative data analysis, ML, PSI, and SQL-adjacent systems, and SCQL provides a genuine SQL front end with MySQL-like syntax and explicit column-control policies. However, usability in MPC tooling often relies on restricted workloads or security policies rather than the flexible execution model found in TEE deployments. [50]
The open-source ecosystem of FHE is evolving rapidly, with OpenFHE offering extensive academic-library capabilities, including threshold FHE and scheme switching. Microsoft SEAL continues to be a key library for BFV/CKKS-focused projects, while TFHE-rs is shifting towards production-oriented solutions, particularly for Boolean/integer tasks. HEBench offers a benchmarking platform, and Concrete ML provides Python APIs, deployment guidance, hybrid execution, and practical ML examples. Compared to TEEs and MPC, FHE requires a higher level of cryptographic knowledge or reliance on specific frameworks as projects move beyond basic examples. [51]
Maturity and Adoption Milestones Relevant to Encrypted Analytics [56]
Compliance, operations, and deployment realities
When considering compliance, it is best to view all three technologies as risk-reducing technical measuresGDPR Article 32 highlights encryption and pseudonymisation as effective security measures for processing, while HIPAA's Security Rule mandates a risk-based approach to safeguarding ePHI. PCI DSS sets out technical and operational standards for protecting payment account data, with a focus on retention minimization and strong cryptography for stored card data. While technologies like TEEs, MPC, and FHE can enhance control environments, they do not negate the need for lawful basis analysis, data-minimization strategies, auditing, retention limits, or output governance. [57]
Operationally, TEEs center on attestation and secret releaseThe Open Enclave, Gramine, Confidential Containers Trustee, and NVIDIA's attestation flow all view attestation as the critical step that must be successful before secrets can be provisioned. This requires production teams to have reference-value management, KMS integration, certificate lifecycle management, image signing, and patch-driven re-attestation workflows. Monitoring becomes more challenging as debugging and introspection clash with confidentiality goals. [58]
Operationally, MPC centers on party coordinationTeams need to determine the host for compute parties, define colluding permissions, establish session rotation protocols, address offline party failures, and establish guidelines for permitted outputs. The importance of output policy is exemplified by SCQL's column-control list, as even properly executed privacy-preserving queries can inadvertently disclose sensitive information if result policies are too lenient or if repeated queries are not properly regulated. [59]
Operationally, FHE centers on key and circuit lifecycleConcrete ML's deployment model segregates client.zip cryptographic parameters from server.zip compiled model artifacts, highlighting the time-consuming nature of key generation and the potential for large keys. Additionally, it cautions that compiled artifacts are specific to machine architecture. As a result, CI/CD for FHE often mirrors a compiler toolchain combined with a crypto-parameter-management pipeline rather than a traditional ML model-serving pipeline. [60]
Case studies, benchmarks, and decision framework
The TEE Case studies show that TEEs are the closest solution for when the workload involves a real analytics engine that needs to be kept confidential. Opaque and Secure XGBoost both showcased how TEEs can efficiently handle encrypted data without compromising performance. This demonstrates that TEEs can be used as a secure platform for analytics and machine learning on sensitive data. [61]
The MPC Case studies show that data ownership is most effective when distributed. VaultDB was implemented in three healthcare facilities in Chicago for clinical research using SQL, demonstrating that federated SQL with privacy protection can go beyond just demonstrations in a lab setting. Meta's Private Lift Measurement utilizes MPC to ensure that neither Meta nor the advertiser has to share both datasets. SECRECY and SCQL highlight the latest advancements in outsourced or federated relational analytics, offering support for SQL, joins, aggregation, and security-policy controls. [62]
Public FHE Case studies now focus more on productized pilots, benchmarks, and packaged demos rather than large enterprise disclosures. Concrete ML offers a range of examples including end-to-end client/server deployment patterns, encrypted data-frame support, sentiment analysis, credit scoring, tree-models, and hybrid neural-network and LLM examples. TFHE-rs also provides documentation on string operations and GPU-backed integer/bootstrapping benchmarks. While FHE is proving to be operationally real, public evidence still mainly centers on specific workloads rather than broad production analytics. This is leading many teams to use FHE at the edges of systems rather than as the universal execution model. [63]
Decision Framework
| Use case | Best first choice | Why | When to choose differently |
|---|---|---|---|
| Single-organization confidential SQL / ETL / BI | TEE | Broad compatibility with existing engines and the best latency profile | Only use FHE if it is essential that there is never any plaintext on the server and the query set is limited. [64] |
| Cross-organization joins, clean rooms, collaborative aggregates | MPC | SQL and PSI ecosystems are credible because no single operator can have access to all data. | Add TEE for easier orchestration; add FHE for client-server steps [65] |
| Private ML inference as a service | FHE or Hybrid | Strong server-side confidentiality; concrete client/server deployment patterns exist | Use TEE instead if latency or model breadth matters more [66] |
| Confidential ML training on existing frameworks | TEE | Highest software compatibility | MPC for collaborative training; FHE only for narrow classes [67] |
| Streaming analytics on sensitive data | TEE | Best match to existing stream processors and fault-tolerant runtimes | MPC for specialized sketches; FHE for narrow transforms [68] |
| Lowest operational friction for near-term rollout | TEE | Best ecosystem support and closest to standard infra practices | MPC/FHE if the trust model, not convenience, is non-negotiable [70] |
Open questions and limitations
- Benchmark comparability: The lack of perfect comparability in public benchmarks persists, as TEE studies often involve contrasting hardware generations and runtimes, MPC studies are influenced by network topology and corruption models, and FHE studies differ based on scheme, packing strategy, and GPU utilization. HEBench was created specifically due to the difficulty in achieving standardized comparisons. [72]
- Security posture: The security stance of all three families is in flux. TEEs are constantly adapting to new attack classes and vendor advisories, MPC implementations are grappling with real software-security challenges despite solid theoretical foundations, and FHE implementations require side-channel protection and meticulous metadata governance. It is important to note that none of these technologies should be relied upon as a replacement for secure software engineering practices. [73]
- Evidence base: The public evidence base shows that TEE and MPC have more documented analytics deployments and SQL-oriented systems compared to FHE. FHE, on the other hand, has its strongest evidence in standards, libraries, deployment APIs, and focused application demos rather than large-scale production analytics disclosures. It is important to make architectural decisions with a realistic understanding of the current maturity levels in mind. [74]
References
- Data Product Concepts https://www.dataproduct.net/ [1, 5, 9, 11, 24, 49]