Summary As proposed, the Cloud and AI Development Act (CADA) mandates that cloud providers seeking Union assurance level 2 recognition must maintain a complete and up-to-date software bill of materials (SBOM). Defined by reference to the Cyber Resilience Act (Regulation (EU) 2024/2847), this SBOM must be made available to auditing organizations to verify that third-country software components are subject to source code audits and that documented migration plans exist to address vendor failure or third-country restrictions. Crucially, providers must also demonstrate controls to block remote features that could tamper with or disrupt the service.

Detail

The proposed Cloud and AI Development Act (CADA), COM(2026) 502 final, establishes a four-tiered sovereignty framework for cloud computing services, known as Union assurance levels. While Level 1 relies on self-assessment, Union assurance level 2 introduces a mandatory independent audit regime with stringent requirements regarding software supply chain transparency and resilience.

The specific obligations for Level 2 are codified in Annex II, point 2.1(i) of the proposal. This section sets out the cumulative criteria an audited provider must meet to be recognised as offering Union assurance level 2. It explicitly requires the provider to demonstrate that specific software supply chain measures are in place, moving beyond simple inventory to active risk management and decoupling capabilities.

The SBOM Requirement: Definition and Scope

The core of the Level 2 requirement is the maintenance and disclosure of a complete and up-to-date software bill of materials (SBOM). CADA does not define "software" or "SBOM" in isolation; instead, it cross-references existing Union law. Specifically, the proposal defines "software" by referencing Regulation (EU) 2024/2847 (the Cyber Resilience Act), specifically Article 3, point (39).

Under Annex II, point 2.1(i)(i), the provider must document and make available to the auditing organisation:

  1. A complete and up-to-date SBOM for all software components used in the provision of the service.
  2. A list of identified dependencies relevant to the provision of the service.

This is not a static inventory. The SBOM must be dynamic, reflecting the current state of the software stack, including all third-party libraries, open-source components, and proprietary dependencies. The "up-to-date" requirement implies that the SBOM must be refreshed whenever the software stack changes, ensuring the auditor always has a current view of the supply chain.

Controls on Third-Country Software Components

The SBOM serves as the foundational evidence for verifying compliance with stricter controls on software provided, owned, and licensed by legal entities established in third countries. Annex II, point 2.1(i)(ii) imposes specific obligations if such third-country software components or products are used.

The provider must implement and document controls to achieve two primary objectives:

  1. Blocking Remote Features: The provider must block any remote features that could materially tamper with or disrupt a device, system, or software, including during updates. This is a direct sovereignty safeguard against external actors degrading service continuity or accessing data via "kill switches" or backdoors embedded in third-country code.
  2. Source Code Audits and Migration Plans: Security-relevant components from third-country software manufacturers must be subject to source code audits. Furthermore, the provider must have a documented migration plan in place. This plan must address scenarios where the third-country vendor fails or where a third country imposes restrictions on the software. The migration plan ensures operational autonomy and prevents vendor lock-in that could compromise public order.

These measures ensure that even if a provider relies on non-EU software, they retain the technical and legal ability to decouple from that software if geopolitical risks materialise.

Audit Evidence and Verification

The SBOM and related documentation are not self-declared; they are verified through an independent audit process. Article 20 of CADA requires providers seeking Level 2 recognition to undergo independent third-party audits. The auditing organisation assesses compliance against the criteria in Annex II using audit evidence listed in Annex III.

Annex III, point 9 ("Audit criterion I - Ensuring the transparency of the software supply chain") details the specific evidence an auditing organisation should request to verify compliance with Annex II 2.1(i). This includes:

  • The SBOM and Dependencies: A complete and up-to-date SBOM for all software components, including open-source software, and a list of dependencies detailing the origin of the software (country of origin, designer, developer, maintainer), the degree of reliance on non-EU vendors, and visibility into the manufacturer chain.
  • Risk Mitigation Processes: Evidence of a risk-based process for identifying and mitigating dependencies on external software manufacturers.
  • Alternative Solutions and Switchover Plans: Proof that alternative software solutions (including open-source) have been identified. Crucially, the provider must demonstrate that switchover plans enabling migration to these alternatives are tested and ready. The auditor must verify that the provider can migrate to an alternative solution in the event of any defect, failure of the vendor, or restrictions from a third country.
  • Source Code Auditability: Evidence that the third-party independent auditor is granted the right to access and audit the source code of such software, and that all necessary documentation is available in a complete, accurate, and accessible format.

