The shared idea behind all three is straightforward: take some computation that needs to be kept secret from the rest of the system, and run it somewhere the operating system can't reach. Cryptographic keys, biometric matching, DRM, attestation — these are tasks where even a kernel-level adversary should not be able to peek at the working state.
How each platform achieves that isolation, and how strong the resulting boundary is in practice, differs enormously. Lumping them together as "secure enclaves" obscures the engineering decisions that matter when you're choosing what to trust.
Intel SGX: Enclaves Inside the CPU
Intel Software Guard Extensions, introduced with Skylake in 2015, added new instructions that let user-space applications carve out encrypted memory regions — enclaves — whose contents are inaccessible to the rest of the system, including the operating system and hypervisor. The CPU itself enforces the boundary; physical DRAM reads outside the chip see only ciphertext.
The ambition was massive. Servers running untrusted workloads could put sensitive computation in an enclave, attest to its integrity remotely, and assume even a compromised host couldn't read the data. Whole confidential-computing platforms were built on this premise.
The reality has been harder. SGX has been broken repeatedly by side-channel attacks — Foreshadow (2018), Plundervolt (2019), LVI, AEPIC Leak (2022), and others. None of these defeated the encryption itself; they extracted secrets through timing, speculative execution, undervolting, or other physical side channels the threat model never claimed to cover. Intel has issued microcode mitigations, but each new disclosure further narrowed the practical safety margin.
In 2021, Intel removed SGX from consumer CPUs entirely, restricting it to Xeon server parts. By 2023, several confidential-computing services that depended on it were quietly migrating to AMD SEV-SNP or other alternatives. SGX still exists; the unconditional trust it once attracted does not.
Apple's Secure Enclave: A Separate Chip Doing One Job
Apple's Secure Enclave is a physically separate processor co-resident on the same silicon die as the main CPU. It runs its own operating system (sepOS), has its own boot ROM, its own private memory, and its own dedicated cryptographic accelerator. The main CPU talks to it via a constrained mailbox interface — no shared memory in the SGX sense.
The scope is narrower than SGX. The Secure Enclave handles Touch ID and Face ID matching, manages keys for the Apple Keychain, decrypts the user's data partition during boot, and signs payment transactions for Apple Pay. It does not run arbitrary developer code. Third-party apps interact with it only indirectly, through Apple's CryptoKit and Security framework APIs.
Because the Secure Enclave is a separate processor running a separate OS, side channels that ride on shared CPU state (cache, speculative execution, branch prediction) don't apply the same way. The enclave isn't time-multiplexed with untrusted code on the same execution unit.
The Secure Enclave has had vulnerabilities — the 2020 sepOS extraction via a checkm8 bootrom exploit on older iPhones is the most notable — but they've been substantially fewer and narrower than SGX's. The trade-off is flexibility: you cannot put arbitrary computation behind the Secure Enclave the way you can with SGX. You get the operations Apple ships, and that's it.
Modern Pixel devices use Google's Titan M2, which is architecturally similar — a separate security chip with constrained, well-defined operations.
ARM TrustZone: Two Worlds, One CPU
TrustZone is the oldest of the three — first introduced in ARMv6 in the early 2000s and refined in every generation since. The mechanism is fundamentally different from both SGX and Secure Enclave: TrustZone splits a single CPU into two worlds, secure and non-secure, sharing the same execution units but with hardware-enforced separation of memory and peripheral access.
The "secure world" runs a small trusted OS — Trusty (Android), Kinibi (Trustonic), OP-TEE (open source), or various vendor proprietary kernels. Applications running in the normal world request services from the secure world through SMC calls (Secure Monitor Calls), which trigger a context switch. The hardware ensures the normal world can't read secure-world memory, even with kernel privileges.
TrustZone is ubiquitous in Android phones. It implements the Android Keystore for hardware-backed keys, runs DRM modules (Widevine L1), validates trusted UI for payment confirmations, and on many devices is the only barrier protecting fingerprint templates from a compromised OS.
The security record is mixed. Because TrustZone shares execution units with the normal world, side-channel attacks similar to those that hit SGX (cache timing, speculative execution) apply here too. Several Trusted Execution Environment (TEE) implementations have had remote code execution vulnerabilities — Qualcomm's QSEE has had multiple, Samsung's Knox/Trustzone has been broken on specific Exynos models, and OP-TEE bugs are discovered with some regularity.
The other complication: TrustZone is a mechanism, not a TEE. Each vendor builds their own secure-world OS, and the security of the system depends on whichever vendor's implementation is running. "My phone uses TrustZone" is roughly as informative as "my computer runs an operating system." It tells you the architecture but nothing about the actual code in charge.
Side-by-Side
| Property | Intel SGX | Apple SE | ARM TrustZone |
|---|---|---|---|
| Isolation type | Encrypted memory regions | Separate chip | Privileged CPU mode |
| Arbitrary code? | Yes (developer enclaves) | No (Apple-defined ops only) | Yes (vendor TEE apps) |
| Shares execution unit? | Yes — side-channel exposed | No | Yes — side-channel exposed |
| Public scrutiny | High (academic + industry) | Limited (proprietary) | Varies by vendor TEE |
| Notable breaks | Foreshadow, AEPIC, LVI | checkm8 sepOS extraction | Numerous vendor TEE CVEs |
| Where you'll meet it | Confidential computing in cloud | iPhone Keychain, Touch/Face ID | Android Keystore, DRM, payments |
What "Hardware-Backed" Actually Buys You
All three architectures share a common honest claim: they raise the bar for an attacker, particularly one who has only software access. Extracting a key from the Secure Enclave or a TrustZone Keystore requires either a specific vulnerability in the trusted firmware or physical access with sophisticated equipment. For threat models involving stolen devices, malware that lands on the device with user-level privileges, or remote attackers without an OS-level exploit, hardware-backed key storage is a meaningful upgrade.
What hardware-backed security does not buy you:
- Protection from a sophisticated nation-state with physical access — forensic tools like Cellebrite and Grayshift have repeatedly demonstrated extraction capabilities against current devices, often within months of release
- Defense against the vendor — Apple, Samsung, and Google can ship signed firmware updates that change the enclave's behavior; if the vendor is your adversary, the enclave is not on your side
- Immunity from side channels — particularly for SGX and TrustZone, where the secure code shares physical execution resources with untrusted code
- Protection from supply-chain compromise — if the firmware was malicious before it ever reached you, the enclave does the wrong thing perfectly
Where This Connects to Messaging
Secure messaging applications use these primitives constantly, even when they don't advertise it. Signal and Haven both store private keys in platform-protected keystores — Android Keystore on Android (often backed by TrustZone), iOS Keychain on iPhone (backed by the Secure Enclave). These are the layer below the application that prevents a malicious app from reading another app's private keys.
It's worth being clear-eyed about what this provides. End-to-end encryption protects messages in transit and at rest from the server operator and from network observers. Hardware-backed key storage protects those keys from other apps and from many classes of malware. Forensic extraction is a separate threat model that neither one defeats entirely. Each layer is doing a specific job, and confusing their guarantees is how marketing material becomes misleading.
The Pragmatic Take
For consumer mobile devices, the secure enclave / TrustZone story is a meaningful security improvement over keys-in-flash, and the practical security record is strong enough to trust for everyday threat models. For server-side confidential computing, the SGX story is more cautionary — the threat model is wider, the attack surface is larger, and the public break record is longer. Treat hardware-backed claims as one layer in a defense-in-depth strategy, not as a substitute for sound cryptographic engineering at every other layer.