Confidential Computing: Protecting Data While It's Being Used

Every security review asks the same two questions about data: is it encrypted at rest, and is it encrypted in transit? Both have had good answers for years. Disk encryption is standard, TLS is universal, and auditors tick the boxes. But there is a third state that almost nobody asks about, and it is the one where the data is most exposed: while it is actually being processed.

To compute on data, you have historically had to decrypt it. At that moment it sits in plaintext in memory, visible in principle to the operating system, the hypervisor, the cloud provider's infrastructure, and anyone who compromises any of those layers. Confidential computing is the set of technologies that closes this gap — and in 2026 it has moved from research curiosity to something you can actually deploy.

The Third State of Data

Think of the threat model plainly. Encryption at rest protects against someone stealing a disk or a backup. Encryption in transit protects against someone intercepting the network. Neither protects against a compromised host, a malicious insider with infrastructure access, or a vulnerability in the virtualisation layer beneath your workload. In a public cloud, you are trusting the provider's operational controls at exactly the point where your data is readable.

For most workloads, that trust is reasonable and well-managed. For a minority — regulated financial data, health records, cryptographic key material, another company's data you have been entrusted with — "we trust the operational controls" is not a satisfying answer to a regulator or a partner.

Trusted Execution Environments

The core mechanism is a trusted execution environment, or TEE: a hardware-isolated region of a machine where code and data are protected even from the software that runs the machine. Memory belonging to the enclave is encrypted by the CPU itself, with keys the host operating system and hypervisor never see. If a privileged process on the host tries to read that memory, it gets ciphertext.

Two broad approaches exist in practice. Process-level enclaves protect a specific piece of code and its data, requiring the application to be written or partitioned for it. Confidential virtual machines — now available from every major cloud provider on modern AMD and Intel server CPUs — protect an entire VM, letting you lift an existing workload in with far less engineering effort. The second approach is why this technology suddenly became practical: you no longer have to rewrite your application to use it.

Attestation Is the Part That Actually Matters

Hardware isolation alone is not enough, because it does not tell you whether you are talking to a genuine enclave or a convincing imitation. Attestation solves this. Before you send any secrets, the environment produces a cryptographically signed report describing the hardware it is running on and a measurement — essentially a hash — of the exact code loaded inside it. You verify that signature against the CPU vendor's chain of trust and check the measurement against the code you expect.

This flips the usual security model in a genuinely useful way. Instead of trusting an operator's promise about what runs on their infrastructure, you get a verifiable statement about what is running before you release your data to it. Only if the attestation checks out do you provision the decryption keys. If someone swapped the code, the measurement changes and the keys never arrive.

Attestation is also the part teams most often get wrong. An enclave with unverified attestation is expensive theatre — you have paid the performance cost without gaining the security property.

Confidential AI

The most compelling current application is AI inference on sensitive data. The tension is familiar: you want the capability of a strong model, but the data you would send it is exactly the data you cannot expose — patient records, transaction histories, legal documents, identity files.

Confidential computing offers a middle path between sending everything to a public API and running everything yourself. The model runs inside an attested enclave, on GPUs that now support confidential execution, so the prompt and the response are protected from the infrastructure operator. You can verify, cryptographically, which model version processed your data and that nothing else had access to it. For businesses that have been blocked from using AI on their most valuable data, this changes the calculation.

Where It Genuinely Pays Off

Confidential computing earns its complexity in a specific set of situations:

• Multi-party computation: two organisations want a joint result — a fraud signal, a shared risk model — without either revealing its underlying dataset to the other.
• Regulated workloads in public cloud: when a framework or contract requires that the infrastructure operator cannot access the data, not merely that it promises not to.
• Key management and signing: protecting cryptographic material in software with hardware-grade isolation, including custody and blockchain signing infrastructure.
• Processing customers' data: if you are a platform handling your clients' sensitive data, attestation lets you prove your isolation claims rather than assert them.
• AI on confidential data: the case above — inference where the input cannot be exposed to the host.

The Costs the Demos Leave Out

Being honest about the trade-offs matters, because this technology is easy to over-apply:

• Performance overhead: memory encryption and enclave transitions cost something. It is modest for confidential VMs and far more noticeable for I/O-heavy or fine-grained enclave workloads.
• Operational complexity: attestation verification is a service you now have to run, monitor, and keep current as firmware and hardware generations change.
• Debugging is harder by design: the whole point is that you cannot inspect enclave memory. Your observability strategy needs rethinking.
• It does not fix application bugs: an enclave protects data from the infrastructure below it. Vulnerable code inside the enclave is still vulnerable code, and it now has your plaintext.
• Portability constraints: specific CPU and GPU generations are required, which shapes instance selection and cost.

How to Decide Whether You Need It

Ask one question: is the infrastructure operator inside or outside your threat model? For the majority of business systems, the honest answer is that your cloud provider is a trusted party, and confidential computing adds cost without addressing a risk you actually carry. But if you are handling data where a regulator, a contract, or a partner requires that trust to be removed — or where the value of the data makes an insider or hypervisor compromise a serious concern — this is now the mature answer, and it no longer demands rewriting your application.

The practical path is narrow: identify the one workload where the exposure genuinely matters, move it to a confidential VM, build proper attestation verification around it, and measure the performance impact against your real traffic before extending the pattern anywhere else.

If you are weighing confidential computing for a regulated workload, an AI system that touches sensitive data, or key management infrastructure, our team designs and builds secure cloud architectures end to end. Get in touch to work through whether it fits your threat model.