Summary As proposed, the Cloud and AI Development Act (CADA) imposes rigorous software supply chain controls on cloud providers seeking Union assurance levels 2, 3, or 4. Engineering teams must maintain a complete, up-to-date Software Bill of Materials (SBOM) and document all dependencies for auditing. Crucially, providers must implement technical controls to block remote tampering features in third-country software, maintain documented migration plans for vendor failures, and, at Level 4, demonstrate effective control over the design and evolution of all software components. These requirements are cumulative and verified by independent third-party audits.

Detail

CADA's sovereignty framework (Title IV) links cloud procurement eligibility to strict technical and operational criteria defined in Annex II. For engineering and architecture teams, the most significant operational burdens lie in the software supply chain requirements for Union assurance levels 2, 3, and 4. These requirements are cumulative; a provider claiming Level 3 or 4 must satisfy all lower-level criteria first, as established in Article 20(1).

The core engineering obligations are detailed in Annex II, paragraphs 2.1(i), 3.1(i), and 4.1(i), which mandate specific software supply chain measures. These are not merely administrative checklists but require deep architectural changes to ensure operational autonomy and prevent third-country interference.

1. Mandatory SBOM and Dependency Transparency

Under Annex II, paragraphs 2.1(i), 3.1(i), and 4.1(i), cloud providers must demonstrate that specific software supply chain measures are in place. The foundational requirement is the creation and maintenance of a complete and up-to-date Software Bill of Materials (SBOM).

This SBOM is a primary audit evidence item. Under Annex III, Audit Criterion I, auditing organisations will request this SBOM for all software components, including open-source software (OSS). The SBOM must be accompanied by a detailed list of identified dependencies relevant to the service provision. This list must comprehensively cover:

  • All software modules, libraries, or APIs used.
  • Development tools.
  • The origin of the software (country of origin, designer, developer, maintainer).
  • The degree of reliance on non-EU vendors and proprietary technologies.
  • The degree of reliance on open-source software.
  • Visibility into the entire software manufacturer and sub-manufacturer chain, including audit rights.

The proposal explicitly states that for Level 3, evidence must show that if the software stack is provided by a third-country entity, "no unduly unjustified licensing restrictions are in place." This requires legal and engineering teams to collaborate to ensure that licensing terms do not prevent the necessary sovereignty controls.

2. Blocking Remote Tampering and "Kill Switches"

A critical engineering control introduced by CADA is the prohibition of remote features that could materially tamper with or disrupt a device, system, or software. This applies specifically to software components provided, owned, or licensed by legal entities established in third countries.

Annex II, paragraphs 2.1(i)(ii), 3.1(i)(ii), and 4.1(i)(ii) require providers to implement and document controls that:

  • Block any remote features that could materially tamper with or disrupt the system, including during updates.
  • Ensure that security-relevant components from third-country manufacturers are subject to source code audits.
  • Have a documented migration plan in the event that the vendor fails or a third country imposes restrictions.

For open-source software, Annex II, paragraphs 2.1(j), 3.1(j), and 4.1(j) require similar controls. Providers must demonstrate they have implemented and documented appropriate controls to prevent the use of any remote features or mechanisms that could be used to materially tamper with or disrupt the service. This requires engineering teams to actively test and verify that OSS libraries do not contain hidden remote access capabilities or "kill switches."

Annex III, Audit Criterion I(4) further details the evidence required, including test procedures, test reports, and test plans proving that remote features are disabled. It also mandates that change management procedures cover firmware, BIOS, and software updates to prevent the introduction of such features.

3. Effective Control at Level 4

The requirements escalate significantly at Union assurance level 4. While Levels 2 and 3 focus on blocking tampering and ensuring migration plans, Level 4 introduces a requirement for effective control over the software components themselves.

Annex II, paragraph 4.1(i)(ii) states that the audited provider must demonstrate measures in place to retain effective control over software components or products. Specifically, the provider must demonstrate that a third country or a legal entity established in a third country does not hold or exercise effective control over the design, development, maintenance, and evolution of those components.

The proposal defines "effective control" to include the ability to materially influence:

  • Technical evolution.
  • Maintenance priorities.
  • Security remediation.
  • Long-term continuity of the component.

