Confidential Computing and Trusted Execution Environments

Updated on Oct 2, 2026

9 min read

Confidential computing uses hardware-backed isolation to reduce exposure of sensitive data while a program is processing it. It is relevant to cloud architects, security teams, and developers who must run workloads on infrastructure they do not fully control. The central building block is a trusted execution environment (TEE), but a TEE is a boundary with specific guarantees, not a promise that an entire application is immune to attack.

Why Confidential Computing Is Being Discussed

Cloud encryption protects stored data and network connections, but applications normally need plaintext to perform useful work. That creates a trust gap: a cloud operator, compromised host, or privileged administrator may have opportunities to inspect memory or alter the software that handles a workload.

Confidential computing aims to narrow that gap with processor-enforced isolation and remote attestation. The Confidential Computing Consortium brings together work on technologies and open-source projects in this area. The idea is especially relevant when organizations want to collaborate on sensitive data or move regulated workloads to shared infrastructure without treating the host operating system or cloud control plane as fully trusted.

What Is Confidential Computing?

Confidential computing protects selected code and data while they are in use by placing them inside a hardware-enforced boundary. Depending on the platform, that boundary may cover a small application enclave or a whole virtual machine. The processor is intended to prevent software outside the boundary, including a privileged host, from reading or modifying protected memory directly.

The Microsoft overview of Azure Confidential Computing describes the goal as protecting data in use through hardware-based trusted execution environments. In practice, “confidential computing” describes a family of platform capabilities and services, not one universal interface or security level. A buyer must check which processor, firmware, guest, and workload components are protected and how the service exposes evidence of that protection.

A TEE does not keep data encrypted from the code that processes it. The workload must use its inputs in plaintext inside the protected boundary. The security benefit is that the platform restricts who else can inspect that computation and can provide evidence about the environment before secrets are released.

The Problem It Solves

Traditional encryption protects data at rest, such as files on storage, and in transit, such as API requests crossing a network. During computation, however, an application generally decrypts the data into memory. Access controls and operational trust are then relied on to prevent administrators, a compromised hypervisor, or another process from reading it.

Confidential computing changes this trust model rather than removing trust altogether. It can reduce the cloud host’s ability to inspect workload memory, and attestation can let a remote service check a platform’s reported state before sending it a key. This can help customers deploy workloads on shared infrastructure while retaining more control over when sensitive data becomes available.

Another approach is homomorphic encryption, which can perform supported operations without exposing input plaintext to the processor. A TEE instead processes plaintext inside an isolated boundary and relies on hardware protections and attestation. The two approaches have different performance and trust trade-offs; homomorphic encryption explained covers the encrypted-computation model in more detail.

How Trusted Execution Environments Work

A typical confidential workload follows a sequence like this:

Start a protected environment. The processor and platform establish an isolated memory region or confidential virtual machine.
Measure its initial state. Hardware or trusted firmware records cryptographic measurements of relevant components, such as the initial code and configuration.
Request attestation evidence. The platform produces signed evidence that binds measurements and platform claims to the running environment.
Verify the evidence. A verifier checks the signature chain, freshness, platform status, and measurements against an approved policy.
Release secrets conditionally. A key service provides decryption keys or credentials only when the evidence satisfies that policy.
Process data inside the boundary. The workload decrypts and uses the data there, then returns only the intended output.

Remote attestation is not simply a green check from a cloud console. The IETF RATS architecture in RFC 9334 describes roles such as an attester that provides evidence, a verifier that appraises it, and a relying party that uses the result. A production design needs an explicit policy for acceptable measurements and current platform status. It should also bind evidence to a fresh request, for example with a nonce, to reduce replay risk.

The isolation boundary can vary significantly. An application enclave aims to protect a particular trusted program and its memory, while a confidential VM generally protects a broader guest environment from the host. Neither automatically proves that the application’s logic is safe or that its inputs and outputs are handled correctly.

Feature	Application enclave	Confidential virtual machine
Protected unit	Selected application code and data	Most of a guest VM’s memory and execution state
Guest operating system	Usually outside the enclave boundary	Inside the protected guest boundary
Workload changes	May require partitioning code and designing enclave interfaces	Often runs a supported guest OS with fewer application changes
Attestation focus	Enclave identity and measured code	VM launch state, firmware, and guest configuration
Main engineering concern	Minimize trusted code and secure communication across the boundary	Secure the guest as a whole and validate its boot and configuration
Typical fit	A narrowly scoped secret-handling component	Existing workloads that need broader host isolation

