Confidential computing: what hardware isolation protects—and what it does not

Confidential computing is often described as encryption for data in use. That is useful shorthand, but it can hide the decision that matters most: which parts of the system are still trusted when a workload runs? A trusted execution environment (TEE) can prevent a cloud hypervisor, host operating system, or neighboring tenant from directly reading or altering protected memory. It does not make an application correct, hide every observable behavior, or remove the need to trust silicon, firmware, attestation services, and the code loaded into the environment.

The Confidential Computing Consortium (CCC) defines confidential computing as protecting data in use by computing inside a hardware-based, attested TEE. Its definition is an industry description, not a single protocol or certification. A TEE is a hardware-enforced execution environment intended to provide data confidentiality, data integrity, and code integrity against specified unauthorized entities. The exact boundary, measurements, I/O model, update process, and threat model vary by implementation. The CCC's technical analysis also makes clear that “absolute security” is not the goal; the practical goal is to make particular attacks by a platform owner or operator substantially harder and less economically viable. Confidential Computing Consortium, _A Technical Analysis of Confidential Computing_

This article is scoped to the state of the technology on 20 October 2026. Product availability, cloud regions, supported CPU generations, firmware versions, and preview status change quickly, so a deployment decision should always be checked against the current platform documentation and security advisories.

The security problem: data in use and the trust boundary

Encryption at rest protects a disk or database snapshot. Encryption in transit protects a network connection. Neither protects plaintext while a processor is using a value. In a conventional virtual machine, the guest ultimately relies on the host kernel, hypervisor, firmware, device mappings, and physical machine to keep that plaintext private. A privileged cloud operator may not be malicious, but the operator's access is still a high-value path for compromise, coercion, insider abuse, or an accidental diagnostic exposure.

A TEE changes the boundary. Sensitive pages are encrypted as they leave the processor package or memory controller, and hardware rules restrict which components may access them. The guest or enclave normally sees plaintext while executing; an untrusted host sees ciphertext or is denied access. Integrity mechanisms can detect unauthorized changes to protected memory, and launch measurements can provide evidence about what was loaded. The protection is therefore not “the data is encrypted everywhere,” but rather “the hardware mediates plaintext access and can provide evidence about the protected workload.” Microsoft and Google both describe their confidential-computing offerings in these terms, while also separating them from ordinary encryption at rest and in transit. Microsoft, _What is confidential computing?_ Google Cloud, _Confidential Computing overview_

A useful threat model names the adversary instead of saying simply “the cloud.” For a confidential virtual machine, the intended adversary commonly includes a hostile or compromised hypervisor, host kernel, cloud administrator, co-tenant, or host-side malware. Depending on the product, it may also include some physical-access attacks and attempts to inspect DRAM, bus traffic, or memory mappings. The intended adversary usually does not include a compromised application running inside the protected VM, a malicious user who can submit chosen inputs, a bug in the workload, a fully invasive chip laboratory, or denial of service. The CCC classifies basic physical attacks, software attacks on the host, and protocol attacks as relevant vectors, while treating sophisticated physical attacks, upstream hardware attacks, and availability attacks as generally out of scope. Confidential Computing Consortium, _A Technical Analysis of Confidential Computing_

That distinction changes the question a security review should ask. “Can the provider read my database?” may have a good answer. “Can a compromised service leak a customer's records through its API?” is an application-security question. “Can a provider stop my VM?” is an availability and business-continuity question. “Can I prove which image received a decryption key?” is an attestation and key-management question. One hardware feature cannot answer all four.

What memory encryption actually does

Memory encryption is the basic mechanism behind many TEEs, but its properties are easy to overstate. A memory controller or processor encryption engine encrypts protected lines or pages when they move to external memory. A hardware-managed key is associated with the VM, enclave, or protection domain. The CPU decrypts data for an authorized execution context and re-encrypts it when it leaves the protected path. Keys are normally generated or controlled by a hardware security processor or a protected CPU subsystem rather than supplied as ordinary guest files.

Confidentiality is only one property. If an attacker can replace ciphertext, remap a page, replay an old value, or induce an unexpected mapping, encryption without integrity can leave the guest vulnerable to manipulation. This is why modern confidential-VM designs add metadata, ownership checks, versioning, or integrity trees. The coverage is implementation-specific. It may include guest memory and some CPU state, but not automatically every device buffer, register, firmware component, or shared page. A security design must identify where plaintext exists during page faults, hypercalls, device I/O, crash collection, migration, and suspend/resume.

