Secure Enclaves vs Secure Multi-Party Computation: Hardware Trust or Cryptographic Trust

Secure enclaves and secure multi-party computation both let you process data or use keys that no single operator should see, but one asks you to trust a chip manufacturer and its attestation chain while the other asks you to trust that enough independent parties will not collude. That difference in trust assumption drives everything else: performance, how keys are held and recovered, which side channels matter, how you prove to a regulator or partner that the protection is real, and what fails when an assumption breaks. This guide compares hardware-based trusted execution environments (TEEs, including secure enclaves and confidential virtual machines) with cryptographic MPC across threat model, architecture, key custody, AI data use cases and side-channel exposure, then gives decision criteria, a worked scenario and a rollout approach. It is for security architects, data protection leads and key management owners. For each technology on its own, see the Confidential Computing Guide and Secure Multi-Party Computation.

Key takeaways

• The trust anchor is the real choice. An enclave moves trust from the operator to the processor vendor and its attestation infrastructure; MPC removes the single trusted place and replaces it with a non-collusion assumption across parties.
• Enclaves are fast, MPC is costly. TEEs compute on plaintext inside protected memory, so overhead is modest; the UN privacy-enhancing technologies guide cites slowdowns of up to 10,000 times for general MPC computation, driven by communication between parties.
• Side channels hit enclaves hardest. The Confidential Computing Consortium states that TEE security assumes no exploitable side channels, and practical attacks have been demonstrated; MPC's equivalent weak points are implementation flaws and collusion.
• Neither protects outputs. Both keep inputs private during processing, and both leave the result to reveal whatever it reveals; the ICO notes TEEs do not protect outputs unless the code adds that protection.
• They combine well. Running MPC parties inside TEEs, or using an enclave for bulk work and MPC for the key, gives defence in depth when the assets justify the cost.

The short answer

Choose a secure enclave when one organisation, or one cloud tenant, needs to process sensitive data or hold keys so that the host operating system, hypervisor, cloud administrators and anyone with ordinary physical access cannot read them, and you can accept trusting the hardware vendor and its attestation service. The Confidential Computing Consortium (CCC) defines confidential computing as protecting data in use by computation in a hardware-based, attested TEE, with data confidentiality, data integrity and code integrity as required properties.

Choose secure multi-party computation when no single party, platform or vendor may be trusted with the whole input or the whole key, and the parties can be placed in genuinely independent trust domains. ISO/IEC 4922-1:2023 sets out the terminology and processes for computing a function on data while keeping that data private. The UN guide describes cryptographic approaches as offering protocol-level guarantees at computational cost, while TEEs mimic the behaviour of a trusted third party and require trust in the hardware or cloud provider.

Choose both for high-value keys or regulated cross-organisation analytics where a single hardware flaw or a single compromised party must not be enough.

Side-by-side comparison

Secure enclaves: threat model, architecture and failure modes

Threat model

The CCC threat model aims to make attacks by the platform owner or operator economically or logically unviable, while acknowledging there is no absolute security. In scope are software attacks, protocol attacks, cryptographic attacks, basic physical attacks such as cold DRAM extraction, bus and cache monitoring or devices plugged into ports, and gross supply chain changes such as added debug ports. Out of scope are sophisticated long-term invasive physical attacks, upstream hardware supply chain attacks at chip manufacture or key injection, and availability attacks.

Architecture in words

The processor creates a protected region, either a process-level enclave or a whole confidential virtual machine, whose memory is encrypted and integrity protected against everything outside it, including the hypervisor. The ICO describes code inside reaching data outside, but outside code unable to reach data inside. Before a relying party sends a secret, it asks for attestation. In the IETF RATS architecture (RFC 9334, Informational, January 2023), the Attester produces Evidence, a Verifier appraises it against Reference Values and Endorsements from the manufacturer, and a Relying Party acts on the Attestation Results, typically by releasing a key. Implementations include AMD SEV-SNP, Arm CCA, Intel SGX and Intel TDX (listed alphabetically); the Confidential Computing Guide covers each.

Failure modes

• Side channels: the CCC states TEE security assumes no exploitable side channels and that practical attacks on some TEEs have been demonstrated. The ICO adds that timing attacks can reveal memory access patterns or keys, especially in shared environments.
• Vulnerable enclave code: the ICO warns that insecure or buggy code inside a TEE creates risk and that isolated VMs can enlarge the attack surface. A confidential VM with a full guest OS carries all of that OS's vulnerabilities inside the boundary.
• Attestation that checks too little: a policy that accepts any genuine enclave rather than a specific measured image, firmware version and debug-disabled state will release keys to the wrong code.
• Manufacturer dependence: verification depends on the manufacturer's PKI, which the ICO notes must also be trusted. Revocation of compromised platform keys is part of the CCC's attestation expectations.
• Capacity limits: the ICO notes limited memory can constrain large workloads, though newer implementations are improving.

