In the world of computing security, there’s growing rage around protecting data in use. This means protecting data not just at rest or in transit, but when the data is being processed. This goal is shared by two technologies that operate at a very different level: Homomorphic Encryption (HE) and Trusted Execution Environments (TEEs).
While we have already talked about HE, which can be used to train ML models on encrypted data or to develop privacy-preserving Federated Learning, this article unpacks TEEs and then compares them with HE.
Spoiler: neither is magic. Each has strong advantages and serious trade-offs.
What are TEEs?
A Trusted Execution Environment (TEE) is a protected region inside a device’s processor (or sometimes separate hardware) that guarantees confidentiality and integrity of code and data loaded inside it, even if the main operating system or hypervisor is compromised.
A trusted execution environment (TEE) is a secure area of a main processor. It helps the code and data loaded inside it be protected with respect to confidentiality and integrity. Data confidentiality prevents unauthorized entities from outside the TEE from reading data, while code integrity prevents code in the TEE from being replaced or modified by unauthorized entities, which may also be the computer owner itself as in certain DRM schemes described in Intel SGX. (Wikipedia)
Inside a TEE, sensitive code, often called a trusted application or enclave, runs in complete isolation from the rest of the system. The operating system, hypervisor, and even system administrators can’t access or tamper with the code or data inside. Hardware-level protections may include attestation mechanisms to verify what’s running, and memory encryption to prevent snooping at the hardware interface.
Key properties:
Isolation: The TEE’s memory and execution is separate from the untrusted world (OS/hypervisor).
Attestation: Optionally you can prove remotely that a given enclave is running expected code.
Hardware rooting: Security derives from hardware protections (rather than purely from software).
Data‐in‐use protection: While data is processed, it stays protected.
In effect, TEEs aim to extend the “trust perimeter” into the device/processor, enabling secure execution of critical functions even on untrusted hosts.
Types of TEEs
Nowadays, TEEs can be found on a variety of devices and machines, ranging from common laptops to big datacenters.
PCs
Intel SGX: Intel’s enclave architecture that allows user‑level code to execute inside “enclaves” isolated from the OS/hypervisor.
ARM TrustZone: A trusted execution environment concept for ARM devices; splits the world into Secure and Normal worlds.
Other secure elements / separate chips (e.g., Apple’s Secure Enclave, TPMs) can also be considered TEEs or related.
Servers/Cloud
AMD SEV‑SNP: AMD’s hardware virtualization/secure‑VM technology for confidential computing.
Intel TDX: Intel’s technology for confidential VMs.
Apple Private Cloud Compute: to run Apple Intelligence queries in the cloud with strong privacy guarantees.
These enable “confidential computing” in the cloud: workloads can run in an environment where even the cloud provider’s software may not see the decrypted data.
What are TEEs used for?
As we have seen in the previous section, TEEs are widely diffused both on common machines and on the cloud. These are some of the common scenarios which involve their use:
Protecting cryptographic keys and algorithms: Running key‑management or cryptographic operations inside an enclave so that no malicious software can intercept them (e.g., when you decrypt a file with your password).
Confidential computing in the cloud: Allowing untrusted infrastructure to host sensitive workloads (e.g., processing sensitive data, machine‑learning inference on proprietary model) with trust that the host cannot see inside.
DRM / content protection: Ensuring video/audio decryption happens inside a trusted environment so the user/OS cannot easily intercept it.
Secure credential processing / authentication: For example processing biometric data inside a secure enclave.
Mixed/trusted workflows: Combining client device TEE with cloud TEE for end‑to‑end trust chains.
It is evident that TEEs play an important role in guaranteeing the security and privacy of many of the actions we perform daily.
Pros and Cons
In general, we can say that the followings are the pros and cons of TEEs:
Pros:
High performance: Because you’re running native code and using hardware isolation, performance overhead is low compared to heavy cryptography.
Familiar programming model: You can port existing code (with modifications) rather than rewriting everything for encryption.
Useful for real‐time / latency‐sensitive workloads.
Cons / caveats:
Trust assumptions: You must trust the hardware vendor, firmware, the attestation path, enclave SDKs, etc. If the hardware is compromised, all bets are off.
Threat model limitations: Many TEEs assume the attacker has no physical access, no tampering of hardware etc. Real‑world attacks (see below) challenge these assumptions.
Side‐channels / vulnerabilities: TEEs have been subject to many microarchitectural attacks (cache‑timing, page‑faults, fault injection) and now physical attacks.
Comparison with HE
While trying to accomplish the same (or, at least, a similar) goal, TEEs and HE have important differences.
As a reminder, HE allows computations to be performed on encrypted data without decrypting it. The result, when decrypted, matches the result of operations on the plaintext. It’s the "do work while still encrypted" paradigm.
Key differences (and trade‑offs)
Trust model:
TEE: trust hardware + vendor + firmware + attestation chain. If any of those fail, your confidentiality/integrity assumption may break.
HE: trust is moved to crypto math. You don’t need to trust the server/hardware to see plaintext; you can operate purely on ciphertext.
Performance & practicality:
TEE: near‑native performance, easier to integrate for many workloads.
HE: high overhead, ciphertexts are large, operations expensive, circuit depth limited (especially for fully HE). 
Security boundaries:
TEE: strong isolation, but side‑channels, hardware vulnerabilities, and physical attacks still exist.
HE: strong cryptographic guarantees for confidentiality, but integrity / correctness issues and still performance/feature gaps. 
Use‑case suitability:
TEE: good for latency‑sensitive, large memory workloads, real‑time processing.
HE: good for outsourced analytics, where performance trade‑offs are acceptable and data confidentiality is paramount.
Hybrid options: As some recent works suggest, the future might be a hybrid: use TEE for performance‑critical parts, and HE for ultra‑sensitive segments. 
Are TEEs a Silverbullet?
Putting a pin in it: TEEs still face serious issues. Ars Technica reports that in late 2025, researchers discovered physical attacks that break down TEEs from major vendors. Specifically, attacks dubbed "Battering RAM" and "Wiretap" exploit interposers between CPU and memory to extract keys from TEEs like SGX and SEV‑SNP.
It is unfortunate that vendors treat physical access attacks as “out of scope”, yet the attacks are realistic and relatively cheap to mount.
So: if your model of threat includes physical attacker on your hardware, TEE guarantees may collapse. That doesn’t mean TEEs are useless, but you must understand the threat model and where the assumptions break.
The Future
Homomorphic Encryption (HE) is still maturing, but it’s expected to improve significantly in the coming years, especially in terms of performance and developer tooling. As these improvements roll out, HE could become a go-to choice for privacy-critical workloads. In that context, it’ll be increasingly important to design systems where everything stays encrypted, end-to-end, even during computation, not just at rest or in transit. HE pushes us toward that future, a future where Dhiria will be present.
