Confidential Computing: The Missing Layer for Data in Use

Encryption at rest and TLS in transit are table stakes. But there is a third state of data that most architectures still expose: data in use. When a database decrypts a page, an AI model loads weights, or a payment service signs a transaction, the data exists in plaintext inside CPU memory. Confidential computing is the hardware and software stack designed to protect that state. It is not a single product. It is a combination of trusted execution environments (TEEs), remote attestation, sealed storage, and new operational patterns. This article explains what it protects, what it does not, and how to design systems that actually benefit from it.

Why data in use is the hard problem

Traditional security controls assume the infrastructure is trusted. A cloud provider, hypervisor, kernel, or container runtime can usually read process memory. That assumption is acceptable for many workloads, but it breaks down for regulated data, multi-party computation, and zero-trust architectures. If an attacker compromises the hypervisor, memory encryption at rest does not help. If an insider with root on a node dumps memory, TLS keys and plaintext records are exposed. Confidential computing changes the trust boundary from the server and operator to the CPU package and verified code.

The core promise is simple: even the cloud provider or hypervisor cannot read the memory of a protected workload. The practical reality is more nuanced. You must verify what code is running, manage new key flows, accept performance costs, and understand that side channels and application bugs remain real risks.

What is a trusted execution environment?

A TEE is a hardware-enforced isolated environment. It provides three properties:

• Confidentiality: Memory belonging to the TEE is encrypted and inaccessible to the host.
• Integrity: The hardware can detect tampering with protected memory and execution state.
• Attestation: The TEE can produce a signed statement describing the hardware and software it is running.

Some TEEs also offer sealed storage, which binds encryption keys to a specific TEE measurement. That allows a workload to persist secrets that only the same verified code on the same hardware family can unseal. Sealing is not a replacement for a KMS, but it is useful for local state and bootstrap secrets.

The threat model: know what you are buying

Confidential computing is often oversold. A precise threat model prevents disappointment and misconfiguration.

Threats a TEE can mitigate

• Malicious or compromised hypervisor: The host cannot read TEE memory or modify execution without detection.
• Privileged cloud operator: Insiders with host root access cannot inspect protected workloads.
• Other tenants: Cross-VM and cross-container memory attacks are blocked by hardware isolation.
• Physical memory attacks: Cold boot, DMA, and memory bus snooping are mitigated when memory encryption is active.
• Supply chain verification: Attestation proves the expected firmware, kernel, and application image are running.

Threats a TEE does not automatically solve

• Application vulnerabilities: SQL injection, RCE, and logic bugs still work inside a TEE. The attacker just needs to execute inside the trust boundary.
• Side channels: Cache timing, speculative execution, power analysis, and memory access patterns can leak information. Mitigations exist but are not complete.
• Denial of service: The host can still starve, pause, or kill a confidential workload.
• Malicious code inside the TEE: Attestation proves identity, not intent. If you attest a backdoored image, you have cryptographically verified a problem.
• Weak key management: Attestation is only as strong as the policy that releases secrets to a measurement.

The useful mental model is this: confidential computing removes the infrastructure operator from the plaintext trust boundary. It does not remove your own code, dependencies, or operational mistakes.

Hardware landscape: SGX, TDX, SEV-SNP, CCA, and GPU TEEs

The TEE market is not standardized at the API level. Each vendor implements different isolation boundaries and attestation formats. The following table summarizes the major options.

For most cloud-native teams, the practical choice is a confidential VM (CVM) based on AMD SEV-SNP or Intel TDX. Enclaves like SGX are better for small, high-value secrets. GPU TEEs matter when the workload is AI and the model or data cannot be exposed to the host.

Remote attestation: the trust anchor

Attestation is the feature that turns a TEE from an isolated box into a verifiable participant in a distributed system. Without attestation, you have no proof that the TEE is genuine or running the expected code. With attestation, you can make authorization decisions based on hardware-rooted evidence.

A typical remote attestation flow looks like this:

• The workload starts inside a TEE and requests a quote or evidence from the hardware.
• The quote includes measurements of firmware, boot chain, kernel, container image, and sometimes runtime configuration.
• The quote is signed by a hardware root of trust and sent to a verifier.
• The verifier checks the signature chain, compares measurements against a policy, and checks freshness to prevent replay.
• If the policy passes, the verifier releases secrets, issues a certificate, or grants network access.

