Does Microsoft's Sovereign Private Cloud Actually Escape the US CLOUD Act?

Key Points:

• No, not fully. Sovereign Private Cloud moves the data plane into a datacenter you or a European partner operate, which reduces CLOUD Act exposure, but Microsoft remains the software vendor and keeps the update chain. Only a National Partner Cloud operated by an EU legal entity (Bleu in France, Delos Cloud in Germany) takes Microsoft out of the chain of custody.
• The legal test is corporate control, not geography. 18 U.S.C. 2713, added by the CLOUD Act in March 2018, compels a US provider to produce data in its "possession, custody, or control" wherever it is stored, so a rack in Frankfurt run by a Microsoft subsidiary does not change the answer.
• Decide with three questions: who operates the platform, which legal entity signs the contract (and under which parent jurisdiction), and who physically holds the encryption keys. Exposure runs high for Sovereign Public Cloud, reduced for Sovereign Private Cloud, and low for a National Partner Cloud.
• Customer-managed keys in an external HSM are the strongest technical mitigation. A valid order then yields ciphertext, not plaintext. It is a mitigation, never an exemption, and it collapses the moment the provider can escrow or recover key material for support.
• The durable hedge is architectural. Containers, Kubernetes, Terraform or OpenTofu, standard PostgreSQL and S3-compatible storage let you move between Azure, a partner cloud, a European provider or your own hardware without rebuilding your delivery pipeline. Qovery operates at that layer, across AWS, GCP, Azure, Scaleway or your own existing Kubernetes cluster.

Partly, and only in one of the three tiers. Microsoft's Sovereign Private Cloud reduces your exposure to the US CLOUD Act when you run it disconnected and hold the keys, but Microsoft still owns the software. Only a National Partner Cloud run by an EU-owned operator, such as Bleu or Delos Cloud, puts a non-US company between your data and a US court order.

I'm not writing an anti-Microsoft piece. Microsoft has arguably built the most complete sovereign portfolio of any hyperscaler. The problem is simpler: contracts and EU datacenters do not change where a company is headquartered, and Microsoft France said so under oath in June 2025.

I've talked with more than 200 CTOs over the last few years. In European mid-market companies, sovereignty moved from a public-sector checkbox to a board-level question in roughly two years. This article is the answer I give them.

What exactly did Microsoft launch under the Sovereign Cloud umbrella?

