Confidential Computing Across Clouds: Why Multi-Cloud Just Got a Lot More Private

Most large organisations don't run on a single cloud. They run on several. AWS for compute, Azure for enterprise integrations, Google Cloud for data and ML workloads—each chosen because it does something better or cheaper than the alternatives. In regulated industries like financial services, multi-cloud is also a regulatory requirement. Operational resilience frameworks explicitly mandate that firms avoid dependency on a single vendor. In 2026, 92% of organisations use a multicloud approach, and the number continues to grow.

But as workloads spread, so does the attack surface. Data moves between infrastructures with different security standards, compliance requirements, and levels of trust. Keeping sensitive data protected during processing, not just while it's at rest or in transit, becomes significantly harder when no single provider controls the full environment.

Confidential computing has long addressed that gap within a single cloud. What's new is the ability to extend it across providers, allowing organisations to run workloads on AWS and Azure simultaneously, with cryptographic proof that data is protected in both environments and across the connections between them.

A Quick Recap: What Confidential Computing Does

Most security solutions protect data in two states: while it's stored, and while it's moving between systems. That leaves a third state, data being actively processed, exposed. Confidential computing closes this gap by safeguarding data even during computation, inside hardware-protected environments called Trusted Execution Environments (TEEs), or secure enclaves.

A TEE is an isolated region of processor and memory within a virtual machine, an enclave, that keeps code and data protected from everything outside it, including the cloud provider's own infrastructure, administrators, and the host operating system. Nothing running outside the enclave can read what's happening inside it.

Remote attestation is the other essential piece. Before any sensitive data enters an enclave, attestation allows you to cryptographically verify that the enclave is running exactly the code you expect, on hardware that meets your security requirements. It's not a contractual assurance or a vendor's word. It's a signed cryptographic proof, verifiable by anyone, falsifiable by no one, that the environment handling your data is exactly what it claims to be.

Together, TEEs and attestation mean an organisation can say, with technical certainty: this specific code processed this data, in this verified environment, and nothing else touched it.

The Multi-Cloud Problem

In a single-cloud deployment, confidential computing is relatively contained. You deploy your workloads into TEEs on one provider's infrastructure, verify them via attestation, and operate within a known environment.

Multi-cloud complicates this. When an application running in a TEE on AWS needs to communicate with an application running in a TEE on Azure, several questions arise immediately. How do you establish that both environments are trustworthy? How do you ensure the communication between them hasn't been intercepted or tampered with? How do you enforce consistent data governance policies when the underlying infrastructure is controlled by two different providers, potentially in two different jurisdictions?

Without a solution to these questions, multi-cloud architectures force a tradeoff: either you accept weaker privacy guarantees at the boundaries between providers, or you centralise sensitive workloads on a single cloud and lose the flexibility multi-cloud is supposed to deliver.

Confidential computing, extended properly across cloud providers, removes that tradeoff.

How It Works: Attested Connections Across Clouds

The key capability is cross-cloud attestation; the ability for a TEE running on one cloud provider to verify the integrity of a TEE running on another, and establish a secure, encrypted channel between them.

When two applications running in separate TEEs need to communicate, each enclave generates a cryptographic attestation report: a signed proof of what code it's running and what hardware it's running on. These reports are exchanged and verified before any data flows between the enclaves. If either environment fails the attestation check, the connection is rejected.

The result is a system where sensitive data can only flow between environments that have been mutually verified. Even if one provider's infrastructure were compromised, an attacker couldn't intercept data in transit between verified enclaves because it's encrypted end-to-end, with keys that never leave the TEEs.

This makes it possible to build genuinely private distributed systems: workloads split across cloud providers, each processing sensitive data in isolation, communicating only through attested channels that prove the integrity of both ends.

Why This Matters for Compliance

Every organisation handling personal data operates under some version of the same obligation, whether that's GDPR, CCPA, HIPAA, or an equivalent framework, to demonstrate control over how that data is processed. In multi-cloud environments, meeting that obligation has historically meant relying on contractual assurances: data processing agreements, vendor certifications, and third-party audits. These matter, but they document commitments, not outcomes.

