Confidential computing for classified workloads: enclaves and attestation

Classified data has historically been protected in two of its three states. Encryption at rest protects it on disk; encryption in transit protects it on the wire. The third state – data in use, decrypted into CPU registers and RAM so it can actually be processed – has always been the soft underbelly. Any code with sufficient privilege on the host, including the operating system, the hypervisor, and a cloud operator with physical access to the memory bus, can read that plaintext. Confidential computing closes this gap by running the workload inside a hardware-isolated trusted execution environment (TEE), where the CPU keeps memory encrypted and unreadable to everything outside the enclave. For classified workloads, this changes who has to be trusted – and that change is the whole point.

The data-in-use problem and the confidential computing threat model

The defining premise of confidential computing is a reduced trusted computing base. In a conventional cloud deployment, the tenant is forced to trust the entire stack beneath the application: the guest OS kernel, the hypervisor, the host firmware, the cloud control plane, and the people who operate the data center. Each of those is a path to the plaintext while the workload runs. For a Secret or sensitive-compartmented workload, that trust surface is unacceptable.

A TEE inverts the model. The CPU itself enforces an isolation boundary, encrypting the enclave's memory with keys that are generated and held inside the processor's hardware security module and never exposed to software. The host operating system can schedule the enclave, allocate it pages, and stop it – but it cannot read what is inside. A hypervisor compromised by an attacker, or a malicious administrator who attaches a debugger or dumps physical memory, sees only ciphertext. The trust boundary collapses to two things: the silicon vendor's hardware and the code you deliberately load into the enclave.

This is precisely the property that lets defense organizations contemplate hosting sensitive workloads on infrastructure they do not physically control. It does not, on its own, make a commercial region accredited for classified data – that requires the full set of controls discussed in our analysis of zero-trust architecture for military networks – but it removes the operator from the trust boundary for data in use, which materially changes the risk calculus.

Trusted execution environments: SGX, SEV-SNP, TDX, and CCA

There are two architectural families of TEE, and the choice between them is the first and most consequential design decision.

Process-level enclaves (Intel SGX). Software Guard Extensions carves a small, application-defined region of memory – the enclave – out of a process and seals it from everything else, including the kernel. The trusted computing base is minimal: only the code you place inside the enclave is trusted, not the surrounding OS. The cost is that the application must be partitioned into trusted and untrusted halves, with a controlled call interface between them, and enclave memory is constrained. SGX is the right tool when you want the smallest possible attack surface around a specific secret-handling routine – a key-wrapping service, a cryptographic signer, a small policy engine.

VM-level confidentiality (AMD SEV-SNP, Intel TDX, Arm CCA). Secure Encrypted Virtualization with Secure Nested Paging, Trust Domain Extensions, and Arm's Confidential Compute Architecture Realms all protect an entire virtual machine. The guest's memory is transparently encrypted and integrity-protected, and the hypervisor is removed from the trust boundary, but the workload inside runs unmodified. An existing classified application can be lifted into a confidential VM with no code change. The trusted computing base is larger – it includes the whole guest OS – but the adoption cost is dramatically lower. For most defense workloads being migrated rather than written from scratch, VM-level confidentiality is the pragmatic choice.

SEV-SNP and TDX added a feature SGX's first generation lacked and that matters acutely for classified data: memory integrity protection, defending against an attacker who replays or remaps encrypted pages rather than merely reading them. Any TEE selected for classified use must provide both confidentiality and integrity; confidentiality alone leaves the workload open to active memory-corruption attacks from the host.

Remote attestation: proving the enclave before trusting it

Hardware isolation is necessary but not sufficient. The party that holds the classified data – or the key that decrypts it – needs proof that the enclave it is about to talk to is genuine TEE hardware running the exact code expected, and not an emulator, a tampered image, or a downgraded-microcode platform pretending to be secure. That proof is remote attestation, and it is the mechanism that makes confidential computing trustworthy rather than merely plausible.

How an attestation flow works

When an enclave starts, the CPU measures the loaded code and configuration into a hardware register and, on request, produces a signed quote: a structure containing those measurements, the TEE's security-version numbers, and a signature chaining back to a key fused into the silicon at manufacture. The enclave sends this quote to a verifier – a service the data owner controls or trusts. The verifier validates the signature chain back to the vendor's root certificate, confirms the platform is on current, un-revoked microcode, and compares the reported measurements against an allow-list of code it is willing to trust. Only if every check passes does the verifier authorize the next step.

