In September 2016, Microsoft opened two Azure regions in Germany under a partnership with T-Systems, a subsidiary of Deutsche Telekom. The arrangement was called Azure Germany, codename Black Forest. T-Systems held the keys. The servers sat in German data centers. Microsoft's own engineers could not access the infrastructure without T-Systems' approval. If a German law enforcement agency or a US federal warrant wanted data from those regions, they had to go through a German company operating under German law on German soil.

This was not a branding exercise. It was the most structurally sovereign cloud a US hyperscaler has ever built. It had every attribute the sovereignty debate asks for: local entity, local staff, local data, local control, and a genuine jurisdictional firewall between the US parent and the EU operator. The CLOUD Act did not exist yet (it passed in 2018), but the architecture would have resisted it better than any hyperscaler deployment before or since.

Microsoft stopped accepting new customers for Azure Germany in August 2018. Two years after launch. The existing regions were frozen, and Microsoft opened standard Azure regions in Germany instead — normal regions, owned and operated by Microsoft, no T-Systems intermediary, no jurisdictional firewall.

Why It Died

The official reason was that "customer needs had evolved." The real reason was that the sovereign version didn't have the services.

Azure Germany ran a subset of the Azure catalog. New services launched on global Azure first, sometimes years before reaching the German sovereign regions — if they reached them at all. A customer who wanted the latest machine learning tools, the newest database services, or integration with the broader Azure ecosystem couldn't get them in Azure Germany. They could get sovereignty, or they could get capability. Most chose capability.

This is the part of the sovereignty conversation that procurement frameworks don't address. Sovereignty without capability is a locked room. You can build the most architecturally sovereign cloud in the world, and if it doesn't have the services your users need, they will leave. Not because they don't value sovereignty. Because they have work to do.

European providers hold about 15 percent of their own cloud market. That number has been roughly unchanged for four years. The American big three hold most of the rest. The gap is not about to close, because the gap is not a certification problem. It's a capability problem. European providers don't have the service breadth of AWS or Azure, and a procurement badge doesn't build services.

Enter CADA

On June 3, 2026, the European Commission proposed the Cloud and AI Development Act (CADA) as part of its Tech Sovereignty Package. The Act introduces a four-tier assurance framework for cloud services procured by public-sector bodies and critical infrastructure operators. The levels are progressive — a provider qualifying at Level 3 also satisfies Levels 1 and 2.

Level 1 — Data in the EU

Data is stored, processed, and backed up within EU member states. Data transfer outside the EEA requires documented GDPR-compliant mechanisms.

Who qualifies: Everyone. AWS, Azure, GCP, OVHcloud, Hetzner, Scaleway — all operate EU-based infrastructure and can contractually commit to EU data residency. This is the floor.

What it doesn't address: jurisdictional control. A US company can store data in Frankfurt while remaining subject to the CLOUD Act. Data residency without jurisdictional sovereignty is compliance theatre. The data is physically in the EU but legally accessible to non-EU authorities through the parent company's US legal obligations.

Level 2 — Independence from Third-Country Law

The provider demonstrates that no third-country law can compel access to customer data without an EU court order. The corporate structure must prevent extraterritorial legal access.

Who qualifies: EU-headquartered providers — OVHcloud (France), Scaleway (France), Hetzner (Germany), IONOS (Germany), Exoscale (Austria). Their parent entities are incorporated in EU member states without extraterritorial data access legislation analogous to the US CLOUD Act.

Who fails: AWS, Azure, GCP, Oracle, IBM. All are US-incorporated. All are subject to the CLOUD Act (18 U.S.C. §2523), which permits US law enforcement to compel US-headquartered companies to produce data they possess, control, or can access — regardless of where it is stored. EU subsidiary structures (AWS EMEA SARL in Luxembourg, Microsoft Ireland Operations Ltd, Google Cloud EMEA Ltd in Dublin) do not create genuine jurisdictional independence. Parent company control over the subsidiary extends CLOUD Act obligations globally.

Their European sovereign cloud offerings — AWS European Sovereign Cloud in Brandenburg, Azure EU Data Boundary, Google Sovereign Cloud — are technical architecture proposals, not ownership restructurings. They may achieve EUCS certification, but they cannot achieve Level 2 because the parent company structure has not changed.

Level 3 — EU Ownership, EU Personnel, EU Jurisdiction

The provider is owned or majority-controlled by entities incorporated in EU member states. Key technical and security personnel are EU nationals or residents operating under EU employment law. All access to customer data is performed exclusively within EU jurisdiction. No non-EU entity holds operational control, directorship, or effective veto power.

This is the structural wall. Level 3 is where CADA stops asking about data location and starts asking about who owns the company. AWS, Azure, GCP, Oracle, and IBM all fail — not because they refuse to comply, but because their corporate structure makes Level 3 structurally impossible without divesting their EU operations into genuinely independent EU entities. A subsidiary with a US parent is, by definition, subject to US parent company control. That control creates the CLOUD Act access vector. Level 3 explicitly rules out this structure.

The provider qualification matrix at Level 3:

| Provider | EU Incorporated | EU Ownership | No US Parent | CADA Level 3 | |----------|---------------|-------------|-------------|-------------| | Hetzner | Yes (DE) | Yes (private, family-owned) | Yes | Qualifies | | OVHcloud | Yes (FR) | Yes (publicly traded, Paris) | Yes | Qualifies | | Scaleway | Yes (FR) | Yes (Iliad SA, Xavier Niel) | Yes | Qualifies | | IONOS | Yes (DE) | Yes (United Internet AG) | Yes | Qualifies | | Exoscale | Yes (AT) | Yes (A1 Telekom Austria) | Yes | Qualifies | | AWS | US subsidiary | Amazon.com Inc. (US) | No | Fails | | Azure | US subsidiary | Microsoft Corp. (US) | No | Fails | | GCP | US subsidiary | Alphabet Inc. (US) | No | Fails | | Oracle | US subsidiary | Oracle Corp. (US) | No | Fails | | IBM | US subsidiary | IBM Corp. (US) | No | Fails |

