What is confidential computing?

Confidential computing protects data while it is being processed — not just when it is stored or transmitted. It uses hardware-based isolation called Trusted Execution Environments (TEEs) to create secure enclaves where code and data are shielded from everything else on the machine, including the operating system, the hypervisor, and the cloud provider's administrators.

This solves the last major gap in data security. Encryption already protects data at rest (on disk) and data in transit (over the network). But until confidential computing, data had to be decrypted to be processed — creating a window where it was exposed in plain text in memory. Anyone with privileged access to the machine could read it.

Confidential computing closes that window.

Why does it matter?

Every time you run a workload in the cloud, you trust the cloud provider not to inspect your data while it's being processed. For most applications, that trust is acceptable. But for certain workloads, it's not:

• Healthcare: A hospital running AI diagnostics on patient records needs a guarantee that the cloud provider's engineers cannot access protected health information (PHI) during processing.
• Financial services: A bank running risk models on transaction data needs to prove to regulators that no unauthorized party accessed the data — including the infrastructure operator.
• AI and machine learning: A company running inference on a proprietary model doesn't want the infrastructure provider to copy the model weights. A data owner providing training data doesn't want the model operator to see the raw inputs.
• Multi-party computation: Two companies want to run a joint analysis on their combined datasets without either party seeing the other's raw data.

In all of these cases, encryption at rest and in transit isn't enough. You need encryption during processing. That's what confidential computing provides.

How it works: Trusted Execution Environments

The core technology behind confidential computing is the Trusted Execution Environment (TEE) — a hardware-isolated region of a processor where code and data are protected from everything outside it.

A TEE works at the chip level. The CPU itself enforces the isolation. Software running outside the TEE — including the operating system, hypervisor, firmware, and other applications — cannot read or modify the data inside the TEE. Even a malicious administrator with root access to the machine cannot see what's happening inside the enclave.

There are two main approaches to TEE implementation:

Process-level TEEs (Intel SGX)

Intel Software Guard Extensions (SGX) pioneered the process-level approach. SGX creates encrypted memory regions called "enclaves" within a user-space application. Only the code running inside the enclave can access the enclave's memory.

Strengths:

• Smallest possible attack surface — the operating system and hypervisor are excluded from the Trusted Computing Base (TCB)
• Strong isolation guarantees verified through remote attestation
• Well-suited for workloads where you need to protect specific functions or data processing steps

Trade-offs:

• Developers must partition their code into trusted (enclave) and untrusted (host) components
• Limited enclave memory (historically 128MB–256MB, improved in newer generations)
• Higher development complexity compared to VM-level approaches

VM-level TEEs (Intel TDX, AMD SEV-SNP)

To reduce the development friction of SGX, chip manufacturers introduced Confidential Virtual Machines (CVMs). Instead of protecting a single process, these technologies encrypt an entire virtual machine.

Intel TDX (Trust Domain Extensions) creates isolated "Trust Domains" — full VMs with their own encrypted memory space. The hypervisor can manage the VM's lifecycle but cannot read its memory or registers.

AMD SEV-SNP (Secure Encrypted Virtualization — Secure Nested Paging) encrypts VM memory with unique per-VM keys and adds integrity protection to prevent memory tampering by the hypervisor.

ARM CCA (Confidential Compute Architecture) introduces "Realms" for ARMv9 processors, targeting cloud-scale workloads on ARM hardware. As of 2026, CCA is not yet available in production hardware.

Strengths:

• "Lift and shift" — run existing applications inside a confidential VM without modifying code
• Larger memory capacity than SGX enclaves
• Lower performance overhead (typically 5–15% vs. potentially higher for SGX)

Trade-offs:

• Larger Trusted Computing Base (includes the guest OS inside the VM)
• Less granular isolation than process-level TEEs

Remote attestation: proving the enclave is real

Hardware isolation is only half the story. The other half is attestation — a cryptographic mechanism that lets you verify, before sending any data, that:

1. The code running inside the TEE is exactly the code you expect
2. The TEE is running on genuine, certified hardware
3. The TEE has not been tampered with

Without attestation, you'd have to take someone's word that the enclave is real. Attestation replaces trust with cryptographic proof.

Each TEE technology has its own attestation mechanism:

• Intel SGX DCAP (Data Center Attestation Primitives) — the enclave generates a "quote" signed by the CPU's hardware keys. A remote verifier checks this quote against Intel's attestation service to confirm authenticity.
• Intel TDX — uses a similar quote-based mechanism but at the VM level.
• AMD SEV-SNP — the AMD Secure Processor generates attestation reports signed by AMD's key hierarchy.

Where confidential computing runs today

Confidential computing is available from every major cloud provider:

These are all centralized offerings — you run your workload on the provider's hardware and trust their implementation.

Decentralized confidential computing

A different approach is to run confidential workloads on decentralized networks — community-operated hardware instead of a single cloud provider's data centers.

This is what projects like Ethernity Cloud do. Instead of trusting AWS or Azure, your code runs inside Intel SGX enclaves on 5,000+ independently operated nodes. The network uses a triple-enclave architecture where three separate enclaves handle validation, execution, and attestation — so no single point can compromise your workload. Every execution produces a cryptographic Proof of eXecution written on-chain, creating a permanent, auditable record that the computation ran correctly on attested hardware.

The benefit of decentralized confidential computing is that you remove the single point of trust entirely. No single company owns the hardware. No single administrator can access your data. And every execution is independently verifiable on a public blockchain.

The three pillars of data protection

Confidential computing completes the triangle. With all three pillars in place, data is encrypted at every stage of its lifecycle.

What's next

The confidential computing market is projected to reach $15–54 billion by 2030, growing at 36%+ CAGR. The drivers are clear:

1. AI regulation — As AI models process increasingly sensitive data, regulators are demanding provable data protection during processing, not just storage.
2. Multi-cloud and hybrid — Organizations running workloads across multiple clouds need hardware-level guarantees that don't depend on trusting any single provider.
3. Confidential AI — Running inference on encrypted data, where neither the model owner nor the data owner can see each other's assets, is one of the fastest-growing use cases.
4. GPU TEEs — NVIDIA's H100, H200, and B200 GPUs now support confidential computing, enabling AI training and inference inside hardware-secured enclaves.

Confidential computing isn't a future technology. It's shipping today, on hardware you can use right now, from both centralized cloud providers and decentralized networks like Ethernity Cloud.