AMD's SEV family illustrates an incremental design. SEV assigns a key per virtual machine and uses the AMD Secure Processor to manage the memory-encryption context. SEV-ES encrypts guest register state when a VM stops, while SEV-SNP adds memory-integrity protections intended to address attacks such as replay and malicious remapping. AMD describes newer Trusted I/O work as extending the protected domain to selected PCIe devices through the PCI-SIG TDISP protocol, but that is an extension with its own hardware, firmware, and device requirements, not a property that every SEV deployment automatically has. AMD, _Secure Encrypted Virtualization (SEV)_

Intel TDX uses a different abstraction: a trust domain (TD) is a hardware-isolated virtual machine. Its TDX module runs in a CPU-protected mode and helps enforce access rules for TD private memory. The TDX specification describes memory encryption and integrity support through Intel's multi-key memory-encryption facilities, with keys selected using hardware identifiers and controlled by the TDX module. It also distinguishes private memory from shared memory, because a TD must exchange data with an untrusted host and devices. Intel, _Trust Domain Extensions overview_ Intel, _TDX Module Base Architecture Specification_

A small enclave is not merely a small confidential VM. Enclave systems such as Intel SGX put a selected application region inside a protected memory area and generally require the application to use a specialized SDK, carefully controlled calls, and an enclave boundary. Confidential VMs protect a larger guest operating system and can often run existing applications with fewer changes, but their trusted computing base (TCB) includes more guest software. The trade-off is familiar: a smaller boundary can reduce exposure, while a larger boundary can make migration and operations easier. Neither choice eliminates bugs in the trusted code.

Arm CCA takes yet another architectural route. Arm's Realm Management Extension provides hardware primitives for confidential VMs called Realms, separated from the Normal world that runs the host and hypervisor. CCA also defines Secure and Root worlds for other platform functions. The host can schedule a Realm, but the Realm Management Monitor mediates creation and execution so the Normal world cannot directly observe or modify Realm code and data. In CCA, platform attestation and Realm attestation combine into a token describing platform and Realm state. Arm, _The Role of Attestation in Arm CCA_

These are vendor architectures, not interchangeable standards. “TEE,” “confidential VM,” “enclave,” and “confidential container” describe families of designs. They do not specify a universal key format, measurement register, quote service, firmware update policy, or side-channel guarantee. Standards work can make evidence and verifier roles interoperable, but a buyer still has to assess the implementation on its target processor and cloud service.

Remote attestation: evidence, not a verdict

Remote attestation lets a workload prove claims about its execution environment to a party that is not on the same host. The usual flow is:

1. Hardware and trusted firmware measure some combination of the platform, TEE code, initial memory, configuration, and policy.
2. An attesting component creates signed evidence containing those measurements and often a freshness value supplied by the verifier.
3. A verifier checks the signature chain, device or platform endorsements, certificate status, measurement format, freshness, and policy.
4. A relying party uses the verifier's result to authorize an action, such as releasing a key or accepting a connection.

The IETF's RATS architecture gives these roles precise names. An Attester produces Evidence. A Verifier appraises Evidence against reference values, endorsements, and an appraisal policy. A Relying Party uses the resulting Attestation Result to make an application decision. RATS is an architecture and vocabulary; it does not mandate AMD SNP, Intel TDX, Arm CCA, or a particular cloud provider. IETF, RFC 9334, _Remote ATtestation procedureS (RATS) Architecture_

A measurement is not the same as a security judgment. A hash can show that the bytes of an image, firmware component, or configuration match a known value. It cannot show that the image has no exploitable bug, that its operator will use data lawfully, or that its output is accurate. A verifier must also know what the measurement means, which firmware and microcode versions are acceptable, whether debug mode is disabled, whether the TEE is patched, and what policy should apply to a revoked or deprecated platform. The reference value may be a single exact hash, a set of approved hashes, a signer identity, a version floor, or a structured policy claim.

Freshness matters. A signed report copied from last month should not authorize a key today if the workload has been rolled back or a vulnerable image has been revived. Nonces bind evidence to a verifier's request. Short validity windows, platform security-version claims, revocation checks, and workload session keys can add further protection. RATS explicitly discusses freshness and the need for a relying party to avoid treating an attestation result as valid forever. The exact nonce, timestamp, and validity semantics remain protocol- and vendor-dependent.

Attestation also has a coverage problem. A report may attest to a launch measurement while the service later loads plugins, fetches an unpinned container layer, accepts a writable script, or talks to an untrusted accelerator. Some systems support runtime measurements or staged evidence, but no report should be assumed to cover code and data that the platform never measured. A practical policy therefore defines the exact asset being authorized: “this signed image, with this configuration and minimum security version, in production mode, running on an approved platform,” rather than “a secure machine.”

