The EU Just Legislated Who Can Sell Cloud to Its Governments: What CADA's Four Tiers Mean for Your PaaS Choice

On June 3, 2026, the European Commission did what its sovereignty framework had only graded before: it legislated who can sell cloud to its governments.

The vehicle is the Cloud and AI Development Act — CADA — tabled inside the Commission's Tech Sovereignty Package. Its companion, the Cloud Sovereignty Framework published two days earlier on June 1, gave every cloud service a diagnostic score and a SEAL-0 to SEAL-4 grade across eight sovereignty objectives. CADA takes that diagnostic and turns it into a procurement gate.

If you handle the data, you must meet the tier the risk assessment puts you in — or you don't get to bid.

That is the sentence every EU public-sector pitch deck will have to survive for the next two years. The question is no longer "where is the data stored" but "who is the parent that can be ordered to hand it over."

CADA also carries the Commission's buildout bet: at least tripling EU data-center capacity within five to seven years, backed by roughly €200 billion in predominantly private investment. The bar goes up at the same time the capacity to clear it is being pushed to exist.

Here is the concrete mapping the law creates — early so you can find your row before we argue about what it means.

The answer up front: four levels, one table, one structural cliff​

Every contracting authority — member-state ministry, municipal operator, Union entity — must run a sovereignty risk assessment and assign the workload to one of four assurance levels. Each level inherits the controls below it and adds a legal test you cannot satisfy with a technical workaround.

Two things to notice. First, most workloads stay at Levels 1–2 — roughly 90% of today's public-sector estate per the Commission's impact assessment. CADA is not a blanket ban on US cloud in Europe.

Second, the cliff is discrete, not gradual. Levels 3 and 4 do not ask for better encryption or a different region. They ask "who owns the company that can be ordered to disclose," and no key-management design answers that if the answer is "a US corporation."

That is the whole compliance pitch in four rows. The rest shows why grading versus legislating is the difference that makes it stick, why headquarters beats region, and what a fleet on owned EU hardware has to prove.

From a grade to a gate: SEAL is the diagnostic, CADA is the law​

Early explainers treat CADA and the Framework as synonyms. They are not.

The Framework (June 1) is a rating system. It scores every cloud service across eight objectives — strategic, legal, data, operational, supply-chain, technology, security, environmental — using 48 criteria. The math produces two outputs: a weighted Sovereignty Score and a SEAL level from SEAL-0 ("no sovereignty") to SEAL-4 ("full digital sovereignty"), calculated as the weakest link across objectives. FOSDEM and the Commission's implementation guide present it as an interactive calculator any agency can run.

By itself it blocks no procurement. A SEAL-2 provider can still win a SEAL-1 workload. Think SOC 2 diligence, not statute.

CADA (June 3) is procurement law. It takes a four-level derivative of that SEAL logic, ties each level to mandatory bidder qualifications, and tells every buyer: publish the required assurance level in the tender, reject bids that do not meet it. The difference is a credit score versus a lending rule. A low score only matters once the rule says you must meet a minimum to qualify.

The mapping compresses the floor: SEAL-0 by definition fails even CADA Level 1, because Level 1 already requires EU residency. The top two CADA levels (3 and 4) track SEAL-3 and SEAL-4 directly — the tiers where legal immunity and supply-chain provenance become pass/fail.

Legal trackers from Jones Day and Hogan Lovells describe CADA as the most comprehensive framework yet for regulating cloud services in Europe precisely because it makes sovereignty a mandatory, tiered procurement criterion rather than a scored preference.

Why this matters to a PaaS operator: a hosted platform that advertises "EU region" clears a SEAL diagnostic question but may fail a CADA gate. The gate is not "does this store data in Frankfurt" but "can the provider demonstrate immunity from non-EU disclosure orders at the level the tender demands." That is why CADA, not the Framework, is the compliance event — and why a voluntary high SEAL score without the right domicile still leaves the top tiers out of reach.

The CLOUD Act trap: why headquarters matters more than region​

The control that bars US hyperscalers from Levels 3–4 is not a technical checkbox. It is a legal fact about who can be compelled.

Under the US CLOUD Act (2018), a US-domiciled provider can be ordered to disclose data in its possession, custody, or control regardless of where that data physically sits. FISA Section 702 extends the pattern to intelligence access with limited individual notice. An EU data-center lease, EU key management, even customer-held encryption do not erase the parent's jurisdiction. If the corporation that operates the service answers to a US court, the service answers to a US court.

This is exactly the criterion CADA elevates at Level 3: immunity to third-country extraterritorial compulsion for the operator itself, not just encryption of the data at rest.

