Analysis · Regulatory

CADA: the four Union assurance levels

On 3 June 2026 the European Commission presented the European Technological Sovereignty Package, including a proposal for a Cloud and AI Development Act — COM(2026) 502 final. Most of it is industrial policy: research funding, data centre acceleration zones, faster permitting, a public sector cloud federation, open source obligations for Union bodies. One part of it changes how cloud is bought and described in Europe: a Union cloud sovereignty framework of four assurance levels, with criteria in Annex II, recognition by national authorities, and a central repository of recognised services. Level 1 is self-assessed; levels 2 to 4 require a third-party audit. Public buyers must use at least level 1, and levels 2 to 4 where their activities have been identified as contributing to the preservation of public order.

By Corrado Patierno ·

This is a proposal, not law. It has to go through the European Parliament and the Council, and the text — including article numbers and the criteria summarised below — can change before adoption. Under the proposal as published, the Regulation would enter into force twenty days after publication and apply one year later. Nothing here is a compliance obligation today; it is a description of the direction of travel, which is what procurement planning actually needs.

What the proposal contains

The stated problem is dependency: computing capacity in the Union is limited and geographically concentrated, and the EU relies on non-European providers for cloud and AI services, with consequences for control over data and operational autonomy. The response is spread across four blocks.

Cloud and AI Leadership Initiatives — research and innovation funding, a network of Experience and Acceleration Centres for AI built on the European Digital Innovation Hubs, recognition of frontier AI priority projects, and national cloud and AI strategies that Member States would have to adopt within a year of entry into force.

Data centre capacity — Member States designate acceleration zones with facilitated permitting and single information points, the Commission designates strategic projects, and progress against the capacity gap is monitored centrally.

Autonomy and adoption — the part discussed below: assurance levels, procurement duties, a public sector cloud federation, a common procurement framework run by the Commission, and obligations on Union entities and public bodies to prefer open source and to share and reuse the software they commission.

In the impact assessment, the audit mechanism for sovereign services is described by cloud providers themselves as the measure that would end “sovereign-washing”, and its benefit is framed as a single audit valid across the Union rather than one per Member State. That is the honest summary of the ambition: not to make sovereignty compulsory, but to make the word mean something specific enough to be audited.

The four levels, as drafted

Annex II sets cumulative criteria: each level carries everything below it and adds its own. What follows is a summary in plain terms, not the legal text — and Annex II is explicitly subject to review by the Commission at least every eighteen months. Note the scope line at the top of the annex: ‘software’ as defined in the Cyber Resilience Act is in scope, hardware is not.

Level 1

Self-assessment
  • —Provider established in the Union; infrastructure and assets of the provider and of the subcontractors involved in the service located in the Union, unless the public body explicitly requires otherwise.
  • —Customer data — including metadata and telemetry — stays exclusively within the Union, before, during and after use of the service, subject to the same exception.
  • —Support outsourced outside the Union only with legal, technical and organisational measures for traceability, security and governance, and without compromising the provider's operational autonomy.
  • —Full transparency on subcontractors, with due diligence and ongoing oversight; state-of-the-art cybersecurity.
  • —No third-country law requiring the provider to report software vulnerabilities to that country's authorities before they are known to be exploited.

Level 2

Third-party audit
  • —Personnel — of the provider and of the subcontractors involved — located in the Union; screening and citizenship requirements available on request of the public body.
  • —A European cybersecurity certificate of at least 'substantial' under a scheme established pursuant to Regulation (EU) 2019/881, once such a scheme exists; national schemes apply in the meantime.
  • —Data generated by using the service is not used to train or fine-tune any AI system operated by a third country or a third-country entity, and is never transferred outside the Union.
  • —Where the provider is under third-country control: demonstrated measures preventing that control from restricting service delivery, from reaching customer data, from disrupting continuity, and from forcing compliance with third-country sanctions or equivalent measures.
  • —Support initiated and performed exclusively within the Union.
  • —Software supply chain: a complete, current SBOM and dependency list; blocking of remote features that could tamper with or disrupt a system, including during updates; source-code audits of security-relevant third-country components and a documented migration plan if the vendor fails or a third country imposes restrictions; equivalent controls for open-source components.
  • —Effective legal, technical and organisational separation between the Union parent company and any third-country subsidiary.

Level 3

Third-party audit
  • —Personnel, including subcontractor personnel involved in the service, are Union citizens, with national security clearance where classified information is handled.
  • —Support performed within the Union by Union residents and by third parties not under third-country control.
  • —Subcontractors in scope are those that may require access to classified or sensitive information.
  • —A third country may be recognised as offering sufficient assurances, which is what makes services controlled from that country eligible at this level and not above it.

Level 4

Third-party audit
  • —The provider and the subcontractors involved are not subject to the control of a third country or of a third-country entity at all — the condition that cannot be met by contract.
  • —A European cybersecurity certificate of at least 'high' under the same scheme regime.
  • —Effective control retained over software components: no third country or third-country entity holding or exercising effective control over their design, development, maintenance and evolution.

The structure repays attention. Levels 1 to 3 are, in the end, about where things are and who touches them: establishment, location, data residency, personnel, support. Level 4 is about who controls the provider and the software, and control is the one criterion a contract cannot manufacture. That is also the distinction this practice has been making between a system that is private and a system that is sovereign.

Who would have to do what

Public sector. Member States and Union entities would run risk assessments to determine which of their activities contribute to the preservation of public order. Contracting authorities procuring cloud services for their own use must use services recognised at level 1 as a minimum. Where the activity has been identified as public-order relevant — in sectors falling under Annex I or II of the NIS2 Directive, and in national security, internal security, border management, defence, justice and law enforcement — only levels 2, 3 or 4 may be procured. Narrow derogations exist, chiefly where no recognised service can supply what is being tendered.