Key release turns evidence into a control

Confidential computing becomes operationally meaningful when secrets are released conditionally. Keeping a database key in an encrypted image is not enough if any booted image can ask the key service to unwrap it. The key service should require evidence that is fresh, valid, and consistent with an explicit policy.

A typical flow looks like this. The protected workload generates an ephemeral key pair and includes a public key or session nonce in an attestation request. The verifier validates the evidence and checks the requested image, platform, security version, debug state, and environment. A key broker or KMS then encrypts a data-encryption key to the attested public key, or performs a decrypt operation only when the evidence satisfies its policy. The workload receives plaintext key material only inside the TEE and uses it to open data. The host may relay messages, but should not be able to substitute its own key or replay an old authorization.

Open the full-size diagram

AWS Nitro Enclaves demonstrates a provider-specific version of this pattern. An enclave has its own kernel, memory, and virtual CPUs, no external network connectivity, and no persistent storage; it communicates through a vsock channel with its parent instance. The Nitro hypervisor signs an attestation document containing enclave measurements, a nonce, and additional claims. AWS KMS can use values in that document as authorization conditions for cryptographic operations. This is useful precisely because attestation is connected to a concrete key-release decision, but the semantics are AWS-specific rather than a universal TEE contract. AWS, _Nitro Enclaves concepts_

A key-release design should answer five questions. Who verifies? It may be a cloud service, an enterprise-operated verifier, or a split-trust service. What is measured? Include image identity, configuration, security version, and relevant sidecar or policy components. What is the failure behavior? Deny by default when evidence is stale, unavailable, revoked, or ambiguous. Where does plaintext appear? Trace it through boot, memory, logs, crash dumps, swap, backup, and application caches. How are keys revoked? Tie authorization to short-lived grants, version floors, workload identity, and a tested rotation process.

Do not place the only copy of a long-lived secret inside a TEE without a recovery plan. A protected workload can still crash, lose its filesystem, or be intentionally stopped by its host. Use envelope encryption, retain ciphertext outside the TEE, separate key-encryption keys from data-encryption keys, and define how a replacement instance is authorized after a measured software update. Migration is especially important for confidential VMs: live migration, snapshots, suspend/resume, and disaster recovery can change the evidence and the trust boundary. A design that cannot explain rehydration is not production-ready.

Platform differences that affect a design

The first choice is the size of the protected boundary.

Confidential VMs such as AMD SEV-SNP, Intel TDX, and Arm CCA protect a guest operating system and its memory from a host-level adversary. They are usually the most practical path for rehosting databases, application servers, and existing services. The guest still needs a secure boot path, patching, endpoint hardening, and careful handling of shared pages and device I/O. The cloud provider may offer attestation, but the customer must determine whether the report covers the guest image, firmware, hypervisor configuration, and security version needed for the use case.

Application enclaves protect a smaller code and data region. They can reduce the TCB and make a narrow secret-handling service easier to reason about, but they impose boundary-crossing costs and may require refactoring. An enclave normally depends on an untrusted host for networking, storage, scheduling, and sometimes system calls. Treat every call across the boundary as an input that requires validation and as a possible information-leak path.

Confidential containers are an operational layer over confidential VMs or other TEEs, not a new hardware primitive. They package container workflows with guest isolation, image measurement, attestation, and secret-management components. The Confidential Containers project describes an architecture for bringing TEE protection to cloud-native workloads and documents an attestation and secret-management component called Trustee. Confidential Containers, documentation The security question remains: which guest kernel, runtime, init process, image layers, and policy service are measured and trusted?

Device and accelerator protection is a separate boundary. A GPU, NIC, storage controller, or CXL memory device may receive sensitive data outside the CPU TEE. An encrypted VM does not automatically make an attached device trustworthy. Where a platform supports protected I/O, review the exact protocol, device firmware, DMA restrictions, attestation claims, and cloud-service availability. Otherwise, design the interface so that sensitive plaintext is minimized, masked, or processed inside the CPU-protected region.

Cloud wrappers differ even when the CPU is the same. A provider may expose a VM through a managed image pipeline, a custom enclave runtime, or a managed confidential database. It may operate the verifier, rotate endorsement certificates, restrict snapshots, or add a key broker. These are service properties, not inherent properties of AMD, Intel, or Arm hardware. Record the CPU generation, firmware, TEE module version, cloud image, launch mode, attestation endpoint, and supported update path in the security case. As of October 2026, some provider or hardware combinations remain preview or region-dependent; do not infer general availability from a vendor architecture page.

