Confidential Computing: Protecting Data While It's In Use

The third state of data, and the gap in it

Data security has long rested on two pillars. Data at rest is encrypted on disk; data in transit is encrypted over the network with TLS. Both are mature, expected, and audited. But there is a third state that both leave exposed: data in use. To actually compute on data — run a query, train a model, process a transaction — a processor has to decrypt it into memory in plaintext. For that window, the data sits unprotected in RAM, readable by anyone or anything with sufficient privilege on the machine: the hypervisor, the host operating system, a cloud administrator, or malware that has reached that level.

For most workloads this gap is tolerated because the operating environment is trusted. But it is exactly the gap that matters when you process highly sensitive data on infrastructure you do not fully control, or when the threat model includes a privileged insider or a compromised host. Confidential computing closes it — protecting data while it is being processed, not just while it is stored or moved.

How a trusted execution environment works

Confidential computing relies on hardware. Modern CPUs can create a trusted execution environment (TEE) — a hardware-isolated, encrypted region of memory where code and data are protected even from the rest of the system. The processor encrypts the enclave's memory with keys held inside the CPU, so that memory appears as ciphertext to everything outside the boundary: the host OS, the hypervisor, other tenants, and anyone with physical access to the RAM.

The critical shift is in the trust boundary. Normally, running a workload means trusting the entire stack beneath it — the hardware, the hypervisor, the host OS, and by extension whoever operates them. A TEE shrinks that boundary to the CPU and the code inside the enclave itself. You no longer have to trust the host operating system or the cloud operator to keep your in-use data confidential, because the hardware enforces the isolation below the level either of them operates at.

Attestation is the point, not a detail

A TEE that you cannot verify is just a claim. The feature that makes confidential computing trustworthy — and the part teams most often overlook — is remote attestation. Before you hand sensitive data or keys to an enclave, you need proof that:

• It is running on genuine, uncompromised TEE hardware, not an emulation.
• It is running the exact code you expect, unmodified.

Attestation provides that proof. The hardware produces a signed measurement — a cryptographic fingerprint of the enclave's contents and the platform — rooted in a key the silicon vendor vouches for. A relying party checks that measurement against what it expects, and only then releases secrets or data to the enclave. The typical pattern: an enclave starts, generates an attestation, a verifier validates it, and a key management service releases decryption keys only to an enclave that attests correctly. Without attestation you have isolation you cannot trust; with it, you have isolation you can prove. This is what makes the model a real security control rather than a marketing label.

Enclaves versus confidential VMs

TEEs come in two broad styles, and the difference determines how much you have to change to adopt them.

• Process-level enclaves. A small, specific portion of an application runs inside a tightly scoped enclave, with the rest of the app outside it. This gives the smallest trusted computing base — only the truly sensitive code is protected — but usually requires adapting the application to partition itself around the enclave boundary.
• Confidential VMs. An entire virtual machine, guest OS and all, runs inside a hardware-protected, memory-encrypted boundary. The big advantage is that existing workloads can often run largely unchanged — you lift an application into a confidential VM and its memory is protected without re-architecting it. The trusted computing base is larger (the whole guest OS is inside the boundary), but the adoption cost is far lower.

The major clouds offer both shapes: dedicated enclave environments for the fine-grained model and confidential VM families for the lift-and-run model, with confidential container options layered on top so orchestrated workloads can inherit the protection. For organizations running sensitive workloads on dedicated or private cloud infrastructure, confidential VMs are often the most practical on-ramp.

What actually runs on it

Confidential computing earns its complexity for a specific set of high-value scenarios, not for everything:

• Regulated and highly sensitive data. Processing health, financial, or personal data where the in-use exposure is a genuine compliance and risk concern, and where demonstrable protection supports obligations tracked through compliance programs.
• Protecting data from the operator. Running on infrastructure where you want the cloud provider or host administrator to be unable to see your data even in memory — reducing the operator to an untrusted party for confidentiality purposes.
• Multi-party computation. Several organizations that do not trust each other jointly compute on combined data — fraud detection across banks, shared analytics — inside a neutral enclave, so each party's raw data stays private from the others.
• Protecting keys and models. Keeping cryptographic keys, or high-value AI models and their inputs, inside an enclave so they are never exposed in plaintext to the host, even during use.

If none of these describe your risk, standard encryption at rest and in transit remains the right, proportionate baseline — a point worth making honestly rather than treating confidential computing as a universal upgrade.

The limits and the honest threat model

Confidential computing is a strong control with a bounded scope, and overstating it is a mistake.

• It does not fix application bugs. A vulnerability inside the enclave — an injection flaw, a logic error — runs with the enclave's access. The TEE protects the environment, not your code's correctness.
• Side channels remain a research frontier. TEEs have faced speculative-execution and microarchitectural side-channel attacks over time, addressed through ongoing hardware and firmware mitigation. It is a hardened boundary, not an unbreakable one.
• You still have to verify. The protection is only as good as your attestation discipline. Skip attestation and you have turned a provable control into an unverified assumption.
• There is overhead and ecosystem friction. Memory encryption and the enclave model carry some performance cost and, for the fine-grained approach, real development effort.

Treat it as one layer — a powerful one for the in-use gap — inside a broader cloud security posture, not a replacement for the rest.

Where to start

Begin with the threat model, not the technology. Identify whether you actually have a workload where in-use exposure is a real risk — regulated data, an untrusted operating environment, or multi-party computation. If you do, the confidential VM path is usually the fastest proof of value: lift a sensitive workload into a confidential VM, stand up attestation so keys release only to a verified enclave, and confirm the workload runs correctly inside the boundary. Prove it on that one workload before generalizing, and keep attestation central the whole way — it is what makes the protection real.

Confidential computing is maturing from a specialist capability into a practical option for protecting sensitive workloads, and it fits best inside a deliberate security and compliance strategy. If you want help deciding whether it belongs in your architecture and standing it up correctly, talk to our team.