Confidential computing

For a long time, encryption only existed for two states of data: on the hard disk (at rest) and on the way through the network (in transit). As soon as a program computes with the data, it sits in plain text in main memory. That is exactly where confidential computing comes in. The processor encrypts the memory area of the protected environment with keys that only it knows and rejects any access from outside. Anyone who controls the physical server only sees noise.

For managing directors and CTOs in mid-sized companies, the topic has become relevant for two reasons. First, more and more sensitive workloads run at a hyperscaler, and the question of who can technically read along there is a question of data protection and liability. Second, AI agents that work with mailboxes, calendars, customer data and means of payment are becoming part of everyday life. That a provider promises not to look is a contractual commitment. That it technically cannot look is an architectural decision. Confidential computing is the attempt to turn the promise into proof.

The three states of data compared

The following table classifies the three levels of protection. They complement each other; none replaces another.

The "in use" point was the open flank for decades. Anyone who controlled a server could read main memory at any time. In a public cloud, this "anyone" is a third-party company with its own administrators, its own legal framework and its own contacts with the authorities.

How the technology works

Trusted execution environments and enclaves

A TEE is an area sealed off by the processor. For this, the CPU manages its own keys in hardware, encrypts the associated main memory on the way to the RAM module and only decrypts it again inside the chip. The host operating system can manage the protected pages, i.e. allocate or swap them out, but not read them. Two designs have become established:

• Process-level enclaves. A single program or part of it runs in a protected memory area. The rest of the application, the operating system and the hypervisor stay outside. Intel SGX (Software Guard Extensions) is the best-known example. The approach is precise but requires software to be written specifically for the enclave or adapted with helper libraries.
• Confidential VMs. An entire virtual machine, including the guest operating system, is encrypted in memory. The hypervisor starts and stops it but cannot look inside it. For operators this is the pragmatic route, because existing applications can move without code changes.

The hardware: Intel, AMD, Arm, NVIDIA

Confidential computing is tied to processor functions. Three architectures dominate:

• Intel SGX and TDX. SGX protects individual enclaves within a process and is today available mainly on Xeon server processors. TDX (Trust Domain Extensions) is Intel's answer to the VM approach: a "trust domain" is a complete virtual machine with its own hardware-encrypted memory.
• AMD SEV-SNP. Secure Encrypted Virtualization has existed since the first EPYC generation. The SEV-SNP (Secure Nested Paging) extension adds integrity protection against attacks by a malicious hypervisor, such as memory remapping or replaying old memory contents. SEV-SNP is the basis of most confidential VMs at Azure and Google Cloud.
• Arm CCA. The Confidential Compute Architecture is part of Armv9-A and introduces "realms", a fourth security world alongside the normal world, secure world and root world. The Realm Management Extension isolates realms from the hypervisor. Details are on the Arm page on the Confidential Compute Architecture.
• NVIDIA confidential computing. With the H100 GPUs, protection was extended to graphics processors. The data path between confidential VM and GPU is encrypted, which only makes training and inference of AI models with confidential data practical.

Remote attestation: the real core

Encrypted memory alone proves nothing. You need an answer to the question of whether your code is actually running in a genuine TEE and not in an environment that only pretends to be one. Remote attestation provides this. The processor generates a cryptographically signed report on the state of the environment: which firmware is loaded, which measurements (hashes) the guest system or enclave has, which chip is signing. The report can be checked via the manufacturer's certificate chain.

Only this proof completes the model. A key management system can, for example, only release keys if a valid attestation report is available that describes exactly the approved software. If a manipulated version is running, the key is withheld. AWS builds on exactly this: Nitro Enclaves link attestation documents to key policies in AWS KMS, as described in the Nitro Enclaves documentation.

Who is behind it: the Confidential Computing Consortium

The term is not a marketing word of a single provider. In 2019, Intel, Microsoft, Google, Arm, Red Hat, AMD and other companies founded the Confidential Computing Consortium (CCC) under the umbrella of the Linux Foundation. It defines confidential computing as "the protection of data in use by performing computation in a hardware-based, attested Trusted Execution Environment" and maintains open-source projects such as the Open Enclave SDK, Enarx or Intel's SGX SDK for Linux. For you as a decision-maker this means: the definition has been agreed across manufacturers, and if a provider writes "confidential" on a product, you can check against this definition whether attestation and hardware isolation really are present.

