Summary Under the proposed Cloud and AI Development Act (CADA), the use of open-source software (OSS) in cloud services does not grant immunity from strict sovereignty and security mandates. For Union Assurance Levels 2, 3, and 4, providers must implement and document specific, verifiable controls to prevent the use of any remote features or mechanisms within open-source code that could materially tamper with, disrupt, or compromise the system. These obligations are cumulative: higher assurance levels inherit all lower-level requirements, creating a rigorous, auditable supply-chain security baseline for any provider seeking to serve EU public sector bodies.

Detail

The Cloud and AI Development Act (CADA), as proposed in COM(2026) 502 final, establishes a harmonized "Union cloud computing sovereignty framework" comprising four Union assurance levels (UALs). While Level 1 relies on a self-assessment declaration, Levels 2, 3, and 4 mandate independent third-party audits. A critical, non-negotiable component of these audits is the scrutiny of the software supply chain, specifically the management of open-source components.

The proposal explicitly rejects the notion that open-source code is inherently "safe" or exempt from sovereignty controls. Instead, it treats OSS as a potential vector for remote interference that must be actively neutralized through engineering controls and documented evidence.

The Core Obligation: Preventing Remote Tampering

The specific requirements for open-source controls are detailed in Annex II of the proposal. The language is consistent across the three highest assurance levels, emphasizing that the presence of open source is permissible only if accompanied by active prevention of remote compromise.

Union Assurance Level 2 (UAL 2) To qualify for UAL 2, a provider must meet the cumulative criteria in Annex II, Section 2.1. Point (j) sets the baseline for open-source security:

"where software released under an open-source licence is used for the provision of the service, the audited provider demonstrates 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;"

This clause requires providers to move beyond simple dependency listing. They must prove that their OSS stack is free from "kill switches," remote configuration backdoors, or telemetry hooks that could allow a third party (including a foreign state or malicious actor) to interfere with the service.

Union Assurance Level 3 (UAL 3) UAL 3 builds upon Level 2 with stricter personnel and control requirements, but the open-source obligation remains identical in its core mandate. Annex II, Section 3.1, point (j) states:

"where software released under an open-source licence is used for the provision of the service, the audited provider demonstrates 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;"

While the wording is the same, the context of UAL 3 is more demanding. Because UAL 3 services may handle classified information and require Union citizenship for personnel, the audit evidence required to prove the absence of remote tampering mechanisms must be correspondingly robust. The provider must demonstrate that the OSS controls are integrated into a broader framework of operational autonomy.

Union Assurance Level 4 (UAL 4) UAL 4 represents the highest tier of sovereignty, reserved for the most critical public-order activities. Annex II, Section 4.1, point (j) reiterates the same fundamental obligation:

"where software released under an open-source licence is used, the audited provider demonstrates 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;"

At this level, the scrutiny is intensified. The provider must also demonstrate effective legal, technical, and organizational separation from any third-country subsidiaries (Annex II, Section 4.1(k)) and ensure that no third country holds effective control over the design, development, or evolution of the software components (Annex II, Section 4.1(i)). The open-source controls in point (j) are thus part of a holistic "no third-country control" architecture.

The Role of Audit Evidence: From Claim to Proof

Compliance for Levels 2–4 is not self-declared. Article 20 mandates independent third-party audits, and Annex III (Audit Evidence for the Audit Procedure) specifies exactly what auditors must verify regarding open source.

Under Annex III, Section 10 (Audit criterion J – Open-source software), auditors are required to request specific evidence that the provider has:

  1. Tested for Remote Features: Evidence related to the testing of software components to prove the absence of any remote features or mechanisms that could be used to materially tamper with or disrupt a device, system, or software. This includes test procedures, test reports, and test plans.
  2. Secured Change Management: Evidence that the organisation's change management procedures cover any change in firmware, BIOS, and software updates, as well as the integration of new components, specifically to prevent the use of any remote feature or mechanism.
  3. Updated Maintenance Protocols: Evidence that maintenance procedures are updated to include preventing any remote feature or mechanism that could be used to materially tamper with or disrupt a device, system, or software.

Furthermore, Annex III, Section 9 (Audit criterion I) reinforces this by requiring a complete and up-to-date Software Bill of Materials (SBOM) and evidence of a risk-based process to identify and mitigate dependencies on external software manufacturers. If equivalent open-source solutions cannot be identified, the provider must demonstrate a switchover plan to ensure minimal viable functionality in the event of vendor failure or third-country restrictions.

This shifts the burden of proof entirely. A provider cannot simply state, "We use open source." They must demonstrate, via auditable evidence, that they have actively secured their open-source stack against remote compromise.

What this means for you

For CTOs, security architects, and compliance officers, the proposed CADA framework signals a paradigm shift: open source is no longer a sovereignty loophole. If you aim to serve EU public sector bodies, you must treat your open-source dependencies as high-risk assets requiring active, documented security governance.

1. Implement "Remote Feature" Scanning and Blocking You need tooling or processes capable of detecting "remote features" in your OSS stack. This includes checking for hardcoded API endpoints, telemetry hooks that send data to external servers, or configuration files that pull from remote URLs. Your documentation must prove that these features are either blocked, removed, or rendered inoperative.

2. Document Your Controls Rigorously CADA requires demonstrated and documented controls. You must maintain records of:

  • Static and dynamic analysis results for all OSS libraries.
  • Change management logs showing how updates are vetted specifically for remote access capabilities.
  • Maintenance protocols that explicitly address the prevention of remote tampering.
  • Test plans and reports proving the absence of remote mechanisms.

3. Prepare for Cumulative Audits If you target UAL 3 or 4, you must satisfy all UAL 2 requirements first. Your open-source controls will be subject to annual review (Article 20(8)). Ensure your supply chain visibility extends to sub-dependencies, as auditors will look for evidence of comprehensive risk-based processes to identify and mitigate weak OSS ecosystems (Annex III, Section 10).

4. SME Considerations While CADA includes provisions to support SMEs in public procurement, the technical requirements for open-source security at Levels 2–4 remain stringent. SMEs should prioritize automated supply-chain security tools that can generate the necessary audit trails for remote-feature prevention, as manual verification will not scale for the rigorous demands of an independent audit.

Common misconceptions

Misconception: Open source is exempt from sovereignty rules. Reality: CADA explicitly regulates open source used in cloud services. The assumption that "open code equals transparent and safe" is rejected; instead, open code is seen as a vector for remote tampering if not properly controlled.

Misconception: Only proprietary software needs supply chain scrutiny. Reality: Annex II applies the same "remote tampering" control requirement to open-source software as it does to proprietary components. In fact, because open source is often updated frequently, the requirement for documented change management and maintenance procedures is even more critical.

Misconception: UAL 1 has no open-source requirements. Reality: UAL 1 requires compliance with state-of-the-art cybersecurity standards and transparency around subcontractors (Annex II, Section 1.1). While it does not have the specific "remote tampering" clause of Levels 2–4, providers must still ensure their open-source usage does not compromise operational autonomy or security.

Misconception: You can use any open-source library from a public repository. Reality: You can, but you must demonstrate controls. If a library has a known remote configuration feature, you must prove you have disabled or removed it. The audit will check for this evidence.

Related

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