The phrase data in use protection hides three materially different architectures. Confidential computing decrypts data inside a hardware-isolated trusted execution environment. Homomorphic encryption lets an operator evaluate supported functions over ciphertext. Secure multiparty computation distributes a function across parties so they need not reveal private inputs to one another. A useful confidential computing vs homomorphic encryption comparison therefore does not ask which technology is strongest in general. It asks where plaintext appears, which component must behave correctly, which parties may collude, and how the customer verifies those assumptions.
Begin with a prohibited-observation statement: cloud administrators must not read the dataset, no participant may learn another participant's records, or the compute provider must never receive a decryption key. These statements place different boundaries. The Confidential Computing Consortium defines confidential computing around protecting data in use through hardware-based trusted execution environments. NIST's privacy-enhancing cryptography program describes FHE and MPC as cryptographic tools for computation without extraneous disclosure. They can overlap, but they do not make identical promises.
Locate plaintext before selecting a data-in-use design
Draw every state transition from data owner to result consumer. In a TEE design, encrypted inputs are decrypted in protected memory; approved code and the processor security boundary see plaintext. In HE, the evaluator normally sees ciphertext, but the data owner or designated result holder decrypts outputs. In SMPC, each party begins with a private input and receives protocol messages; the intended function output is reconstructed according to the protocol. Add logs, crash dumps, model checkpoints, caches and support tooling. These side paths frequently escape the advertised boundary.
Outputs deserve their own review. A protocol can conceal inputs and still return an identifying answer. Limit functions, dimensions, precision and query frequency. Apply aggregation or differential privacy where output inference is a concern. Decide whether code owners can alter a function after contributors consent, and whether a result recipient can combine outputs with external data. Protecting computation is not equivalent to anonymizing its result.
| Property | Confidential computing | Homomorphic encryption | SMPC |
|---|---|---|---|
| Plaintext during compute | Inside an attested TEE | Absent from evaluator for supported operations | Inputs remain distributed; protocol state exists at parties |
| Primary trust anchor | Hardware, firmware, attestation and approved code | Cryptographic scheme, parameters and decryption key holder | Protocol, implementations and corruption threshold |
| Typical strength | Runs broader existing workloads with isolation | Delegates bounded compute without evaluator plaintext | Avoids one central input holder across organizations |
| Typical cost | TEE lifecycle and side-channel exposure | Compute, memory and ciphertext expansion | Communication, coordination and dropout handling |
| Critical failure | Bad measurement accepted or enclave compromised | Weak parameters, key misuse or unsafe output | Excess collusion, malicious input or abort |
Choose confidential computing when attested code is acceptable
A TEE is often the pragmatic choice when the workload is complex, uses existing libraries, or needs lower latency than cryptographic evaluation permits. The trust boundary becomes smaller than a conventional host, not trust-free. Review processor generation, firmware and microcode update process, debug settings, memory and I/O protection, side-channel posture, host denial-of-service risk and cloud recovery behavior. The code inside the enclave can still leak data by design or defect, so minimize it and treat outbound network access as a controlled capability.
Turn remote attestation into authorization policy
Attestation evidence matters only when a verifier checks it against policy before releasing data or keys. Bind approval to workload measurement, signer, security version, configuration, nonce freshness and an expected environment. Protect the verifier and endorsement supply chain. Define what happens during certificate, firmware or vulnerability changes: fail closed for new secrets, retain a narrow recovery path, and require explicit approval for temporary measurements. Store the evidence and decision so an auditor can link a dataset release to the exact accepted workload.
Choose HE for stable functions on encrypted inputs
HE is compelling when the evaluator must not receive plaintext and the function can be expressed efficiently in supported operations. Scope the arithmetic circuit, multiplicative depth, batching, precision and error tolerance before choosing parameters. Benchmark with production-shaped data and concurrency. Assign decryption authority separately from the evaluator where the governance model requires it, rotate and recover keys deliberately, and authenticate ciphertext sources. Encryption does not prove that inputs are truthful or that the evaluated function is the one stakeholders intended.
Avoid describing HE as universally encrypted processing. Some designs support additions and multiplications well but struggle with branching, comparisons or data-dependent access. Bootstrapping and parameter choices affect cost and security. Library defaults, scheme version and parameter review are part of the security boundary. The ICO PET guidance correctly treats benefits and risks together; deployment feasibility must be demonstrated for the exact use case.
Choose SMPC when trust must be distributed among parties
SMPC is a natural fit when several institutions contribute inputs but none should become the central custodian. Specify whether the adversary is semi-honest or malicious, how many parties may collude, whether security is honest-majority or dishonest-majority, and what parties learn on abort. Authentication, input validity, fairness and availability remain system concerns. A participant can submit strategically false data even if it cannot inspect another input; business controls must validate eligibility and reconcile source records.
NIST's Multi-Party Threshold Cryptography project illustrates how MPC principles distribute trust in cryptographic operations and highlights explicit thresholds. Apply the same precision to an analytics protocol. Record party count, corruption threshold, key shares, preprocessing assumptions, communication topology and recovery. Test participant dropout and network partition before production. A protocol that protects confidentiality but cannot finish within the decision window may move users back to unsafe manual exchange.
Compose technologies only for named risks
Compositions can be valuable: SMPC can distribute a decryption operation; a TEE can protect a coordinator; HE can protect values handled by a service inside a wider multiparty workflow. Composition also combines assumptions and failure modes. Draw the resulting plaintext map again. Verify that one compromised layer cannot silently weaken another, and avoid marketing a hybrid as stronger without an attack argument. Often a narrow TEE design with strict output control is more governable than an elaborate combination with no team able to test it.
| Decision question | Favor TEE | Favor HE | Favor SMPC |
|---|---|---|---|
| Who must not see inputs? | Host operators outside approved workload | External evaluator | Other contributing organizations |
| Function shape | Complex application or existing runtime | Stable bounded arithmetic | Joint function over distributed inputs |
| Coordination tolerance | One workload can operate independently | Key holder and evaluator can work asynchronously | Parties can coordinate rounds and availability |
| Verification model | Remote attestation and release policy | Parameter, implementation and key review | Protocol proof, threshold and transcript controls |
| Operational priority | Compatibility and latency | Strong evaluator separation | No single data custodian |
Compare verification and recovery before performance
Make the trust decision observable at every invocation
A benchmark can show that a design is fast enough, but only verification shows that the intended boundary was present. For confidential computing, bind key release to an attestation policy covering hardware identity, security version, boot chain and approved workload measurement; log the policy decision without exposing secrets. For HE, validate scheme, parameter set, key identity and allowed evaluation function before accepting a ciphertext. For SMPC, authenticate parties, negotiate the expected protocol version and reject a session whose participant set or corruption assumptions do not match the approved job. Verification failures should stop the sensitive computation rather than silently fall back to ordinary execution.
Design failure recovery that preserves the boundary
Recovery paths are where strong designs often reintroduce plaintext. A TEE crash dump, an HE debugging export or an SMPC checkpoint can expose state that normal execution protects. Specify whether a job restarts, resumes from encrypted state or aborts; who can request diagnostic material; how keys survive regional loss; and how participants learn that a result may be incomplete. Test revoked attestation identities, lost key shares, a malicious or unavailable party, version skew and rollback to vulnerable firmware. The recovery objective must include confidentiality and result integrity, not only elapsed time.
Use total job cost for comparison: verification latency, cryptographic preprocessing, network rounds, key ceremonies, secure hardware capacity, failure retries, evidence retention and specialist support. Then price the cost of a trust failure and the operational value of a simpler design. This prevents a narrow throughput number from deciding an architecture whose assurance team cannot verify or restore. The winning option is the least complex boundary that satisfies the named adversary and can be operated under failure.
Use the six-stage Edilec data-in-use boundary review
The review forces a team to locate plaintext, name the adversary and place trust before discussing products. It then constrains executable functions and verifies either attestation evidence or protocol properties. The last stage covers what every option leaves behind: result disclosure, metadata, keys, logs and recovery paths. Run the review again when code, hardware, participants, parameters or output recipients change.
Key takeaways
- A TEE trusts isolated hardware and approved code; HE trusts cryptography and key custody; SMPC trusts a stated corruption model.
- Map plaintext and outputs across the whole system, including diagnostics and recovery.
- Make attestation a key-release decision, not a dashboard artifact.
- Benchmark HE and SMPC with the exact function, scale, network and failure pattern.
- Use composition only when each added layer addresses a documented adversary.
Frequently asked questions
Is a TEE the same as encryption?
No. Data is commonly encrypted before entering a TEE, then decrypted within hardware-isolated memory for execution. The isolation and attestation boundary is the central control during use.
Does HE eliminate trust?
It removes plaintext trust from the evaluator for supported operations, but leaves trust in scheme parameters, implementation, key holders, input authenticity and output governance.
Can SMPC work with two parties?
Yes, but security and availability properties depend on the chosen protocol. Two-party settings deserve particular attention to malicious behavior, aborts and what either party can infer from inputs and outputs.
Conclusion
The right data-in-use architecture is the one whose trust boundary matches the collaboration. Choose confidential computing when attested general-purpose execution is acceptable, HE when an evaluator must operate on ciphertext through a bounded function, and SMPC when control must be distributed among input holders. In every case, verify the complete path from input release to output use rather than treating the technology name as the assurance result.