None of these approaches is “best.” They disagree about how much of the guest you must trust, and about whether the proof is a CPU quote, a Nitro attestation document, or a contractual commitment.
That gap is no longer a specialist talking point. Cloud platforms have spent the past year putting “encryption in use” next to ordinary compute SKUs, managed data services, and AI inference paths, because the workloads that most need it are the ones already running in someone else’s memory.
The third state becomes a cloud product
AWS leans on Nitro isolation and contractual operator-access controls, with Enclaves for the cases that need a smaller trusted computing base than a full guest OS. Fortanix, a specialist rather than a hyperscaler, sells a confidential computing manager that it says can lift applications onto Nitro Enclaves across EC2 instance families (AWS Nitro Enclaves). That is a software control plane on someone else’s TEE, not a new chip.
AMD Secure Encrypted Virtualization–Secure Nested Paging (SEV-SNP) and Intel TDX encrypt guest memory so the hypervisor is not supposed to see the plaintext. Keys are managed by the processor’s security architecture. Microsoft’s VM options describe SEV-SNP on EPYC-based confidential VMs and TDX on 5th Gen Xeon confidential VMs as different implementations with similar protection from the cloud infrastructure stack. AMD says SEV encrypts VM memory with no code changes. That is the lift-and-shift pitch, and for many apps it is true at the binary level: you reboot on a confidential SKU.
What is emerging, over the next 12–24 months, is the AI-shaped version of the same idea: GPU-linked TEEs, confidential inference APIs, and multi-party “clean room” analytics that keep collaborating firms from seeing each other’s raw tables. Microsoft lists NCCadsH100v5 confidential GPU VMs and Whisper inferencing with TEEs as current offerings; treat those as vendor-described services, not as proof that every model in Azure now runs inside a TEE.
Microsoft exposes both AMD and Intel confidential VM families, plus H100-class confidential GPU VMs and SQL Always Encrypted with enclaves. It also states, as a first-party claim, that cryptographic and code-signing services using these patterns handle about 3 billion transactions per day. That figure is Microsoft’s.
The two paths that matter for most cloud buyers are VM-level TEEs and process-level enclaves.
What “in use” actually means
Disk encryption and TLS are now default in most cloud estates. They do not stop a hypervisor, a cloud operator, or a compromised guest kernel from reading the same data once it is loaded for processing. Confidential computing narrows who can see that plaintext while it is in use; it does not take the chip vendor, the attestation service, or (in the common VM-level design) the guest operating system out of the picture, and buyers should price it that way.
The nearest confusion for a CISO is “we already encrypt everything.” You encrypt two of three states. The third is the one the application lives in. The three-state model is a useful way to understand the problem, not an exhaustive taxonomy of data protection.
A concrete path: a payments service keeps card-holder fields in a cloud KMS until a confidential VM presents valid attestation. The VM decrypts, scores fraud, writes an encrypted result, and keeps PAN out of host-readable memory, assuming the platform’s protections hold and the workload is correctly configured. The guest OS still sees the PAN. So do the application and anyone who compromised that guest. The TEE moved the trust boundary. It did not delete it.
Side channels, CPU bugs, and attestation PKI failures sit outside the brochure. A TEE is as strong as the measurements you actually verify and the firmware you actually trust.
Memory encryption, then a quote you can check
Vendors will say a confidential VM means the cloud operator cannot read your data. Fair, inside a stated threat model: host OS, hypervisor, and many operator debug paths are supposed to see encrypted RAM. That is real, and it is why regulated buyers ask for these SKUs. It does not follow that you have removed the operator. You still depend on the operator to offer the SKU, to run the attestation service, to patch the host, and not to ship a TEE that measures the wrong thing. You still depend on AMD or Intel. On VM-level TEEs you still depend on the guest kernel. Price the residual, not the slogan.
Who attests, and what happens if attestation fails? A good answer is a key-release rule: no valid quote, no plaintext, enforced by a service whose credentials are separated from those of the workload. Self-attestation that logs a warning and continues is theatre. Check whether your CI/CD, KMS, and data plane refuse work on a failed quote, and whether you can pin expected measurements when the provider rotates firmware.
What remains speculative is the claim that cryptography will make the TEE unnecessary, or that a TEE makes the operator irrelevant. Fully homomorphic encryption (FHE) can support computation on ciphertext without decrypting the underlying data on the server. Hardware TEEs, by contrast, decrypt data inside a protected environment. Those are different bets.
The hardware split is VM memory encryption versus enclave isolation. AMD SEV-SNP and Intel TDX both aim to protect a guest from the host; they differ in CPU lineage and in how nested paging, memory encryption, and integrity protections are implemented. AWS’s Nitro line is a third design: a purpose-built virtualization system and, for Enclaves, an isolated environment with no persistent storage and no interactive access. Nitro Enclaves use their own attestation mechanism; NitroTPM provides a separate virtual TPM capability for measured boot and related platform functions.
The Confidential Computing Consortium, a Linux Foundation project, defines confidential computing as the protection of data in use by performing computation in a hardware-based, attested TEE. A TEE, in the Consortium’s technical analysis, is an environment that provides some assurance of data confidentiality, data integrity, and (in the usual reading) code integrity while work is running. Unauthorized entities should not be able to view or alter protected data inside the TEE.
What is inside the trusted computing base, in writing? A good answer names CPU generation, firmware, guest OS (or its absence), hypervisor, attestation service, and key-release policy. “Confidential VM” is not an answer. VM-level SEV-SNP and TDX typically include the guest OS; a process-level enclave can leave it outside the protected boundary. If your threat is a curious hypervisor, VM TEEs help. If your threat is your own application stack, they do not. Check the provider’s threat model document against the attack you actually fear, not against a slide titled zero trust.
Does this workload still decrypt, and is that acceptable? If the answer is yes, you are buying a TEE, and you should ask about GPU memory, crash dumps, live migration, and admin consoles that might still touch plaintext. If the answer is no, you are in FHE or secure multi-party computation territory, which is a different product with different latency and operational trade-offs. Mixing the two in a procurement sentence is how teams buy a confidential VM and tell the board they “never decrypt in the cloud.”
Questions that separate a SKU from a control
The signal that would overturn it is a class of TEE break that makes measurements untrustworthy faster than buyers can update their verification policies, or an FHE stack that becomes cheap enough on ordinary CPUs that hardware isolation looks like a stopgap. That remains a speculative scenario, not an established direction of travel. Until one of those happens, treat encryption in use as a narrower window on plaintext, not as the end of plaintext.
What is happening now is productization. Confidential VMs are generally available on major clouds. Google made Confidential VMs generally available on the C3D series with AMD SEV in October 2024, and today documents Confidential VM as an option inside Dataflow, Managed Service for Apache Spark, Google Kubernetes Engine, and Vertex AI Workbench. AWS documents the Nitro System, Nitro Enclaves, and NitroTPM as its confidential computing path, and states that controls preventing operator access are part of the AWS Service Terms.
Google’s own documentation, last updated in October 2026, states the three-state model in plain terms: encryption at rest for storage, encryption in transit for movement, and encryption in use for processing. Google Cloud presents confidential computing as the last of those three, built on a hardware trusted execution environment (TEE). Microsoft’s product page for Azure confidential computing, last updated in June 2026, lists AMD SEV-SNP and Intel Trust Domain Extensions (TDX) VMs, confidential GPU VMs, confidential AKS nodes, confidential containers on Azure Container Instances, Always Encrypted with secure enclaves in Azure SQL, and confidential inferencing for the Azure OpenAI Whisper model. Microsoft Learn is describing a catalogue, not a lab.
Different chips, different clouds, different boundaries
Attestation is the part that is not a reboot. The platform produces cryptographically signed attestation evidence covering specific hardware, firmware, configuration, or workload measurements, depending on the design. A relying party checks that evidence against an explicit policy before releasing keys or data. The report proves only what its measurements and verification process actually cover; application identity and runtime integrity may require additional checks. Without that check, you have an encrypted VM you cannot distinguish from a lookalike. Google documents Google Cloud Attestation next to Confidential VM and Confidential Space for that reason. Azure documents Azure Attestation the same way.
Google Cloud wraps Confidential VM, Confidential Space, attestation, and a split-trust encryption tool, and threads Confidential VM into analytics and GKE rather than leaving it as a raw SKU. Confidential Space is aimed at parties that want to combine data without sharing it.
The pressure is operational. Training sets, prompts, embeddings, and inference logs are regulated data that must be decrypted to be useful. A disk ciphertext that becomes a RAM plaintext the moment a model scores a patient record or a payment is not a theoretical leftover. It is the working copy. Daniel Lohrmann put the same point in Security Info Watch in July 2025: data is never more vulnerable than when it is in use.
Confidential computing will keep spreading as a line item on regulated AI and payments workloads, because the alternative is to keep pretending RAM is not a copy of the database. GPU TEEs and attested inference will decide whether that line item is real for the models that now dominate risk reviews. The signal that would confirm this is not another SKU announcement. It is production systems that refuse to unseal keys without a valid quote, including after a firmware rotation, and inference paths that keep prompts out of the operator’s memory as a default rather than a preview.
It is also not FHE. The Cloud Security Alliance (August 2024) and Wikipedia’s comparison describe the central split: FHE supports computation on encrypted data without decrypting it on the server; confidential computing allows data to be decrypted inside a hardware-enforced perimeter. FHE’s cost is performance. A TEE’s cost is trust in silicon, firmware, and whoever signs the attestation.
The checkbox arrives before the trust root does
That is not disk encryption with a better name. AES on a volume protects bits on a drive. TLS protects bits on a wire. Both stop at the point where conventional application processing requires plaintext. The CPU ordinarily needs usable data representations to perform operations such as addition and multiplication. In a conventional VM, plaintext may be present in guest memory and caches, and privileged host software may be able to inspect guest memory or capture it in a snapshot. Confidential VMs are designed to restrict that access through hardware-enforced memory protection, although the guest itself still processes plaintext.
Process-level enclaves, historically exemplified by Intel SGX, isolate a protected portion of an application. AWS Nitro Enclaves take a different approach, creating an isolated environment with dedicated resources and restricted communication with its parent EC2 instance. Both aim to reduce exposure, but they differ in their isolation model and application requirements. The cost is engineering. You split the app, you lose easy debugging, and you live with a smaller, fussier runtime. Nitro Enclaves isolate an enclave environment from its parent instance; they are not a drop-in for every container.