Secure multi-party computation: threat model, architecture and failure modes

Threat model

MPC assumes some parties may be corrupt and states how many. The UN guide classes adversaries as semi-honest (follows the protocol but inspects what it sees), covert or malicious (deviates arbitrarily), and as honest majority or dishonest majority by the proportion of parties compromised. Its rule of thumb is that the more parties you defend against, the higher the protocol overhead. No hardware vendor is in the trust base, but every party's operations team is: if enough parties share administrators, cloud accounts or credentials, the threshold is met by one compromise.

Architecture in words

Each input or key is split into shares distributed to compute parties. Additions run locally on shares; multiplications and comparisons need rounds of messages between parties, which is why the UN guide says run time can be estimated from communication cost alone and why bandwidth and latency kept MPC largely theoretical until the mid-2000s. Specialised protocols do much better than general computation: threshold signing produces an ordinary signature while the key stays split, and private set intersection reveals only an overlap. NIST describes threshold schemes as applying MPC principles to distribute trust, and its first call for multi-party threshold schemes, NIST IR 8214C, was finalised on 20 January 2026, asking for schemes whose outputs can be used in place of their non-threshold counterparts.

Failure modes

• Collusion above threshold: the protocol is secure only while fewer parties than the threshold cooperate against it.
• Shared trust domains: three shares in one cloud tenancy under one admin team are, operationally, one share.
• Implementation flaws: the paper proof covers the protocol, not the code; abort handling and share refresh are where practical key extraction problems have been reported. See the MPC Wallet and Threshold Signing Security Guide.
• Wrong security model: semi-honest protocols used where a party could be fully compromised.

Trust assumptions in practice

The comparison is often framed as hardware against mathematics, but both reduce to people and processes you must trust.

Key custody

Key management is where the two approaches are most often weighed against each other, and against hardware security modules. The HSM vs TPM vs Secure Enclave guide covers the hardware options in depth.

• Enclave pattern: a key management service releases a data key or private key only to an enclave whose attestation matches a pinned measurement. The key exists whole inside one enclave at a time. Recovery depends on the key service and on re-attesting a patched platform. This suits per-workload secrets, decryption of sensitive records for processing and signing at service speed. See Envelope Encryption and KMS Integration Patterns Guide.
• MPC pattern: the key is generated in shares and never assembled; each signature or decryption needs a quorum of parties. A single device, administrator or cloud account cannot use the key alone. This suits root keys, digital asset custody and keys shared between organisations where no party should hold unilateral power.
• Combined pattern: each MPC share is held inside an enclave or HSM, so an attacker needs both a hardware break and quorum compromise. The ICO lists secure multi-party computation on untrusted platforms among TEE use cases.

Where identity fits: enclaves and MPC nodes are non-human identities. Each MPC party and each enclave workload authenticates with a credential, and that credential, not the cryptography, is the usual attack path. Give each its own workload identity, scope it to the key operations it needs, and monitor its use like any privileged account. See the Cryptographic Key Management Guide.

AI data use cases

Neither technology governs what the model or query computes; output review and purpose limitation remain separate controls.

Side channels and implementation attacks

Enclaves share the processor with untrusted code, so timing, cache, power and memory access patterns can leak information across the boundary. The CCC illustrates this with elliptic curve double-and-add multiplication, where timing and power differences reveal secret bits, and a dummy operation for zero bits makes the cases indistinguishable. It places mitigation with TEE vendors, third-party vendors and application developers together. The ICO advises configuring available security properties, using well-reviewed implementations rather than custom TEE stacks and auditing any custom code for observable memory access patterns.

MPC moves the side channel problem rather than removing it. Each party's own host must still use constant-time cryptography for its share operations, and the protocol transcript itself must not leak more than the security model allows. The larger practical risk is implementation error in abort handling, randomness and share refresh, which is why independent review of the code matters more than the protocol paper.

• Enclave controls: keep microcode and firmware current, pin minimum security versions in attestation policy, disable debug, prefer dedicated or single-tenant hosts for the most sensitive keys, and write constant-time enclave code.
• MPC controls: malicious-secure protocols for keys, constant-time share arithmetic, abort monitoring, proactive share refresh and independent implementation review.

Decision checklist

• Who is the adversary you most need to exclude? The cloud operator or host admin: an enclave suffices. Any single party, including your own admins or a hardware vendor: MPC.
• Can you place parties in independent trust domains? If not, MPC adds cost without its main benefit.
• What latency and throughput do you need? Interactive AI and bulk processing favour enclaves; signatures, aggregates and set matching are feasible under MPC.
• Who needs proof? An auditor can review attestation policies and logs; a consortium may prefer MPC because no member depends on another's hardware choice.
• What is the impact of a single platform flaw? If one hardware advisory would expose a root key, add MPC or an HSM quorum.
• Small or large organisation? Smaller teams should consume enclaves and MPC through managed services with published attestation or protocol documentation rather than build their own; large organisations and consortia can justify custom MPC with independent review.

