Confidential computing is the protection of data while it is actively being processed, achieved through hardware-enforced isolation inside a Trusted Execution Environment (TEE). Conventional encryption protects data at rest on disk and in transit over a network, but the moment a CPU must compute on that data, the plaintext has historically been visible to the operating system, the hypervisor and any privileged actor who controls the host. TEEs close that gap by extending the cryptographic boundary into the processor itself, so that no software layer above the hardware, including the cloud operator, can read working memory.
How TEEs Work and the Threat Models They Address
Intel TDX, AMD SEV-SNP and ARM CCA each implement the TEE concept differently at the microarchitectural level, but all three share the same structural principle: memory pages assigned to a protected workload are encrypted by a key held inside the CPU package and inaccessible to any software outside the enclave, including the hypervisor and the host kernel.
Intel Trust Domain Extensions (TDX) isolate entire virtual machines as “trust domains.” The CPU enforces strict access controls so that the virtual machine monitor cannot read or modify guest memory, and the guest OS itself is measured cryptographically at boot. AMD Secure Encrypted Virtualisation with Secure Nested Paging (SEV-SNP) adds memory integrity protection on top of encryption, preventing a malicious hypervisor from injecting false data pages into a guest. ARM Confidential Compute Architecture (CCA) introduces the concept of Realms, hardware-isolated execution contexts usable from mobile and edge devices through to server silicon.
The threat models that TEEs address go well beyond what disk encryption or TLS can handle. The specific adversaries in scope include: a rogue or compelled cloud operator reading tenant memory via a hypervisor call; a law-enforcement warrant served on an infrastructure provider demanding plaintext access; a co-tenant attempting to extract data via a privileged exploit; and a compromised administrator with root access to the host OS. None of these actors can read encrypted enclave memory because the decryption key never leaves the CPU.
Remote Attestation as Cryptographic Compliance Evidence
Remote attestation is the mechanism by which a TEE proves to an external party, whether an auditor, a regulator or a counterparty, that a specific, unmodified workload is running inside a genuine hardware enclave. The CPU generates a signed measurement report, called a quote, that contains a cryptographic hash of the code and configuration loaded into the enclave. That quote is signed by a hardware-embedded key whose certificate chain roots in the silicon manufacturer.
For compliance purposes, this is highly significant. GDPR Article 32 requires controllers and processors to implement “appropriate technical and organisational measures” that account for “the state of the art.” Attestation reports provide verifiable, machine-readable evidence that the state-of-the-art control was active at a specific point in time, something a contractual assurance or a penetration-test report cannot match in precision. NIS-2 Article 21 similarly mandates that essential and important entities implement measures proportionate to their risk, covering “the security of network and information systems.” An archived attestation log constitutes direct technical evidence that isolation was cryptographically enforced during the processing of sensitive data.
“Article 32 of the GDPR requires controllers and processors to implement appropriate technical measures, taking into account the state of the art. Hardware-enforced isolation of data in use now qualifies as part of that state of the art.” (European Data Protection Board, https://www.edpb.europa.eu)
Attestation also has an operational use: it allows a regulated organisation renting sovereign infrastructure from a third party to verify, independently and continuously, that the workload has not been tampered with between deployments. This removes reliance on the operator’s self-declaration, which is particularly relevant under the CLOUD Act exposure that US-controlled providers carry regardless of where their servers are located.
Processing Sensitive Data on Shared Sovereign Infrastructure
European regulated organisations increasingly need to consolidate infrastructure for cost efficiency, but consolidation traditionally meant accepting a shared-responsibility model in which the host operator retains privileged access to tenant workloads. Confidential computing dissolves that trade-off. A hospital consortium can run patient-record analytics on a shared sovereign data centre in Switzerland, for example, and demonstrate to the Swiss Federal Data Protection Commissioner (under the revised FADP) that the operator never held access to plaintext, because the CPU enforced that boundary technically rather than contractually.
The practical deployment path combines three elements: a TEE-capable server (Intel TDX or AMD SEV-SNP), a confidential container runtime, and a policy engine that ties workload launch to a valid attestation. Data is decrypted inside the enclave and re-encrypted before it leaves. The host operator sees only ciphertext, both at rest and in the memory bus.
| Control | Conventional cloud | Sovereign TEE deployment |
|---|---|---|
| Data at rest | Encrypted; keys often held by operator | Encrypted; keys held inside enclave or by tenant |
| Data in transit | TLS; operator terminates TLS at load balancer | TLS; termination inside enclave, operator sees ciphertext |
| Data in use | Plaintext visible to hypervisor and host OS | Encrypted in CPU memory; inaccessible to hypervisor |
| Compliance evidence | Audit logs; operator assertions | Cryptographic attestation reports; verifiable by regulator |
| Foreign jurisdiction risk | CLOUD Act / FISA 702 exposure if US-controlled | Eliminated where operator has no plaintext access |
Confidential Computing and Sovereign AI Inferencing
Sovereign AI inferencing means running model inference without sending data or model weights to a public cloud provider. TEEs add a further dimension: they protect both the proprietary model and the sensitive input during computation, even from the infrastructure operator.
In healthcare, an AI diagnostic tool processing radiology images or clinical notes inside an AMD SEV-SNP enclave keeps patient data subject only to the GDPR purposes for which it was collected, with no exposure to a third-party model-as-a-service API. In financial services, a credit-scoring or fraud-detection model running inside an Intel TDX trust domain can process trading positions and account histories without those records ever appearing in the host operator’s memory space, which directly addresses the data-minimisation obligations under GDPR Article 5(1)(c) and the ICT risk requirements under DORA Article 9.
“Confidential computing is not just another encryption layer. It fundamentally changes the trust model between a tenant and an operator by making the hardware the root of trust rather than the operator’s promises.” (Confidential Computing Consortium, https://confidentialcomputing.io)
A key practical consideration is that model weights themselves are intellectual property. Running inference inside a TEE prevents the operator, a co-tenant or a compromised administrator from extracting a fine-tuned Mistral or Llama model that an organisation has trained on proprietary data, protecting both the data subject and the organisation’s competitive asset in a single architectural decision.
EUCS and the EU Cloud Sovereignty Framework
The European Union Agency for Cybersecurity (ENISA) has been developing the EU Cybersecurity Certification Scheme for Cloud Services (EUCS), which introduces assurance levels that map directly onto technical sovereignty controls. At the highest assurance levels (the proposed “High” and “High+” or SEAL categories in the draft framework), the scheme requires that the cloud provider can demonstrate the absence of legal obligations that would compel disclosure of tenant data to non-EU authorities. Confidential computing is one of the technical mechanisms that can fulfil this requirement: if the operator provably has no access to plaintext, a foreign government order served on the operator yields nothing of value to an adversary.
ETSI GS TEE, the ETSI working group on Trusted Execution Environments, produces technical specifications that underpin interoperability between TEE implementations and certification frameworks. Compliance officers mapping their architecture to EUCS requirements should document their TEE selection, attestation chain and key management policy against these ETSI specifications, as ENISA is expected to reference them in the final scheme requirements.
The IBM Cost of a Data Breach Report 2024 found that the average total cost of a data breach reached USD 4.88 million, the highest in the report’s history (IBM, 2024). A 2023 edition of the same report found that 45 percent of breaches involved data stored in cloud environments (IBM, 2023). These figures sharpen the business case for architectural controls that limit the blast radius of a host-level compromise. In August 2024, NIST published its first three finalised post-quantum cryptography standards (FIPS 203, 204 and 205), signalling that the migration window for critical infrastructure has formally opened; TEE key management must be designed to accommodate post-quantum algorithms from the outset (NIST, 2024).
Open-Source Options for Sovereign Deployment Without Vendor Lock-In
Three production-grade open-source projects allow organisations to deploy confidential computing without committing to a single silicon vendor or commercial platform.
Confidential Containers (CNCF) integrates TEE support transparently into standard Kubernetes pod definitions. An operator marks a pod as confidential, and the runtime automatically provisions an enclave using the available hardware, whether Intel TDX or AMD SEV-SNP, without requiring application code changes. This makes it the most accessible path for organisations already running containerised workloads.
Enarx (now a CNCF sandbox project) takes a hardware-agnostic approach by compiling workloads to WebAssembly and running them inside a TEE-provided WebAssembly runtime. The same binary runs on Intel TDX, AMD SEV-SNP and IBM Secure Execution without recompilation, which is particularly valuable for multi-vendor sovereign infrastructure strategies.
Gramine is a library OS that allows unmodified Linux binaries to run inside Intel SGX or TDX enclaves. For organisations that have existing applications they cannot or do not want to rewrite, Gramine provides a migration path with relatively limited engineering effort. Its manifest system provides fine-grained control over which file system paths, network calls and system calls the enclave is permitted to make, which is directly relevant to demonstrating least-privilege compliance under NIS-2 Article 21.
Choosing between these three depends on the organisation’s existing technology stack, its hardware procurement flexibility and the skills of its security engineering team. All three are published under open-source licences that allow independent security audits, which is a prerequisite for sovereign deployments where trust in the toolchain must be independently verifiable rather than assumed from a vendor’s assurance documentation.
FAQ
Does confidential computing eliminate the need for conventional encryption at rest and in transit?
No. TEEs protect data while it is actively being processed inside the CPU, but data still needs encryption at rest (storage) and in transit (network). Confidential computing closes the third gap, data in use, that the other two controls leave open.
Can a cloud host operator or a compromised hypervisor read data inside a TEE?
In a correctly configured TEE such as Intel TDX or AMD SEV-SNP, memory pages belonging to the enclave are encrypted by the CPU before they leave the processor package. A compromised hypervisor or host operator cannot read plaintext from those pages. Residual risks include firmware supply-chain attacks and microarchitectural side-channels, which require additional mitigations at the platform and configuration level.
What is remote attestation and is it accepted as compliance evidence by European regulators?
Remote attestation is a cryptographic process in which the TEE hardware generates a signed report proving the exact code and configuration running inside the enclave. GDPR Article 32 requires measures reflecting the state of the art, and ENISA’s EUCS framework at higher assurance levels explicitly recognises hardware-enforced isolation. Attestation reports can be archived as verifiable audit artefacts that a data protection authority or sector regulator can inspect independently.
Which open-source projects allow sovereign deployment without vendor lock-in?
Three production-grade options exist: Confidential Containers (CNCF) integrates TEE support into standard Kubernetes pods; Enarx provides a WebAssembly-based runtime that is hardware-agnostic across Intel TDX, AMD SEV-SNP and IBM Secure Execution; Gramine lifts unmodified Linux applications into Intel SGX or TDX enclaves with minimal porting effort.
How does confidential computing relate to sovereign AI inferencing in healthcare or financial services?
When an AI model runs inference inside a TEE, both the model weights and the input data (for example a patient record or a trading position) are encrypted in memory and inaccessible to the host. This allows organisations to run inference on shared or rented sovereign infrastructure without exposing proprietary models or personal data to the operator, meeting the purpose-limitation and data-minimisation requirements of GDPR and sector-specific rules such as those under DORA.