Summary Under the proposed Cloud and AI Development Act (CADA), software supply-chain controls intensify significantly across the four Union assurance levels. While Level 1 relies on baseline cybersecurity and subcontractor transparency, Level 2 mandates a complete, up-to-date Software Bill of Materials (SBOM) and dependency mapping. Level 3 introduces strict requirements for source-code audits of third-country components and explicit blocking of remote tampering features. Level 4 escalates to a prohibition on third-country "effective control" over the software's design, development, and evolution. Crucially, open-source software requires specific controls to prevent remote tampering mechanisms across all tiers from Level 2 upwards, regardless of the code's public availability.

Detail

The Cloud and AI Development Act (CADA), as proposed in COM(2026) 502 final, establishes a tiered sovereignty framework designed to mitigate risks associated with dependencies on non-European cloud providers. Central to this framework is the recognition that software supply chains are a primary vector for state-sponsored disruption, data exfiltration, or service degradation. The proposal differentiates the required software supply-chain controls based on the sensitivity of the public-sector activity, categorized into four Union assurance levels defined in Annex II.

While Level 1 sets a baseline for providers established in the Union, Levels 2, 3, and 4 introduce cumulative, increasingly stringent requirements for software transparency, auditability, and control. These requirements are detailed in Annex II, Sections 2.1(i), 3.1(i), and 4.1(i), which specifically address software supply-chain measures.

Level 1: Baseline Cybersecurity and Transparency

At Union Assurance Level 1, the focus is on establishing a baseline of trust rather than deep supply-chain forensics. Providers must demonstrate that their service complies with state-of-the-art cybersecurity standards and provide "full transparency around the use of subcontractors."

Crucially, Level 1 does not explicitly mandate a Software Bill of Materials (SBOM) or source-code audits. Instead, it requires that if a provider is subject to third-country control, they must guarantee that no laws in that third country require reporting software vulnerabilities to foreign authorities before those vulnerabilities are known to have been exploited. This creates a "break-glass" protection against coordinated vulnerability disclosure abuse but does not require the granular visibility demanded by higher tiers. The requirement for a detailed SBOM and dependency mapping begins strictly at Level 2.

Level 2: The SBOM Mandate and Dependency Mapping

Moving to Union Assurance Level 2, the requirements shift from general transparency to specific, auditable documentation. Annex II, Section 2.1(i) mandates that providers demonstrate specific software supply-chain measures are in place. The cornerstone of Level 2 is the requirement for a "complete and up-to-date software bill of materials (SBOM)" and a list of identified dependencies relevant to the service provision.

This SBOM must be made available to the auditing organisation. It is not merely a static list; it must be accompanied by controls that address third-country software components. If software components are provided, owned, or licensed by a legal entity established in a third country, the provider must implement controls to:

  1. Block remote tampering: Implement controls to block any remote features that could materially tamper with or disrupt the device, system, or software (including during updates).
  2. Source-code audits: Ensure that security-relevant components from third-country manufacturers are subject to source-code audits.
  3. Migration plans: Maintain a documented migration plan in the event of vendor failure or third-country restrictions.

Furthermore, for open-source software used in the service, the provider must demonstrate controls to prevent the use of remote features or mechanisms that could tamper with or disrupt the system. This marks the first tier where "kill switches" or remote tampering capabilities in third-party code must be explicitly blocked and documented.

Level 3: Source-Code Audit Rights and Stricter Separation

Union Assurance Level 3 is designed for activities contributing to public order, such as national security or critical infrastructure. The software supply-chain controls here become more invasive. Annex II, Section 3.1(i) retains the SBOM requirement but tightens the conditions for third-country software.

At this level, the provider must ensure that security-relevant components from third-country manufacturers are subject to source-code audits. Unlike Level 2, where the audit requirement is framed as a control to be implemented, Level 3 implies a stricter enforcement where the auditing organisation must have the ability to verify these audits directly. The provider must also demonstrate that there are no existing laws in a controlling third country requiring the reporting of software vulnerabilities to foreign authorities prior to exploitation.

Additionally, Level 3 requires effective legal, technical, and organizational separation between the Union parent company and any third-country subsidiaries. This ensures that even if a provider operates globally, the software stack serving Union public-sector bodies at Level 3 is insulated from foreign operational influence. The SBOM and dependency lists must be available to the auditor, who will assess whether the provider has identified alternative software solutions (including open-source) and has a switchover plan if a vendor fails or restrictions are imposed.

Level 4: Effective Control and Sovereign Code