Offerings from the major cloud providers

All three major hyperscalers offer confidential computing as a bookable product, with different focuses.

• Azure confidential computing. Microsoft has the broadest portfolio: confidential VMs on AMD SEV-SNP and Intel TDX, SGX-based enclaves, confidential containers on AKS, confidential GPUs with NVIDIA H100 and managed services such as Azure Confidential Ledger and the attestation tool Microsoft Azure Attestation. The Azure documentation adopts the CCC definition word for word.
• Google Cloud Confidential VMs. Google started in 2020 with AMD SEV and today supports SEV, SEV-SNP, Intel TDX and NVIDIA confidential computing for GPUs. Attestation runs via a virtual TPM and Google's attestation service. Confidential GKE Nodes bring the model to Kubernetes. The overview is in the Google Cloud documentation.
• AWS Nitro Enclaves. Amazon takes a different route. Instead of relying on processor extensions, the Nitro hypervisor carves CPU cores and memory off an existing EC2 instance and starts an enclave in them without persistent storage, without a network and without interactive access. Communication runs exclusively via a local socket to the parent instance. This works equally on Intel, AMD and Graviton instances but requires a dedicated application split.

European providers are following suit. OVHcloud, IONOS and Scaleway have confidential VM offerings based on AMD in their range or have announced them; the level of maturity varies. Anyone looking for a solution that manages without US providers should ask specifically about the attestation service, key management and supported processor generations.

Why AI agents give the topic new urgency

A classic SaaS service sees the data you give it. A personal AI agent that reads emails, fills in forms and books with a stored credit card sees a great deal more: the entire digital everyday life of a person or a company. The question of whether the operator of the agent infrastructure can read along therefore becomes the core question.

Meta provides a real-world example. On 8 September 2026, the group presented its agent Muse, which runs in its own "Secure VM" in the cloud for each user, flanked by a separate Sentinel agent that has to approve every outgoing action. The announcement goes on to say that a "Muse Confidential VM" will follow later this year, in which the entire VM, including data and conversations, is encrypted with a key held only by the user, so that Meta has no access either. This is an announcement, not a product that has shipped. Whether Meta will disclose the attestation process, who actually manages the keys and whether independent auditors will get an insight had not been published as of 30 September 2026. But the process shows where the market is heading: isolation per user and hardware-backed confidentiality are becoming a selling point, no longer a footnote.

For your company, the transfer is obvious. If you let agents work on customer data, contracts or calculations, the question to every provider is: does my agent run in an attested TEE, who holds the key, and can I check the attestation report myself?

GDPR, data sovereignty and the CLOUD Act

Confidential computing does not solve legal questions, but it shifts the technical starting position. The CLOUD Act obliges US companies to hand over data on official orders, even if it is located in data centres outside the USA. However, a provider can only hand over what it can read. If the key for a confidential VM is held solely by the customer and attestation runs against policies controlled by the customer, the authority at best receives encrypted memory pages. Lawyers argue about how robust this argument is in practice; technically, it is in any case the strongest lever that a customer of a US hyperscaler currently has.

From a GDPR point of view, confidential computing is a technical and organisational measure under Article 32. It reduces the risk of unauthorised access by the processor and its employees. It replaces neither the data processing agreement nor the legal basis of the processing nor a transfer impact assessment for transfers to third countries. Anyone who uses it correctly can, however, cite it in exactly these documents as an argument for an appropriate level of protection.

In the debate on digital sovereignty, confidential computing is therefore double-edged. It makes the use of US clouds for sensitive data more justifiable and thus takes pressure off the question of European alternatives. At the same time, the hardware comes almost exclusively from US manufacturers (Intel, AMD, NVIDIA) or a British company in Japanese ownership (Arm). The root of trust lies in the chip, and nobody in Europe builds it.

Limits and risks

Side-channel attacks

A TEE protects the memory contents, not every physical side effect of the computation. Since 2018, researchers have demonstrated a series of attacks against Intel SGX, including Foreshadow (a Spectre variant), Plundervolt (manipulation of the supply voltage) and SGAxe (reading out attestation keys). Attacks against AMD SEV via the memory controller and the hypervisor's error handling have been shown. The manufacturers have reacted with microcode updates and the new generations (SEV-SNP, TDX), but the category remains. Anyone using confidential computing must take firmware updates seriously and regularly bring attestation policies up to date.

