Europe's four levels of cloud sovereignty, read from Ottawa

On June 3, 2026, the European Commission proposed the Cloud and AI Development Act, the cloud-and-AI pillar of a broader European Technological Sovereignty Package.¹ Most of the coverage went to the headline ambition: at least tripling the Union’s data-centre capacity inside five to seven years.² The part that matters from Ottawa is smaller and more durable. CADA sorts cloud and AI vendors into four sovereignty levels for public procurement, and it puts defence at the top.²³

An earlier piece in this series drew a line between Canadian-hosted and Canadian-jurisdictional, and argued that residency answers a question about geography while sovereignty is a question about law. CADA is that line, written into a draft statute by a major ally. The four levels are a regulatory ladder from geography at the bottom to jurisdiction and supply-chain control at the top. None of that has to clear the European Parliament to be legible from Ottawa.

The rubric: residency at the floor

The four levels read, in the Commission’s own framing, as a progression.²³

• Level 1. Data is processed and stored on infrastructure located in the Union. This is residency, and nothing more.
• Level 2. The provider demonstrates independence from third countries and transparency over its software supply chain.
• Level 3. The provider is owned and controlled from the EU and meets additional criteria, such as personnel citizenship.
• Level 4. The provider has full transparency and control over its software supply chain, and there is no interference from a third country.

Where a vendor lands in the structure is the argument the Act is making. Level 1 is the floor it expects everyone to clear. The Act builds three levels on top of residency precisely because residency doesn’t answer the question that matters: whose law reaches the entity that operates, supplies, and controls the system. Level 2 adds supply-chain transparency. Level 3 adds corporate ownership and control. Level 4 adds the absence of third-country interference. Read top to bottom, the ladder is the distinction this series has been drawing, expressed as procurement tiers rather than prose.

Defence sits at the top level

Rather than apply the strictest tier across the board, CADA ring-fences. Defence procurement falls into Level 4, the most restrictive level, while the Act deliberately avoids a broad ‘Buy European’ mandate that would pick a fight with Washington and the US hyperscalers over the whole public market.³ One analysis puts the ring-fenced share at roughly 1% of the public market: the most sensitive workloads, walled off, with the other 99% left to compete on a softer ‘EU value’ score.³

Watch where the Commission set the bar. Given a free hand to write sovereignty into law, it concluded that for defence and the most sensitive workloads, neither residency nor independence nor even EU ownership clears it on its own. The bar for sensitive workloads is Level 4: transparency and control over the entire software supply chain, and no third-country interference. That’s a jurisdiction-and-supply-chain requirement rather than a hosting one, and it’s exactly the requirement a Canadian classified workload faces.

The levels are the surfaces, sorted

The earlier piece in this series mapped the surfaces where Canadian-hosted and Canadian-jurisdictional come apart: the operator, the trust roots, the supply chain, the runtime dependencies, and the corporate parent. CADA’s ladder sorts those same surfaces into tiers. Level 2’s ‘transparency over the software supply chain’ maps to supply-chain provability. Level 3’s ‘owned and controlled from the EU’ maps to corporate control, and Level 4’s ‘no interference from a third country’ states the jurisdictional surface as an outcome. The European Commission and this corpus started from different doors, a procurement regulation and a procurement-evaluation argument, and arrived at the same place: hosting is the floor, and supply-chain control plus the absence of foreign legal reach is the bar.

That convergence is the useful part. When two Western blocs independently write down the same test, an evaluation no longer rests on a single vendor’s framing. The test has external authority.

Read from Ottawa

Two things follow for a Canadian defence buyer.

The first is direct. Canada is the first non-European country admitted to the EU’s SAFE defence-procurement instrument, a point an earlier piece in this series covered. A Canadian-incorporated vendor competing for work inside the European frame will, in time, be read against CADA’s levels. A vendor that can’t answer the Level 4 questions doesn’t reach the workloads SAFE is built to fund.

The second is more useful today. Canada’s Defence Industrial Strategy named Secure Cloud as a sovereign capability the federal government committed to building, and then didn’t specify the supply chain underneath it. That gap, which an earlier piece in this series named, is now easier to fill, because CADA supplies a ready-made vocabulary. A Canadian RFP for a classified Kubernetes workload can ask, in plain language, which level a vendor meets, and can state that the answer for a classified workload is the top one: full supply-chain transparency and control, no foreign legal interference. The rubric is borrowable. Ottawa didn’t have to write it.

Open source is a different test

The same package pairs CADA with an EU Open Source Strategy, built on three pillars (trusted assets, empowered communities, and strong governance) and a commitment to favour open standards and models in public procurement over lock-in to proprietary systems.⁴ It’s tempting to read ‘sovereignty’ and ‘open source’ as the same requirement. They are related but distinct.

Level 4 asks for transparency and control over the software supply chain and the absence of third-country interference. It doesn’t ask for the product to be open-source. A proprietary product whose verification path is open, where the artifact format is a published specification and a third party can verify a deployment with stock cryptographic tooling that reaches no foreign service, answers the Level 4 questions. An open-source product whose build, signing, and trust roots still resolve to a third-country service does not. What the test measures is the transparency and jurisdiction of the trust path. The license on the source is beside the point. Open-verifiable and open-source overlap, but a sovereignty evaluation that conflates them will pass vendors it should fail and fail vendors it should pass.

A proposal, not yet law

CADA is a Commission proposal as of June 3, 2026. It hasn’t passed. It enters the ordinary legislative procedure, where the European Parliament and the Council negotiate the text, and complex digital files commonly take twelve to thirty-six months before anything binds.¹ The levels, the thresholds, and the defence ring-fence can all move. This piece reads CADA as direction of travel among allies, not as settled law, the same discipline an earlier piece in this series applied to the EU courts’ adequacy rulings.

The direction, though, isn’t ambiguous. A second major Western bloc has now written down, in a procurement instrument aimed squarely at public and defence buyers, that for sensitive workloads hosting is the floor and supply-chain control with no foreign interference is the bar. The CLOUD Act made the gap. Canada’s Defence Industrial Strategy made it a procurement problem. The residency-versus-jurisdiction distinction named the surface. CADA sorted that surface into a four-level rubric. They are four descriptions of one test.

Northfleet is a Canadian-incorporated vendor building the sovereign supply chain that wraps a customer-operated classified cluster: a deploy-time bundle protocol, attestation chain, and tamper-evident audit trail. The customer’s cleared engineering teams operate the cluster on Canadian-jurisdictional infrastructure, under their own keys. Northfleet holds no customer data and no customer signing keys. Every release Northfleet ships carries provenance binding it to the source it was built from, which the customer can check without Northfleet’s participation. The architecture assumes the vendor can be compromised or compelled. That assumption is what stops a compelled vendor from silently changing what runs in the cluster.

If you’re evaluating sovereign infrastructure for classified workloads, and you want the rubric translated into the questions your RFP should ask, the conversation is open.