Side channels are the hard boundary

Memory encryption hides the value in a cache line or DRAM row. It does not necessarily hide how the program behaves. A side channel is an indirect signal—timing, cache occupancy, branch behavior, page faults, contention, interrupt patterns, power, electromagnetic emissions, or resource usage—from which an attacker infers secrets. A host that cannot read an enclave's memory may still schedule it, observe exits, measure shared resources, or supply carefully chosen inputs.

The risk is not theoretical. A survey of published attacks on Intel SGX catalogs attacks that bypass the intended hardware defense through side channels and related weaknesses, including controlled-channel techniques. Its lesson is broader than SGX: isolation is a mechanism, while resistance to inference depends on the processor, runtime, workload, and mitigations. Nilsson, Bideh, and Brorsson, _A Survey of Published Attacks on Intel SGX_ The CCC similarly treats side channels as an assumption that can fail and gives timing and power analysis as examples.

Defenses are workload-specific. Use constant-time cryptography and avoid secret-dependent branches and memory accesses. Reduce page-fault and system-call observability. Partition or flush shared resources where the platform supports it. Avoid colocating mutually hostile workloads when the risk justifies dedicated capacity. Rate-limit chosen-input interfaces, pad response timing where practical, and keep high-value operations short. Treat performance counters, logs, tracing, crash diagnostics, and autoscaling signals as potential leakage paths. Ask the platform provider which channels are addressed by the current TEE version; do not assume “encrypted memory” means “side-channel resistant.”

A side channel can also exist at the application boundary. A service that returns whether a record exists, how long a query took, or how many matches were found may leak more than the host ever could. The TEE protects data from some infrastructure actors; it does not stop an authorized API from revealing it. Privacy budgets, query controls, output review, and tenant isolation remain necessary for multi-party analytics.

Supply-chain and software limits

Attestation can establish that approved bytes ran in an approved environment. It cannot establish that the bytes are safe. A signed container can contain a credential-stealing backdoor. A measured kernel can have a remotely exploitable bug. A trusted verifier can apply the wrong reference policy. A malicious update process can make a legitimate measurement acceptable while changing what the application does with the data.

The hardware supply chain is also part of the TCB. The CCC identifies upstream hardware attacks, including compromise during chip manufacturing or key injection, as generally outside the normal confidential-computing threat model. Firmware, microcode, board controllers, platform identity services, endorsement certificates, build systems, base images, and the verifier itself all influence the result. Hardware isolation lowers trust in a cloud operator; it does not remove trust in the manufacturer, firmware signing chain, image builders, or the people who approve measurements.

Operational controls should therefore sit beside the TEE. Build images reproducibly and record source commits, dependencies, compiler versions, and image digests. Sign artifacts and keep provenance separate from the runtime measurement. Review privileged guest components and minimize the TCB. Pin dependencies, scan and fuzz the code that handles untrusted host input, and use independent review for key-release policy. Maintain a vulnerability process that can revoke a measurement or raise a minimum security version quickly. Keep an inventory of which data was processed by which image and platform generation so that a newly disclosed hardware issue can be scoped.

The phrase “secure enclave” can itself become a supply-chain risk if it leads teams to skip ordinary controls. A TEE does not validate business authorization, classify personal data, prevent a developer from logging plaintext, or enforce a retention policy unless the workload implements those rules. It does not provide availability against a host that simply refuses to schedule the VM. It may reduce forensic visibility because the operator cannot inspect memory, so application-level telemetry and tested recovery paths become more important.

A practical decision and implementation framework

Use the following sequence before selecting a product.

1. State the asset and adversary

Name the data, code, and output that require protection. Then list the attackers: cloud operator, hypervisor compromise, co-tenant, malicious workload user, physical attacker, supply-chain attacker, or an insider with application credentials. Mark availability, integrity, and confidentiality separately. If the objective is only to protect a database key from host administrators, an enclave-backed key service may be enough. If the objective is to run an entire existing application while excluding the hypervisor, a confidential VM may be a better fit.

2. Choose the smallest workable boundary

Prefer a small enclave for a narrow cryptographic or matching function when the application can tolerate the interface and side-channel analysis. Prefer a confidential VM when migration, operating-system compatibility, or broad memory protection matters more than a minimal TCB. Use confidential containers when Kubernetes workflow integration is valuable, but account for the guest kernel, runtime, orchestrator, and attestation policy. Do not choose by product label alone.

