Confidential computing is a way of protecting data while it is being processed, not only while it is stored or sent across a network. Workloads run inside a hardware-isolated environment, often called a trusted execution environment, whose memory is encrypted and kept apart from the rest of the system, including the operating system, hypervisor and, in many designs, the cloud provider’s administrators. The environment can also provide a remote party with signed attestations about its identity, configuration and measured software, a step called attestation.
At a glance
- Encryption traditionally protects data at rest and in transit; confidential computing targets data in use.
- It relies on processor features that isolate and encrypt a workload’s memory, available from the major chip makers and offered by major cloud providers.
- Attestation gives you or a key service signed measurements of the platform and the software loaded at startup, to check before secrets are released; what is measured varies by hardware and service.
- Common forms are confidential virtual machines, confidential containers and smaller application enclaves.
- Strength depends on the hardware, the service design and who controls keys and attestation, so it is not a blanket guarantee.
What problem it solves
To compute on data, a system normally has to decrypt it in memory. Anyone with enough control of the machine, such as a compromised hypervisor, a malicious insider with host access or someone with physical access, could in principle read it there. For many workloads that risk is acceptable. For regulated data, sensitive intellectual property or jurisdictions where organizations worry about provider or government access, it can block a move to the cloud.
Confidential computing narrows who and what can see data while it is being used. It also enables some new patterns, such as several organizations pooling sensitive data for joint analysis without any of them, or the operator, seeing the others’ raw data, and running AI models on sensitive inputs in shared infrastructure.
How it works
Hardware isolation. Modern server processors can create protected regions of memory that are encrypted with keys held inside the processor. Code outside the protected region, including the host operating system and hypervisor, can’t read or change its contents in normal operation.
Confidential VMs and containers. The most common cloud form wraps a whole virtual machine or container in this protection, so existing applications can often run unchanged. Some providers extend it to graphics processors for AI workloads.
Enclaves. An alternative protects only a small, sensitive part of an application, such as key handling. This shrinks what must be trusted but usually requires application changes.
Attestation. Before trusting the environment, a verifier checks a signed report from the hardware with claims about the platform, its configuration and measurements of the software loaded. Keys or data are released only if the report matches expectations. What is measured, and when, varies by hardware and service, and a report reflects the environment’s state when it was measured, not proof of how the workload behaves while it runs. Who runs that verification, you, the cloud provider or a third party, affects how much you must trust the provider.
Key management. Data is commonly encrypted with keys you control, sometimes stored in a hardware security module (HSM) or a key service, and released to the environment only after successful attestation.
When it matters for buyers
- When moving regulated or highly sensitive workloads to the cloud. It can address concerns about provider access that encryption at rest doesn’t.
- When data sovereignty is on the table. It is one tool, alongside location and key control, in data sovereignty discussions.
- When sharing data with partners for joint analysis. It can let each party contribute data without exposing it to the others.
- When running AI on sensitive data. Confidential VMs and GPUs are increasingly offered for private AI workloads.
- When reviewing the shared responsibility model. It changes what you have to trust the provider for, but doesn’t remove your own responsibilities.
To see how this fits into cloud provider selection, see our public cloud overview.
Questions to ask vendors
- Which forms do you offer (confidential VMs, containers, enclaves, GPUs), in which regions and instance types?
- Which hardware technology protects the workload, and what threats does it explicitly exclude?
- How does attestation work, and can we verify it ourselves or through a third party rather than relying only on you?
- Who controls the keys, and can they be released only after attestation?
- What changes to our applications, images or deployment are required?
- What performance and price differences should we expect for our workload?
- How do you handle firmware and hardware vulnerabilities that affect the protection?
How it differs from encryption at rest and in transit
Encryption at rest protects data on disks and in storage, and encryption in transit protects it on the network. Both stop at the point where an application needs to use the data, because the data is decrypted in memory to be processed. Confidential computing covers that remaining state, data in use, by keeping memory encrypted and isolated in hardware while the workload runs. It complements rather than replaces the other two: a complete design usually encrypts data in all three states and ties key release to attestation. Other approaches to computing on sensitive data, such as homomorphic encryption, which computes on data that stays encrypted, are mostly used in narrower cases today.