The SEAL calculator's legal-sovereignty objective makes it explicit. A US-headquartered hyperscaler cannot achieve high legal-sovereignty scores without restructuring, because the weakest-link math will always be dragged down by the jurisdiction objective no matter how strong the data-residency answers are.

Two cases illustrate the boundary:

• S3NS (Thales) + Google Cloud at Level 3. The Commission-recognized pattern where US technology touches Level 3 is a jurisdiction-layer joint venture: Thales-controlled S3NS operates the sovereign instance, holds operational control and key custody, and Google Cloud supplies technology under license without direct operator status. The structure exists because the direct operator must be EU-owned and EU-controlled. Google Cloud alone, without that EU control layer, does not clear L3. The same logic applies to the Azure + Capgemini/Orange "Bleu" construct and the AWS European Sovereign Cloud pattern tested since 2023.

• OVHcloud SecNumCloud 3.2 as a proxy. France's ANSSI standard version 3.2 requires immunity to extraterritorial laws like the CLOUD Act, which structurally excludes US-owned operators wherever the servers sit. It is the credential history buyers already recognize, and providers like OVHcloud, Scaleway, and Hetzner map naturally onto it as EU-domiciled operators. The Commission's own "Cloud III" sovereign lot applied SEAL-2 as a minimum qualification in early 2026, awarding €180 million to four EU providers — and fielding press questions when one winner's tech partnership included Google Cloud, precisely because "operator versus technology supplier" is now the legal line.

For CADA, the triggers that escalate a workload to Level 3 or 4 are not mysterious. They are NIS2 Annex I essential entities (energy, transport, banking, health, drinking water, digital infrastructure, space, public administration) plus the OIV/OSE-derived criticality overlays each member state applies. If your PaaS will run the hospital, the grid, or the payment rail, the tender will ask for Level 3 or higher — and headquarters moves to the first page.

This is also why "but you hold the key" fails at Level 3. EU key management satisfies Level 2. Level 3 asks who can be ordered to press the key into someone else's hand.

What a self-hosted PaaS actually has to prove at each tier​

A hosted PaaS tenant inherits its provider's domicile as a procurement attribute whether it chose that provider for sovereignty reasons or not. A self-hosted fleet inverts the burden: the operator is the provider, so the evidence is about the operator's choices — jurisdiction, ownership, control — not a hyperscaler addendum.

Here is the checklist for a bid running a bex.co-style fleet — Cluster API on owned Hetzner, OVHcloud, or Scaleway hardware — at each tier:

Level 1 (open): prove EU residency and NIS2 hygiene. Cluster-API fleet in Hetzner Falkenstein/Nuremberg, OVHcloud Gravelines/Strasbourg, or Scaleway Paris/Amsterdam; data and backups EU-only; GDPR records and NIS2 controls documented. Any competent hosted PaaS in an EU region also clears this. The self-hosted edge is architectural — the nodes are where the tender says they are, not where a contract promises they are.

Level 2 (narrow but open): add verifiable localisation and audit rights. Beyond L1: EU-managed key custody, EU-only operational telemetry and support access, and the right to audit placement. A bex fleet shows this with EU KMS (OVHcloud KMS or Vault on EU metal), telemetry in an EU observability stack, and runbooks that never route a shell into an EU node from outside the EU. Hosted tenants also clear L2 if their PaaS offers EU key management and can restrict support jurisdiction. The self-hosted edge is operational: there is no vendor support backdoor because there is no vendor.

Level 3 (structural gap): demonstrate EU ownership and legal immunity. This is where the cap table and the hardware invoice matter. The operating entity must be EU-headquartered and EU-controlled; no non-EU parent can be compelled to disclose; day-to-day control (root, deploy authority, break-glass) sits with EU persons under the tender's definition. Running on Hetzner (German GmbH), OVHcloud (French SAS), or Scaleway (Iliad subsidiary, French) with a European operating company as bidder satisfies the hardware leg without argument — none are US-domiciled or CLOUD Act-exposed. The remaining work is organizational: the legal entity that operates the Cluster API control plane and Flux controllers must itself be EU-domiciled and EU-controlled.

A European SME running its own app on its own Hetzner fleet clears L3 more naturally than a US-headquartered hosted PaaS tenant ever can, because the gap is the parent, not the data center.

Level 4 (EU-only): extend to supply chain where demanded. Invoked only for defense and national-security-adjacent workloads where the tender asks for chip-to-software provenance. No near-term commodity fleet on Intel/AMD/Ampere nodes will claim end-to-end EU silicon provenance; even EU-native providers depend on non-EU silicon today. The Commission's five-to-seven-year buildout exists precisely because supply-chain sovereignty cannot be satisfied by contract language alone. Budget L4 only when the tender truly demands it.