Worked scenario

A payments group and three partner banks want to train a fraud model on combined transaction features and to protect the key that signs the model's risk scores.

Analytics: the banks will not trust one another's infrastructure, and two of them will not accept a single hardware vendor as the root of trust. Feature matching between banks uses private set intersection under MPC. Aggregate statistics for feature selection run as MPC sums with a minimum group size on outputs. Model training on the matched, pseudonymised feature set runs in GPU-capable confidential VMs operated by the payments group, with each bank's key service releasing its data key only after verifying attestation against an agreed image measurement, published to all four parties.

Signing key: the score signing key is a threshold key held by the payments group and two banks, two of three required, each share in its own HSM or enclave and each party under separate administrators. Loss of one party triggers share refresh and party replacement under the consortium agreement.

Residual risks recorded: enclave side channels on shared hosts (mitigated with dedicated hosts for training), model outputs that could reveal individual transactions (mitigated with output review), and MPC implementation risk (mitigated with independent review before go-live).

How to implement

1. Write the trust statement first: name who must not see the data or key, who is trusted, and what the output may reveal.
2. Select the mechanism per asset: use the decision checklist for each dataset and key, not one choice for the programme.
3. Define attestation or protocol acceptance criteria: for enclaves, the exact measurements, signer, security version and debug state the verifier accepts; for MPC, the security model, threshold and reviewed implementation version.
4. Pilot on synthetic data: measure latency and cost against a plaintext baseline, and test failure paths: attestation rejection, party loss, aborted runs.
5. Roll out in rings: non-sensitive workloads, then regulated data, then root keys. Keep the old key path until the new one passes a recovery test.
6. Plan rollback and recovery: for enclaves, a documented path to re-provision keys after a firmware advisory; for MPC, share backup under quorum and party replacement.

Detection and measurement

• Attestation outcomes: log every verification with measurement, security version and result; alert on rejections, debug-enabled evidence and unexpected measurements.
• Key release events: correlate key service release logs with attestation results; any release without a matching verified result is an incident.
• MPC protocol health: alert on aborts and repeated failed runs, which can indicate a party probing for leakage.
• Party and node identity: monitor sign-ins and admin changes on every enclave host and MPC node as privileged systems.

Metrics:

• Percentage of high-value keys that never exist whole outside an attested enclave, HSM or MPC quorum.
• Time from a TEE firmware or microcode advisory to updated minimum security version in attestation policy.
• Number of MPC deployments where two or more parties share an administrator, account or credential (target zero).
• Attestation rejection rate and its trend after each release.
• Percentage of confidential workloads with output controls documented and tested.

Common failure patterns

• Treating attestation as a tick box: accepting any genuine enclave rather than a pinned measurement turns confidential computing into encryption with extra steps.
• MPC in one tenancy: shares split across nodes run by the same team in the same cloud account give the cost of MPC with the trust model of a single server.
• Ignoring outputs: both technologies compute the agreed result exactly, including results that identify individuals.
• Assuming side channels are solved: the CCC model assumes none are exploitable; patch status and code discipline are what make that assumption hold.
• Unreviewed MPC code: trusting the paper while the code mishandles aborts.
• No recovery plan: sealed data tied to one platform version, or shares with no refresh or replacement procedure.

Framework mapping

Practitioner checklist

• Write a trust statement per asset: who is excluded, who is trusted, what outputs may reveal.
• Pin attestation policy to measured image, signer, minimum security version and debug disabled.
• Release keys only on verified attestation and log every release against its attestation result.
• Place MPC parties in separate organisations or accounts with separate administrators and credentials.
• Use malicious-secure MPC protocols and independent code review for keys.
• Add output controls for every analytics or AI use case.
• Give every enclave workload and MPC node its own scoped workload identity.
• Test recovery: re-attestation after patching, share refresh and party replacement.

Standards and references

• ISO/IEC: 4922-1 Information security, Secure multiparty computation, Part 1: General
• NIST: IR 8214C First Call for Multi-Party Threshold Schemes
• NIST: Multi-Party Threshold Cryptography project
• IETF: RFC 9334 Remote ATtestation procedureS (RATS) Architecture
• Confidential Computing Consortium: A Technical Analysis of Confidential Computing
• ICO: Privacy-enhancing technologies, Trusted execution environments
• United Nations: Guide on Privacy-Enhancing Technologies for Official Statistics
• NIST: IR 8320 Hardware-Enabled Security

Related NHI Mgmt Group resources: Confidential Computing Guide, Secure Multi-Party Computation, Homomorphic Encryption Guide, Hardware key attestation.