Level 3 mandatory for federal ministry procurement is targeted for 2027. Municipal authorities: 2028.

Level 4 — Full Supply Chain Sovereignty

All hardware, firmware, software, and network infrastructure in the supply chain must be manufactured or developed within EU/EEA jurisdictions or by verified-trustworthy partners. No components from jurisdictions with mandatory backdoor requirements. Full transparency over the hardware bill of materials.

No commercial cloud provider currently qualifies at Level 4. OVHcloud and Hetzner run on Intel, AMD, and ARM silicon. Network equipment comes from Cisco, Juniper, and similar US firms. Level 4 is aspirational for 2026, with a 2028–2030 horizon tied to the European Chips Act and AI Factories programme. For procurement today, Level 3 is the practical ceiling.

The Problem with the Floor

The CADA framework is a useful thinking tool. The four levels correctly identify that sovereignty is not a binary — it's a gradient from "data is here" to "no foreign law reaches this system at any layer." For a community organization assessing its own infrastructure, the levels are a good checklist: Where does the data sit? Who can compel access? Who owns the provider? Who built the hardware?

But the framework has a structural weakness, and it's the same weakness that killed Azure Germany.

The floor — Level 1 — asks only that data sits in the EU. Every US hyperscaler can meet it. The Commission's own analysis acknowledges this. European providers have warned that the floor invites more sovereignty washing, not less. A US provider with EU data centers gets a Level 1 badge, and procurement offices stop asking whether the data that actually needs higher protection — health records, citizen data, legal proceedings — should be at Level 3 instead.

A certificate turns a hundred decisions into one. You buy the floor, and nobody asks again whether your customer records, your tax data, and your test environment belong in the same place. That question — which data can sit under foreign law and which cannot — is the entire job. No badge produces the answer. It's a layer-by-layer assessment that depends on what the data is, who depends on it, and what happens if it's compelled, breached, or cut off.

Azure Germany proved this. Microsoft built Level 3 before Level 3 existed. It had EU ownership (T-Systems held operational control), EU personnel, EU jurisdiction, and a genuine jurisdictional firewall. By any reasonable assessment, it was the most CADA-compliant cloud a US company ever offered. And customers left, because the badge wasn't the point. The point was: can I do my work with this tool?

What This Means for Community Infrastructure

The CADA framework is European policy. Most readers of this site are not EU procurement officers. But the four levels are a useful framework for any community making infrastructure decisions, because they separate the questions that matter from the questions that sound like they matter.

Level 1 asks: where is the data? This is the question everyone asks. It's the easiest to answer and the least meaningful on its own. Data in a US-owned data center in Frankfurt is still subject to US law. Data in a community-owned server in a fire hall is subject to the law of the jurisdiction the fire hall sits in. Location matters, but ownership matters more.

Level 2 asks: who can compel access? This is the question that distinguishes a European provider from a US provider with European data centers. For community infrastructure, the equivalent question is: who can compel access to your data, and through what mechanism? If the answer is "a US company that is subject to the CLOUD Act," you have a dependency. If the answer is "the community owns the hardware and the software," you don't.

Level 3 asks: who owns and operates the system? This is the structural test. For community infrastructure, the equivalent is: do you own the hardware, run open-source software you can inspect, and control who has administrative access? A self-hosted Proxmox cluster running Nextcloud, Matrix, and Keycloak, on hardware the community owns, operated by people the community trusts, clears Level 3 by default. Not by badge — by architecture.

Level 4 asks: who built the hardware? This is the supply chain question. No one fully clears it — everyone runs on Intel, AMD, or ARM. But the question is worth asking: do you know what's in your server? Can you audit the firmware? For community infrastructure, this is the layer where you accept residual risk honestly and document it, rather than pretending a badge resolved it.

The Lesson

The lesson from Azure Germany is not that sovereignty doesn't work. It's that sovereignty by procurement badge is a different thing from sovereignty by architecture, and the badge doesn't substitute for the architecture.

Azure Germany had the architecture. It died because it lacked the capability. CADA's four levels provide a framework for assessing the architecture. But the floor is set where US hyperscalers can stand, and the Level 3 wall that excludes them arrives in 2027–2028 — years after the current procurement cycles have locked in decisions.

The communities that own their infrastructure — Proxmox on hardware they control, Nextcloud and Matrix and Keycloak in containers they operate, backups in open formats on storage they own — don't need a badge to know where they stand. They're at Level 3 by default. They can assess Level 4 honestly because they know what's in the rack. The badge is for procurement offices that need to check a box. The architecture is for communities that need to keep running.

Microsoft built the most sovereign cloud a US company ever made. Customers left it for the one that had more services. The lesson isn't to build a more sovereign cloud. The lesson is to build one that has both sovereignty and capability — and the only way to do that is to own the stack.

Sources: Petri — Changes to Azure Germany Operations, OpenTechHub — Europe had a Sovereign Cloud. Customers left it., sota.io — CADA Cloud Sovereignty: The 4 Assurance Levels, Digital Samba — Cloud and AI Development Act (CADA), European Commission — Tech Sovereignty Package, June 2026