"Encrypted in use," except where it isn't
Data is encrypted at rest, in transit, and in use. Ciphertext on disk and ciphertext on the wire has two decades of audit practice behind them. "In use" reads as if it were the same kind of claim. Is it?
What did the consortium decide?
The Confidential Computing Consortium, the Linux Foundation body that hardware vendors and cloud providers formed in 2019 to define the field, defines confidential computing as the protection of data in use through computation inside a hardware-based, attested trusted execution environment. The word "encryption" does not appear in the definition. The consortium's governance record explains that encryption is a mechanism rather than the property being sought. A system can protect data in use through access control without encrypting anything, and some of the trusted execution environments the consortium wanted in scope do exactly that. The technical advisory committee noted that definitions built on the phrase "encrypted data processed in memory" were problematic for the same reason, which made it cleaner to draw its scope on promoting hardware-based, attested TEEs, with no commitment to encryption as the means.
Why do we care? Well, Microsoft's Azure documentation quotes the consortium's definition accurately in its overview, while an adjacent Azure training module markets the same capability as encryption of data while in use, then concedes that although the data is in the clear during processing, it is protected by the enclave rather than by ciphertext. The two pages are using one phrase for two different claims. Further down the explainer food chain, it is now easy to find introductions to confidential computing that list TFHE and Microsoft SEAL, libraries for fully homomorphic encryption, as the encryption algorithms that trusted execution environments run on. But those are different technologies with close to opposite performance profiles and threat models.
"Encrypted in use" currently describes different plaintext boundaries and unrelated guarantees. The differences matter because they decide what an operator can see, what a physical attacker can reach, and what perhaps nobody in the system is checking at all.
What's in plaintext?
Take the deployment that the phrase is most often selling right now: a confidential virtual machine on an AMD or Intel CPU, attached to an Nvidia H100 in confidential computing mode, running inference on a model somebody considers proprietary. Nvidia's engineers published a detailed account of how the H100's confidential mode was built, and it lets you follow a byte of model weight through the machine and name the protection it enjoys at each stop.
Start in CPU memory. The confidential VM technologies underneath, AMD's SEV-SNP or Intel's TDX, encrypt the virtual machine's DRAM, with keys the hypervisor never holds. This is the strongest literal reading of "encrypted in use" on the rack, but even here it has an asterisk: the encryption boundary is the CPU package. Inside the package, in registers and caches, the data is plaintext. Encrypting at the memory interface and computing in the clear inside the silicon is the founding compromise of the whole category.
Now move the byte to the GPU. It crosses PCIe, and here the H100's DMA engines encrypt and sign data into staging areas in shared memory, called bounce buffers, and the payload is decrypted and authenticated only after it arrives inside the GPU's protected region. This hop is also where the performance bill arrives.
The byte now sits in the GPU's high-bandwidth memory, and the protection changes character. The H100 partitions its device memory into a compute protected region, and when the GPU boots in confidential mode it blocks ingress and egress to that region. Inside the protected region, the GPU processes data at full speed in HBM, and the bits in those memory cells are plaintext. Nothing is encrypting them. What stands between an adversary and the model weights is access control enforced in hardware.
HBM is stacked silicon sitting on the same package as the die, not a module in a socket, so the physical interposition attacks that motivated CPU memory encryption have a much higher bar against it. Encrypting memory at H100 bandwidths would have taxed exactly the throughput the chip exists to deliver, and Nvidia's team has been candid that confidential features entered late in the H100's hardware cycle. Access control on on-package memory is a defensible answer to that constraint set. It is also confidentiality without encryption.
The ladder has two more rungs. On Hopper, NVLink carries traffic between GPUs without protection, so multi-GPU confidential jobs route secured communication through the host. And the map is redrawn generation by generation, with Blackwell-era parts reported to add both HBM and NVLink encryption. If that holds, the summary is that "encrypted in use" has a hardware version number.
Count the stops on one rack: CPU DRAM encrypted, CPU package plaintext, PCIe encrypted, HBM plaintext behind a firewall, and NVLink unprotected.
What does FHE mean by the same phrase?
Fully homomorphic encryption is the technology for which the phrase would be literally true. An FHE system computes on ciphertext directly. The server holding the computation never decrypts, holds no key that could decrypt, and the plaintext boundary is wherever the client keeps the secret key, which is to say, off the machine. This is why FHE vendors describe their systems as end-to-end encrypted and why the phrase "encrypted in use" migrated into general marketing from the thing FHE actually does.
But the thing is, FHE ciphertexts are malleable, since malleability is what makes computation on them possible. Nothing inside FHE proves that the server computed the function the client asked for. A malicious operator cannot read the data, and can still return the encryption of the wrong answer, and the client cannot tell from the ciphertext alone. The research literature on verifiable FHE shows that trusted execution environments have seen their confidentiality guarantees repeatedly broken by side-channel work while their attestation-backed integrity has held up well, and FHE is the mirror image, confidentiality guaranteed by mathematics.
The two camps have already admitted this to each other, in the way engineers like: by building the combination. A line of research runs FHE workloads inside TEEs, using the enclave's attestation to establish that the correct FHE computation ran while the ciphertext supplies the confidentiality. The combination shows how cleanly the two guarantees separate. Because an FHE application never touches plaintext, an enclave running one has nothing for side channels to leak, and a client does not even need to verify the enclave's attestation before sending input, since the input is never decrypted inside.
Read "encrypted in use" as a claim about confidentiality, where the plaintext lives, and FHE delivers the strongest version while TEEs deliver a hardware-specific map of boundaries. Read it as a claim about integrity, whether the computation performed was the one specified, and attestation is the strongest deployed answer.
Which property does each mechanism get you?
Lay two properties out as axes. One axis is confidentiality of data, and it is a boundary question: encrypted at the memory interface, access-controlled on package, ciphertext everywhere. The other axis is integrity of computation: attestation that specific measured code ran, a cryptographic proof that it ran correctly, re-execution by someone you trust, or nothing.
Walk three buyers through it. The first fears the operator, the cloud provider or its insiders reading data during processing. The CPU confidential VM answers this well, HBM's firewall answers it adequately, and FHE answers it absolutely. The second buyer fears physical access, the seized server, the interposed memory bus, the hostile datacenter. Now the boundaries matter enormously: encrypted CPU DRAM defends against the interposer, on-package HBM raises the physical bar without encryption, and the evaluation is about which attacks each boundary actually prices out. The third buyer fears a computation that was tampered with. This buyer has been reading the wrong axis entirely. Their question is answered by attestation and verification, and an FHE deployment without a verifiability layer gives them, strictly speaking, less than a TEE does.
What about cost? Where the encryption is, the overhead is. Nvidia characterizes confidential mode's compute penalty as small, because inside the protected region the GPU computes on plaintext at full speed, which is the whole design. Benchmarking reports much larger figures for IO-heavy inference workloads, because those workloads live on the PCIe hop, where the bounce buffers are, where the actual cryptography is. Both characterizations can be true at once.
What to ask
On this specific deployment, where does plaintext exist, in which memory, on which interconnect, for which generation of silicon, and separately, who or what checks that the computation performed was the one specified?
The consortium's governance record shows the field's founders understood the first question before the marketing hardened, and chose their words accordingly. The hardware roadmap suggests an ironic resolution: if Blackwell and its successors extend encryption to device memory and interconnects, "encrypted in use" will drift toward being literally true on the confidentiality axis.