Microsoft Sovereign Cloud is three delivery models: Sovereign Public Cloud (sovereign controls on existing Azure regions), Sovereign Private Cloud (Azure services on Azure Local in your own or a partner's datacenter, able to run disconnected) and National Partner Clouds (Microsoft technology operated by an EU-owned company). The operator, the contracting entity and the key holder differ in each tier, and that triplet decides your exposure.

Microsoft announced the portfolio on 16 June 2025 with Sovereign Public Cloud and Sovereign Private Cloud in preview. Since then it has shipped Azure Local disconnected operations worldwide in February 2026 and, on 20 October 2026, made external key management for Azure Managed HSM generally available and widened the partner ecosystem around Bleu and Delos.

Sovereign Public Cloud layers controls on Microsoft's existing European regions: data residency, customer-managed keys, confidential computing, and Data Guardian, under which only Europe-resident Microsoft staff control remote access, logged in a tamper-evident ledger. Operator: Microsoft. Contracting entity: a Microsoft entity with a US parent. Key holder: Microsoft by default, you if you configure customer-managed or external keys.

Sovereign Private Cloud runs Azure services on Azure Local (formerly Azure Stack HCI) hardware in your datacenter or a partner's. Operator: you or your partner. Contracting entity: Microsoft for the software licence. Key holder: you.

The disconnected mode is real but demanding. Microsoft's documentation requires an approved business need, a Standard or higher support plan and a dedicated three-node management cluster, each node with 24 physical cores. The disconnected service list covers VMs, Arc-enabled servers, AKS on Azure Local, Container Registry, Key Vault and Azure Policy, which is a small fraction of the Azure public catalogue.

National Partner Clouds are Microsoft technology licensed to a non-Microsoft operator. Bleu is "fondée et détenue à 100% par Capgemini et Orange", sells commercially in France, and remains in SecNumCloud qualification. Delos Cloud is an SAP subsidiary built to German BSI requirements and still runs a pilot-customer programme. Operator: the EU company. Contracting entity: the EU company. Key holder: the operator or you.

The EU Data Boundary sits underneath all of this. Microsoft completed it on 26 February 2025, covering customer data, pseudonymised personal data and professional services data. It is a storage-and-processing guarantee, and it does not shield anything from a US legal order.

Does the US CLOUD Act still apply if the servers are physically in Europe?

Yes, in most cases. 18 U.S.C. 2713 requires a US provider to preserve and produce data within its "possession, custody, or control" regardless of whether it is stored inside or outside the United States, so server location is not the test. What matters is which company can be served the order and whether that company can decrypt what it holds.

The statute reads: a provider "shall comply with the obligations of this chapter to preserve, backup, or disclose the contents of a wire or electronic communication and any record or other information pertaining to a customer or subscriber within such provider's possession, custody, or control, regardless of whether such communication, record, or other information is located within or outside of the United States."

Congress passed it as Division V of the Consolidated Appropriations Act, 2018, approved on 23 March 2018. Three weeks later, on 17 April 2018, the Supreme Court vacated the Ireland warrant case, United States v. Microsoft Corp., and remanded it with instructions to dismiss as moot.

The law has limits. The Department of Justice white paper states that "indiscriminate or bulk data collection is not permitted" and that the US still needs personal jurisdiction over the company. Under 18 U.S.C. 2703(h), a provider can move to quash within 14 days, but only when the request conflicts with the law of a "qualifying foreign government" that has an executive agreement in force with the US.

Four instruments get blurred in this debate:

• CLOUD Act: compels a provider under US jurisdiction to disclose data through warrants, subpoenas or court orders.
• FISA Section 702: authorises collection targeting non-US persons abroad with the compelled help of US providers; it lapsed on 12 June 2026 after Congress failed to reauthorise it, and the fight over its return continues.
• Executive Order 12333: the presidential framework for US intelligence activity, including collection outside the United States.
• EU-US Data Privacy Framework: an adequacy mechanism for transfers; the General Court upheld it on 3 September 2025, and the appeal before the Court of Justice is still pending.

GDPR and the CLOUD Act do not flatly contradict each other. GDPR Article 48 says a third-country court order "may only be recognised or enforceable" if based on an international agreement such as a mutual legal assistance treaty. The EDPB's Guidelines 02/2024 add that any response still counts as a transfer under Chapter V. They also exclude the classic CLOUD Act case, where the US serves the parent and the parent asks its EU subsidiary for the data, from Article 48's scope.

Then came the hearing. On 10 June 2025, before the French Senate commission of inquiry on public procurement, rapporteur Dany Wattebled asked Anton Carniaux, director of public and legal affairs at Microsoft France, whether he could guarantee under oath that French citizens' data entrusted to Microsoft via Ugap would never be handed over to US authorities without French consent. His answer, per the Senate record: "Non, je ne peux pas le garantir, mais, encore une fois, cela ne s'est encore jamais produit."

Microsoft's own numbers show the scale is small and not zero. In the second half of 2025, Microsoft's Law Enforcement Requests Report lists 190 requests concerning enterprise customers, with content disclosed in 45 cases. Three non-US enterprise customers whose data was stored outside the US had content disclosed to US authorities, one of them in the EU or EFTA.

Customer-held keys change the calculus. An order can compel the ciphertext a provider holds, but not plaintext it has no way to decrypt, provided it never holds, escrows or can recover the key.

The scoreboard: Sovereign Public Cloud is still exposed, Sovereign Private Cloud is reduced and depends on who operates it and who holds the keys, and a National Partner Cloud is lowest because the operator is an EU legal entity outside US jurisdiction. No provider is CLOUD Act proof.

Is Sovereign Private Cloud real sovereignty, or just Azure in your own basement?

Sovereign Private Cloud delivers real data and operational sovereignty when you or a European partner run it and hold the keys, but not technological sovereignty. The Azure Local software stack, the update and firmware signing chain, the roadmap and the licensing terms stay with Microsoft, so you control who reads the data but not the platform's future.

Three layers, three different owners:

• Data sovereignty: where data sits and who can read it.
• Operational sovereignty: who runs, patches and supports the platform.
• Technological sovereignty: who controls the code, the roadmap and the supply chain.

In Sovereign Private Cloud you control the hardware, physical access, network egress, key custody and the choice to run disconnected. You do not control the Azure Local software, signed updates and firmware, the feature roadmap, licence terms, support escalation paths, or the commercial dependency itself.

The "kill switch" debate is the reason buyers stopped treating this as theory. In May 2025 the Associated Press reported, citing ICC staff, that Microsoft cancelled the email address of ICC chief prosecutor Karim Khan after US sanctions, and that he moved to Proton Mail. Microsoft later told Politico it had disconnected a sanctioned official but "at no point" ceased services to the ICC.

Microsoft's answer is contractual. In its European Digital Commitments of 30 April 2025, Brad Smith pledged that if any government orders Microsoft to suspend cloud operations in Europe, "Microsoft will promptly and vigorously contest such a measure using all legal avenues available." European cloud operations will be overseen by a board of European nationals, and Microsoft plans to grow European datacenter capacity by 40% in two years. That promise carries real reputational weight, and it is still a promise, not a jurisdictional exemption.

Running it costs more than the licence. Azure Local puts you back into capacity planning, hardware refresh, firmware management and a platform team. The Azure Local pricing page lists a host fee of $10 per physical core per month, and Microsoft's retail price list shows disconnected operations at roughly $50 per physical core per month, before hardware, power or people.

My conclusion: Sovereign Private Cloud is the right answer for regulated data that must stay inside a known perimeter, and overkill for most of a typical application portfolio.

How does Microsoft's sovereign offer compare to AWS, Google, Oracle and European providers?

Every US hyperscaler now ships a sovereign tier built on the same recipe: an EU-incorporated operating entity, EU-resident staff on the control plane, and customer-held keys. European providers such as OVHcloud, Scaleway, IONOS, STACKIT and Exoscale start from EU ownership but ship a narrower managed-service catalogue, so the real trade is jurisdiction versus service depth.

AWS European Sovereign Cloud went generally available on 14 January 2026 in Brandenburg, Germany, under AWS European Sovereign Cloud GmbH and German subsidiaries, operated by EU residents. Amazon has committed €7.8 billion to it by 2040. The ultimate parent is still Amazon.

Google goes through partners. S3NS, wholly owned by Thales, obtained SecNumCloud 3.2 qualification for PREMI3NS, and the ANSSI catalogue lists it as qualified from 17 December 2025 to 17 December 2028. Google Distributed Cloud air-gapped holds US Top Secret, Secret and DoD IL6 authorisations.

Oracle EU Sovereign Cloud runs in Frankfurt and Madrid through EU legal entities with European boards, operated and supported by EU residents.

European providers are EU-owned with thinner PaaS layers. SecNumCloud applies to named services, not whole catalogues: OVHcloud is qualified for Hosted Private Cloud powered by VMware, Bare Metal Pod and SNC Cloud Platform, while its Managed Kubernetes Service is not listed. Scaleway appears on ANSSI's in-progress list. IONOS, STACKIT and Exoscale all cite BSI C5.

The certification vocabulary matters in RFPs. The SecNumCloud 3.2 référentiel, section 19.6, requires an EU registered office and caps non-EU holders at 24% of capital and voting rights individually and 39% collectively, which is why no US-owned entity holds it directly. BSI C5 is an attestation that hyperscalers publish too. EUCS is still not adopted, and the Commission's Cloud and AI Development Act proposal of June 2026 says cybersecurity "must be distinguished from sovereignty requirements."

The trade-offs are plain. Hyperscaler sovereign tiers win on service depth and tooling, EU providers win on jurisdiction and certification, and partner clouds sit in between with the newest, least battle-tested operating models.

This is a board topic because of concentration. Synergy Research Group puts Amazon, Microsoft and Google at 70% of the European cloud market in 2024, with European providers at about 15%. And Gartner's November 2025 survey found 61% of Western European CIOs expect geopolitics to increase their reliance on local or regional cloud providers.

What should a European CTO actually do about this in 2026?

Classify workloads by sensitivity, buy the cheapest tier that satisfies each class, and make portability a hard architectural requirement so the decision stays reversible. Paying air-gapped prices for a marketing site is the most common and most expensive mistake I see in European sovereignty programmes.

1. Classify data into three buckets: public or low-risk, regulated personal and sector data (GDPR, DORA, NIS2, health), and state or defence-grade. Only the third usually justifies disconnected Sovereign Private Cloud or a National Partner Cloud.
2. Hold your own keys for anything that matters, in an external HSM the provider cannot reach. Microsoft says its external key management keeps the key outside its infrastructure. Then read the support terms: if the provider can recover keys for support, the mitigation is gone.
3. Read the contract: which legal entity is the counterparty, what it commits to do on receipt of a US order, what notification it owes you, and what exit costs apply. Under the EU Data Act, applicable since 12 September 2025, providers cannot impose any switching charges from 12 January 2027.
4. Make the stack portable: containers, Kubernetes, Terraform or OpenTofu, standard PostgreSQL and S3-compatible object storage. Avoid proprietary PaaS primitives for anything you might move.
5. Run an exit rehearsal. Redeploy one production-shaped environment on a second provider and time it. A sovereignty plan you have never tested is a slide.

The trap is that "sovereign" branding can lock you in harder than the public cloud did. Sovereign tiers have narrower catalogues, fewer regions and fewer people who know them, so the switching cost grows quietly.

How do you stay portable across Azure, a partner cloud and your own hardware?

The only durable hedge against jurisdiction risk is an application layer that does not care which cloud runs it: Kubernetes plus infrastructure as code, with the platform layer owned by you rather than rented from the provider you are hedging against. If redeploying your estate elsewhere is a 12-month project, you have a preference, not a sovereignty strategy.

Kubernetes is the lowest common denominator across AKS, EKS, GKE, Scaleway Kapsule, OVHcloud Managed Kubernetes, AKS on Azure Local and bare metal. The CNCF's latest annual survey reports 82% of container users running Kubernetes in production.

Lock-in bites in the same places every time. Audit these:

• Identity and IAM
• Managed databases with proprietary extensions
• Queues and event buses
• Serverless functions
• Provider-specific IaC modules
• Proprietary observability

This is where Qovery fits. Qovery is an internal developer platform that deploys and operates applications inside your own cloud account on AWS, GCP, Azure or Scaleway, or on your own existing Kubernetes cluster, self-managed or on-prem. The cloud contract, the data plane and the bill stay in your name.

Your developers get git-push deployments, preview environments per pull request, auto-stop for non-production environments, managed cluster upgrades, per-environment RBAC and databases backed by managed cloud services. The experience stays the same whichever cloud or cluster sits underneath.

Bring-your-own-cloud matters for sovereignty because no third-party SaaS holds your workloads or your data plane. Swapping the cluster underneath does not mean rebuilding your delivery pipeline or retraining your developers.

It matters even more if you have no dedicated DevOps engineer. Running Kubernetes across two jurisdictions is exactly the work that stalls a sovereignty programme in a 40-person engineering team.

The honest limit: Qovery does not make Azure European. Your provider contract decides jurisdiction. Qovery makes leaving Azure a decision rather than a 12-month project.

How do I test cloud portability with Qovery from Claude Code or Cursor?

Install the Qovery Agent Skills once, then ask your coding agent in plain language to deploy the same application to a second cloud or to your own Kubernetes cluster. Every action is scoped and asks for your approval, and the MCP Server is read-only until you explicitly enable write access.

Install the Agent Skills globally for Claude Code, Cursor, Codex, OpenCode or Gemini CLI:

curl -fsSL https://skill.qovery.com/install.sh | bash

Or scope them to the current project:

curl -fsSL https://skill.qovery.com/install.sh | bash -s -- --project

Add the Qovery MCP Server to Claude Code. It uses OAuth and is read-only by default:

claude mcp add --transport http qovery https://mcp.qovery.com/mcp --callback-port 4242

Enable write access only when you want the agent to change things. This also requires enabling write access in the Qovery Console:

claude mcp add --transport http qovery "https://mcp.qovery.com/mcp?read_write=true" --callback-port 4242

The skills include qovery-onboard, qovery-deploy, qovery-troubleshoot, qovery-optimize, qovery-speedup, qovery-preview and qovery-terraform. Skills deploy, and the MCP Server operates what already exists.

Then ask, for example, "deploy this app to my Scaleway account with Qovery" or "reproduce this environment on our on-prem Kubernetes cluster". That is the cheapest exit rehearsal you will ever run. The full reference is in the AI agent quickstart and the Claude Code integration page.