TEE.fail does not make confidential computing security theatre

TEE.fail and related research demonstrate several practical physical attacks against confidential-computing hardware. Depending on the platform, researchers have extracted workload keys, recovered attestation keys, forged measurements, replayed protected memory, and composed a CPU compromise into a false GPU attestation. Those results should change how some systems are designed and how the technology is marketed. They do not make confidential computing security theater. Confidential compute can still remove powerful software actors, including a compromised host, hypervisor, or cloud administrator, from the trust boundary. A control can provide meaningful security without defeating every attacker.

Table of contents

What the physical attacks proved
What the attacks did not prove
Where the criticism is justified
Nitro makes a different trade-off
Why Caution is designed for hardware diversity
Security theater is the wrong conclusion
Further reading

What the physical attacks proved

TEE.fail is an ongoing security research effort, not one generic key-extraction exploit. It builds on a line of physical memory attacks whose methods and consequences depend on the hardware:

WireTap passively observed DDR4 memory traffic and used Intel’s deterministic memory encryption to recover an SGX attestation key. Its main result was a confidentiality failure that became an attestation failure.
Battering RAM used an active interposer costing less than $50 to create dynamic memory aliases. On Intel SGX, it enabled plaintext reads and writes through ciphertext replay. On AMD SEV-SNP, it replayed a valid launch measurement so a modified VM could be attested as genuine.
TEE.fail brought passive bus observation to DDR5 systems with equipment costing less than $1,000, then followed different exploit paths on each platform. On Intel SGX and TDX, the researchers extracted a provisioning certification key and forged attestations. On AMD SEV-SNP with Ciphertext Hiding enabled, they extracted an OpenSSL ECDSA workload key. For Nvidia confidential computing, they exploited its dependence on the CPU trust domain to present a genuine GPU attestation while running the workload without TEE protection.

The application-level consequences were different again. The researchers extracted configuration secrets and demonstrated undetectable front-running against BuilderNet, directly recovered a Secret Network node’s ECDH key without attacking its quoting enclave, and showed TDX and GPU-attested applications running outside TEE protection.

These attacks share a requirement for access to the physical memory path, but they do not all break the same component or security property. Depending on the platform and system design, physical access became memory disclosure, memory modification, workload-key theft, attestation-key theft, forged measurements, or misuse of a neighboring hardware trust chain. The variety is the point.

The equipment was built from readily available parts and ranged from less than $50 to less than $1,000. That price matters. Describing all physical attacks as prohibitively sophisticated is no longer credible. At the same time, some attacks do require more expensive equipment such as electron microscopes.

There is also a genuine disagreement about scope. Intel and AMD classify this kind of physical interposition as outside their threat models and recommend physical security rather than a firmware mitigation. Yet the Confidential Computing Consortium’s technical analysis lists bus monitoring among the basic physical attacks considered in scope, while excluding more invasive techniques such as chip scraping and electron-microscope probing.

TEE.fail therefore exposed more than a clever attack. It exposed a gap between what users may reasonably understand confidential computing to protect and what particular hardware vendors actually promise. That gap deserves direct language, not marketing evasions.

What the attacks did not prove

These attacks did not show that a remote attacker, a malicious hypervisor, or a cloud administrator can simply read a confidential workload’s memory. They did not erase the isolation that confidential compute provides against those actors. They showed several ways an attacker who can reach the correct physical machine and instrument its memory path can cross that boundary on the tested platforms.

Those are different threat models.

Confidential computing exists primarily because conventional cloud security gives privileged infrastructure software and its operators enormous power. Confidential compute can prevent the host operating system, hypervisor, and administrators from inspecting or silently modifying a workload. Remote attestation can let a user verify the measured environment before releasing data or keys. Neither property becomes imaginary because a separate physical attack exists.

Calling the entire field security theatre makes the perfect the enemy of the materially safer. TLS does not become theatre because a compromised endpoint can read plaintext. Full-disk encryption does not become theatre because it cannot protect a machine after it has been unlocked. Security controls are evaluated against specific attackers, not against omnipotence or a cherry-picked set of conditions under which they fail.

The honest claim is not that confidential compute makes a remote machine trustless. It is that confidential compute can drastically reduce whom and what must be trusted. TEE.fail, WireTap, and Battering RAM tell us that physical custody of affected Intel and AMD servers remains in that reduced trust boundary.

Where the criticism is justified

The physical-access limitation matters differently in different deployments. A workload running in a tightly controlled hyperscale data center has independent physical safeguards between an attacker and a specific server. A machine deployed at an untrusted edge location does not. A permissionless network that assumes the operator may be actively malicious should not quietly assume that the operator will decline to open the case.

