Your database is encrypted. Your connections are TLS. Your backups are encrypted. Every box on the compliance questionnaire is ticked.
And then the CPU decrypts everything to do any actual work with it, which is most of the time, and in that moment the data sits in memory in plain text where anyone with sufficient access to the host can read it.
The third state nobody encrypted
Data exists in three states, and the industry spent twenty years thoroughly solving two of them.
At rest — on disk — is solved. In transit — over the network — is solved. In use — loaded into memory while a program operates on it — has always been the exception, because computation on encrypted data was not practical.
For most workloads that gap is acceptable. You trust your cloud provider, their staff, and their hypervisor, and that trust is reasonable given how much they invest in deserving it.
For some workloads it is not acceptable, and increasingly the question is not whether you trust the provider but whether you can prove the provider could not have seen the data. Those are different claims, and only one of them satisfies a regulator.
What a trusted execution environment actually does
Confidential computing closes the gap in hardware. Modern server processors can create an encrypted region of memory — an enclave — where data is decrypted only inside the CPU itself.
The practical consequence: anything outside that boundary sees ciphertext. The operating system sees ciphertext. The hypervisor sees ciphertext. A cloud engineer with root on the physical host sees ciphertext. Someone who physically removes the memory module and reads it directly gets ciphertext.
The second half is attestation, and it is the part that matters more for compliance. Before sending data, you can ask the hardware to prove — cryptographically, signed by the manufacturer — exactly what code is running inside the enclave. If someone swapped the binary, the attestation fails and you never send the data.
That is the genuinely new capability. Not just encrypted memory, but verifiable proof of what is processing your data before it arrives.
Fig. — The trust boundary moves from the provider's staff to the silicon.
Where it earns its cost
Multi-party computation without mutual trust. Several banks want to run fraud detection across their combined transaction data. None will hand their data to the others or to a third party. An enclave lets all of them contribute encrypted inputs to a computation whose code they have all verified, and receive only the result. This was previously a contract negotiation that never concluded.
Regulated workloads in public cloud. Health and financial data that legal has refused to let leave the building often becomes acceptable when the provider is cryptographically excluded from access. That reframes a cloud migration that had been blocked for years.
Protecting the model rather than the data. If you have spent heavily training a proprietary model and need to deploy it somewhere you do not control, an enclave lets it run without exposing the weights to whoever owns the machine.
Key management. Any operation involving private keys benefits, which is why this technology quietly underpins a great deal of digital asset custody.
The costs and the caveats
Performance is no longer the objection it was. Memory encryption carries overhead — commonly a modest single-digit percentage for typical workloads, occasionally worse for memory-intensive ones — and the current generation is good enough that this rarely decides anything.
Complexity is the real cost. Attestation has to be integrated into your deployment pipeline, which means your build becomes part of your security boundary. Change the code and the measurement changes, so release processes need to account for it. Debugging is harder by design, because the whole point is that you cannot inspect memory.
Portability is imperfect. The major cloud providers all offer confidential computing, and the underlying hardware implementations differ enough that moving between them is not a configuration change.
And the honest caveat: enclaves protect against the infrastructure, not against your own code. An application with a vulnerability inside the enclave leaks data that was perfectly encrypted right up to the moment your bug handed it over. This raises the floor on infrastructure risk. It does nothing for application security.
What it looks like to adopt
The adoption path splits by how much control you want, and the two ends are very different projects.
The managed route is a confidential VM: your workload runs in a virtual machine whose memory is encrypted, and you change almost nothing about the application. All three major providers offer this, migration is often close to a configuration change, and you get the memory-encryption benefit immediately. What you get less of is fine-grained attestation — you are attesting a whole machine image rather than a specific piece of code, which satisfies some requirements and not others.
The deeper route is an application enclave: you partition your code so only the sensitive part runs inside the protected region. That gives you a small, precisely attestable trusted computing base, which is what a demanding auditor wants to see. It also means restructuring your application around a boundary, deciding what crosses it, and accepting that everything inside is harder to observe and debug.
Most teams should start with the confidential VM. It answers the common version of the question — can your provider read our data — with a defensible no, at a fraction of the effort. Move to enclaves only when someone specific has asked for something the VM answer does not cover.
Do you need this
Most teams do not, and vendors selling it will not lead with that.
The test is whether you can name a specific adversary that this — and only this — defends against. "A malicious or compromised administrator at our cloud provider" is a legitimate answer. "Better security generally" is not, and will produce a lot of expense for no measurable reduction in risk.
The clearer signal is regulatory. If a regulator, an auditor, or a large customer's security review has specifically asked how you protect data in use, you have a concrete requirement and this is the answer to it. That question is being asked more often each year, particularly in finance and healthcare, which is why the technology is moving from research into procurement documents.
If nobody has asked, spend the effort on access control and application security first. Those defend against the attacks that actually happen to companies your size, and they are considerably cheaper.