Context within the Sovereignty Framework

This requirement sits within the broader "Union cloud computing sovereignty framework" established by Article 16. The framework is designed to mitigate risks associated with dependence on third-country providers, such as unauthorized access to data or service disruption. By mandating SBOMs and migration plans at Level 2, CADA aims to ensure that even when third-country software is used, the EU provider retains effective control and can rapidly decouple from that software if geopolitical or operational risks materialise.

It is important to note that while Level 2 requires these measures, Level 3 and Level 4 impose even stricter criteria. For instance, Level 3 generally prohibits the use of software controlled by third-country entities unless a specific Commission decision allows it under strict conditions (Article 18), and Level 4 requires that third countries do not hold effective control over the design and maintenance of software components. However, Level 2 represents the first tier where explicit, audited migration plans and source code audit requirements for third-country components become mandatory for providers serving the public sector.

What this means for you

For CTOs, architects, and SMEs evaluating the practical impact of CADA, the Level 2 SBOM requirement signals a shift from voluntary supply chain transparency to mandatory, auditable compliance. If you plan to offer cloud services to EU public sector bodies or entities in sectors covered by Annex I or II of the NIS2 Directive, you must be prepared to meet these standards.

Immediate Actions for Cloud Providers

  1. Inventory and Automation: You must implement tools that automatically generate and maintain a complete SBOM for your entire software stack, including all third-party libraries, open-source components, and proprietary dependencies. Manual tracking will not suffice for the "up-to-date" requirement.
  2. Map Third-Country Dependencies: Identify all software components owned or licensed by entities outside the EU. For each, document the country of origin, the manufacturer, and the specific security-relevant components.
  3. Develop and Test Migration Plans: Create and test documented migration plans for critical third-country software. These plans must demonstrate how you would switch to alternative solutions (e.g., open-source equivalents or EU-based vendors) in the event of vendor failure or geopolitical restriction. Auditors will look for evidence that these plans are viable and tested, not just theoretical.
  4. Source Code Audit Readiness: Ensure that security-relevant components from third-country manufacturers are available for source code audits. This may require negotiating new contractual terms with vendors to allow for such inspections.
  5. Prepare for Audit: Engage with potential auditing organisations early. Understand the specific evidence they will request under Annex III, particularly regarding risk-based dependency mitigation and alternative solution identification.

Impact on Procurement

Public sector buyers and private entities in critical sectors should factor these requirements into their procurement strategies. When evaluating cloud providers, request evidence of their SBOM management and migration planning capabilities. Providers who can demonstrate robust supply chain transparency and resilience will be better positioned to achieve Union assurance level 2 recognition, making them eligible for contracts involving sensitive data or critical functions.

Strategic Considerations

For SMEs, the cost of compliance may be significant. However, the requirement also encourages the adoption of open-source and EU-based software components, which may simplify compliance. Consider investing in tools that automate SBOM generation and dependency analysis. Additionally, explore partnerships with EU-based software vendors to reduce reliance on third-country components, thereby lowering the complexity of your migration plans and audit evidence.

Common misconceptions

  • Misconception 1: "An SBOM is just a list of libraries."

    • Reality: Under CADA Level 2, the SBOM must be complete, up-to-date, and include detailed dependency information, including the origin and manufacturer of each component. It must also be supported by documented controls, such as blocking remote features and having tested migration plans. It is a dynamic compliance artifact, not a static inventory.

  • Misconception 2: "I can use any third-country software as long as I have an SBOM."

    • Reality: While Level 2 allows the use of third-country software, it imposes strict conditions. You must block remote tampering features, subject security-relevant components to source code audits, and have documented migration plans. Furthermore, Level 3 and 4 impose even stricter prohibitions on third-country control.

  • Misconception 3: "Migration plans are optional if I have a good SBOM."

    • Reality: Migration plans are explicitly required by Annex II 2.1(i)(ii) for third-country software components. The SBOM identifies the dependencies; the migration plan ensures you can decouple from them if necessary. Both are mandatory for Level 2 recognition.

  • Misconception 4: "Open-source software is exempt from SBOM requirements."

    • Reality: Annex III 9(1) explicitly states that the SBOM must include all software components, including open-source software. Open-source components must also be subject to the same dependency analysis and, if they contain remote features, the same controls to prevent tampering.

Official sources

Related

This is general information about a draft EU regulation, not legal advice.