Cross-cloud confidential computing changes what's provable. Rather than auditing vendor behaviour after the fact, organisations can verify it at the infrastructure level before data is ever processed. 

For those navigating GDPR's data residency requirements specifically, it also means sensitive workloads can be deployed in the right region, on the right provider, while still carrying the same cryptographic guarantees regardless of where they run.

What This Enables in Practice

The clearest way to see what cross-cloud confidential computing unlocks is through the problems it directly removes.

A mid-sized European bank runs its core transaction monitoring on Azure but relies on a fraud detection model built and maintained by a partner on AWS. Today, connecting those two systems means accepting that sensitive transaction data crosses a cloud boundary neither party fully controls. With attested cross-cloud channels, the transaction data stays sealed in the bank's enclave on Azure, the model runs in the partner's enclave on AWS, and the connection between them is cryptographically verified before any data flows. The bank gets better fraud detection. Its customers' financial data never leaves a verified environment.

In the public sector, cross-departmental data sharing, the kind that became urgent during COVID-19, connecting benefits records, health data, and local authority information to reach vulnerable households, stalls not because of policy, but because neither agency can prove to the other that its environment is trustworthy. Cross-cloud attestation solves that specific problem, not by asking either party to trust the other, but by giving both parties proof.

OBLV Deploy: Multi-Cloud Confidential Computing in Practice

OBLV Deploy now supports deploying applications into TEEs across both AWS and Azure, with attested cross-cloud communication. Whether deploying single workloads or groups of related services, attestation is performed between enclaves as well as between clients and enclave-based services—whether those services are in the same cluster, different clusters on the same cloud or hosted across different cloud providers entirely, giving maximum flexibility. TEEs can attest one another whether they belong to the same organisation or different parties, fostering mutual trust based on cryptographic proof rather than contractual assurances. 

OBLV Deploy is designed to minimise friction when adopting confidential computing. For development teams, application code remains unmodified; built as standard Docker containers and deployed to existing container registries, with no changes to the software development lifecycle. For operations teams, the familiar Kubernetes ecosystem is extended to support TEEs, managed with existing tooling. For security and audit teams, OBLV Deploy integrates with standard logging and monitoring systems, allowing confidential computing to plug directly into existing observability infrastructure.

Built to Scale

OBLV Deploy extends the attestation process to verify not just the software running within the enclave, but also the runtime configuration and the networking controls, giving even greater assurance that data is being sent to a trustworthy environment. The attestation process is backed by the underlying hardware: the Nitro subsystem on AWS and AMD CPUs on Azure.

The cryptographic guarantees provided by the hardware are rooted in a chain of trust that can be traced right up to the public root certificates of the hardware vendors. Any changes to software, configuration or network controls will cause attestation to fail, and connections between enclaves will be denied.

Confidential computing is sometimes perceived as a niche capability, suited only to small, highly specialised workloads. OBLV Deploy is built to counter that assumption. It supports deployment to any compatible VM size with horizontal auto-scaling, and with cross-cluster and cross-cloud support, there's no practical reason sensitive data in use should remain unprotected. 

OBLV Deploy recently added support for attestation of NVIDIA H100 GPUs, enabling CPU and GPU to operate together within a single TEE with full attestation, extending confidential computing to GPU-intensive workloads, including generative AI. Support for GCP is also on the roadmap, expanding cross-cloud options further.

For more technical details, please visit the OBLV Deploy documentation or contact us for a demo or a copy of our architecture whitepaper.  

The Bigger Picture

Multi-cloud confidential computing solves one problem well: it ensures that sensitive data stays protected and verifiable even when processed across infrastructure you don't control. As cloud architectures grow more distributed and regulations become more demanding, that capability moves from nice-to-have to foundational.

At Oblivious, we build technology for organisations that need their data governance to hold up under scrutiny. If you'd like to discuss how OBLV Deploy fits into your multi-cloud architecture, we'd welcome the conversation.