Most organizations already encrypt their data. Disks are encrypted, connections run over TLS, and backups are protected. Yet there is a third state of data that traditional encryption leaves exposed — and it is the one that matters most.
Data exists in three states: at rest, in transit, and in use. The first two are well covered. The third is not. The moment an application actually processes information, that information must be decrypted in memory. At that instant it is plain text — visible in principle to the operating system, the hypervisor, the infrastructure administrators, and anyone who manages to compromise them.
Confidential computing is the technology designed to close this last gap.
What Is Confidential Computing?
Confidential computing protects data while it is being processed by running the workload inside a hardware-based Trusted Execution Environment (TEE) — an isolated, encrypted region of memory created and enforced by the processor itself.
Inside a TEE, memory is encrypted with keys held in the silicon. The host operating system and the hypervisor can schedule the workload, but they cannot read it. Neither can a cloud administrator with root access, nor an attacker who compromises the host.
Encryption at rest protects data you are not using. Confidential computing protects data you are.
This changes the trust model of the cloud in a fundamental way. Traditionally, using a cloud provider means trusting that provider — its staff, its processes, its contracts. Confidential computing replaces part of that trust with hardware guarantees. The provider is no longer inside the security boundary.
Attestation: The Part That Makes It Verifiable
Isolation alone would not be enough. If you cannot verify what is running inside the protected environment, you are simply trusting a different promise.
This is why remote attestation is the second essential component. Before you send sensitive data or a proprietary model into a TEE, the hardware produces a cryptographic report describing exactly what code is running inside and on what platform. You verify that report first, and release your data only if it matches what you expect.
Attestation is what turns "trust our cloud" into something a security team can actually check.
How It Works in Practice
Modern confidential computing operates at the level of the whole virtual machine. Technologies such as AMD SEV-SNP and Intel TDX allow a standard VM to run inside hardware-encrypted memory without rewriting the application.
This is a significant practical point. Earlier approaches required developers to partition their code into special secure enclaves — a substantial engineering effort. VM-level confidential computing supports a lift-and-shift model instead: existing workloads move into a protected environment largely as they are.
The same principle now extends to GPUs. Confidential computing support on modern NVIDIA data-center GPUs means that AI training and inference can be protected too — not just the data, but the model weights themselves.
Why It Matters Now
The regulatory direction of travel
GDPR does not name confidential computing, and it never will. But Article 32 requires security measures appropriate to the risk and reflecting the state of the art — a deliberately moving standard. As hardware-based in-use protection becomes widely available on mainstream cloud platforms, the argument that it was impractical becomes harder to sustain.
Other frameworks are more explicit. DORA, which governs digital operational resilience in EU financial services, refers directly to protecting data at rest, in transit, and in use. The gap has been named in regulation.
The EU AI Act adds a further dimension. Its high-risk obligations were postponed in mid-2026 and now apply from December 2027 for standalone systems, but transparency obligations remain live from August 2026 — and the underlying security expectations for AI systems have not moved at all. Compliance deadlines slip. Threat models do not.
For a broader view of the regulatory baseline, see our guide to GDPR compliance in the cloud.
AI made the problem urgent
AI workloads concentrate sensitive information in one place. A model may be fine-tuned on medical records, financial transactions, or legal documents. A retrieval-based assistant queries a knowledge base built from internal company documents. Prompts, retrieved context, embeddings, and model weights are all valuable, and all of them exist in plain text in memory during processing.
Confidential computing allows organizations to run these workloads on infrastructure they do not own, without exposing the data or the model to that infrastructure.
Common Use Cases
- Confidential AI — training, fine-tuning, and inference on regulated data without exposing inputs or model weights.
- Multi-party analytics and data clean rooms — two organizations compute a joint result without either seeing the other's raw data.
- Regulated workloads in shared infrastructure — healthcare, finance, insurance, and public sector processing in multi-tenant clouds.
- Protection from insider and privileged access risk — reducing what a compromised administrator account can reach.
- Digital sovereignty — technical, not merely contractual, assurance about who can access data.
What Confidential Computing Does Not Solve
It is a control, not a cure. An honest assessment includes the limits:
- It does not fix your access model. If an authorized user can query sensitive data, a TEE will faithfully protect that query. Identity and authorization remain your problem — which is why confidential computing complements rather than replaces a Zero Trust approach.
- It is not immune to attack. TEEs have a documented history of side-channel research, and hardware assumptions can be challenged.
- It has a performance cost. Usually modest with VM-level technologies, but real, and worth benchmarking for latency-sensitive workloads.
- Attestation is the hard part. Verifying attestation reports correctly, and managing keys around them, is consistently reported as the biggest practical adoption challenge. Deployed carelessly, it provides the appearance of assurance rather than assurance itself.
Getting Started
You do not need to protect everything. Start by identifying the workloads where the infrastructure operator being able to read memory would be a genuine problem — regulated personal data, valuable models, multi-party computations — and address those first.
From there, the practical questions are straightforward: which TEE technology does the platform use, is attestation available and independently verifiable, does the workload need code changes, and what is the measured overhead? Organizations already using virtual machine encryption have the natural next step available; those running AI workloads should look at protection on GPU servers for machine learning as well as CPUs.
Conclusion
Confidential computing is not a new layer of paperwork. It is the point at which "we encrypt your data" stops being a partial statement.
Analysts now expect in-use protection to become a default expectation rather than a specialist option within a few years. For any organization processing regulated data or valuable models on infrastructure it does not physically control, the question is no longer whether hardware-protected processing is worth understanding — only which workloads should move there first.
