Confidential Computing Explained: Protecting Data While It Is in Use

Encryption is good at protecting information that is stored on a drive or traveling across a network. The difficult moment comes when a computer must actually use that information.

To calculate a result, software normally loads data into memory and makes it available to the processor. Powerful system software, such as an operating system or hypervisor, may also have broad access to that environment. This creates a gap between encrypted storage and encrypted communication.

Confidential computing narrows that gap by placing sensitive code and data inside a hardware-protected environment while they are processed. It reduces how much of the surrounding computer must be trusted.

The three states of data

Security discussions often divide data into three states:

1. Data at rest sits in a database, file system, backup, or storage device. Disk and database encryption can protect it.
2. Data in transit moves between devices or services. Secure network protocols can protect it from interception and tampering.
3. Data in use is being read, compared, transformed, or analyzed by running software.

The first two states have familiar protections. The third is harder because ordinary computing requires code to access usable values. Even if memory is encrypted outside the processor, authorized instructions need to work with the underlying information inside a protected boundary.

Confidential computing addresses this problem with hardware isolation rather than trying to keep every value mathematically encrypted during every instruction. It complements storage and transport encryption; it does not replace them.

This matters most on shared infrastructure. Cloud computing gives organizations flexible access to servers they do not physically control. Confidential computing can reduce the need to trust the cloud operator, host operating system, hypervisor, and neighboring workloads with the contents of a sensitive process.

What a trusted execution environment does

The protected area is called a trusted execution environment, or TEE. It is an isolated region backed by processor security features. Depending on the design, the TEE may contain a small section of an application, a process, a container, or an entire virtual machine.

Code and data inside the TEE are separated from software outside it. Memory belonging to the protected workload can be encrypted so that the host sees unreadable contents. Access rules enforced by hardware aim to stop other processes, administrators, the hypervisor, and the host operating system from reading or changing that protected memory.

Authorized code still needs usable data to perform a calculation. Inside the processor's protected context, the code can work with that data. From outside the boundary, the memory remains inaccessible or encrypted. This is why saying that data is "always encrypted while being computed" can be misleading. The more precise claim is that its use is isolated inside a hardware-enforced trust boundary.

How confidential computing works

A practical confidential workload usually depends on more than memory encryption. It combines isolation, measurement, attestation, and controlled access to secrets.

1. A protected environment starts

The system launches an enclave, confidential virtual machine, or another supported workload on TEE-capable hardware. The processor establishes an isolated memory region and protects it from the surrounding host.

2. The environment is measured

The platform records cryptographic measurements that represent important parts of the workload and its configuration. A measurement can help identify which code started, how the environment was configured, and whether required security features were enabled.

This is not a judgment that the application is bug-free. It is an identity and state check: does this running environment match the version and configuration that a policy expects?

3. Remote attestation checks the evidence

The TEE produces signed evidence rooted in the hardware. An attestation service or another verifier examines that evidence and compares its claims with policy. A remote party can then decide whether it trusts the environment before sharing sensitive material.

Attestation is the feature that makes the protection verifiable rather than a request to take the server operator's word for it. It also supports a zero trust approach: access can depend on evidence about the current workload instead of its network location alone.

4. Keys and data enter only after approval

If the attestation result satisfies policy, a key manager can release a decryption key to the protected environment. Encrypted code, models, or records can then be opened only inside the approved TEE.

5. The workload returns an allowed result

The application performs its calculation and releases an output defined by the system's rules. That output still needs ordinary access control, privacy review, and secure transport. A TEE protects the computation boundary, but it cannot decide whether the requested result reveals too much.

Enclaves and confidential virtual machines

Two broad designs make different tradeoffs.

An application enclave protects a deliberately limited portion of a program. Keeping the trusted code small can reduce the amount that must be reviewed. However, developers may need to redesign the application, carefully control every boundary crossing, and account for a more constrained runtime.

A confidential virtual machine protects a much larger workload, often including the guest operating system and applications. Existing software may be easier to move into this model because the isolation surrounds the VM. The trusted computing base is also larger, so more code remains capable of accessing the data from inside the protected guest.

Neither design is universally stronger. The right choice depends on the threat model, application architecture, performance needs, and how much software an organization is prepared to trust.

Where confidential computing can help

Sensitive cloud workloads

An organization can process financial, health, government, or proprietary business data while reducing exposure to the underlying cloud host. This can add an important layer when contractual controls and conventional encryption are not enough for the workload's risk.

Joint analysis between organizations

Several parties may want a shared result without giving one participant unrestricted access to everyone else's records. They can encrypt inputs for an attested workload, release keys only to the approved environment, and limit what comes back out.

Protected AI models and inputs

AI creates two valuable assets in one computation: the user's data and the model itself. A confidential environment can help protect private inputs from infrastructure operators while also making a proprietary model harder to inspect from outside the workload.

This approach is different from federated learning, where participants train locally and share model updates. Federated learning distributes the training data; confidential computing isolates a calculation. The two techniques can also be combined.

Edge and remote processing

A protected workload may run near a factory, vehicle, retail site, or communications network. Attestation can let a central service verify the software state before releasing a key or accepting a result. That extends ideas from edge computing with a hardware-backed way to evaluate remote execution.

What confidential computing does not protect

The phrase sounds broad, but its boundary is specific.

It does not fix vulnerable application code. If authorized code inside the TEE has a memory safety bug, insecure dependency, or flawed permission check, the protected environment may faithfully run that vulnerable code.

It does not make inputs or outputs safe. Malicious input can still exploit an application. An output can still reveal a person's information or expose too much about a confidential dataset.

It does not eliminate side channels. Timing, memory access patterns, shared hardware behavior, and implementation flaws can leak information without directly reading protected memory. Defenses depend on the processor, firmware, workload, and threat model.

It does not guarantee availability. A host may be unable to read a workload yet still pause it, deny it resources, block its network, or destroy it. Confidentiality and integrity are different from uptime.

It does not remove operational work. Teams must patch hardware and firmware, review attestation claims, rotate keys, update approved measurements, monitor failures, and plan for revoked or replaced platforms.

There can also be performance and portability costs. Extra isolation, encrypted memory, attestation, and boundary crossings may add overhead. Hardware capabilities and programming models differ, which can make migration between environments harder.

Questions to ask before adopting it

A useful evaluation starts with the threat, not the feature name:

1. Which data and code need protection while running?
2. Which actors should be unable to access them: other tenants, host administrators, the hypervisor, or someone else?
3. What code remains inside the trusted computing base?
4. Which measurements and security claims will attestation verify?
5. Who controls the verification policy and key release?
6. What information can leave through logs, errors, network requests, and final outputs?
7. How will patches change approved measurements without causing unsafe exceptions?
8. Which side channels, availability risks, and hardware failures remain outside the design?

If a provider cannot answer these questions precisely, the word "confidential" offers little assurance on its own.

The bottom line

Confidential computing protects data in use by processing it inside a hardware-based, attested trusted execution environment. Hardware isolation reduces access from the host and other surrounding software. Attestation lets a remote party check the environment before releasing keys or sensitive data.

It fills an important gap between encryption at rest and encryption in transit, especially for shared cloud systems, sensitive collaboration, AI, and remote workloads. It remains one layer in a larger security design. The application, key policy, inputs, outputs, hardware, and operations all determine whether the complete system deserves trust.