Trusted Execution Environments (TEEs) — like Intel SGX, AMD SEV, and ARM TrustZone — are marketed as cutting-edge security features designed to protect sensitive code and data, even from system administrators or attackers with root access. In reality, they’re opaque, proprietary black boxes riddled with vulnerabilities, deployed under the pretense of trust without transparency. For anyone serious about actual security, TEEs should not be trusted — and certainly not relied upon.

Over the past decade, major chip manufacturers like Intel and AMD have positioned TEEs as a solution to growing concerns about data breaches and cloud provider trust. TEEs are now a foundational component of “confidential computing” — systems that claim to protect data in use by isolating sensitive operations in secure enclaves.

AMD’s whitepaper promotes their TEE technology AMD-SEV with confident claims:

“Even an administrator with malicious intentions at a cloud data center would not be able to access the data in a hosted VM.”

Cloud providers eagerly jumped onboard. Microsoft, Amazon, and Google all market “confidential computing” using TEE-backed technology. They make promise such as that even they — the infrastructure operators — can’t access your data.

Amazon:

“AWS confidential computing is always on. There is no mechanism for any AWS operator to access customers’ Amazon Elastic Compute Cloud (Amazon EC2) instances within the AWS Nitro System.”

Microsoft:

“Azure provides the broadest support for hardened technologies such as AMD SEV-SNP, Intel Trust Domain Extensions (TDX), and Intel Software Guard Extensions (SGX). All technologies meet our definition of confidential computing, which is to help organizations prevent unauthorized access or modification of code and data while in use.”

Sounds good on paper. But that’s just nice words and marketing.

All major TEEs are built on closed, proprietary hardware and firmware. The microcode, management engines, secure enclaves, and cryptographic operations running on your machine are invisible to you. You can’t audit them. You can’t verify them. You can’t change them. And it’s not just the TEEs — the same goes for the CPUs themselves, and nearly every other component in your computer. In cloud environments, the situation is even worse, where you’re expected to trust layers of infrastructure you have zero visibility into.

You’re asked to trust these companies with long histories of opaque development processes, security mishaps, and collaboration with states and surveillance agencies. You’re also asked to trust the cloud provider running the hypervisor, and the hypervisor itself, and the firmware signed by a vendor you can’t see.

So when you hear these corporations say, “we promise your data is safe, even from us,” what they really mean is: “just trust us, bro.”

Even setting aside the trust model, TEEs have failed to deliver on their technical promises. From their very inception, they’ve been riddled with vulnerabilities — a litany of side-channel attacks, speculative execution exploits, and firmware-level compromises. In practice, these “trusted” environments have resembled Swiss cheese more than secure enclaves: full of holes.

In just the past few years:

Intel SGX has been repeatedly broken via side-channel leaks and memory probing.

AMD SEV-SNP was shown vulnerable to microcode exploitation.

Intel TDX, one of the latest additions to the TEE family, has already suffered from cross-VM data leakage.

And that’s just what’s been published in academic circles during the last few years. These attacks aren’t hypothetical. They demonstrate that even attackers without root privileges — in some cases, just another VM on the same host — can bypass the confidentiality guarantees these TEEs claim to provide.

TEEs don’t eliminate trust; they centralize it in opaque entities. You’re not removing risk, you’re transferring it. Real security isn’t based on blind trust. It’s based on verifiability — the ability to inspect, audit, and control the systems that process your data. That means:

Open hardware designs.

Transparent, open-source firmware, and free software if possible.

Community-led alternatives like Libre-SOC.

Secure hypervisors and minimal TCB (trusted computing base) systems, built from first principles.

Projects such as Libre-SOC aren’t mainstream yet. But they’re grounded in a security model that respects the user, not just corporate and state interests or regulatory checkboxes.

TEEs were never a silver bullet, but they’ve been sold like one. Instead of challenging centralized trust models, they’ve deepened the problem. Instead of offering true privacy, they offer unverified assurances. And instead of moving toward a more secure future, they lock us further into a hardware and software monoculture we can’t escape or examine.

So if you’re placing your trust in TEEs to protect your data: don’t. Reject the black box.

Below is a growing list of academic research exposing the minefield of side channels, speculative execution flaws, and architectural fuckups that plague TEEs. If we missed something worth highlighting, let us know.

2025:

Battering RAM breaking Intel SGX and AMD SEV-SNP with a $50 malicious DRAM interposer. https://batteringram.eu [archived]

MDPeek breaking Intel SGX. Side-channel attack. https://www.comp.nus.edu.sg/~tcarlson/pdfs/liu2025mbbbiswmdusc.pdf [archived]

