What "Confidential Computing" Actually Protects — and What It Doesn't

A new DDR5 attack is a reminder that processor-based isolation was never
designed to solve the full problem.

Munich, September 2026 — The academic paper "DDRop: Active Memory Interposer
Attacks on Confidential VMs by Dropping DDR5 Writes," presented at ACM CCS
2026, demonstrates a practical physical attack against Intel TDX, Intel
Scalable SGX, and AMD SEV-SNP using a hardware interposer costing less than
$200. The attack exploits the absence of cryptographic freshness protection in
current memory encryption and can compromise the integrity of confidential
virtual machines — including forging attestation reports.

DDRop is significant, but it is not surprising. It follows a pattern: BadRAM,
Battering RAM, CacheOut, Plundervolt, SGAxe. Each new generation of attacks
demonstrates another boundary condition that processor-based Trusted Execution
Environments were not designed to cover. The real issue is not any single
vulnerability. It is how the technology is positioned.

A. TEEs protect against the neighboring VM — not against the infrastructure

Major cloud providers market Intel TDX and AMD SEV-SNP as "confidential
computing" — a term that implies comprehensive protection of data during
processing. In practice, these technologies do one thing well: they isolate a
virtual machine from the hypervisor and from co-tenant workloads on the same
physical server. That is a meaningful security improvement for shared
infrastructure.

But it is not confidential computing in the sense that most customers
understand the term. TEEs do not protect against the cloud operator who has
physical access to the hardware, controls the network, manages the
orchestration layer, and may be subject to legal compulsion. They do not
protect against supply-chain manipulation of firmware or hardware components.
And as DDRop demonstrates, they do not fully protect against physical
interference with the memory subsystem.

"When a customer hears 'confidential computing,' they expect that their data
is protected during processing — full stop," says Udo Riedel, CTO of
DriveLock. "What they actually get with current TEE offerings is protection
against a specific class of co-tenant attacks on shared hardware. That is
valuable, but it is not what the term promises."

B. The distinction matters

For workloads that are sensitive enough to require confidential computing —
medical data, financial processing, classified information, AI training on
proprietary datasets — the threat model extends well beyond the neighboring
VM. It includes the operator, the operator's personnel, the operator's legal
jurisdiction, and anyone with physical access to the hardware.

A TEE does not address any of these. It was never designed to. Intel and AMD
are transparent about this in their technical documentation. But somewhere
between the engineering specification and the sales deck, "protects the VM
from the hypervisor" becomes "your data is protected during processing."

C. An architectural problem requires an architectural answer

idgard's Sealed Cloud, a subsidiary of DriveLock, follows a different design
principle: rather than isolating a workload within shared infrastructure, it
isolates the infrastructure itself. Customer workloads run on dedicated
bare-metal servers that boot from the network with no local storage. The
operator is excluded from access to customer data by architecture — through
physical sealing with tamper detection, automated data clean-up before any
maintenance access, cryptographic key separation, and a zero-knowledge
operating model.

"DDRop is a good example of why we chose this path," says Riedel. "The
interposer requires physical access to the server. In our architecture, the
compute segments are physically sealed and monitored. Unauthorized access
triggers an automated shutdown and data purge. That doesn't make us immune to
every conceivable physical attack — no honest vendor claims that. But it means
that the physical layer is part of our security architecture, not outside of
it."

D. What organizations should ask their cloud provider

The lesson from DDRop is not that TEEs are broken. It is that organizations
should understand exactly what their confidential computing solution actually
protects against. Three questions matter:

1. What is the trust model? Who must be trusted for the security guarantee to hold — the processor vendor, the cloud operator, the datacenter staff, a foreign legal jurisdiction?

2. What happens at the physical layer? Is the hardware shared? Who has physical access? What happens if someone opens the server?

3. What does "confidential" actually cover? Protection from co-tenants? From the operator? From legal compulsion? From physical manipulation?

TEE-based confidential computing gives a clear answer to the first question.
For most customers, it is not the answer they expect.

E. About idgard / Sealed Cloud

idgard, a DriveLock subsidiary, operates the Sealed Cloud — a sovereign
bare-metal Kubernetes platform with patented operator shielding. The platform
runs customer workloads including containerized applications, databases, and
AI inference on dedicated hardware in German datacenters, with full technical
exclusion of operator access. Deployment models include sovereign cloud,
on-premise (Seed), and autonomous edge installations.

FAQ