When we rent a machine in the cloud, trust rests on a contractual promise: the provider says it does not look at our data. For decades that promise had no technical backing. The hypervisor — the software that shares out CPU and memory among virtual machines — can in principle read any byte our code writes to RAM. If someone with privileges on the physical machine wants to see what our application is processing, they do not need to break any disk encryption: they only have to dump the memory of the running process.
The solution the industry has been rolling out for years is called confidential computing, and it rests on a simple idea: put the workload inside an encrypted envelope whose lock is built into the processor itself. The area of memory and CPU where that code lives is called a TEE (Trusted Execution Environment) or enclave. Inside it, the key that decrypts the RAM is generated and held by the silicon, and neither the host operating system nor the hypervisor ever gets to touch it.
Where the key lives
The centrepiece is the memory encryption engine, today integrated into the processor package itself, very close to the memory controller. Every protected virtual machine starts out with its own symmetric key, produced by a physical random number generator inside the die (the sliver of silicon in the chip). Memory is encrypted with AES-XTS, a mode designed precisely for encrypting block storage: it keeps the encrypted region in independent chunks, so the order of writes does not change the result. That key never leaves the chip in the clear; when memory is dumped to disk to suspend a machine, it is stored wrapped with another key derived from the silicon.
Three manufacturers dominate this field today under different names: AMD SEV-SNP, Intel TDX (which supersedes the older SGX, a model of smaller enclaves) and ARM CCA, heir to TrustZone. All of them solve the same problem with the same underlying idea, even if they differ in how much integrity they guarantee. And there lies the fine print: encrypting does not stop an attacker from tampering with data traffic towards the CPU. Blocks of encrypted memory can be reordered, replayed or injected without knowing their contents. That is why modern versions add an integrity tree: for every block of memory they check a cryptographic fingerprint that reveals such tampering, at the cost of reserving a fraction of RAM (in a typical scheme, around 6%) just for those checks and of a measurable performance penalty.
Letting the client check who it is talking to
Encryption is of little use if we cannot confirm which code is running inside. That is the job of remote attestation. The processor signs a cryptographic report (quote or attestation report) containing the hash of the loaded binary, its configuration and the version of firmware or microcode it runs on — a value known as the TCB (Trusted Computing Base). The client receives that report, verifies the signature against the manufacturer’s certificate chain (AMD publishes its ARK/VCEK chain, Intel uses a quoting enclave of its own) and only then hands over its secrets. It is the digital equivalent of checking the licence plate and the seal before opening the box.
Isolation does not end at the CPU: a device with direct memory access (DMA) could read the RAM without going through the processor. That is why these environments require an IOMMU — the unit that translates and restricts peripheral addresses — and devices able to speak encrypted with the host, the so-called encrypted DMA, or interfaces such as PCIe IDE with TDISP. Without that piece, a compromised network adapter would ruin the whole guarantee.
What it still does not cover
No TEE is a perfectly airtight box. Side channels remain the weak spot: how long an operation takes, cache usage, page faults or memory access patterns leak information even when the content is encrypted. Attacks such as Spectre exploit exactly that class of clues. There are structural limits too: live migration of a confidential machine is complex, the maximum number of vCPUs is usually capped, and boot requires trusting the firmware chain. And the hypervisor, though blind, keeps considerable power: it can decide when our virtual machine runs, and encryption does not solve that ability to deny service.
On this foundation, confidential containers have been built (projects such as CoCo and Kata, now standardised in the CNCF ecosystem), wrapping applications in containers inside these protected virtual machines, along with the commercial offerings from Azure, Google Cloud and AWS Nitro Enclaves. Their real use is in scenarios where the data is too sensitive to trust the operator: joint analysis between hospitals or banks that do not want to exchange records, training and inference of models on medical histories without exposing them, or key custody in virtual HSMs.
An alternative route exists — homomorphic encryption — which allows computing on data without ever decrypting it, but its computational cost keeps it today in very specific niches. Confidential computing takes the opposite path: it decrypts inside a bubble and relies on the hardware to keep everyone else out. It is not an absolute guarantee; it is a shift of trust: from the contract with the provider to the processor silicon and its certificate chain. For many organisations, that change — being able to prove with mathematics what used to be a verbal promise — is already the decisive argument.