3. Map plaintext and shared state

Draw the data path from input to output. Identify private memory, shared memory, device buffers, host calls, network sockets, disks, snapshots, backups, logs, crash dumps, and caches. For each transition, specify confidentiality, integrity, authentication, and replay protection. If a device cannot be attested or isolated, keep sensitive plaintext away from it or use an additional application-level protection layer.

4. Define the attestation policy before deployment

Specify acceptable hardware roots, firmware and TEE versions, debug state, image identity, configuration, security version, and evidence freshness. Decide whether exact hashes or signed identities are appropriate. Store policy as code, review it like production authorization code, and test both acceptance and denial paths. A verifier that fails open during an attestation-service outage defeats the purpose of attestation.

5. Gate keys, not just startup

Release the minimum secret to the minimum workload for the minimum time. Use an external KMS or broker with attestation-aware authorization, bind the release to a fresh session key, and separate data keys from key-encryption keys. Record the decision and evidence identifiers without logging plaintext. Plan rotation, revocation, image rollback, disaster recovery, and replacement-instance authorization before the first production secret is released.

6. Test the negative cases

Try an altered image, stale nonce, revoked certificate, debug configuration, downgraded security version, unexpected shared-page mapping, failed verifier, unavailable KMS, and a host that drops or delays messages. Test snapshot restoration and workload migration. Measure side-channel exposure for the actual API and data distribution, not only a synthetic benchmark. A confidential-computing deployment is credible when it fails closed and recovers predictably.

7. Operate the TCB as a living inventory

Track hardware model, firmware, microcode, TEE module, guest kernel, runtime, image digest, verifier, endorsement chain, and key policy. Subscribe to vendor security advisories and maintain a response playbook for TEE vulnerabilities. Decide how to pause key release, rotate secrets, drain affected workloads, and re-attest after remediation. Keep enough application telemetry to investigate behavior without collecting plaintext that the TEE was intended to protect.

Realistic use cases

The strongest use cases share data between parties that need computation but do not want to hand one another raw records. A hospital network and a research organization can run a narrowly designed analysis in an attested environment while limiting the hosting operator's ability to inspect inputs. Several companies can compare fraud indicators or compute aggregate statistics without placing all source data in one ordinary host environment. The TEE does not settle consent, purpose limitation, or output privacy; it supplies one technical control in a larger data-sharing agreement.

Confidential VMs are also practical for regulated workloads hosted by a cloud provider. A team can reduce the trust placed in the provider's hypervisor and host administrators while retaining a familiar guest operating system, encrypted storage, ordinary network controls, and an external key service. The benefit is greatest when the threat is infrastructure access during execution—not when the application itself is untrusted or the main concern is denial of service.

Less suitable cases include workloads whose dominant risk is endpoint compromise, application authorization, malicious insiders with valid credentials, or high-availability failure. A TEE may protect a key from a host while the endpoint that submits the key or receives plaintext remains compromised. It may make debugging and live migration harder. It may also be the wrong answer when information-theoretic privacy, verifiable computation, or strict output privacy is the real requirement; those are different technologies and should not be disguised as confidential computing.

Conclusion

Hardware isolation is valuable because it can remove the cloud host and hypervisor from part of the plaintext trust boundary. Memory encryption, integrity checks, measured launch, attestation, and policy-gated key release can make that reduction enforceable rather than contractual. The protection is strongest when the workload has a clearly defined adversary, a small and measured TCB, a verifier policy that fails closed, and a key lifecycle designed around fresh evidence.

The boundary stops where the design stops. TEEs do not guarantee safe code, private outputs, resistance to every side channel, trustworthy hardware manufacture, continuous availability, or compliant data use. Treat confidential computing as a precise isolation and evidence mechanism—not a security category that replaces application security, supply-chain governance, incident response, or sound operations.

References and further reading

• Confidential Computing Consortium, _A Technical Analysis of Confidential Computing_, v1.3
• NIST, _Hardware-Enabled Security: Confidential Computing of Data in Cloud Workloads_, IR 8320E initial public draft
• AMD, _Secure Encrypted Virtualization (SEV)_
• Intel, _Trust Domain Extensions overview_
• Intel, _TDX Module Base Architecture Specification_
• Arm, _The Role of Attestation in Arm CCA_
• IETF, RFC 9334, _Remote ATtestation procedureS (RATS) Architecture_
• AWS, _Nitro Enclaves concepts_
• Google Cloud, _Confidential Computing overview_
• Nilsson, Bideh, and Brorsson, _A Survey of Published Attacks on Intel SGX_