CADA explained for Azure customers: EU cloud sovereignty

On 3 June 2026 the European Commission published its proposal for the Cloud and AI Development Act (CADA), the centrepiece of a wider technological sovereignty package that also includes a Chips Act 2.0 and an EU Open Source Strategy. CADA does two big things. It creates an EU-wide cloud sovereignty framework, built on four Union assurance levels, that public-sector bodies will use to decide which cloud services are sufficiently protected from foreign control. And it commits the EU to at least tripling its data centre capacity within the next five to seven years. If you run workloads on Azure for a Swedish municipality, agency, region or regulated enterprise, this proposal will eventually decide which of those workloads can stay where they are. The final text is years away, but the assessment logic it introduces is concrete enough to start planning against today.

What the Commission actually proposed

The proposal is a directly applicable Regulation, published with annexes and a two-part impact assessment. It rests on three pillars:

Research, development and innovation. Support for next-generation cloud and AI technologies, including frontier, industrial and physical AI, through national strategies and acceleration centres.
Capacity. At least tripling EU data centre capacity within five to seven years, backed by streamlined permitting and better access to energy, land, water and financing. The Commission's own analysis is blunt: without intervention, current capacity will not meet projected demand.
Autonomy. An EU-wide framework to assess cloud and AI sovereignty, paired with a mechanism to drive adoption of qualifying services in the public sector, while keeping most of the market open to international providers.

The first two pillars matter for anyone building data centres or buying compute in Europe. The third pillar is the one that lands on your architecture review board, so the rest of this analysis focuses there.

The cloud sovereignty framework: four Union assurance levels

The framework grades cloud services on criteria spanning control over the service, control over the supply chain, treatment of data, infrastructure location and cybersecurity posture. The Commission describes the four levels like this:

Level 1: data is processed and stored on EU-located infrastructure.
Level 2: adds demonstrated provider independence from third countries and transparency in the software supply chain.
Level 3: requires EU ownership and control, plus further criteria such as personnel citizenship.
Level 4: full transparency and control over the software supply chain, with no third-country interference. This is the tier for the most sensitive workloads, including defence and national-security processing.

How conformity is demonstrated

Level 1 works on self-assessment: the provider confirms that the service, infrastructure and customer data are EU-based and publishes an EU statement of conformity. Levels 2 through 4 require an independent third-party audit. According to Wilson Sonsini's analysis of the proposal, that audit examines whether all staff are located in the EU, whether data generated by the provider may be used to train or fine-tune AI models, whether the provider has adopted software supply-chain security measures, and whether the service holds a European cybersecurity certificate rated at least "substantial" under the Cybersecurity Act.

Two details in that audit scope deserve attention from anyone who has run a vendor assessment. Staff location is an operational criterion, not a legal-entity criterion: it asks where the humans who can touch the service actually sit. And the AI-training question pulls model-development practices into a procurement framework for the first time. Both go well beyond the data-residency checkboxes most cloud questionnaires stop at.

The level 3 door for non-EU providers

The framework is not a flat ban on non-EU providers. The proposal leaves a route for a provider controlled from outside the EU to qualify at level 3, if it is controlled from a jurisdiction the Commission has approved, with adequate legal protections and reciprocal market access. That is a political instrument as much as a technical one: whether a US-controlled hyperscaler can ever reach level 3 will depend on a Commission decision about the United States, not on anything the provider engineers. Level 4, with its requirement of no third-country interference, is for practical purposes reserved for EU-controlled providers.

Who decides which level a workload needs

Member states and Union entities carry out sovereignty risk assessments for their activities and match workloads to levels, with room for national variation rather than a uniform mandate. The proposal also floats a common EU-level procurement framework so public administrations can pool purchasing power. For Swedish readers: expect the level-setting exercise to land with the same bodies that today wrestle with cloud legal analyses, and expect the classification of any given verksamhet to be argued about at length.

Where Azure plausibly lands, level by level

What follows is our reading of a two-month-old proposal against Microsoft's current sovereignty portfolio. None of it is settled law.

Level 1 looks reachable. Microsoft completed the EU Data Boundary in early 2025, committing to store and process customer data for European customers within the EU and EFTA. In June 2025 it announced Microsoft Sovereign Cloud, including a Sovereign Public Cloud across its European regions and a Data Guardian control under which only Microsoft personnel residing in Europe approve and monitor remote access, logged in a tamper-evident ledger. A criterion of "data processed and stored on EU-located infrastructure" is close to what these offerings already advertise.

Level 2 is the genuinely open question. "Demonstrated independence from third countries" is exactly the property that European critics of US hyperscalers have disputed for years, because US legislation such as the CLOUD Act reaches providers subject to US jurisdiction regardless of where the servers stand. European staffing and European datacentres do not change the parent company's legal position. Whether level 2 can be satisfied by operational separation (European operations, European personnel, contractual guardrails) or demands structural separation from the US parent is precisely what the Parliament and Council negotiations will fight over.

Levels 3 and 4 are out of reach on today's facts. EU ownership and control is not something Microsoft can offer through a product SKU, and the level 3 jurisdiction-approval route requires a Commission decision plus reciprocity conditions that do not exist today. Anything your organisation classifies at these levels should be planned on EU-controlled infrastructure.

