Executive summary
MPC, FHE, and TEE all tackle different angles of the shared problem: unlocking value from sensitive data while protecting it from unauthorized access. These technologies are separate and not interchangeable, with TEEs focusing on securing data. in use Data security is ensured through the distribution of trust among various computing parties, preventing any single entity from accessing the data. Fully Homomorphic Encryption (FHE) enables an untrusted server to process encrypted data without the need for decryption. Trusted Execution Environments (TEEs) offer high compatibility with workloads and a user-friendly development experience, while Multi-Party Computation (MPC) provides the strongest level of data protection. cross-organization Collaborative analytics demand a collective trust among multiple participants, and fully homomorphic encryption (FHE) provides the highest level of security for specific tasks such as private inference and arithmetic-heavy analytics, albeit with added latency and specialized engineering. [1]
TEE technology is ideal for secure analytics tasks like SQL queries, ETL processes, batch processing, ML training, and streaming engines. It enables software to operate in enclaves or confidential VMs with minimal adjustments. In contrast, MPC is most beneficial when multiple data owners need to collaborate on aggregates, joins, set intersections, or private training and inference without exposing plaintext to a third party. FHE is excellent for clients who require untrusted services to perform computations on encrypted data without relying on hardware trust assumptions. However, it is better suited for limited inference pipelines, vectorized arithmetic, small tabular models, and specialized encrypted data-frame operations rather than complex relational analytics. [2]
The main trade-off involves trust placement in security measures. Trusted Execution Environments (TEEs) depend on CPU vendors, firmware, attestation roots, and preventing exploitable side channels. Conversely, Multi-Party Computation (MPC) lessens reliance on a single infrastructure provider by requiring multiple parties to adhere to a corruption threshold in the protocol. Fully Homomorphic Encryption (FHE) decreases trust in the server during runtime and removes the threat of TEE hardware attacks, but requires careful 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 needs to accurately define the output based on the requirement. Computation is outsourced securely, without revealing server plaintext or relying on hardware trust assumptions.A hybrid approach is frequently the best solution in different production systems: TEE for stateful orchestration and software compatibility, MPC for cross-party primitives such as 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 all provide hardware-based isolated execution environments that safeguard code and data from the operating system, hypervisor, and system components. These technologies also enable remote attestation to verify the integrity of running software before disclosing confidential information. [5]
MPC Cryptographic protocols enable multiple parties to jointly compute a shared function using private inputs while only disclosing the final output. Originally proposed by Yao for secure two-party computation, this concept was further developed by GMW for multi-party scenarios with honest-majority guarantees. Contemporary frameworks like MP-SPDZ leverage secret sharing, homomorphic encryption, and garbled circuits to support a wide range of semi-honest and malicious protocols. Advanced systems such as SecretFlow and SCQL provide higher-level abstractions for data analysis and SQL-like operations over MPC or hybrid privacy-enhancing technologies. [6]
FHE In 2009, Gentry introduced a cryptographic primitive that allowed computation on encrypted data without the need for the secret key, laying the foundation for practical Fully Homomorphic Encryption (FHE) schemes. Today, OpenFHE, Microsoft SEAL, TFHE-rs, and Concrete ML provide various schemes and APIs for encrypted computation with integers, real numbers, Booleans, and machine learning. Current standards prioritize RLWE/LWE-based schemes and standardized security parameters, highlighting the transformation of FHE from theory to practical engineering. [7]
The main deployment styles for encrypted analytics include Trusted Execution Environments (TEEs) storing plaintext in secure hardware, Multi-Party Computation (MPC) distributing data among parties or compute nodes to maintain confidentiality, and Fully Homomorphic Encryption (FHE) enabling end-to-end encryption of ciphertext with server-side evaluation and client-side decryption. [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 main practical difference is not found in the crypto definition but in the. shape of analytics each technology can support without heroic redesignTEE systems leverage the flexibility of supported software, making them ideal for securing SQL engines, data pipelines, training tasks, and real-time processors. Gramine focuses on 'lift and shift' for unchanged Linux applications on SGX, Opaque SQL runs encrypted Spark SQL in hardware enclaves, and confidential-computing runtimes provide attestation and secret release for containerized workloads. [14]
MPC provides a diverse set of analytical features that may necessitate unique engineering for specific tasks. MP-SPDZ encompasses multiple MPC protocols and security models, whereas ABY3 concentrates on preserving privacy in a three-party setting. SecretFlow supports data analysis and machine learning, SCQL transforms SQL into a hybrid MPC-plaintext execution graph, and platforms such as VaultDB and SECRECY showcase the possibility of federated SQL operations on confidential data repositories. [15]
FHE provides a limited range of analytics at an affordable price, with expanding capabilities. OpenFHE offers support for operations like CKKS, BFV, BGV, FHEW/TFHE-style, threshold FHE, and more. Concrete ML enables 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, along with GPU benchmarks. While FHE is ideal for private inference and arithmetic-heavy analytics, it does not fully replace SQL warehouses or streaming engines yet. [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 key secure computation tool that is extensively used in SQL systems. | Suitable for arithmetic operations and vectorized aggregations, the actual performance may differ depending on the circuit's design and complexity. [17] |
| SQL select / filter / group-by | Strong; closest to plaintext execution model | While more expensive, SCQL, VaultDB, SECRECY, and SMCQL all offer powerful features | Access is limited to specialized encrypted data frames or compiled pipelines, and not general SQL engines. [18] |
| Joins | Strong, including large equi-joins through existing engines | Supported and increasingly optimized, but often the dominant cost center | Not suitable for general joins, frequently replaced by 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 offer advantages, whereas deep models remain costly. | Restricted to certain models; more limited than deduction but accessible to a chosen few. [21] |
| Streaming analytics | Good fit when existing stream processors run in confidential environments | Mainly concentrating on specialized systems and composite/schematic arrangements instead of conventional full-stack streaming services. | Currently lacking in strength for general stream processing, but excelling in 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
A useful mental model to consider is that Trusted Execution Environments (TEEs) closely mimic 'encrypted analytics by'. confidential execution," MPC approximates "encrypted analytics by distributed trust," and FHE approximates "encrypted analytics by encrypted algebraThis inconsistency affects nearly every decision made in security assessment, performance improvement, and operational processes. [24]
A second pattern worth highlighting is the growing role of hybridsPractically speaking, teams frequently combine MPC, HE, and other privacy tools within SecretFlow, use threshold and multiparty features in OpenFHE, and employ TEEs for attestation and secret-release functions to manage trust reduction and latency issues effectively. [25]
MPC for collaboration
TEE for orchestration
FHE for sensitive inference
Security guarantees and threat models
TEEs offer the strongest protection against a compromised host OS or malicious hypervisor. within the vendor's threat modelAMD asserts that the effectiveness of their assurances is contingent upon the model's inclusions and patch readiness, with SEV-SNP offering protection against malicious-hypervisor threats and Arm CCA safeguarding Realm VMs. Conversely, Intel's SGX/TEE resources concentrate on attestation and enclave integrity, emphasizing the importance of side-channel inclusions and firmware/microcode updates in their deployment track record. [26]
The warning is not just theoretical. Both Foreshadow and Plundervolt have revealed flaws in core SGX privacy assumptions, prompting Intel to recommend software-based defenses against side-channel attacks. Recent studies on confidential-VMs have also uncovered interrupt-driven assaults on SEV-SNP and TDX. Even in 2026, AMD flagged a SEV-SNP routing error that could jeopardize integrity in privileged attack scenarios. The lesson is not that TEEs are ineffective, but that TEE security must be seen as an ever-changing systems-security goal rather than a one-off cryptographic guarantee. [27]
MPC provides a secure narrative by preventing any single executor from having access to plaintext data, but its effectiveness depends on protocol assumptions like party settings, adversary types, and collusion levels. GMW's approach relies on an honest majority, while MP-SPDZ offers flexibility for both semi-honest and malicious scenarios. SECRECY's outsourced analytics framework ensures data confidentiality as long as a majority of non-colluding cloud providers are not compromised by the adversary. [28]
A study conducted in 2025 found that despite MPC not being inherently secure at the implementation level, practical security concerns persisted in SPDZ implementations. This underscores the critical need for thorough software assurance, concurrency testing, and disciplined deployment practices in contemporary MPC frameworks. [29]
FHE provides the cleanest server-side confidentiality The server can ensure system security without viewing plaintext, thanks to modern FHE security guidelines based on LWE/RLWE hardness assumptions and parameter selection. OpenFHE follows HomomorphicEncryption.org's post-quantum security standards. It is worth noting that FHE does not fully hide all information, as metadata, access patterns, model structure, and outputs could disclose information at the application layer. Side channels against FHE libraries have been demonstrated, so additional security measures like output filtering, model partitioning, or threshold decryption policies may be required alongside cryptography for enhanced 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 | Reduced dependence on hardware side channels has not eliminated vulnerabilities in software and data leakage through outputs. | Avoids TEE hardware constraints, but implementations and metadata could still be vulnerable. [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 and access-pattern leakages are influenced by the system, along with the possibility of collusion or cheating. | Output leakage, metadata, application design, implementation side channels [35] |
Performance, scalability, and costs
TEE's consistently excel in terms of workload flexibility and often outperform in latency as well. However, SGX-era enclaves can face challenges due to enclave exits and protected-memory limits. Fortunately, advancements in newer runtimes and confidential-VM approaches have greatly improved the situation for many workloads. Research conducted by Opaque on SGX revealed that exceeding the EPC size by a small margin resulted in 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 demonstrated performance enhancements ranging from 52% to a 3.3x slowdown compared to Spark SQL, while its oblivious mode added approximately 1.2x to 46x overhead. Another study on 2023 Gramine+SGX HPC work found a 4-17% overhead on compute- and bandwidth-sensitive workloads, but up to a 170% overhead on memory-latency-sensitive workloads. [36]
Confidential-VM TEEs are frequently favored over SGX for migrating analytics workloads due to their avoidance of SGX's per-process enclave model and small EPC constraints. Recent assessments showcase the shift from process-based SGX to VM-based SEV/TDX, with a 2024 analysis revealing up to an 8.5% throughput overhead for confidential VMs on NEXMark query workloads. This is why TEEs are often selected for encrypted streaming analytics and traditional SQL engines. [37]
MPC performance is significantly impacted by factors such as communication rounds, network latency, batching strategy, and expensive nonlinear operators like comparison and join. SECRECY's findings are especially relevant for relational-analytics scenarios: using batching can greatly reduce communication latency compared to eager messaging, allowing for the exchange of 100 million 64-bit shares in about 2 seconds. While secure analytics with millions of rows are possible, queries heavy on joins may still take anywhere from tens of minutes to hours to complete. For example, 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 is capable of handling up to 10 billion equality and inequality comparisons within the specified experiment duration. ABY3 also demonstrates the impressive speed of honest-majority MPC, achieving processing rates in the billions of AND gates per second under optimized conditions. [38]
While FHE is still slower than plaintext, progress is being made, with different libraries excelling in various workloads. TFHE is best for binary circuits, HElib is great for parallel instances, and PALISADE leads in arithmetic benchmarks. Recent documentation for TFHE-rs shows benchmarking on H100 GPUs and 8xH100 systems, indicating a trend towards FHE utilizing hardware acceleration. Concrete ML's examples demonstrate that small linear models can run in about 1 ms in FHE, but caution is advised 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 provide a comprehensive ecosystem for infrastructure teams, including hardware stacks from Intel, AMD, and Arm for confidential computing. Open Enclave offers a versatile cross-TEE SDK, Gramine streamlines SGX integration on Linux, Enarx enables portability across TEEs using WebAssembly, and Confidential Containers enhances Kubernetes orchestration with attestation and secret delivery. The primary difficulty lies in managing secure operations, patching, and designing side-channel-resistant workloads, rather than a shortage of tools. [49]
Although MPC tooling has advanced in research and practicality, it lacks the standardization present in the TEE stack. MP-SPDZ is versatile with various protocols and security models, ABY3 is well-regarded in PPML, SecretFlow integrates collaborative data analysis, ML, PSI, and SQL-related systems, while SCQL offers a genuine SQL front end with MySQL-like syntax and explicit column-control policies. However, the usability of MPC tooling often depends on limited workloads or security policies, rather than the flexible execution model in TEE deployments. [50]
The open-source landscape for Fully Homomorphic Encryption (FHE) is rapidly evolving, with various libraries catering to different needs. OpenFHE provides academic-library capabilities like threshold FHE and scheme switching. Microsoft SEAL remains a popular choice for BFV/CKKS projects, while TFHE-rs is transitioning towards production-focused solutions, particularly for Boolean/integer tasks. HEBench offers a benchmarking platform, and Concrete ML offers Python APIs, deployment guidance, hybrid execution, and practical ML examples. As projects advance beyond basic examples, FHE requires a higher level of cryptographic knowledge or reliance on specific frameworks compared to Trusted Execution Environments (TEEs) and Multi-Party Computation (MPC). [51]
Maturity and Adoption Milestones Relevant to Encrypted Analytics [56]
Compliance, operations, and deployment realities
When evaluating compliance, it is optimal to see all three technologies as risk-reducing technical measuresArticle 32 of GDPR emphasizes the importance of encryption and pseudonymization in securing data, while HIPAA's Security Rule requires a risk-based approach to protecting ePHI. PCI DSS establishes standards for safeguarding payment account data, focusing on retention minimization and strong cryptography. While technologies like TEEs, MPC, and FHE can improve control environments, they do not eliminate 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 recognize attestation as a crucial prerequisite for provisioning secrets. This necessitates production teams to implement reference-value management, KMS integration, certificate lifecycle management, image signing, and patch-driven re-attestation workflows. Balancing debugging and introspection with confidentiality objectives makes monitoring more complex. [58]
Operationally, MPC centers on party coordinationTeams must identify a host for computing parties, set colluding permissions, create session rotation protocols, handle offline party failures, and establish guidelines for allowed outputs. The significance of output policy is demonstrated by SCQL's column-control list, as even well-executed privacy-preserving queries can unintentionally reveal sensitive data if result policies are too lax or if repeated queries are not appropriately monitored. [59]
Operationally, FHE centers on key and circuit lifecycleConcrete ML's deployment model separates the cryptographic parameters in client.zip from the compiled model artifacts in server.zip, emphasizing the lengthy process of key generation and the possibility of using large keys. It also warns that the compiled artifacts are dependent on the machine architecture. This leads to CI/CD for FHE resembling a compiler toolchain integrated with a crypto-parameter-management pipeline rather than a conventional ML model-serving pipeline. [60]
Case studies, benchmarks, and decision framework
The TEE Studies demonstrate that TEEs are the optimal solution for managing confidential analytics workloads, as shown by Opaque and Secure XGBoost. These platforms efficiently handle encrypted data while maintaining performance, proving TEEs' potential as a secure environment for sensitive data analytics and machine learning tasks. [61]
The MPC Studies have found that distributed data ownership is most successful. In a real-world scenario, VaultDB was utilized in three healthcare facilities in Chicago for clinical research with SQL, proving that federated SQL with privacy protection is practical outside of a lab setting. Meta's Private Lift Measurement uses MPC to keep both datasets private. SECRECY and SCQL showcase the latest developments in outsourced or federated relational analytics, providing support for SQL, joins, aggregation, and security controls. [62]
Public FHE Case studies are now focusing on productized pilots, benchmarks, and packaged demos instead of large enterprise disclosures. Concrete ML provides examples such as 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 offers documentation on string operations and GPU-backed integer/bootstrapping benchmarks. While FHE is becoming operationally real, public evidence primarily focuses on specific workloads rather than broad production analytics. As a result, many teams are utilizing 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 | Utilize FHE only when it is crucial to ensure no plaintext is stored on the server and the query set is restricted. [64] |
| Cross-organization joins, clean rooms, collaborative aggregates | MPC | SQL and PSI ecosystems maintain credibility by preventing any single operator from having 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 challenge of achieving standardized comparisons in public benchmarks persists due to various factors such as hardware differences in TEE studies, network topology in MPC studies, and scheme variations in FHE studies. This led to the creation of HEBench. [72]
- Security posture: The security postures of all three families are constantly evolving. TEEs are continuously adjusting to emerging attack classes and vendor advisories, MPC implementations are facing tangible software-security obstacles despite strong theoretical bases, and FHE implementations necessitate side-channel defenses and careful metadata management. It is crucial to understand that none of these technologies can substitute for secure software engineering practices. [73]
- Evidence base: The evidence indicates that TEE and MPC have a higher number of documented analytics deployments and SQL-oriented systems than FHE, which excels in standards, libraries, deployment APIs, and focused application demos rather than large-scale production analytics disclosures. When making architectural decisions, it is crucial to consider the current maturity levels of each technology. [74]
References
- Data Product Concepts https://www.dataproduct.net/ [1, 5, 9, 11, 24, 49]