Encryption has a well-known blind spot. Data is usually protected at rest on disk and in transit over the network, but the moment it gets loaded into memory to actually be processed, it has to be decrypted first. That’s the gap confidential computing is designed to close, and it’s becoming a bigger deal as more sensitive workloads move to shared cloud infrastructure that companies don’t physically control.

The Problem With “Trust the Cloud Provider”

Cloud security has traditionally rested on a layered set of promises: the hypervisor isolates your virtual machine from your neighbor’s, the operating system isolates processes from each other, and access controls keep unauthorized people out. Those layers work well against outside attackers, but they all assume the infrastructure operator itself, along with anyone who compromises its privileged software, is trustworthy.

For a lot of workloads that assumption is fine. But for things like healthcare records, financial transactions, or proprietary machine learning models, some organizations want a stronger guarantee: that not even a compromised hypervisor, a malicious cloud administrator, or a rooted host OS can read their data while it’s being computed on.

How Trusted Execution Environments Work

Confidential computing relies on hardware features generally called trusted execution environments, or TEEs. Chipmakers build these directly into the processor. The core idea is to carve out an encrypted, isolated region of memory, sometimes called an enclave, where code and data are decrypted only inside the CPU itself. Everything outside that boundary, including the hypervisor, the OS kernel, and physical memory, sees only encrypted, unreadable content.

A remote party can also ask the TEE for a signed statement, called an attestation, proving that a specific piece of code is running inside a genuine, unmodified enclave. That lets a customer verify what’s actually executing before sending it any sensitive data, rather than just trusting a vendor’s word for it.

Different chip vendors implement this with different names and different tradeoffs. Some approaches protect the memory of an entire virtual machine, which is easier to adopt because existing applications need little or no modification. Others protect smaller, more granular application-level enclaves, which shrinks the attack surface further but usually requires rewriting software to fit the enclave’s constraints.

Where It Actually Gets Used

The clearest use case is multi-party computation, where several organizations want to run analysis on a combined dataset without any of them exposing their raw data to the others, common in fraud detection consortiums or medical research collaborations. Confidential computing also underpins “clean rooms” for advertising and analytics, where companies want to match datasets against each other without either side seeing the other’s underlying records.

It’s also relevant to cloud migration for regulated industries. Banks and healthcare providers that were hesitant to move certain workloads off their own hardware have a stronger technical argument for doing so when the cloud provider can cryptographically prove it can’t see inside the enclave.

The Tradeoffs

None of this is free. TEEs add computational overhead, since encryption and decryption happen constantly at the memory boundary. They also have a track record of side-channel vulnerabilities, where attackers infer secrets from timing, power consumption, or cache behavior rather than breaking the encryption directly. Hardware vendors keep patching these issues, but it’s an ongoing arms race rather than a solved problem.

There’s also a practical adoption hurdle. Application-level enclaves often need real code changes, and different vendors’ TEEs aren’t interchangeable, which makes portability across clouds harder than it should be. Standards groups have been working on common APIs and attestation formats, but the ecosystem is still maturing.

Confidential computing won’t replace the existing layers of cloud security, and it’s not going to be the default for every workload given the overhead involved. But as a targeted tool for the subset of data that genuinely needs protection from the infrastructure operator itself, it fills a real gap that encryption at rest and in transit never addressed.