One architectural implication: the bex.co posture is "bring your own sovereignty evidence." Because the platform runs on your machines, under your legal entity, in your chosen EU region, every CADA control is a property of choices you made — hardware invoice, company registration, runbook — rather than a hyperscaler attestation you attach and hope the evaluator trusts. The hosted-PaaS tenant is limited by the strongest claim its provider can make, and that claim's ceiling is fixed by headquarters.

Honest gaps: where "own the box" doesn't automatically win​

CADA raises the bar; self-hosting does not automatically vault it.

• Certification burden is real. Tripling data-center capacity does not triple audit-ready capacity. EUCS, evolving sovereignty overlays, and national SecNumCloud credentials require an audited ISMS, penetration tests, and weeks of assessor time. A three-person team with a beautiful CAPH fleet will struggle to carry the paperwork OVHcloud spreads across dozens. Budget staff, not just servers.

• Supply-chain provenance at Level 4 is nascent for everyone. Even EU-native providers depend on non-EU silicon today. Claiming L4 on commodity hardware without a provenance story is a protest risk. Bid L4 only when the tender demands it and the evidence exists.

• Resilience is yours to own. An owned fleet opts out of a vendor's multi-tenant blast radius, but opts into owning every remediation. A well-run small fleet fails less often than a hyperscaler tenant's worst week, but when it fails there is no vendor status page to blame — only your runbook.

• Levels 1–2 are often good enough. Not every public-sector workload needs Level 3. If the tender assesses as L1 or L2, a US hyperscaler's EU region is compliant and often simpler. Don't sell L3 capability where the buyer only asked for L1.

• Jurisdiction-layer JVs are legitimate competition at L3. S3NS and Bleu are not loopholes; they are the compliance architecture the Commission anticipated for US technology to remain in the European public sector at controlled tiers. A bex fleet competes against them on price and data-plane simplicity, not on the claim that US technology is banned everywhere.

Where to place the fleet​

CADA does not ban American cloud in Europe. It does something more durable: it forces every buyer to write down which tier their workload belongs to, then to reject bids that cannot meet it.

Once that is mandatory, the roughly 10% of public-sector workloads the Commission assesses as needing Levels 3–4 become a market US-headquartered direct operators cannot clear without a change of domicile. Not next quarter, not after better encryption.

For teams that already self-host, the strategic move is cheap to make now: put the fleet where the compliance answer wants it before the tender is published. A European entity operating a Cluster API fleet in Falkenstein, Gravelines, or Paris-Saclay produces Level 3 evidence as a side effect of choices made for cost reasons anyway. It is not a special "sovereign cloud" product to buy. It is an ordinary PaaS on ordinary EU metal that happens to answer the sovereignty question with a hardware invoice and a company registration.

That alignment is the deeper point of the Commission's €200 billion bet. If Europe triples capacity regardless, the workloads that must live on European operators will have somewhere to live — and the operators who already placed their fleet in a trusted jurisdiction will not have to move when the tender lands.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. A Cluster API fleet on your own Hetzner, OVHcloud, or Scaleway boxes gives you Render-compatible deploy ergonomics with a sovereignty story a tender can verify: your hardware, your region, your legal entity. Star the repo on GitHub or deploy your first EU-region app today.

Sources​

• European Commission — Proposal for the Cloud and AI Development Act (CADA), June 3, 2026; Tech Sovereignty Package briefing; tripling EU data-center capacity by 2033, €200B investment, four assurance levels, public-sector risk assessment mandate.
• European Commission — Cloud Sovereignty Framework v1.2.1 (June 1, 2026) implementation guide: eight sovereignty objectives, 48 criteria, SEAL-0 to SEAL-4 weakest-link calculation, Sovereignty Score; FOSDEM 2026 and Bitkom summaries.
• Jones Day / Global Policy Watch / Mondaq: four public-sector assurance levels as mandatory procurement gate; CLOUD Act / FISA barrier to top tiers; S3NS-Thales + Google Cloud and Bleu JV patterns for Level 3.
• Computerworld impact-assessment reporting: ~70% workloads at Level 1, ~20% at Level 2; Levels 3–4 as narrow EU-only tiers; SecNumCloud 3.2 extraterritorial-law immunity; Horizon / Incyber.
• EC communications / Fierce Network: "three non-EU hyperscalers control over 70% of the European cloud market" (CADA recital), faster permitting and grid reform.
• DC Byte / Reuters H1–H2 2026 data-center tracking; Commission Strategic Roadmap for Digitalisation and AI in Energy.
• Provider posture: Hetzner (DE), OVHcloud (FR), Scaleway (Iliad/FR) as EU-native infrastructure without US parent or CLOUD Act exposure.