Summary As proposed, the Cloud and AI Development Act (CADA) imposes strict, escalating controls on open-source software (OSS) for cloud providers seeking Union Assurance Levels 2, 3, and 4. Providers must demonstrate documented controls to prevent remote tampering or disruption via OSS components, a requirement explicitly set out in Annex II paragraphs 2.1(j), 3.1(j), and 4.1(j). While Level 1 relies on self-assessment and general cybersecurity standards, Levels 2–4 require independent third-party audits to verify these specific security measures, ensuring that open-source dependencies do not introduce hidden backdoors, unauthorized remote execution, or "kill switches" that could compromise service continuity.

Detail

The CADA proposal introduces a tiered sovereignty framework designed to mitigate risks associated with third-country control and supply chain vulnerabilities. A critical component of this framework is the treatment of software supply chains, including open-source components. The requirements for open-source controls are not uniform; they escalate significantly as providers move from Union Assurance Level 1 to Level 4, shifting from general compliance to specific, auditable technical mandates.

The Baseline: Union Assurance Level 1

Under Article 16, Level 1 represents the minimum baseline for public sector procurement. Providers seeking this level must conduct a conformity self-assessment. While Annex II 1.1 requires providers to demonstrate state-of-the-art cybersecurity standards and transparency around subcontractors, it does not explicitly mandate the specific, granular open-source remote-tampering controls found in the higher tiers. The focus at Level 1 is on establishment in the Union, data localization, and general cybersecurity compliance. The specific "remote tampering" clause is absent from the Level 1 criteria.

Escalating Controls: Levels 2, 3, and 4

For providers aiming for Union Assurance Levels 2, 3, or 4, the proposal introduces cumulative criteria that include stringent software supply chain measures. These levels require independent third-party audits (Article 20) to verify compliance.

The specific requirement for open-source software is explicitly detailed in Annex II. The text is consistent across the three higher tiers, creating a unified technical standard for high-assurance services:

  • Level 2: Annex II 2.1(j) states that where software released under an open-source licence is used, the audited provider must "demonstrate that it has implemented and documented the appropriate 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."
  • Level 3: Annex II 3.1(j) repeats this exact requirement for Level 3 providers.
  • Level 4: Annex II 4.1(j) applies the same mandate for the highest assurance level.

These provisions target the risk of "remote tampering" or "disruption" via open-source components. This addresses scenarios where open-source libraries or frameworks might contain hidden remote access trojans, kill switches, or update mechanisms that could be exploited by malicious actors or third-country authorities to disrupt service continuity or compromise data integrity. The requirement is cumulative; a provider at Level 4 must meet the Level 2 and 3 criteria in addition to the Level 4 specificities.

Supporting Evidence and Auditability

The requirement to "implement and document" controls is not merely a policy statement; it is subject to rigorous audit evidence. Annex III, which outlines the audit evidence for the procedure, provides further context. Under Audit Criterion J (Open-source software), auditing organizations must assess whether providers have:

  1. Implemented mechanisms to detect and provide timely notice if open-source software is acquired by or comes under the control of a third country or a legal entity established in a third country.
  2. Evidence of a risk-based process to identify and mitigate weaknesses in the open-source ecosystem, such as lack of community support or deprecated components.
  3. Documented procedures to prevent the use of remote features or mechanisms that could tamper with or disrupt the system.

Furthermore, for Levels 2–4, providers must maintain a complete and up-to-date Software Bill of Materials (SBOM) (Annex II 2.1(i), 3.1(i), and 4.1(i)). This SBOM must be made available to the auditing organization, ensuring full transparency into the open-source dependencies used in the cloud service. The audit evidence requirements in Annex III explicitly require proof that the provider has tested the software components 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.

Interaction with Third-Country Control

The open-source controls are closely linked to the broader sovereignty requirements. For instance, Annex II 2.1(g) and 3.1(g) require providers to demonstrate that third-country control does not enable access to customer data or disruption of service. If an open-source component is controlled by a third-country entity, the provider must show effective legal, technical, and organizational separation (Annex II 2.1(k) and 3.1(k)). The remote-tampering controls in paragraphs (j) are the technical implementation of this broader sovereignty goal.