Attestation is not a one-time event. Good designs re-attest on restart, on configuration change, and periodically for long-running workloads. They also log attestation failures as security events, not just operational errors.

Measurement policy is the new firewall

The hardest part of attestation is not cryptography. It is policy. What exact image hash is allowed? Which firmware version is patched? Can debug mode be enabled? Should the workload run only in a specific region or on a specific CPU family? These questions define the security posture. A permissive policy that accepts any measurement defeats the purpose. A rigid policy that cannot be updated will break during incidents. Treat measurement policy as code, version it, review it, and test it in CI.

Architecture patterns

Confidential computing is most useful when it is designed into the architecture rather than bolted on. Here are proven patterns.

1. Confidential VMs for lift-and-shift workloads

This is the lowest-friction path. You run an existing VM or Kubernetes node inside a CVM. The hypervisor encrypts memory, and the guest can request attestation. The application may not need code changes. The main work is in key management, attestation verification, and operational tooling. This pattern fits databases, legacy services, and regulated monoliths.

2. Enclave services for secrets and key management

Instead of protecting an entire application, protect the most sensitive component. A small enclave can hold root keys, perform cryptographic operations, or enforce policy. The rest of the system communicates with it over an attested channel. This reduces the trusted computing base and limits performance overhead. It is common in certificate authorities, HSMs, and payment tokenization.

3. Confidential data clean rooms

Multiple organizations want to compute on combined data without revealing raw records to each other or to the cloud provider. A clean room runs inside a TEE, ingests encrypted inputs, performs the agreed computation, and releases only approved outputs. Attestation proves the computation code to all parties. This pattern is emerging in healthcare, advertising, and financial crime detection.

4. Confidential AI inference and training

AI workloads expose two sensitive assets: the model and the input data. A GPU TEE can protect both during inference. For training, confidential computing can protect gradients and training data in multi-party or federated settings. Expect performance overhead, especially for large models, and plan for secure data loading and attestation of the full AI stack.

5. Edge and IoT attestation

At the edge, physical access is common. A TEE can provide device identity, secure boot, and sealed storage for credentials. Remote attestation lets a backend verify that a device is genuine and running approved firmware before it joins a network or receives commands. This is especially relevant for industrial control, automotive, and medical devices.

6. Zero-trust service identity

Instead of static API keys, services can use TEE-backed identities. A service proves its attestation measurement to a certificate authority and receives a short-lived certificate. Mutual TLS then authenticates both the workload and its runtime environment. This binds authorization to verified code, not just network location.

Confidential containers and Kubernetes

Kubernetes is where many teams will first encounter confidential computing. The Confidential Containers project, Kata Containers, and vendor integrations are building a path to run pods inside TEEs. The general flow is:

• A node supports confidential VMs or enclaves.
• A runtime class selects the confidential runtime, such as Kata with SEV-SNP or TDX.
• The pod image is pulled and measured.
• An attestation agent collects evidence and sends it to a key broker service.
• The key broker validates the measurement policy and releases encrypted image keys or application secrets.
• The pod starts with memory encrypted and host access blocked.

Operationally, this changes several assumptions. Node debugging becomes limited because the host cannot inspect pod memory. Logging and metrics must be emitted from inside the TEE, often through an attested channel. Persistent storage must be encrypted, and the keys must be released only after attestation. The control plane must understand which nodes and runtimes support which TEE features.

Performance and cost realities

Confidential computing adds overhead. Memory encryption and integrity checks consume CPU cycles. Context switches into and out of enclaves are expensive. I/O paths must be secured, sometimes with bounce buffers or encrypted virtio. GPU TEEs add additional overhead for secure transfers and protected memory. The exact cost depends on the workload.

• CPU-bound workloads may see modest overhead when data stays in cache and memory encryption engines keep up.
• Memory-bound workloads often see higher overhead because every memory access is encrypted and integrity-checked.
• I/O-heavy workloads can suffer from secure DMA and encrypted storage paths.
• AI workloads pay for secure GPU memory and host-device transfers.

Benchmark with realistic data and concurrency. Do not assume a fixed percentage. Also consider the cost of attestation services, key management, and additional operational complexity. Confidential computing is usually justified by risk reduction and compliance, not raw performance.

Security best practices

Treat confidential computing as one layer in a defense-in-depth strategy. The following practices prevent common mistakes.