The critical engineering discipline here is reproducible measurement. The enclave or guest image must be built deterministically so its measurement is bit-for-bit identical every time, because the attestation policy is an allow-list of exact measurement values. A non-reproducible build means a constantly changing measurement, which forces operators toward the cardinal sin of loosening the policy until it accepts almost anything – defeating the purpose. Treat the launch measurement as a release artifact, recorded and version-controlled alongside the firmware and microcode versions it depends on.

Attestation policy as the real security boundary

The hardware does the cryptography, but the policy does the deciding, and a weak policy nullifies strong hardware. A defense-grade attestation policy states explicitly: which TEE types are accepted; the minimum trusted computing base version, with security-version-number checks that reject rolled-back microcode after a vulnerability disclosure; the exact set of code measurements permitted; and freshness requirements so an old quote cannot be replayed. The most common failure mode in real deployments is not a broken enclave – it is an over-permissive policy that accepts measurements it should not, or never checks the revocation status of the platform. Attestation is only as good as the rules the verifier enforces.

Key release: binding secrets to a verified environment

Attestation becomes operationally useful when it gates access to secrets. The pattern is attestation-bound key release: the key management service is configured so that a classified data-encryption key is handed out only after the verifier confirms a passing attestation. The enclave requests the key, presents fresh evidence, and the KMS releases the wrapped key into a channel that is terminated inside the TEE, so the plaintext key never exists outside the enclave. An unattested host, a downgraded platform, or a tampered image simply never receives the material it needs to decrypt anything.

This inverts the usual relationship between identity and authorization. Instead of releasing a key because a caller presents a credential that could be stolen, the key is released because the runtime environment has cryptographically proven its integrity. For workloads that must move data across boundaries, this composes cleanly with the controls described in our piece on cross-domain solutions for defense: the enclave performing the transfer can be required to attest before it is ever entrusted with data from a higher classification level.

Cloud deployment patterns for classified workloads

All major government cloud regions now expose confidential VM SKUs backed by SEV-SNP or TDX, and managed enclave and attestation services to go with them. Three deployment patterns recur in classified and sensitive programs.

Confidential data processing. The workload that touches classified data – an analytic, a fusion engine, a model inference service – runs entirely inside confidential VMs. Data arrives encrypted, keys are released only to attested enclaves, and the decrypted data exists only in protected memory. This is the lift-and-shift pattern: existing applications gain data-in-use protection with minimal change, removing the cloud operator from the trust boundary without a re-architecture.

Confidential key management and brokering. A small, SGX-style enclave acts as the trust anchor: it holds wrapping keys, performs attestation verification for other workloads, and brokers data-encryption keys to attested confidential VMs. Concentrating the most sensitive logic in a minimal enclave keeps the trusted computing base for key handling small even when the bulk workloads run as full confidential VMs.

Confidential multi-party and coalition computation. Two organizations that cannot share raw data – coalition partners, or agencies at different classification levels – each contribute encrypted inputs to a confidential VM that computes a joint result. Because no party, including the host, can read the others' inputs, the enclave becomes neutral ground. Attestation lets each contributor verify exactly what code will process its data before releasing it.

Residual risks and operational discipline

Confidential computing narrows the threat surface dramatically but does not eliminate it. Side-channel attacks against TEEs are an active research area, and several have required microcode mitigations – which is why security-version-number enforcement in the attestation policy is not optional. The enclave code itself is inside the trust boundary, so a vulnerability there is a vulnerability in the protected workload; a minimal trusted computing base limits the blast radius. And the silicon supply chain is, ultimately, trusted. None of these defeat the model, but they define the operational discipline: patch microcode promptly, keep the enclave small, re-attest continuously rather than only at launch, and log every attestation decision to immutable storage for audit.

Confidential computing is one strong control inside a broader accredited architecture, not a substitute for accreditation. It belongs alongside data-residency controls, an authorization to operate at the correct impact level, audited key management, and the zero-trust networking and cross-domain controls covered elsewhere in this series. What it uniquely provides is auditable protection for data in use – the state that was, until recently, simply assumed to be exposed.