What Is Confidential Computing? Protect Data in Use When You Don’t Own the Node

Confidential computing protects data in use: the plaintext sitting in CPU memory while a workload runs. It places that work in a CPU trusted execution environment (TEE), so the operating system, hypervisor, and cloud provider can’t read it. The CPU enforces the isolation.

Encryption at rest and TLS on the pipe already cover two of the three states. The third is the running process — on a node you don’t own. In this article, we’ll look at how confidential computing helps with that job: land the service, get a yes from change-control, and keep operating it.

How confidential computing helps

Confidential computing helps by isolating the running process in a CPU trusted execution environment, so the host, hypervisor, and provider can’t read plaintext in memory.

The job is to get a customer-data API onto a hyperscaler this quarter and keep it running. Disk encryption is already on. TLS is on the pipe. Change-control still won’t sign until someone answers who can read memory while that API is up. Disk and TLS don’t finish that job. Confidential computing does: the API runs, provider staff don’t get the plaintext, and the service stays in your hands.

Gartner (20 Oct 2025) put that 2029 share above 75% for operations on untrusted infrastructure, secured in-use. For this job, wrap that API, attest it, and change-control has an answer.

Confidential computing challenges

A confidential computing request goes nowhere when rest and transit are treated as the whole story, when the hardware isn’t yours, or when secrets go into a TEE that nobody attested.

Rest and transit aren’t the third state

Confidential computing exists because encryption at rest and in transit leave a gap: data in use. Disk encryption covers data at rest. TLS covers data in transit. Encryption at rest and in transit is that pair.

The third state is data in use. The process has already decrypted the bytes, and they sit in CPU memory as plaintext. That gap is what people mean by encryption in use, and without a TEE it usually isn’t encrypted at all. Anonymization and transforms help a little. They don’t encrypt that moment.

On-prem, that gap was easier to live with. The organization owned the servers, the room, and who could walk in. Shared cloud is different. The node is someone else’s metal. Another tenant may share it. Provider staff who run the fleet can see memory unless the CPU stops them. Zero Trust is the posture: don’t trust the host because of where it sits. The TEE is how you measure that.

Isolation without attestation isn’t enough

Confidential computing without attestation isn’t enough to land that API. You still have to prove the TEE is genuine and running the binary you meant to run. Attestation is that hardware-rooted proof. Sending work into a TEE doesn’t help if you skip it.

During boot, each stage hashes the following stage, then loads it: firmware, bootloader, kernel, then the app. Those measurements land in PCRs (Platform Configuration Registers) on the CPU. If a hash doesn’t match, the chain breaks and the workload doesn’t start.

For remote attestation, the TEE sends a signed report to a verifier. The verifier checks it against the manufacturer’s root, through Intel’s Attestation Service or AMD’s Key Distribution Service. If it passes, secrets are released only to that TEE instance. Staff with full infrastructure access still can’t read the plaintext. Trust sits on the manufacturer’s certificate chain rather than the provider’s operations team.

PKI is how that chain is checked. Verify the attestation quote. Keep PEMs and roots out of the repo.

Confidential computing isn’t a replacement for the rest of the stack

Confidential computing is the control for data in use. It is not a substitute for disk encryption, TLS, IAM, secure development, or network controls. Change-control will still ask about those. For this API landing, the TEE covers memory on a node you don’t own — not the whole program.

Confidential computing blocks hypervisor-level reads of memory. Cold-boot attacks fail because extracted DRAM (dynamic random-access memory) shows ciphertext. A privileged operating system inspecting memory doesn’t see the plaintext either.

Confidential computing doesn’t fix bugs inside the enclave. It doesn’t protect data on the way into the TEE, or after the result leaves. It doesn’t stop side-channel or cache-timing attacks that infer data from shared CPU resources. Treat it as one layer. IAM, secure development, network controls, and the encryption you already run still have to show up.

Because the host can’t inspect memory, telemetry has to come from inside the workload.

How confidential computing works

Confidential computing works by running the process inside a CPU trusted execution environment. The CPU generates the memory-encryption keys and keeps them; the host OS never sees those keys.

Let’s look at the three processor families that implement confidential computing in hardware. They aren’t interchangeable.

On every family, the CPU generates the memory-encryption keys and keeps them. Software never sees those keys, including the host OS. APIs, attestation flows, and toolchains differ, so map the stack before you choose a family. Gartner flags that mix. They also mention third-party orchestration for heterogeneous environments.

Attest, then release the key

Let’s look at how the secret gets released. Don’t bake a long-lived secret into the image. Keep it in a KMS (key management system) or HSM (hardware security module) and release it only after the attestation report checks out.

That’s key management: the TEE has to attest before the secret is released. Keys shouldn’t live in application code. Keep TLS on the pipe and disk encryption at rest. Don’t hardcode tokens, private keys, or attestation roots in the workload.

How to get started with confidential computing

Get started with confidential computing by wrapping that customer-data API in one enclave, validating attestation end to end, then expanding.

That customer-data API is the first landing.

Those four rows belong in change-control before a wider rollout.

Next step: Key Management in Cryptography. Release secrets only after the TEE attests. Don’t bake a long-lived key into the image.

Confidential computing vs. homomorphic encryption

Homomorphic encryption, secure multi-party computation, and federated learning also try to keep plaintext away from an untrusted party. They are different controls. One doesn’t replace another.

Use them for different jobs. Federated learning can sit next to confidential computing. Homomorphic encryption is the path when even a shared enclave is unacceptable, if the slowdown is tolerable.

Confidential computing for AI

If that customer-data API is inference, wrap inference — that’s what you can land in production now. Ingest and preprocess still run in plaintext. Training repeats full-dataset epochs. Inference holds the model weights in memory alongside the user’s prompt.

The major hyperscalers already run inference inside a TEE. Confidential training is available on NVIDIA H100-class GPUs, but GPU TEE coverage still varies by cloud. Don’t wait on training to land the API.

When the result leaves the TEE, it’s unprotected again. Prompt injection runs inside the enclave, so confidential computing doesn’t cover it.

FAQs about Confidential Computing