Breaking AMD SEV-SNP. Exploits malicious microcode. https://github.com/google/security-research/security/advisories/GHSA-4xq7-4mgh-gp6w [archived]

Breaking Intel TDX. Side-channel attack. https://eprint.iacr.org/2025/079.pdf [archived]

2024:

Heckler breaking both AMD SEV-SNP and Intel TDX. Ahoi attack (exploiting interrupts or signals). https://ahoi-attacks.github.io/heckler/ [archived]

Sigy breaking Intel SGX. Ahoi attack (exploiting interrupts or signals). https://ahoi-attacks.github.io/sigy/ [archived]

WeSee breaking AMD SEV-SNP. Ahoi attack (exploiting interrupts or signals). https://ahoi-attacks.github.io/wesee/ [archived]

BadRAM breaking AMD SEV. “BadRAM attacks can be mounted by local, software-only attackers without physical access (e.g., via SSH).” https://badram.eu/badram.pdf [archived]

2023:

TeeJam breaking Intel SGX. Sub-cache-line attack. https://d-nb.info/1312413972/34 [archived]

Breaking Intel SGX. Controlled data race attacks. https://www.usenix.org/system/files/usenixsecurity23-chen-sanchuan.pdf [archived]

BunnyHop-Reload breaking Intel SGX. Abusing instruction prefetcher. https://www.usenix.org/system/files/usenixsecurity23-zhang-zhiyuan-bunnyhop.pdf [archived]

Downfall breaking Intel SGX. Speculative execution vulnerabilities. https://www.usenix.org/system/files/usenixsecurity23-moghimi.pdf [archived]

NightVision breaking Intel SGX. Side-channel attack. https://dl.acm.org/doi/pdf/10.1145/3579371.3589100 [archived]

ASEV-Step breaking AMD SEV / SEV-SNP. Framework for interactive single-stepping, page fault tracking and eviction set-based cache attacks. https://arxiv.org/pdf/2307.14757 [archived]

2022:

SGX-ROP breaking Intel SGX. Practically demonstrates an enclave malware which fully and stealthily impersonates its host application. From the paper: “This is particularly relevant for trigger-based malware that embeds a zero-day exploit, but also to provide plausible deniability for legal or political reasons, e.g., for a state actor.”, “instead of protecting users from harm, SGX currently poses a security threat, facilitating so-called super-malware with ready-to-hit exploits.” https://arxiv.org/pdf/1902.03256 [archived]

ÆPIC Leak breaking Intel SGX. Architectural attack, exploits undefined APIC register. https://aepicleak.com/aepicleak.pdf [archived]

Breaking Intel SGX. Side-channel attacks. https://dl.acm.org/doi/10.1145/3545948.3545972 [archived]

Breaking AMD SEV-SNP. Side-channel attack, same as CIPHERLEAKs, but can exploit any memory space including kernel areas, heaps as well as stacks. https://ieeexplore.ieee.org/document/9833768 [archived]

2021:

CacheOut breaking Intel SGX. Side-channel attack (MDS). https://sgaxe.com/files/CacheOut.pdf [archived]

CIPHERLEAKs breaking AMD SEV-SNP. Side-channel attack, infering secret register values from the VM Save Area (VMSA) in SEV-SNP. https://cipherleaks.com/ [archived]|

2020:

TeeRex breaking Intel SGX. Memory corruption attacks. https://www.usenix.org/system/files/sec20-cloosters.pdf [archived]

VoltJockey breaking Intel SGX. Exploits software-exposed energy management mechanisms. https://ieeexplore.ieee.org/document/9200659 [archived]

SGAxe breaking Intel SGX. Side-channel attack, transient execution attack. https://sgaxe.com/files/SGAxe.pdf [archived]

2019:

Breaking AMD SEV and allowing an attacker to encrypt or decrypt arbitrary guest VM memory without crashing the attacked VMs. Exploiting unprotected I/O operations and side-channel attacks. https://www.usenix.org/system/files/sec19-li-mengyuan_0.pdf [archived]

Attack extracting CPU-specific attestation keys to fully bypass AMD SEV protections on Epyc CPUs, enabling a malicious cloud provider to compromise VM security with no viable software-based defenses. https://arxiv.org/pdf/1908.11680 [archived]

Breaking Intel SGX, RISC-V, and Sancus TEEs. Exploiting sanitization vulnerabilities in TEE runtimes. https://flaviodgarcia.com/publications/ccs19-tale.pdf [archived]

Plundervolt breaking Intel SGX. Software-based attack controling the CPU voltages. https://www.plundervolt.com/ [archived]

2018:

