Encryption at rest protects data on disk. TLS protects data on the wire. Neither protects data while a program is actually computing on it in RAM — at that point, it typically sits in plaintext, visible to the host operating system, the hypervisor, and anyone with sufficiently privileged access to the physical machine, including the cloud provider running it. Confidential computing closes that specific gap using hardware-enforced trusted execution environments (TEEs): isolated regions of a CPU where code and data stay encrypted and inaccessible to everything outside the enclave, including a compromised or merely curious host. It’s no longer a research curiosity — Intel TDX, AMD SEV-SNP, and AWS Nitro Enclaves are all shipping in production cloud infrastructure today, and real applications like Signal’s backend already depend on it.
At a Glance
| Attribute | Detail |
|---|---|
| What it protects | Data in use — while it’s being actively processed in memory, not just stored or transmitted |
| Core mechanism | A trusted execution environment (TEE): hardware-enforced isolation that hides a workload’s memory and execution even from the hypervisor and host OS |
| How trust is verified | Attestation — a cryptographic proof that specific, unmodified code is running inside a genuine, correctly-configured TEE before you hand it anything sensitive |
| Standards body | Confidential Computing Consortium (CCC), an open community under the Linux Foundation with 40+ member organizations |
| Major implementations | Intel SGX (process-level) and TDX (VM-level); AMD SEV-SNP (VM-level); AWS Nitro Enclaves (isolated companion VM); ARM TrustZone / CCA |
| Known production use | Signal’s backend has run on confidential-computing-backed secure enclaves since 2021; Signal’s earlier private contact discovery service specifically used Intel SGX |
Short Verdict
Confidential computing is the right tool when your threat model specifically includes the infrastructure operator — a cloud provider, a hypervisor bug, or a malicious insider with root access to the host — and you need a technical guarantee, not just a contractual one, that they can’t read the data your workload is processing. It is the wrong tool to reach for as a general security upgrade: enclaves add real performance and engineering overhead, attestation infrastructure has to be built and verified correctly to mean anything, and the space has genuinely different maturity levels depending on whether you need process-level isolation (SGX, with real production history but also real vulnerabilities) or can accept the coarser, easier-to-adopt VM-level model (TDX, SEV-SNP, Nitro Enclaves) that most 2026 cloud confidential-computing products actually ship.
The Problem: Data in Use Is the Gap Encryption Doesn’t Cover
Security teams have had mature answers for data at rest (disk and database encryption) and data in transit (TLS) for decades. Data in use — the state a value is in from the moment it’s decrypted into memory to process it until it’s either discarded or re-encrypted — has historically had no equivalent default protection. In a public cloud, that gap is specifically the host’s hypervisor, kernel, and anyone with administrative access to the physical machine: all of them can, in principle, read a VM’s memory directly, regardless of how well the data was encrypted before it arrived or after it leaves. The Confidential Computing Consortium frames the category’s purpose plainly: “Confidential Computing protects data while it’s in use,” closing the one state storage and network encryption leave open.
How Trusted Execution Environments Actually Isolate a Workload
A TEE is a hardware-enforced enclave: a CPU feature that carves out an isolated execution context whose memory is encrypted and access-controlled by the processor itself, not by software running alongside it. The Confidential Computing Consortium describes this plainly — hardware-enforced enclaves create isolated execution contexts that keep running workloads hidden even from the hypervisor and cloud provider. Implementations differ meaningfully in what, exactly, gets isolated:
- Intel SGX works at the process level: a single application creates an enclave inside its own address space, and the operating system, hypervisor, and every other process — even other enclaves — are explicitly untrusted. This gives the tightest isolation boundary, but it requires rewriting or specially porting an application to the SGX programming model, and comes with real memory-size limits that make lifting legacy software over painful.
- Intel TDX moves the boundary up to an entire virtual machine, running in a new processor mode (SEAM) that reuses some SGX-derived attestation machinery, but trusts the guest OS and its configuration rather than isolating individual processes within it. The trade: far fewer performance and memory constraints, and legacy applications can run largely unmodified inside a “trust domain” instead of being rewritten against a special enclave API.
- AMD SEV-SNP takes the same VM-level approach as TDX on AMD hardware: encrypting a virtual machine’s memory and adding integrity protection (the “SNP,” Secure Nested Paging, addition) so the hypervisor can’t tamper with guest memory contents or page mappings without detection, not just read them.
- AWS Nitro Enclaves takes a structurally different approach: rather than a CPU-level encrypted-memory mode, it carves an isolated, hardened companion virtual machine out of an EC2 instance using the Nitro Hypervisor. AWS’s own documentation is specific about the isolation: the enclave has no persistent storage, no interactive shell access (you cannot SSH in), and no external network connectivity — it can only talk to its parent instance over a local secure socket — and the parent instance itself, including root or admin users on it, has no access to the enclave’s memory or data.
Every one of these mechanisms depends on attestation to be useful in practice: a cryptographic proof, generated by the hardware itself, that specific code — unmodified, with a verifiable measurement/hash — is actually running inside a genuine, correctly-configured TEE. AWS documents this concretely for Nitro Enclaves: AWS Key Management Service has built-in attestation support, so you can write a key policy that only releases a cryptographic key to an enclave whose measurement matches an expected, approved value — meaning a tampered or substituted workload simply can’t get the key, rather than relying on anyone noticing after the fact.
Real-World Use: Signal’s Backend and Private Contact Discovery
Signal is one of the most concrete, publicly documented production users of confidential computing. According to Microsoft’s own customer case study, Signal has hosted its back-end services in secure enclaves on Azure confidential computing since scaling up in 2021, citing the platform’s availability and reliability. Separately, and earlier, Signal’s own engineering blog detailed a specific use of Intel SGX for private contact discovery — the problem of letting Signal’s server tell a user which of their phone contacts also use Signal, without the server itself ever learning the user’s full contact list. Signal’s 2017 technical preview post describes running that matching logic inside an SGX enclave specifically so the server operator (Signal itself) couldn’t see the contact data it was processing, only the enclave could — a direct, concrete example of a TEE being used to make a service provider’s own infrastructure unable to read its users’ sensitive data, not just unwilling to.
Comparing the Major TEE Implementations
| Implementation | Isolation granularity | Programming model impact | Maturity note |
|---|---|---|---|
| Intel SGX | Process-level (single application enclave) | Requires porting to a special enclave programming model; real memory limits | Longest production history (Signal’s 2017 contact discovery); also the most documented history of discovered vulnerabilities; Intel has deprecated it on consumer-platform CPUs |
| Intel TDX | VM-level (whole “trust domain”) | Minimal — legacy apps largely run unmodified inside the VM | Newer; reached smaller cloud providers starting around 2024; fewer long-running public case studies than SGX |
| AMD SEV-SNP | VM-level, with added integrity protection against hypervisor tampering | Minimal — standard VM workloads, no special enclave API | Documented in AMD’s own technical papers as an explicit strengthening of earlier SEV generations against active, not just passive, attacks |
| AWS Nitro Enclaves | Isolated companion VM carved from an EC2 instance | Low — runs as a separate, constrained Linux VM communicating over a local socket | No extra charge beyond normal EC2/KMS usage; tightly integrated with AWS KMS attestation-based key policies |
Trade-offs
- Process-level isolation (SGX) gives the strongest guarantee — even a compromised OS can’t read the enclave — but at real engineering cost: a special programming model, tight memory constraints, and a track record that includes a meaningful number of discovered side-channel vulnerabilities over the technology’s lifetime.
- VM-level isolation (TDX, SEV-SNP, Nitro Enclaves) is dramatically easier to adopt — often requiring little or no application rewrite — but trusts a larger piece of software (the whole guest OS) than a process-level enclave does, and that larger trusted surface is the direct cost of the easier adoption path.
- Attestation is not optional scaffolding — it’s the mechanism that makes any of this trustworthy to a third party. A TEE whose attestation you don’t actually verify (or whose key release isn’t gated on a specific, checked measurement) provides isolation from some threats but no cryptographic proof to anyone else that the isolation is real.
- None of these guarantees survive every attack class — side-channel attacks exploiting shared hardware resources (caches, speculative execution) have repeatedly targeted SGX specifically, which is part of why the industry’s center of gravity has shifted toward the coarser but simpler VM-level model for most new deployments.
Bottom Line
Confidential computing turns “trust us” into “verify this” for the one part of the data lifecycle — active computation — that encryption at rest and in transit were never designed to cover. AWS Nitro Enclaves, Intel TDX, and AMD SEV-SNP have made this practical at the VM level with comparatively little application rewriting, which is why they’re the default entry point for most 2026 cloud confidential-computing offerings; Intel SGX remains the tightest isolation model and has real production history (Signal’s own contact-discovery design among the most concrete public examples), but at a real adoption and vulnerability-surface cost that’s pushed much of the industry toward the coarser VM-level alternatives instead. None of this matters without attestation actually being verified by whoever’s trusting it — the hardware isolation is necessary, but the cryptographic proof that the right code is running inside it is what makes the guarantee meaningful to anyone outside the enclave itself.
FAQ
Is confidential computing the same thing as encryption?
No. Encryption at rest and in transit protect stored and transmitted data; confidential computing specifically protects data while it’s being actively computed on, in memory, using hardware-enforced isolation rather than cryptographic transformation of the data itself at that stage.
Can a cloud provider read data inside a TEE on its own infrastructure?
The entire design goal is no — AWS’s own Nitro Enclaves documentation states explicitly that the parent instance, including its root or admin users, has no access to an enclave’s memory or data. The guarantee is only as strong as the specific implementation’s track record, though, which is why attestation and ongoing vulnerability disclosure matter.
What’s the real difference between Intel SGX and Intel TDX?
SGX isolates at the level of a single process/application inside a specialized enclave programming model with tighter memory limits; TDX isolates an entire virtual machine with far fewer constraints, trusting the guest OS rather than isolating individual processes within it — trading some isolation granularity for dramatically easier adoption of existing software.
Does using a TEE protect against every attack?
No. Side-channel attacks exploiting shared CPU resources like caches or speculative execution have repeatedly been demonstrated against SGX specifically, and the Confidential Computing Consortium itself notes that causality and isolation guarantees generally assume non-Byzantine, non-adversarial hardware behavior — a TEE narrows the attack surface significantly, it doesn’t eliminate every possible attack vector.
Sources
- Confidential Computing Consortium — confidentialcomputing.io
- AWS Documentation — What Is AWS Nitro Enclaves?
- Canarybit — Intel SGX vs. TDX: What Is the Difference?
- AMD — SEV-SNP: Strengthening VM Isolation with Integrity Protection and More
- Signal — Technology Preview: Private Contact Discovery for Signal
- Microsoft Customer Story — Signal on Azure Confidential Computing
Discover more from Software Online Review
Subscribe to get the latest posts sent to your email.