Decision guide: Azure Sovereign Public Cloud vs EU-native providers

The core move: stop asking "is Azure sovereign enough?" as one question. Classify workloads the way CADA will force public buyers to, then answer per class. Most organisations discover that the bulk of their estate sits comfortably at the low end and only a thin slice drives the sovereignty anxiety.

Class A: commercial workloads with no public-sector contract exposure. CADA's adoption mechanism targets public bodies, so nothing here binds you directly. Stay on Azure, but watch for the assurance levels leaking into private RFPs as a convenient label, the way ISO 27001 did.
Class B: public-sector workloads with ordinary sensitivity. Think citizen-facing web, open data, standard case handling without protected information. These map naturally to level 1. Azure with the EU Data Boundary and Sovereign Public Cloud controls is a defensible choice, and the self-assessment regime keeps friction low.
Class C: public-sector workloads with elevated sensitivity. Health data, social insurance, law enforcement adjacency, anything where your legal team already debates confidentiality under outsourcing rules. These are level 2 or 3 candidates. Run a dual-track: keep the Azure deployment portable (containers, infrastructure as code, open data formats, no exotic PaaS lock-in) while evaluating an EU-native landing zone in parallel. The usual shortlist names are OVHcloud, Scaleway, IONOS, Hetzner and, in Sweden, Cleura; assess them on managed-service depth, not just on flag.
Class D: defence and national-security processing. Level 4 territory. Plan on EU-controlled infrastructure from the start and treat hyperscaler services as out of scope, whatever sovereignty branding they carry.

Price the dual-track honestly for Class C. The gap between a hyperscaler and an EU-native provider is not the VM hourly rate, where EU providers often win. It is the managed services above the VM: the equivalents of Azure OpenAI, Cosmos DB, Entra ID conditional access, Sentinel, Purview. Every service without an equivalent becomes either self-managed platform engineering on your side or a feature you give up. That cost belongs in the comparison before any migration decision, and for many teams it is the deciding line item.

The Swedish angle: from national improvisation to EU-wide levels

Sweden has run its public-cloud debate largely without a shared yardstick since the US CLOUD Act passed in 2018. Individual agencies and municipalities have produced their own legal analyses of whether outsourcing to US-controlled clouds is compatible with the confidentiality rules in offentlighets- och sekretesslagen, and security-sensitive activities have their own regime under säkerhetsskyddslagen. The result is uneven: comparable workloads sit on hyperscaler clouds in one kommun and on-premises in the next, based on which legal memo the organisation happened to commission.

CADA would replace that patchwork with a common vocabulary. A sovereignty risk assessment that outputs "this activity needs level 2" is a far more tractable procurement artifact than a bespoke twenty-page sekretess analysis, and it transfers between authorities. For upphandling teams, the assurance levels slot naturally into LOU requirement specifications as qualification criteria. The proposed EU-level joint procurement framework could also matter for smaller Swedish municipalities that currently lack the leverage to negotiate sovereignty terms with any provider, EU-native or otherwise.

Regulated private-sector teams should read the proposal too. Banks under DORA and essential entities under NIS2 already document ICT third-party risk and supply-chain exposure. The CADA audit criteria (staff location, supply-chain transparency, certification under the Cybersecurity Act) overlap heavily with what those regimes ask about, and it is a reasonable bet that Swedish financial supervisors and security auditors will start borrowing the level vocabulary once it exists. Getting your cloud estate mapped against the four levels now is cheap; retrofitting the analysis under supervisory pressure later is not.

Timing matters for expectations. This is a proposal at the very start of the ordinary legislative procedure. Parliament and Council will amend it, the level definitions will be lobbied hard from every direction, and application will follow adoption with transition periods. Nothing changes in your procurement legal basis this quarter. What changes now is the planning assumption: the EU has put a four-level sovereignty ladder on the table, and the direction of travel for sensitive public workloads is away from unconditional hyperscaler use.

What to do before the final text exists

1. Inventory and classify. Map your workloads into the four classes above. For public bodies, sketch a first-pass sovereignty risk assessment per activity, even informally. This exercise is valuable regardless of how the final text turns out.
2. Close the level 1 gap on Azure now. Confirm your tenant and services actually sit inside the EU Data Boundary, and evaluate the Sovereign Public Cloud controls (including Data Guardian) for your sensitive subscriptions. This is the cheapest sovereignty uplift available today.
3. Make Class C workloads portable. Prefer containerised services, infrastructure as code and open data formats where the marginal cost is low. Portability is your hedge against every possible outcome of the negotiations.
4. Price the EU-native alternative. Run one real proof of concept with an EU provider for a representative Class C workload, including the managed services you would have to replace. A concrete number beats a philosophical debate.
5. Track the legislative file. The definition of level 2 independence and the level 3 jurisdiction-approval mechanism are the two provisions that decide the Azure question. Assign someone to follow them through Parliament and Council.
6. Talk to your Microsoft account team. Ask specifically how Microsoft intends to position Sovereign Public Cloud against the assurance levels. The answers will be provisional, but the question signals what your renewal negotiation will hinge on.