The criticism is also justified when a single confidential compute server, one long-lived secret, or one attestation path can authorize an irreversible, high-value action. In that design, extracting a workload key, forging an attestation, or replaying a trusted measurement can become a systemic failure. Physical access may be harder than a remote exploit, but a large enough reward changes the economics.

Systems with those risks need more than simply hitting things with confidential compute: explicit physical-security assumptions, short-lived secrets, limited blast radius, monitoring and recovery paths, and independent machines, providers, or hardware roots that must agree. Attestation proves something about a measured environment; it should not be mistaken for a complete system architecture.

Nitro makes a different trade-off

AWS Nitro Enclaves deserve separate treatment. Nitro is in some ways a weaker and less open trust model than CPU-vendor TEEs. Its isolation depends on AWS’s Nitro system and hypervisor, its attestations depend on the AWS Nitro PKI, and customers cannot buy an equivalent attestation-capable platform to inspect and operate independently. You must trust AWS more.

That centralization also has something going for it. A production-capable Nitro platform is not commodity hardware an attacker can easily buy and operate outside AWS, and production machines are held inside AWS data centers. An attack requiring hardware access must therefore cross a substantial physical and operational boundary before its low component cost becomes relevant. Nitro’s public guarantees focus on isolation from the parent instance, not defense against an attacker who has opened the physical server. This is not cryptographic resistance to a memory-bus attack. It is a practical increase in the cost and detectability of getting close enough to attempt one.

Nitro’s attestation format adds useful provenance as well. AWS-signed attestation documents include a module ID and enclave measurements, while PCR4 contains a hash of the parent EC2 instance ID. A verifier or KMS policy can therefore restrict trust to an enclave running on a particular EC2 instance, rather than accepting any machine that presents the expected code measurement.

That is an EC2 instance identity, not an immutable physical server identity, and AWS remains the authority asserting it. Still, the combination of controlled hardware availability, data-center custody, and AWS-signed instance provenance makes the operational threat meaningfully different from a permissionless network of commodity TDX or SEV-SNP machines. Nitro gives up openness and vendor independence in exchange for a more controlled deployment perimeter. Whether that is a good trade depends on whom the system is trying not to trust. Every confidential compute solution has very real security tradeoffs and there is unfortunately no one solution to fit all threat models.

Why Caution is designed for hardware diversity

These differences are why Caution is not treating every type of confidential compute as interchangeable or forcing every workload onto one hardware root. Caution supports AWS Nitro Enclaves today. Support for Intel TDX, AMD SEV-SNP, TPM 2.0, Nvidia CC and additional cloud backends, and bare-metal deployments is in active development.

The goal is a common source-to-runtime verification workflow across those environments. A team should be able to choose Nitro when AWS’s controlled operational perimeter fits its threat model, a CPU-vendor TEE when memory encryption or independence from the cloud provider matters more, or bare metal when it needs direct control of physical custody. The hardware should be a deployment and security decision, not a permanent platform constraint. We also want to make it easy to move between solutions as you go from development to production, or start taking on higher risk users.

Hardware diversity also enables stronger compositions. The same reviewed source, release, and security policy can be built for and attested by different hardware roots. A system may accept any one approved backend, a single backend to be attested to by multiple-hardware or require independent deployments on different providers or hardware families to agree before authorizing a high-value action. The resulting measurements will not necessarily be identical across architectures; what can be verified is that each measured workload corresponds to the same approved source and policy.

This does not eliminate shared vulnerabilities, and diversity only helps when the trust roots and failure modes are genuinely independent. It does mean that a compromise of one vendor, attestation service, or physical environment does not automatically have to compromise the whole system. TEE.fail is a strong argument for making that choice available.

Security theater is the wrong conclusion

Security theater is a control that creates reassurance without meaningfully changing an attacker’s capabilities. Confidential computing does change them. It can turn a compromised host or a curious administrator from an all-powerful observer into an actor blocked by a hardware boundary. That is a substantial improvement even when the boundary is not absolute.

The right response to TEE.fail is to state the residual trust precisely. Do not claim protection against an attacker with invasive access to the server when the hardware does not provide it.

TEE.fail makes the case for better threat modelling, stronger and more diverse hardware, and defence in depth. It does not make the case for returning sensitive workloads to ordinary servers where every privileged software layer can already read them.

Those asserting that Confidential Compute is useless because it does not stop all possible attacks could just as easily assert that basic sanitation in hospitals is useless because it does not stop all infections.

Confidential computing is a critical component of any organizational security strategy.