For most of computing history, data was protected in two states: at rest, with disk encryption, and in transit, with TLS. The third state, data in use, sat in plaintext in memory the moment a CPU touched it. Anyone with control of the host, the hypervisor, or physical access to the machine could read it. For regulated and sovereign workloads in Europe, that gap is the whole problem.
Confidential computing closes it. Combined with modern isolation primitives like microVMs, it changes what you can credibly promise about a workload: that the operator of the infrastructure cannot read the data, that you can prove it cryptographically, and that the whole thing runs under EU law on EU soil. This post covers both halves of that story, the standards and hardware underneath them, and an honest read on where the technology actually is in 2026.
What confidential computing is
Confidential computing protects data while it is being processed by running it inside a hardware-based Trusted Execution Environment (TEE). The TEE encrypts memory transparently and isolates the workload from everything outside it, including the host OS, the hypervisor, other tenants, and the cloud operator’s own staff. This is encryption-in-use, the missing third state.
The practical consequence matters more than the mechanism. In a properly attested TEE, the entity running the hardware cannot see your plaintext. A hosting provider, a hyperscaler, or an internal platform team becomes technically incapable of reading what runs inside the enclave, not merely contractually forbidden. For workloads where the threat model includes the operator, or where a foreign jurisdiction could compel that operator, this is a categorical shift.
Why it matters for sovereignty and GDPR
Data sovereignty and data residency are different things. Residency is where bytes physically live. Sovereignty is which laws govern them and who can lawfully compel access. EU data residency alone does not stop a non-EU parent company from being subject to extraterritorial legal demands.
Confidential computing strengthens the sovereignty argument at the technical layer. When data is processed inside a TEE and the decryption keys are released only after attestation to keys held outside the operator’s control, the operator cannot produce readable plaintext regardless of the legal demand served on it. Be precise about the regulatory status: no EU data protection authority has yet blessed confidential computing as a standalone Article 46(2) supplementary measure under GDPR. Treat it as strong defence-in-depth that materially improves a Transfer Impact Assessment, not as a compliance silver bullet. The honest framing is the credible one.
The hardware: SEV-SNP, TDX, CCA
Three CPU vendors ship VM-level confidential computing today, each protecting an entire virtual machine rather than asking you to rewrite applications for a small enclave:
- AMD SEV-SNP (Secure Encrypted Virtualization with Secure Nested Paging) encrypts VM memory per-guest and adds integrity protection so a malicious hypervisor cannot remap, replay, or tamper with guest memory. Widely available across server platforms.
- Intel TDX (Trust Domain Extensions) creates hardware-isolated “trust domains” with encrypted memory and hypervisor isolation, plus built-in remote attestation. Shipping on recent Xeon generations.
- ARM CCA (Confidential Compute Architecture) introduces “Realms,” hardware-isolated environments for code and data. It is the newest of the three and points squarely at the edge and ARM server ecosystem, though broad availability still lags x86.
The older enclave model, Intel SGX, protects a small slice of an application rather than a whole VM. It remains relevant for narrowly scoped secrets but is harder to adopt than the VM-level approaches above. The right choice depends on your silicon, your cloud or hardware partner, and your workload, which is exactly the kind of decision a vendor-neutral consultancy should make with you rather than for a product.
Attestation is the load-bearing part
A TEE is only useful if you can prove a workload is running inside a genuine, unmodified one before you trust it with secrets. That proof is remote attestation, and it is the part most teams underestimate.
The vendor-neutral mental model comes from the IETF RATS architecture (RFC 9334), which names three roles: the Attester produces signed evidence about its environment, the Verifier checks that evidence against known-good reference values, and the Relying Party releases keys or data only on a passing result. In practice the flow looks like: the TEE generates hardware-signed evidence, a verifier confirms the firmware and measurements, and only then does a key broker release the secrets needed to decrypt data or pull a model. No valid attestation, no keys.
The open-source software stack
Confidential hardware needs software to be usable in cloud-native environments. The leading open-source effort is Confidential Containers (CoCo), a CNCF project that runs each Kubernetes pod inside its own TEE and standardizes confidential computing at the pod level. CoCo spans the major hardware backends (SEV-SNP, TDX, SGX, IBM Secure Execution) and pairs with the Trustee project for attestation, including a Key Broker Service that gates secret release on a passing attestation. CoCo builds on Kata Containers, covered below, for its VM-isolated runtime. Other open implementations exist in the same space, and the strength of the ecosystem is that the attestation and key-release patterns are converging on shared standards rather than one vendor’s API.
MicroVMs and secure isolation
Confidential computing answers “can the operator read this.” MicroVMs answer a related but distinct question: “if one workload is compromised, can it reach the others.” These are complementary, not interchangeable.
The standard Linux container shares the host kernel. One kernel escape, such as CVE-2024-21626 in runc, and the blast radius is the whole node. For genuinely multi-tenant or untrusted code, a shared kernel is too thin a wall. The alternatives:
- Firecracker is a minimal VMM written in Rust, purpose-built for serverless. It boots a microVM in roughly 125 ms with a footprint of a few MB per VM, by stripping the device model to the essentials. It famously powers AWS Lambda and Fargate.
- Cloud Hypervisor is another modern Rust VMM, with a richer device model than Firecracker and broad hardware support. It is the default backend for Kata Containers.
- Kata Containers makes VM-grade isolation feel like containers: each pod runs in a lightweight VM behind a standard OCI/Kubernetes interface. It supports Cloud Hypervisor, Firecracker, and QEMU as backends, so you tune the isolation/compatibility trade-off.
- gVisor takes a different path, a user-space kernel that intercepts syscalls. No full VM, lower overhead than virtualization, strong isolation for many multi-tenant cases, with some compatibility limits for syscall-heavy workloads.
Where each fits
Match the tool to the workload, not the hype:
- Multi-tenant SaaS and shared Kubernetes: Kata Containers or gVisor to contain tenants behind a hard boundary.
- Fast-booting sandboxes and serverless functions: Firecracker, where sub-second cold starts and density dominate.
- Secure CI and untrusted code execution: microVMs to run arbitrary builds or customer code without trusting them.
- Isolating AI inference: a dedicated VM boundary per model or per tenant so a compromised inference path cannot pivot.
The two layers stack. You can run a Kata or CoCo pod whose underlying VM is itself a confidential VM on SEV-SNP or TDX, getting both operator-blindness and tenant isolation from one deployment.
Confidential AI inference
The fastest-growing driver is AI. Sending prompts, retrieved documents, or fine-tuning data to an LLM means exposing some of your most sensitive material to whoever runs the inference. Confidential AI shrinks that exposure.
The NVIDIA H100 was the first GPU with a hardware TEE: in confidential mode it protects code and data on the GPU with encrypted VRAM and an on-die root of trust, and it pairs with a confidential CPU VM (SEV-SNP or TDX) so data stays encrypted end to end across CPU and GPU. Attestation extends to the GPU, so a relying party can verify both the CPU and GPU environment before releasing model weights or data. Published overhead is modest, on the order of low single-digit percent throughput for many LLM inference workloads, plus a one-time attestation cost at startup. The result: prompts and outputs stay private even from the host, and the execution is cryptographically verifiable. For European organizations that want modern AI without shipping regulated data into an opaque environment, this is the bridge.
Honest maturity and trade-offs
This is powerful, but it is not free or finished:
- Maturity varies sharply. SEV-SNP and TDX are production-ready; ARM CCA and parts of the GPU TEE ecosystem are earlier. Tooling, especially attestation plumbing, is still maturing.
- Attestation is operational work. Verifiers, reference values, and key brokers are the hard part, and you own them or your partner does.
- Performance overhead is real but usually small. Plan for a few percent, more for memory-bound or I/O-heavy patterns, and benchmark your own workload.
- It is not a compliance checkbox. It strengthens a GDPR and sovereignty posture; it does not replace legal review, key governance, and a sound overall architecture.
- Trust boundaries shift, they do not vanish. You still trust the silicon vendor’s root of trust and your verification logic. Know what is in your trusted computing base.
FAQ
Does confidential computing replace encryption at rest and in transit? No. It adds the third state, in-use, and works alongside the other two.
Can the cloud operator still read my data inside a TEE? With correct attestation and external key control, no. The operator cannot produce readable plaintext, which is the core sovereignty benefit.
Do I need confidential hardware to use microVMs? No. Firecracker, Cloud Hypervisor, Kata, and gVisor give strong isolation on standard hardware. Confidential computing is a separate layer you can add on top.
Is this GDPR compliant out of the box? It strengthens compliance and Transfer Impact Assessments as defence-in-depth, but no EU DPA has confirmed it as a standalone supplementary measure. Treat it as one strong control among several.
Which CPU should I standardize on? It depends on your stack, partners, and workload. We assess SEV-SNP, TDX, and CCA against your actual requirements rather than pushing a single option.
Where Rapid Solutions fits
We are a vendor-neutral engineering consultancy and managed-services partner, not a cloud provider. We design and run confidential, hardware-isolated workloads on open-source foundations, with EU data residency and sovereignty built in, and we adapt to the stack you already have rather than locking you into ours. Whether you are evaluating SEV-SNP versus TDX, standing up Confidential Containers with proper attestation, isolating multi-tenant workloads with Kata or Firecracker, or running confidential AI inference, we help you do it correctly and prove it works.