Summary As proposed, the Cloud and AI Development Act (CADA) does not mandate source-code audits for all third-country software components. Instead, this requirement is strictly tied to the Union assurance levels: services seeking Level 2 or Level 3 recognition must subject security-relevant components from third-country manufacturers to source-code audits if those components are owned, licensed, or provided by a legal entity established outside the Union. Level 4 services face even stricter controls, requiring proof that third countries do not hold effective control over the design and evolution of such components. Crucially, providers at Levels 2 and 3 must also maintain a documented migration plan to ensure continuity if a vendor fails or a third country imposes restrictions.

Detail

The CADA proposal introduces a tiered sovereignty framework under Article 16 to mitigate risks associated with dependencies on non-European cloud providers. A central pillar of this framework is the rigorous scrutiny of software supply chains, particularly regarding components originating from third countries. The specific requirements for source-code audits, migration planning, and control structures are explicitly detailed in Annex II, which sets out the cumulative criteria for Union assurance levels 2, 3, and 4.

Level 2 and Level 3: Mandatory Audits for Security-Relevant Components

For cloud computing service providers seeking recognition at Union assurance level 2 or 3, the proposal imposes specific obligations regarding third-country software. According to Annex II 2.1(i)(ii) (for Level 2) and Annex II 3.1(i)(ii) (for Level 3), providers must implement and document controls where software components or products are provided, owned, and licensed by a legal entity established in a third country.

The text specifies two critical, cumulative actions for these specific components:

  1. Source Code Audits: Providers must ensure that security-relevant components from third-country software manufacturers are subject to source-code audits. This is not a blanket requirement for every line of code in a global stack, but specifically targets components where security risks are material. The audit must verify that no remote features or mechanisms exist that could materially tamper with or disrupt a device, system, or software.
  2. Migration Plans: Providers must have a documented migration plan in place for the event that the vendor fails or a third country imposes restrictions. This ensures operational continuity and reduces lock-in risks. The plan must be actionable, demonstrating that the provider can migrate to an alternative solution if the original vendor becomes unavailable or if geopolitical restrictions prevent the continued use of the component.

These provisions aim to prevent scenarios where a third-country actor could remotely tamper with, disrupt, or degrade a service through hidden features in the software. By requiring audits, the framework seeks to verify that no such remote access mechanisms exist. Additionally, Annex II 2.1(i)(iii) and 3.1(i)(iii) require providers to guarantee that no existing laws in the third country compel them to report software vulnerabilities to third-country authorities before those vulnerabilities are known to have been exploited.

Level 4: Effective Control and Design Integrity

At the highest assurance level, the requirements shift from mere auditability to structural independence. Annex II 4.1(i)(ii) mandates that providers demonstrate measures are in place to retain effective control over software components or products. Specifically, a third country or a legal entity established in a third country must not hold or exercise effective control over the design, development, maintenance, and evolution of those components.

"Effective control" is defined broadly to include the ability to materially influence the technical evolution, maintenance priorities, security remediation, and long-term continuity of the component. This means that even if a source-code audit passes, a Level 4 provider cannot rely on third-country components if the foreign entity retains the power to dictate how the software evolves or is secured. The focus here is on the governance of the component's lifecycle, not just its code integrity.

The Role of Auditing Organisations and Evidence

These criteria are verified through independent third-party audits for Levels 2, 3, and 4 (Article 20). Auditing organisations will assess compliance based on evidence listed in Annex III.

For software supply chain criteria, Annex III, Audit Criterion I requires audited providers to make available a complete and up-to-date software bill of materials (SBOM) and evidence of a risk-based process for identifying dependencies on external software manufacturers. The auditor must verify that:

  • The provider has identified alternative software solutions.
  • Tests have been implemented.
  • A switchover plan enabling migration to such alternative solutions exists.

The auditor must also verify that the provider has implemented controls to prevent the use of any remote features or mechanisms that could be used to materially tamper with or disrupt a device, system, or software. This verification includes reviewing test procedures, test reports, and change management procedures that cover firmware, BIOS, and software updates.

What this means for you

For CTOs, architects, and SMEs evaluating the practical impact of CADA, the distinction between assurance levels is critical. If your public sector clients only require Level 1 (which relies on self-assessment), the audit burden is lighter, though you must still demonstrate compliance with state-of-the-art cybersecurity standards and ensure no third-country laws compel vulnerability reporting (Annex II 1.1(g)).

However, if you aim for Level 2, 3, or 4 to access critical public sector contracts, your software supply chain documentation must be rigorous.

  1. Map Your Dependencies: You must identify all security-relevant components owned or licensed by third-country entities. A simple SBOM is not enough; you need to understand the ownership structure, licensing terms, and the specific "security-relevant" nature of each component to determine if it triggers the audit requirement.
  2. Prepare for Audits: For Levels 2 and 3, be ready to undergo source-code audits for these specific components. This may require negotiating new terms with vendors to allow for external audit access or investing in internal audit capabilities to pre-verify code before the official audit.
  3. Develop Migration Strategies: You must have documented, tested plans to migrate away from any third-country component if the vendor fails or if geopolitical restrictions are imposed. This moves beyond theoretical risk assessment to practical operational resilience. The plan must be actionable and include a switchover mechanism.
  4. Assess Control Structures for Level 4: If targeting Level 4, evaluate whether any third-country entity retains effective control over the design or evolution of your software. If they do, you may need to replace those components or restructure your development processes to ensure Union-based control over technical evolution and security remediation.

Common misconceptions

  • "All third-country software is banned." This is incorrect. CADA does not ban third-country components. It imposes transparency, audit, and control requirements. Third-country software can be used if it meets the specific criteria for the desired assurance level.
  • "Source-code audits apply to all open-source software." The requirement in Annex II 2.1(j) and 3.1(j) focuses on controls to prevent remote tampering or disruption. While open-source software is included, the specific source-code audit obligation for third-country manufacturers targets security-relevant components under the criteria in 2.1(i)(ii) and 3.1(i)(ii).
  • "Level 1 requires independent audits." No. Level 1 relies on a conformity self-assessment by the provider (Article 19). Independent third-party audits are only mandatory for Levels 2, 3, and 4 (Article 20).
  • "Migration plans are optional." For Levels 2 and 3, a documented migration plan is a mandatory criterion under Annex II 2.1(i)(ii) and 3.1(i)(ii). Without it, a provider cannot be recognised at these levels.

Official sources

Related

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