Trust in the manufacturer

The security of the model depends on the chip manufacturer's certificate chain. For anyone who does not trust Intel, AMD or Arm, attestation is worthless too. Confidential computing therefore shifts trust from the cloud operator to the processor manufacturer. For many companies this is progress, because a chip manufacturer has no operational access to the data centre. It is not zero trust, though.

Complexity of attestation

In practice, attestation is where projects fail. Attestation reports have to be generated, checked against reference values, versioned and re-approved with every software update. Providers such as Microsoft and Google offer managed services for this that ease the problem but again set an anchor of trust with the cloud operator. Anyone who wants to run the checks themselves needs staff who understand the certificate chains and measurements.

Distinction from homomorphic encryption

Homomorphic encryption allows arithmetic operations directly on encrypted data without ever decrypting it. It needs no special hardware and no anchor of trust in the chip. The price is computing effort that, depending on the method, is orders of magnitude above plain text, and a severely restricted set of practicable operations. For targeted calculations, such as statistical evaluations across data sets from several parties, it can be used today; for an entire application or a language model, it cannot. Confidential computing, by contrast, decrypts the data inside the chip and works at almost normal speed. Both approaches belong to the family of privacy-enhancing technologies and can be combined.

Practice for mid-sized companies

Getting started is easier than the topic sounds. At the major providers, confidential VMs cost only a moderate surcharge compared with standard instances and run with an unchanged operating system and unchanged software. A sensible approach in four steps:

1. Classify workloads. Not everything needs a TEE. Candidates are systems with health, financial or personnel data, key management, licence servers, price calculations and all AI applications that work with customer data.
2. Start with confidential VMs. Moving an existing VM to an SEV-SNP or TDX instance is the step with the best ratio of effort to effect. Process-level enclaves pay off later for narrowly defined, highly sensitive components.
3. Hold the keys yourself. Without customer-managed keys (ideally with attestation binding), the operator remains master of the system. Check whether your provider supports releasing keys only against valid attestation.
4. Build attestation into operations. An attestation report that nobody checks is decoration. Define who maintains the reference values and what happens if a report deviates.

Just as important is the question of what confidential computing does not cover. An attacker who gets in via a vulnerability in your application is inside the enclave and sees everything. So does an employee with legitimate access rights. Secure software development, authorisation concepts and logging remain mandatory.

Outlook

Three developments will shape the topic in the coming years. First, confidential computing is moving from the CPU to accelerators: NVIDIA's H100 will be followed by further GPU generations with an encrypted data path, making confidential AI training and confidential inference a standard option. Second, AI agents are pulling the topic into the mass market. Meta's announcement of the Muse Confidential VM is a signal that providers of personal agents are competing for trust with hardware-backed confidentiality. Third, attestation and key sovereignty are coming into the focus of regulators and purchasing departments. In future, the question "Can the provider see my data?" can be answered with an attestation report instead of a contract annex.

For mid-sized companies, the realistic expectation is this: confidential computing will become standard equipment, as disk encryption is today. The competitive advantage lies not in using it as such but in knowing early which of your own data and processes really need it.

Frequently asked questions

Does confidential computing replace classic encryption?

No. Encryption at rest and in transit remains mandatory. Confidential computing closes the third gap, protection during processing in main memory. Only all three levels together form a continuous chain of protection.

Do I have to rewrite my software?

For confidential VMs, as a rule no. The virtual machine runs with an unchanged operating system and unchanged applications; the processor takes care of memory encryption. Process-level enclaves such as Intel SGX or AWS Nitro Enclaves, on the other hand, require a dedicated application split and adjustments to the code.

Can the cloud provider really see nothing any more with confidential computing?

It cannot read the main memory of the protected environment in plain text. Whether it can still reach the data depends on who holds the keys, whether attestation runs against policies controlled by the customer and whether the provider itself operates the attestation service. Without customer-managed keys, residual access remains possible.

What is the difference from homomorphic encryption?

Homomorphic encryption computes directly on encrypted data, without a hardware anchor of trust, but with considerable computing effort and restricted operations. Confidential computing decrypts the data within a sealed-off processor area and works at almost normal speed, but requires trust in the chip manufacturer.