Notably, Annex II 4.1(i) introduces an additional layer for Level 4 regarding "effective control" over software components, requiring the provider to demonstrate that a third country does not hold or exercise effective control over the design, development, maintenance, and evolution of those components. This complements the remote-tampering rule by ensuring that the governance of the open-source project itself does not fall under hostile influence, which could indirectly enable remote tampering.

What this means for you

For CTOs, architects, and SMEs evaluating the practical impact of CADA, these provisions translate into immediate operational changes for any entity targeting the EU public sector market at Assurance Levels 2–4.

1. Audit-Ready Documentation You cannot simply claim that your open-source stack is secure. You must have documented policies and technical controls that specifically address remote tampering. This means moving beyond standard vulnerability scanning (e.g., CVE checks) to actively verifying that open-source components do not contain remote execution capabilities, unauthorized update mechanisms, or hidden telemetry that could be leveraged for disruption. Your documentation must explicitly map how these controls prevent "material tampering."

2. Supply Chain Visibility The requirement for a detailed SBOM (Annex II 2.1(i)) means you must have full visibility into your open-source dependencies, including transitive dependencies. Auditors will expect to see this SBOM and will verify that your risk management processes cover the entire stack. You must be able to trace the origin of every component and demonstrate that no third-country entity holds effective control over its evolution.

3. Third-Party Audit Preparation Unlike Level 1, Levels 2–4 require independent audits (Article 20). Auditors will specifically look for evidence of the controls mentioned in Annex II 2.1(j)/3.1(j)/4.1(j). Prepare to demonstrate:

  • Code reviews or static analysis results proving the absence of remote tampering mechanisms.
  • Procedures for monitoring open-source project governance (e.g., detecting if a maintainer is compromised or if the project is acquired by a hostile entity).
  • Incident response plans specifically for open-source supply chain attacks.
  • Evidence of migration plans in the event a vendor fails or a third country imposes restrictions (Annex II 2.1(i)(ii)).

4. Strategic Sourcing and Governance Consider the governance of your open-source dependencies. If a critical library is maintained by a single individual in a high-risk jurisdiction, or if the project is funded by a third-country entity, you may face higher scrutiny under the "third-country control" criteria. Proactively assessing the provenance and governance of your OSS stack is now a sovereignty requirement, not just a security best practice. For Level 4, you must demonstrate that you retain effective control over the technical evolution of your critical components.

Common misconceptions

Misconception 1: Open-source software is banned. CADA does not prohibit the use of open-source software. On the contrary, Article 41 encourages the use of open-source solutions. The regulation targets the risks associated with OSS, specifically remote tampering and third-country control, not the licensing model itself.

Misconception 2: Level 1 has the same OSS requirements as Levels 2–4. Level 1 requires general cybersecurity compliance and transparency, but it does not explicitly mandate the specific "remote tampering" controls found in Annex II 2.1(j)/3.1(j)/4.1(j). Level 1 is self-assessed, while Levels 2–4 are independently audited. The depth of scrutiny and the specificity of the controls increase significantly at Level 2.

Misconception 3: Only proprietary software is subject to supply chain controls. The regulation explicitly includes open-source software in its supply chain requirements. Annex II 2.1(j) and its counterparts for Levels 3 and 4 specifically mention "software released under an open-source licence." Providers cannot bypass these controls by using OSS.

Misconception 4: A standard vulnerability scan is sufficient. Standard vulnerability management (e.g., patching known CVEs) is necessary but not sufficient. The requirement to prevent "remote features or mechanisms that could be used to materially tamper" goes beyond known vulnerabilities. It requires active verification that the code does not contain hidden backdoors or unauthorized remote execution capabilities, which may not be listed as CVEs.

Misconception 5: The controls are optional for open-source. The controls are mandatory for any cloud service seeking Union Assurance Levels 2, 3, or 4. The text in Annex II uses the phrase "the audited provider demonstrates," indicating a mandatory proof of compliance, not a voluntary best practice.

Related

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