SgxPectre Attacks breaking Intel SGX. Branch target injection and side-channel attacks, speculative execution (Spectre). Main research paper: https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=8806740 [archived] Other papers:

• https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=8418603 [archived]
• https://arxiv.org/pdf/1707.03473 [archived]
• https://arxiv.org/pdf/1705.07289 [archived]
• https://dl.acm.org/doi/pdf/10.1145/3052973.3053007 [archived]

Also check:

• https://github.com/lsds/spectre-attack-sgx [archived]

Foreshadow breaking Intel SGX. Side-channel attack, speculative execution (Spectre). https://foreshadowattack.eu/foreshadow.pdf [archived] https://foreshadowattack.eu/foreshadow-NG.pdf [archived]

Nemesis breaking Intel SGX. Side-channel attack. https://vanbulck.net/files/ccs18-nemesis.pdf [archived]

Breaking Intel SGX. Side-channel attacks, speculative execution (Spectre). https://www.usenix.org/system/files/conference/woot18/woot18-paper-koruyeh.pdf [archived]

2017:

CLKscrew breaking ARM TrustZone. Exploits software-exposed energy management mechanisms. https://www.usenix.org/system/files/conference/usenixsecurity17/sec17-tang.pdf [archived]

Rowhammer called SGX-Bomb. Locking down the CPU running Intel SGX via an unprivileged user. https://dl.acm.org/doi/10.1145/3152701.3152709 [archived]

Dark-ROP breaking Intel SGX. Code-reuse attack, exploiting memory corruption vulnerability. https://www.usenix.org/system/files/conference/usenixsecurity17/sec17-lee-jaehyuk.pdf [archived]

Breaking Intel SGX. Side-channel attack (branch shadowing). https://arxiv.org/pdf/1611.06952 [archived]

BOOMERANG breaking the most popular commercial TEE platforms in 2017. Confused deputy attack. https://sites.cs.ucsb.edu/~vigna/publications/2017_NDSS_Boomerang.pdf [archived]

CacheZoom breaking Intel SGX. Side-channel attacks, cache attack. https://arxiv.org/pdf/1703.06986 [archived]

MemJam breaking Intel SGX. Side-channel, intra cache level timing attack. https://arxiv.org/pdf/1711.08002 [archived]

SGX-Step breaking Intel SGX. Side-channel attacks. Provides practical attack framework for precise enclave execution control. https://vanbulck.net/files/systex17-sgxstep.pdf [archived]

Breaking Intel SGX. Side-channel attacks, cache attack. https://www.usenix.org/system/files/conference/woot17/woot17-paper-brasser.pdf [archived]

Breaking Intel SGX. Side-channel attacks, cache attack. https://dl.acm.org/doi/10.1145/3065913.3065915 [archived]

Breaking Intel SGX. Side-channel attacks, cache attack. https://www.usenix.org/system/files/conference/atc17/atc17-hahnel.pdf [archived]

Breaking Intel SGX. Side-channel attacks, cache attack. https://arxiv.org/pdf/1702.08719 [archived]

Breaking Intel SGX. Exploits Rowhammer bug. https://arxiv.org/pdf/1710.00551 [archived]

2016:

AsyncShock, exploiting synchronisation bugs in Intel SGX, making it possible to break Intel SGX. https://lsds.doc.ic.ac.uk/sites/default/files/esorics2016%20%281%29.pdf [archived]

ARMageddon breaking ARM TrustZone on default configured unmodified Android smartphones. Cross-core cache attacks. https://www.usenix.org/system/files/conference/usenixsecurity16/sec16_paper_lipp.pdf [archived]

The first paper demonstrating [archived] an attack against the Intel SGX was published in May 2015 by Xu et al. In this work, they introduced controlled-channel attacks targeting Haven, a system based on [archived] Intel SGX built using an instruction-accurate SGX emulator. Notably, this research was conducted prior to the public release of SGX-capable hardware, which occurred in August 2015 with the launch of the first SGX-enabled Skylake CPUs.

Other TEE related vulnerability / exploitation resources:

• https://www.usenix.org/system/files/sec20-suciu.pdf [archived]
• https://bits-please.blogspot.com/2016/06/trustzone-kernel-privilege-escalation.html [archived]
• https://web.archive.org/web/20190713192805/https://www.synacktiv.com/posts/exploit/kinibi-tee-trusted-application-exploitation.html
• https://www.usenix.org/system/files/sec20-harrison.pdf [archived]
• https://medium.com/taszksec/unbox-your-phone-part-iii-7436ffaff7c7 [archived]
• https://vanbulck.net/files/usenix23-aexnotify.pdf [archived]
• https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=10646767 [archived]

Edit: 10th October 2025. Added Battering RAM.