Private sector. This is the paragraph worth reading twice if you run infrastructure in healthcare, energy, transport, banking, water or digital infrastructure. Entities in Annex I of NIS2 that are not public bodies may carry out assessments similar to the public sector ones. The Commission may issue methodology guidance, and may, by delegated act and in consultation with Member States, specify that entities in sectors of high criticality are required to carry them out, together with the risk mitigation measures they must adopt.

In other words: voluntary as drafted, with an explicit mechanism for becoming mandatory in the sectors where the stakes are highest. Organisations in those sectors that already know where their data sits, who can reach it, and what would happen if a supplier's parent were subject to a foreign order will find such an assessment a documentation exercise. The others will find it a project.

The supply chain criteria are not new — and that is the point

Read the level 2 software supply chain requirements next to the obligations already arriving from elsewhere. A complete and current SBOM, defined by reference to the Cyber Resilience Act. Documented controls blocking remote features that could tamper with a system during an update. Source-code audits of security-relevant third-country components. A migration plan for vendor failure or third-country restriction.

The SBOM is the clearest case. It is evidence under the product liability directive, an instrument of vulnerability management under the CRA, and now an audit artefact under CADA — one artefact, three regulatory purposes. The same is true of supplier registers, vulnerability handling and post-market surveillance. Mapping those convergences — which control answers to which regimes, and what that saves — is what the CEPF methodology is for.

The practical consequence for a buyer is that a supplier who cannot produce an SBOM today is not merely unprepared for CADA. They are unprepared for the CRA reporting obligations that start applying on 11 September 2026, and they will be an awkward conversation once Member States have transposed the product liability directive by 9 December 2026 — the subject of the exposure assessment.

How it sits beside the AI Act

The two instruments do different jobs and it is worth not confusing them. The AI Act regulates AI systems by intended purpose and by role: what the system is for, who provides it, who deploys it, what evidence it must be able to produce. CADA does not classify AI systems at all. It regulates the substrate — where the compute sits, who owns the operator, who can reach the data — and it does so mostly through procurement rather than through product obligations.

They meet in one specific criterion. From level 2 upwards, data generated by using the service may not be used to train or fine-tune any AI system operated by a third country or a third-country entity, and may not be transferred outside the Union. That is a constraint on the supplier that lands in the buyer's own documentation: it is the sort of statement that belongs in a GDPR record of processing and in the technical documentation of an AI system, and it is far easier to make when the retrieval and audit layers are inside the perimeter to begin with.

For a system already built to answer the AI Act questions — what it was grounded on, what it answered, who approved it — the CADA vocabulary adds a second axis rather than a second programme: not what the system does, but who could interfere with it.

What this means for a self-hosted deployment

A point of precision first, because it is the sort of thing that gets overstated. CADA's recognition mechanism applies to cloud computing service providers offering services to Union entities and public sector bodies. A platform installed on a client's own infrastructure is not a cloud service being procured, so there is no assurance level to hold and none is claimed here. Nexus MDS Core is not recognised at any Union assurance level, and under the proposal as drafted it could not be.

What the annex does provide is the clearest public vocabulary yet for describing where a deployment stands. Several of its criteria are answered structurally by a self-hosted architecture rather than contractually: data, including metadata and telemetry, stays on infrastructure the organisation owns; no external operator holds administrative access; support is performed by whoever the client engages; the software stack is open-source and inspectable, so an SBOM, a dependency list and a migration plan are documentation exercises rather than negotiations.

Where a deployment uses an external inference endpoint for final generation — the sovereign hybrid model documented in the Federfarma case study — that component sits outside the perimeter and the CADA criteria about the provider apply to whoever operates it. Saying so plainly is the point. The architectural property that matters is that the component is replaceable, which is precisely the property Annex II keeps asking about in a different register: migration plans, effective control over components, separation from third-country entities.

If it becomes useful to describe deployments in CADA's terms — and for public sector buyers it will — the mapping to the three models used across this site is straightforward. A fully local deployment removes the questions the levels are asking rather than answering them. A sovereign hybrid deployment answers them for everything except the generation endpoint, which is where the buyer should demand a recognised service. EU private inference is the case where the assurance level of the provider becomes the whole of the answer.

What is worth doing now

  • —If you are a public body, or a supplier to one: find out which of your activities a public-order risk assessment would touch, because that determines whether level 1 or levels 2–4 apply to everything you buy afterwards.
  • —If you are a NIS2 Annex I entity: run the impact assessment before it is required. The exercise is the same either way, and doing it early means choosing your own scope.
  • —Ask every cloud and AI supplier, in writing, which level they intend to seek and when. The answer, and the speed of it, tells you more than the roadmap slide.
  • —Get the SBOM. It is the single artefact that serves CADA, the CRA and PLD 2024 at once, and the request itself is diagnostic.
  • —Identify which components would be unreplaceable if a supplier were withdrawn or restricted. That is the exposure the proposal is built around, and it is knowable today.

Sources

This analysis is written from the proposal, its annexes and the executive summary of the impact assessment, all published by the Commission on 3 June 2026. Where the page describes what a provision requires, the text of the proposal is the authority.

Regulatory analysis written from delivery experience in regulated environments. It is not legal advice, it describes a proposal that has not been adopted, and article numbers may change during the legislative procedure.

Where would your architecture stand?

The useful version of this question is not which level you would qualify for, but which components would fail the test — and what replacing them would cost.

Start the conversation →