This means that at Level 4, relying on third-country proprietary software is likely insufficient unless the EU provider has contractual or technical rights to override the third-country vendor's decisions on updates, security patches, and feature development. This may necessitate forking code, using only fully open-source components with no single third-country maintainer, or negotiating unprecedented levels of access and control with third-country vendors. Annex III, Audit Criterion I(3) requires evidence of a risk-based process for identifying and mitigating dependencies, including the identification of alternative solutions and a switchover plan.

4. Vulnerability Reporting Restrictions

Across Levels 1, 2, 3, and 4, providers subject to third-country control must guarantee that no existing laws or practices in that third country require them to report software vulnerabilities to third-country authorities before those vulnerabilities are known to have been exploited (Annex II, paragraphs 1.1(g), 2.1(i)(iii), 3.1(i)(iii)). This requires legal and engineering coordination to ensure that vulnerability disclosure policies do not conflict with third-country export controls or security reporting laws.

What this means for you

For CTOs and architects, CADA transforms software procurement and development workflows. Compliance is not a one-time checklist but a continuous operational state verified by independent auditors.

1. SBOM Automation is Non-Negotiable You cannot manually maintain an SBOM for a complex cloud stack. You must integrate Software Composition Analysis (SCA) tools into your CI/CD pipeline to automatically generate and update the SBOM and dependency list. This data must be readily accessible for auditing. The SBOM must trace back to the origin and maintainer of every library, which requires rigorous vendor due diligence.

2. Architectural Changes for "Kill Switches" You must audit all third-party and open-source components for remote management capabilities. If a library allows a maintainer to push updates that could disable functionality (a common pattern in some commercial SDKs), you must block this capability or replace the component. This may require:

  • Disabling telemetry and remote update channels in configuration files.
  • Forking code to remove remote access endpoints.
  • Implementing network-level blocks to prevent outbound connections to third-country update servers.

3. Migration Planning as an Engineering Deliverable You must maintain documented, tested migration plans for critical software components. If a third-country vendor ceases support or a sanction is imposed, you must be able to switch to an alternative solution. This implies:

  • Identifying alternative (preferably EU-based or open-source) solutions for all critical dependencies.
  • Regularly testing the switch-over process to ensure it works within acceptable timeframes.
  • Documenting the steps required for migration.

4. Level 4 Requires Sovereign Software Stacks If you aim for Level 4, you must assess whether you have "effective control" over your software stack. If you rely on a third-country proprietary API or library, you likely do not have effective control over its evolution or maintenance priorities. To comply, you may need to:

  • Use only open-source software where the EU entity maintains the fork or is a primary maintainer.
  • Negotiate contracts that grant the EU provider the right to unilaterally modify, update, and maintain the software, overriding the third-country vendor's roadmap.
  • Develop in-house alternatives for critical components.

5. Audit Readiness Auditors will request the SBOM, dependency lists, test reports for remote tampering controls, and migration plans. They will also review source code audits for security-relevant components from third countries. Ensure your documentation is up-to-date and that your engineering team can explain the controls in place.

Common misconceptions

Misconception 1: "We only need an SBOM for Level 4." Correction: SBOM and dependency documentation are required for Levels 2, 3, and 4. Level 1 has a simpler self-assessment but still requires transparency around subcontractors and cybersecurity standards. The complexity and depth of the SBOM analysis increase with the level, but the baseline requirement starts at Level 2.

Misconception 2: "Open-source software is exempt from these controls." Correction: Open-source software is explicitly included. Annex II requires controls to prevent remote tampering in OSS and mandates that OSS dependencies be listed in the SBOM. If an OSS component is maintained by a third-country entity, you must still demonstrate that you can block remote features and that you have a migration plan if the maintainer withdraws support or is compelled by a third country to act against EU interests.

Misconception 3: "We can use any third-country software if we have a contract." Correction: At Levels 2 and 3, you can use third-country software if you block remote tampering and have migration plans. However, at Level 4, you must demonstrate "effective control" over the design, development, maintenance, and evolution of the software. A standard commercial contract rarely grants the EU provider the right to override the third-country vendor's technical roadmap or maintenance priorities. Therefore, using third-country proprietary software at Level 4 is highly risky and likely non-compliant unless you have exceptional contractual or technical control.

Misconception 4: "This is just a cybersecurity requirement." Correction: While it overlaps with cybersecurity, CADA's focus is on sovereignty and operational autonomy. The goal is to prevent third countries from disrupting services or accessing data through software backdoors or kill switches. The requirements are about maintaining control over the technology stack, not just preventing breaches.

Related

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