The actual claims and interfaces are vendor- and generation-specific. A feature comparison should be based on current platform documentation, not the names “enclave” or “confidential VM” alone.

Components and Key Concepts

Hardware root of trust. The processor and supporting firmware anchor the claims that an attestation report can make. If this foundation, its signing keys, or its update process is compromised, software policy cannot restore the original trust assumption.

Isolation boundary. Memory protections separate the workload from some host-level software. The protected scope matters: an enclave may leave most application code outside, while a confidential VM aims to cover the guest. Input paths, device interfaces, and outputs still cross boundaries and need protection.

Measurements and reference values. A measurement is typically a cryptographic digest of a component or configuration. A verifier compares it with reference values and policy maintained by the workload owner. A valid signature alone does not mean the measured code is approved; it only helps establish that the evidence came from the claimed platform.

Attestation verifier and relying party. The verifier evaluates evidence, endorsements, platform status, and freshness. The relying party—often a key broker or application—decides what to do with that result. Keep this decision in an owner-controlled policy where possible rather than accepting every report a platform labels valid.

Secret provisioning. Keys should be released only after the expected code and configuration are verified. Restrict what the workload can do with a released key, rotate credentials, and consider how revocation and recovery work if a platform or image becomes untrusted.

Side channels and residual trust. TEEs reduce certain direct inspection paths; they do not eliminate vulnerabilities in processors, firmware, trusted code, or shared resources. Timing, memory-access patterns, denial of service, and application-level data leaks can remain in scope for a threat model.

Real-World Use Cases

Sensitive cloud workloads: Process customer or regulated data while reducing the hosting provider’s ability to inspect guest memory.
Confidential collaboration: Let multiple organizations run an agreed analysis over combined inputs, using attestation and controlled key release to enforce which code sees the data.
Protected machine-learning inference: Run a model or handle inference inputs inside an isolated environment when both model confidentiality and input privacy matter.
Key and credential services: Use an attested workload to request narrowly scoped secrets from a key broker rather than embedding long-lived credentials in an image.

These designs still require data minimization, access controls, audit logs, and careful output review. Attestation can help answer “what environment started?” It does not establish that the application’s result is correct, that the workload owner’s policy is wise, or that a user is authorized to see the output.

Getting Started with an AWS Nitro Enclave

An enclave demonstration is useful for understanding resource allocation and the host-to-enclave boundary. It is not a general-purpose deployment recipe: Nitro Enclaves require a supported EC2 instance and operating-system setup, the Nitro Enclaves CLI, and an enclave image file (EIF). Follow the AWS Nitro Enclaves documentation to confirm instance support and prepare the host and image.

Once the host is configured and an EIF has been built, allocate part of the instance’s available CPU and memory to start it:

nitro-cli run-enclave \
  --eif-path confidential-app.eif \
  --cpu-count 2 \
  --memory 512

Inspect the enclave’s runtime state from the parent instance:

nitro-cli describe-enclaves

The CPU and memory values are example allocations, not universal requirements. An enclave also needs an intentional communication path to the parent, and secrets should not be passed over that path before the remote attestation policy has approved the enclave. describe-enclaves confirms runtime information; it is not a substitute for verifying an attestation document or deciding whether its measurements are trusted.

For any provider, start by identifying the threat you want to reduce, choosing the narrowest suitable protected scope, and locating the authoritative format for its attestation evidence. Define approved measurements and freshness checks, test that an unapproved image is denied keys, and rehearse how updates change those measurements before moving sensitive production data.

Common Misconceptions

“A TEE makes the cloud provider completely untrusted.” It can reduce a provider’s ability to inspect protected memory, but the design still depends on processor and firmware security, vendor attestation services, workload code, and the customer’s policies. Availability and metadata may also remain visible to the host.

“A valid attestation proves the application is secure.” Attestation reports claims about a measured platform and its state. The workload owner must decide whether those claims and measurements are acceptable. Vulnerable code can be measured accurately and still be vulnerable.

“Confidential computing encrypts data from the program using it.” The program normally sees plaintext inside its boundary. If the requirement is to compute on ciphertext without exposing inputs to the processor, compare the design with homomorphic encryption and assess which operations it supports.

Changelog

2026-10-02: Initial publication.