• Minimize the trusted computing base. The less code inside the TEE, the smaller the attack surface. Use small enclaves or minimal confidential VMs.
• Attest before releasing secrets. Never send keys, tokens, or sensitive data to a workload before verifying its measurement.
• Pin measurements, but plan rotation. Hard-code expected hashes where possible, but have a controlled process for updates and emergency patches.
• Use memory-safe languages. Rust, Go, and managed runtimes reduce memory corruption inside the TEE. C and C++ remain common but require rigorous review and sandboxing.
• Secure the supply chain. Attestation only proves what ran. Build reproducible images, sign artifacts, and verify dependencies.
• Encrypt everything else. TEEs do not replace disk encryption, TLS, or database encryption. They protect data in use, not every state.
• Monitor attestation and policy failures. Failed attestation can indicate misconfiguration or an attack. Alert on both.
• Assume side channels exist. Isolate tenants, disable unnecessary hyperthreading where required, and follow vendor mitigations.
• Test failure modes. What happens when attestation service is down? Can you recover without weakening policy? Design for degraded trust.

Compliance and privacy implications

Regulations often require technical controls for data confidentiality, but no framework certifies a TEE as automatically compliant. Confidential computing can provide strong evidence for:

• Data minimization: Process data without exposing raw records to the infrastructure operator.
• Access control: Release secrets only to verified code.
• Auditability: Attestation logs show which code ran and when.
• Cross-border data transfer: In some interpretations, encrypted processing inside a TEE may reduce exposure, but legal advice is mandatory.
• Zero-trust architecture: Hardware-rooted identity for workloads.

Privacy laws focus on personal data and lawful processing. Confidential computing can reduce the risk of unauthorized access, but it does not change the legal basis for processing or the need for consent, purpose limitation, and data subject rights. Document the threat model and the technical controls so auditors can evaluate them.

When should you use confidential computing?

Use it when the threat model includes one or more of these conditions:

• You cannot fully trust the cloud provider, hypervisor, or infrastructure operator.
• You process data from multiple parties who do not trust each other.
• You handle regulated data with strict confidentiality requirements.
• You need hardware-rooted proof of what code is running.
• You run AI workloads where the model or input data is highly sensitive.
• You need to protect edge devices from physical tampering.

Do not use it as a substitute for application security. If your main risk is a web vulnerability, a TEE will not save you. Fix the application first, then add confidential computing where the infrastructure trust boundary is the remaining gap.

Implementation checklist

A practical rollout should be incremental. Start with a high-value, well-bounded workload.

• Define the threat model: Identify who you do not trust and what data must remain confidential.
• Choose the isolation level: Enclave, confidential VM, confidential container, or GPU TEE.
• Design attestation: Decide what measurements matter, who verifies them, and how secrets are released.
• Integrate key management: Connect the attestation verifier to a KMS or key broker with least-privilege policy.
• Adapt observability: Emit logs and metrics from inside the TEE; avoid host-based introspection that breaks confidentiality.
• Benchmark performance: Test realistic workloads and set expectations.
• Automate policy: Store measurement policies as code and test them in CI.
• Plan for rotation and recovery: Patch measurements, rotate keys, and define what happens when attestation fails.
• Audit and review: Log attestation decisions and review failed attempts.

The future: standardization and convergence

Confidential computing is moving from niche hardware features to a platform capability. Expect continued convergence around confidential containers, standardized attestation formats, and better GPU support. Homomorphic encryption and secure multi-party computation are complementary but still limited by performance for many workloads. TEEs offer a practical middle ground: hardware-enforced isolation with acceptable overhead for a growing set of use cases.

The most important shift is architectural. As more workloads move to multi-tenant clouds and edge environments, the assumption that infrastructure is trusted becomes harder to defend. Confidential computing gives architects a way to explicitly define and enforce that trust boundary. It is not invisible, free, or foolproof. Used carefully, it closes the gap that encryption at rest and in transit leaves open.

Conclusion

Data in use is the last mile of encryption. Confidential computing protects it with hardware isolation, attestation, and sealed storage. The technology is real, but it demands a precise threat model, disciplined key management, and operational changes. Start with a focused use case, verify attestation end to end, and measure the cost. When the infrastructure operator is inside your threat model, confidential computing is no longer optional—it is the missing layer.