Nvidia and Azure Push Confidential Computing Mainstream

Confidential computing spent a decade as a cryptography-conference curiosity — a hardware feature enterprise architects filed away as "interesting, not urgent." That changed in 2026. Multi-tenant AI inference put sensitive data and proprietary model weights on the same shared GPU clusters, and standard encryption-at-rest and encryption-in-transit stopped being enough, because the moment a model runs, both the input data and the weights sit in plaintext in memory.

The market reflects the shift: analysts put the confidential computing market at roughly $16.7 billion in 2026, up from about $12.3 billion in 2025, a growth rate north of 35% annually. Financial services account for close to half of enterprise adoption, healthcare for over a third, and around three-quarters of U.S. federal agencies now run some form of secure-enclave technology for sensitive workloads. This is no longer a niche compliance checkbox — it's becoming table stakes for anyone running AI on data they can't legally or contractually expose.

What Actually Changed

The trigger wasn't a single breach or regulation. It was the arrival of AI workloads that require two things simultaneously: the customer's sensitive data (medical records, trading positions, biometric data) and the vendor's proprietary model weights, colocated on the same hardware, owned by neither party alone. A hospital sending patient data to a third-party diagnostic model needs assurance the cloud provider and the model vendor can't see the data. The model vendor needs assurance the hospital can't extract the weights. Neither side trusts the other's infrastructure, and neither side can simply "encrypt and decrypt" its way out, because the computation itself has to happen on unencrypted data at some point — unless that point is inside hardware neither party controls.

That's the specific problem Trusted Execution Environments (TEEs) solve: isolated, hardware-encrypted memory regions where code and data are protected even from a compromised hypervisor, cloud operator, or root user. In 2026, that hardware root of trust extends past the CPU and into the GPU for the first time at scale.

The Hardware: CPUs and GPUs Both Now Do This

Four TEE architectures dominate current deployments:

Intel TDX (Trust Domain Extensions) — isolates entire VMs, used heavily on Azure and Google Cloud confidential VM instances.
AMD SEV-SNP (Secure Encrypted Virtualization–Secure Nested Paging) — the most widely deployed option across AWS, Azure, and Google Cloud, favored for lower compute-bound overhead thanks to AES-NI hardware-accelerated memory encryption.
ARM CCA (Confidential Compute Architecture) — newer, targeting mobile and edge devices where confidential inference needs to happen outside the datacenter entirely.
Nvidia Hopper confidential computing — the H100 was the first GPU with a hardware-based TEE anchored in an on-die root of trust; the H200 extends it. This is the piece that made confidential AI inference viable, because it protects data and model weights while the GPU is actively computing, not just while they sit in CPU memory.

The performance story here is better than most engineers assume. On compute-bound CPU workloads, SEV-SNP and TDX both run at roughly 1-5% overhead. On Nvidia's confidential GPU mode, independent benchmarking puts typical LLM inference at 95-99% of native throughput — for most queries, overhead stays under 5%, and it approaches zero for larger models and longer sequences, since the encryption cost is amortized over more computation per byte moved across the CPU-GPU boundary.

Who's Actually Running This in Production

All three major hyperscalers ship confidential AI infrastructure today, not as a roadmap item. Azure Confidential Computing pairs Intel TDX and AMD SEV with confidential GPU VMs built on H100s, marketed specifically at regulated-industry LLM deployment. AWS offers Nitro Enclaves alongside SEV-SNP-backed EC2 instance families. Google Cloud's Confidential Space and Confidential VMs target the same use case, positioned for multi-party data collaboration where no single party can see the others' inputs.

Concrete deployments back this up. NTT DATA and IBM built SimpliZCloud, a hybrid cloud platform for Indian financial institutions that uses confidential computing to protect data during processing, not just storage. The U.S. Department of Defense has authorized confidential-computing-backed cloud infrastructure for mission-critical operations across multiple federal departments. These aren't pilots — they're production financial and government systems where "we encrypted the database" no longer satisfies the compliance or contractual bar.

The Unsolved Problem: Attestation

Here's where the mainstream narrative gets ahead of the technology. Confidential computing's trust model depends on remote attestation — cryptographic proof that a workload really is running inside a genuine, unmodified TEE before you send it sensitive data. For a CPU-only TEE, one vendor issues that proof. For confidential AI inference, you now need attestation from the CPU vendor and the GPU vendor simultaneously, each with a separate supply chain, separate root of trust, and separate verification tooling. Security researchers call this a "composite attester" problem, and there's no single standard yet for verifying it end-to-end.

It gets worse: a Register investigation published July 4, 2026 detailed how several proposed "intra-handshake attestation" schemes — where the TEE proves itself during the TLS handshake itself — remain vulnerable to relay attacks, where a client successfully verifies a genuine, trustworthy enclave but ends up sending encrypted traffic to a different, malicious one entirely. None of the seven cryptographic approaches tested so far close that gap completely. That's not a minor implementation bug; it's a structural weakness in how trust gets established, and it means "we use confidential computing" is not by itself a complete security claim without also asking how attestation is verified and by whom.

When You Actually Need This

Confidential computing solves a specific problem: protecting data while it's being computed on, by a party you don't fully trust with the hardware. Standard encryption-at-rest and in-transit remain sufficient when your own infrastructure runs the computation and you control the hypervisor. You need TEEs when any of these apply:

You're running inference on a third-party cloud GPU and need the cloud provider itself excluded from your threat model — not just outside attackers.
You're serving a proprietary model to customers who could otherwise extract weights from GPU memory during inference.
Multiple parties (e.g., two hospitals, or a bank and a fraud-detection vendor) need to jointly compute on combined data without either seeing the other's raw inputs.
Regulatory or contractual requirements explicitly mandate hardware-isolated processing, common now in healthcare data-sharing agreements and some financial services contracts.

You probably don't need it for internal analytics on your own infrastructure, for public or already-anonymized datasets, or as a substitute for basic access control and encryption hygiene — those problems are cheaper to solve conventionally, and TEEs add real operational cost: refactored application boundaries, attestation infrastructure, and vendor lock-in to specific CPU/GPU hardware generations.

Takeaways

Confidential AI inference is production-ready on all three major clouds today, with H100/H200-based GPU TEEs delivering 95%+ of native performance for most workloads — performance is no longer the blocker it was two years ago.
Attestation, not compute overhead, is the real unsolved engineering problem. Before adopting confidential computing, ask your vendor specifically how they handle composite CPU+GPU attestation and whether they rely on any of the intra-handshake schemes flagged as vulnerable to relay attacks.
Reserve TEEs for cases where you must exclude the infrastructure operator from your threat model — third-party GPU inference on regulated data, or multi-party computation. Don't deploy them as a general-purpose upgrade to encryption-at-rest; the operational cost isn't justified there.
Budget for the attestation layer, not just the TEE hardware. Independent attestation services and the Confidential Computing Consortium's open-source verification tools are currently the practical way to avoid building this from scratch.