What Is Confidential Computing? Encrypting Data in Use

Confidential computing is a set of hardware and software techniques that keep data encrypted while it’s actively being processed in memory, not just while it’s stored on disk or moving across a network. It closes the last gap in the standard “data at rest, data in transit” security model: the moment data is decrypted to be computed on, it has traditionally been exposed in plaintext to the operating system, the hypervisor, and anyone with sufficient access to the physical machine.

The problem: data in use is the gap

Most security architectures treat two states of data carefully and one carelessly:

• Data at rest — encrypted on disk, typically with something like AES. See encryption at rest vs. in transit for how these two states are usually handled.
• Data in transit — encrypted over the network via TLS.
• Data in use — historically, plaintext in RAM the moment a CPU actually operates on it.

For most workloads this gap doesn’t matter, because the only party with access to that RAM is the workload’s own operator. But it matters a great deal for a specific and increasingly common scenario: running your workload on infrastructure you don’t fully trust — a public cloud, a third party’s server, or any environment where the operating system and hypervisor are outside your control. A cloud provider’s own administrators, a compromised hypervisor, or a malicious co-tenant could, in principle, read memory contents while your code runs. Confidential computing is designed to remove that exposure.

Trusted execution environments

The core mechanism is a trusted execution environment (TEE) — a hardware-isolated region of the CPU where code and data are encrypted in memory and only decrypted inside the processor itself, invisible to the OS, hypervisor, and anyone with physical access to the machine. Several CPU vendors ship their own implementations, generally under names like “secure enclave,” “trust domain,” or “confidential VM,” but the underlying idea is consistent: the processor draws a hard boundary around a piece of memory that nothing outside it — including privileged software — can read or tamper with.

This is a different trust model from software-only isolation like containers or virtual machines. A VM hypervisor can, by design, inspect the memory of the VMs it hosts. A TEE is specifically built to deny that access to the hypervisor too — the isolation is enforced by the processor’s own memory encryption and access-control hardware, not by software running at a higher privilege level.

Attestation: proving the enclave is real

Isolation alone isn’t enough — a client trusting a TEE with sensitive data needs proof that it’s actually talking to genuine, unmodified hardware running the expected code, not a spoofed environment. That’s what remote attestation provides: the TEE generates a cryptographically signed report describing its hardware identity and a measurement (a hash) of the code it’s running. A remote party checks that signature against the chip vendor’s public key and compares the code measurement against a known-good value before sending any secrets.

This attestation step is what turns “trust the cloud provider” into “verify the specific enclave, cryptographically, every time.” It’s conceptually similar to how a TPM attests to a device’s boot state, except the code identity being attested is that of the running workload itself rather than the boot chain.

Confidential computing vs. encryption at rest and in transit

	At rest	In transit	In use (confidential computing)
Protects against	Disk theft, unauthorized storage access	Network eavesdropping	Privileged access to running memory
Mechanism	Disk/file encryption	TLS	Hardware-isolated TEE + memory encryption
Who can be excluded	Anyone without disk access	Network intermediaries	The OS, hypervisor, and cloud operator
Maturity	Standard practice	Standard practice	Newer, workload- and hardware-dependent

Real-world use cases

Confidential computing shows up wherever multiple parties need to compute on sensitive data without any one of them seeing the others’ data in the clear:

• Multi-party data analysis — banks or hospitals pooling data for fraud detection or research without exposing raw records to each other or to the cloud provider running the computation.
• Confidential AI inference — running inference on proprietary models or sensitive prompts on rented infrastructure, where neither the model weights nor the input data are exposed to the host.
• Regulated workloads in public cloud — healthcare, financial, and government workloads that need to run on shared infrastructure while meeting requirements that historically pushed them toward on-premises hardware or a dedicated VPC.
• Key management — performing cryptographic operations, like unwrapping keys, inside an enclave so the plaintext key never touches general-purpose memory.

Limitations and trade-offs

Confidential computing isn’t a universal fix. TEEs have historically carried a performance overhead from memory encryption and the restricted execution model, though this has narrowed significantly on newer hardware generations. Side-channel attacks — inferring secrets from timing, power consumption, or cache behavior rather than reading memory directly — remain an active research area against TEE implementations, and hardware vendors periodically patch newly discovered classes of them. And attestation only proves what code is running; it says nothing about whether that code is well-written, so it doesn’t replace ordinary application-level security practices like the zero-trust principle of least privilege.

It’s also not a substitute for encryption at rest and in transit — it’s the third leg of the same stool. A workload with a TEE but a plaintext database backup, or TEE processing over an unencrypted network link, has just moved the weakest point rather than removed it.

The takeaway

Confidential computing extends encryption to cover the one state data traditionally wasn’t protected in: while it’s actually being computed on. Hardware-isolated trusted execution environments keep memory encrypted and inaccessible to the operating system, hypervisor, and cloud operator, and remote attestation lets a client verify it’s really talking to genuine, unmodified hardware before trusting it with anything sensitive. It’s most valuable exactly where you’d expect — running sensitive workloads on infrastructure you don’t fully control — and it complements, rather than replaces, encryption at rest and in transit and ordinary application security discipline.