Union Assurance Level 4 represents the highest tier of sovereignty, reserved for the most sensitive activities involving classified information or critical public order functions. Annex II, Section 4.1(i) introduces the concept of "effective control."

At Level 4, providers must demonstrate that a third country or legal entity established in a third country does not hold or exercise effective control over the design, development, maintenance, and evolution of the software components or products. "Effective control" is defined in the proposal as the ability to materially influence technical evolution, maintenance priorities, security remediation, and long-term continuity.

This is a significant escalation from Levels 2 and 3. While lower levels allow for third-country software if it is audited and migration plans exist, Level 4 effectively requires that the core software stack be under sovereign control. Providers must prove that they retain the ability to make independent decisions about the software's future without external coercion or influence.

Like Level 3, Level 4 requires open-source software to be free of remote tampering features. However, the burden of proof is higher, as the auditor must verify that no third-party entity, including open-source foundations established in third countries, can exert effective control over the component's evolution.

Open-Source Software Controls Across Tiers

Open-source software (OSS) is treated distinctly but consistently across Levels 2, 3, and 4. Annex II Sections 2.1(j), 3.1(j), and 4.1(j) all require providers to demonstrate that they have implemented and documented controls to prevent the use of remote features or mechanisms that could materially tamper with or disrupt the system.

This means that even if the code is open and auditable, the deployment and integration of that code must be secured against remote activation of malicious features. Providers cannot rely solely on the open nature of the code; they must actively verify and block any potential backdoors or remote execution capabilities, regardless of whether the software is proprietary or open-source.

What this means for you

For CTOs, architects, and SMEs evaluating CADA's impact, the tiered approach means that "one-size-fits-all" compliance is impossible. Your software supply-chain strategy must be modular and scalable to meet different assurance levels.

For Level 2 Compliance: You must invest in SBOM generation tools that integrate with your CI/CD pipelines. Manual SBOMs will not suffice for audit readiness. You need to map all dependencies, including transitive ones, and identify which components originate from third countries. For each third-country component, you must document how you block remote tampering features. This may involve containerization, network segmentation, or code modification. If you rely on proprietary third-country software, you must have a documented migration plan to an alternative (potentially open-source) solution.

For Level 3 Compliance: Beyond the SBOM, you must prepare for source-code audits of security-relevant components. This requires maintaining clean, auditable code repositories and ensuring that your vendors provide access to source code for security reviews. You must also implement strict legal and technical separation between your Union operations and any global subsidiaries. This may involve dedicated infrastructure, isolated development environments, and rigorous access controls to ensure that foreign entities cannot influence the software's operation or security updates.

For Level 4 Compliance: This level demands a fundamental review of your software stack's ownership and control. You must prove that no third country holds effective control over your core software. This may require shifting to fully EU-developed software or open-source solutions where the governance is transparent and EU-aligned. You must document the decision-making processes for software evolution, security remediation, and maintenance to demonstrate independence from foreign influence. This is a high-bar requirement that may necessitate significant architectural changes or vendor switching.

For All Tiers: Open-source governance is critical. You must implement processes to detect and block remote tampering features in OSS. This includes regular code scans, dependency monitoring, and potentially contributing to upstream projects to ensure security. You should also prepare for the requirement to identify alternative OSS solutions and maintain switchover plans.

Common misconceptions

Misconception 1: Open-source software is automatically compliant. Many assume that because open-source code is visible, it automatically meets CADA's supply-chain requirements. This is incorrect. CADA explicitly requires controls to prevent remote tampering features in OSS at Levels 2, 3, and 4. Merely using OSS does not exempt you from demonstrating that the software cannot be remotely disrupted or manipulated. You must actively verify and secure the integration of OSS components.

Misconception 2: Level 1 requires an SBOM. Level 1 focuses on general cybersecurity standards and transparency around subcontractors. It does not mandate a detailed SBOM or source-code audits. These requirements begin at Level 2. Providers should not over-invest in SBOM automation for Level 1 services if they do not intend to pursue higher assurance levels.

Misconception 3: Third-country software is banned at all levels. Third-country software is not outright banned at Levels 2 and 3. Instead, it is subject to strict controls, including source-code audits and migration plans. The ban on "effective control" by third countries applies primarily at Level 4. At lower levels, you can use third-country software if you can prove it is secure, auditable, and replaceable.

Misconception 4: SBOMs are a one-time deliverable. The SBOM must be "complete and up-to-date." This implies continuous integration and monitoring. A static SBOM generated at deployment will not satisfy audit requirements if dependencies change during the service lifecycle. Auditors will expect evidence of ongoing dependency management and updates to the SBOM.

Related

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