Does 'open source first' override security requirements under CADA?

Summary No. The "open source first" principle in the proposed Cloud and AI Development Act (CADA) does not override, lower, or bypass security requirements. Article 41 explicitly mandates that Union entities and public sector bodies must encourage the use of open source "taking into account functionalities, including security, total cost, and other relevant, duly justified objective criteria." Security is an explicit, binding constraint in the decision-making process. The proposal frames open source as a tool for auditability and sovereignty, not a shortcut for compliance. If an open source solution fails to meet the necessary security thresholds for a specific use case, the "open source first" encouragement does not compel its adoption.

Detail

The proposed Cloud and AI Development Act (CADA), COM(2026) 502 final, introduces a strategic framework to strengthen Europe's cloud and AI ecosystem. A critical component of this framework is the promotion of open source to reduce vendor lock-in and enhance technological sovereignty. However, for Chief Technology Officers (CTOs), architects, and public procurement officers, a central question arises: does the push for open source compromise the rigorous security standards required for critical infrastructure?

The text of the proposal resolves this tension by embedding security as a primary, equal-weight criterion in the selection process. The "open source first" approach is an encouragement to consider open source, but it is strictly conditioned on a balanced evaluation of objective criteria where security remains paramount.

Article 41: The Mandatory Balancing Test

Article 41, titled "Promoting open source solutions and open source first," establishes the legal obligation for Union entities and Member States. The provision does not create an absolute mandate to use open source regardless of risk. Instead, it sets up a comparative evaluation framework.

The full text of Article 41 states:

"The Union and Member States shall take the necessary measures to encourage Union entities and public sector bodies to use and facilitate the reuse of open standards and components released under an open source licence when building their cloud and AI ecosystem or stack, taking into account functionalities, including security, total cost, and other relevant, duly justified objective criteria."

This provision is legally significant for three specific reasons:

Security is an Explicit Criterion: The text does not merely mention "security" in passing; it lists it alongside "functionalities" and "total cost" as a core factor that must be taken into account. This phrasing ensures that security is not an afterthought. A decision to adopt an open source solution cannot be made in a vacuum; it must pass a security assessment that is at least equivalent to any proprietary alternative. If an open source component lacks the necessary security controls for a specific high-risk use case, the "encouragement" to use it does not override the requirement to ensure security.
No Lowering of the Security Bar: The phrase "taking into account" implies a comparative evaluation where all criteria are weighed. The proposal does not suggest that open source solutions receive a "security discount." The security requirements governing the cloud and AI ecosystem—such as the Union Assurance Levels established in Article 16 and the cybersecurity certification requirements in Annex II—apply uniformly. An open source component seeking recognition at Union Assurance Level 3 or 4 must still meet the stringent criteria for personnel screening, data localization, and cybersecurity certification. The "open source first" principle encourages the selection of such components, but the security validation remains rigorous and non-negotiable.
Requirement for Objective Justification: The requirement to use "duly justified objective criteria" prevents arbitrary or ideological decisions. A contracting authority cannot choose a proprietary solution simply because it is familiar, nor can they choose an open source solution simply because it is free or politically favored, if it lacks the necessary security controls. The justification for the choice must be documented, defensible, and based on the specific functional and security needs of the project. This ensures that the "open source first" principle serves the public interest (sovereignty and efficiency) without compromising the safety of public services.

The Strategic Rationale: Transparency and Auditability

To understand why CADA promotes open source without sacrificing security, one must look to the explanatory memorandum, specifically Recital 81. The recital argues that open source plays a vital role in ensuring "transparency, security and efficiency." It posits that:

"Access to the source code enables auditability, fosters collaboration and reuse and reduces dependency on a single vendor, thereby limiting the risk of vendor lock-in."

This reframes open source not as a security risk, but as a potential security enhancer in the context of sovereignty. In the context of CADA's broader goals of reducing dependence on non-EU providers (as noted in Recital 46), open source allows for independent verification of code. This is crucial for meeting the stringent audit requirements of Union Assurance Levels 2, 3, and 4, which require detailed evidence regarding the software supply chain (see Annex II, Section 3, point (i)). For advanced architectures, the ability to audit source code for backdoors or vulnerabilities is often more secure than relying on a "black box" proprietary solution, provided the open source project is actively maintained and secured.

Interaction with Union Assurance Levels and Cybersecurity

CADA introduces a four-tier sovereignty framework (Union Assurance Levels 1–4) in Article 16. The higher levels (3 and 4) have strict requirements regarding third-country control and cybersecurity certification. Article 41 does not exempt open source projects from these requirements.

Cybersecurity Certification: Under Annex II, Union Assurance Level 2 requires a European cybersecurity certificate of at least assurance level "substantial," while Level 4 requires a "high" assurance level. Open source components must still undergo this certification process. The transparency of the source code may facilitate the audit process, but it does not replace the need for a formal certificate or a "positive" audit opinion from an independent auditing organization (Article 20).
Software Supply Chain: Annex II requires a complete and up-to-date Software Bill of Materials (SBOM) and controls for third-country software components. Open source projects must demonstrate that they have implemented controls to prevent remote tampering and have migration plans in case of vendor failure. The "open source first" principle encourages the use of such transparent supply chains, but the compliance burden remains high.

Total Cost of Ownership (TCO) as a Security Proxy

Article 41 also explicitly mentions "total cost." This is significant for public bodies and SMEs. While open source software may have lower licensing fees, the total cost includes integration, maintenance, and security patching. CADA's framework acknowledges that a secure open source solution might have higher upfront integration costs but offers long-term savings and reduced vendor lock-in.

The decision must balance these economic factors against security risks. A cheap, unsecured open source tool is not a viable option under CADA if it jeopardizes the "total cost" through potential breaches, compliance failures, or the need for costly remediation. The "duly justified objective criteria" requirement ensures that the cost-benefit analysis includes the cost of security failures.

What this means for you

For CTOs, architects, procurement officers, and SMEs evaluating the practical impact of CADA, the following actions are recommended to ensure compliance with Article 41 while maintaining security:

Document Your Balancing Test: Ensure your procurement and technology selection processes explicitly document how security, functionality, and cost were weighed. When choosing between open source and proprietary solutions, create a record of the security assessment for both. This documentation will be crucial for demonstrating compliance with Article 41's requirement for "duly justified objective criteria." If you choose a proprietary solution over an open source one, your justification must be based on security or functional gaps, not just preference.
Prioritize Auditable Open Source: Leverage the "open source first" principle by selecting projects with strong governance, active maintenance, clear security policies, and a transparent supply chain. CADA's emphasis on auditability (Recital 81) favors projects that allow for independent code review, which is essential for meeting higher Union Assurance Levels. Look for projects that already provide SBOMs and have a track record of security patching.
Do Not Assume Security Compliance: Just because a tool is open source does not mean it is secure or compliant with CADA's sovereignty requirements. You must still perform rigorous security audits, vulnerability assessments, and ensure that the software supply chain (including dependencies) is transparent and secure. The "open source first" principle is an encouragement to consider open source, not a waiver of security obligations.
Plan for Total Cost of Ownership (TCO): Evaluate the total cost of ownership, including the resources needed for security maintenance, patching, and integration. CADA's framework supports open source as a strategic investment in sovereignty and efficiency, but only if the long-term security and operational costs are manageable. A solution that is "free" but requires expensive security remediation may fail the "total cost" criterion.
Engage with Open Source Programme Offices (OSPOs): Article 44 establishes a network of Open Source Programme Offices. Engage with these bodies to access best practices, templates, and guidance on securing open source components within the CADA framework. They can provide the "objective criteria" and technical expertise needed to justify your decisions.

Common misconceptions

Misconception: "Open source first" means I must use open source even if it's less secure.
- Reality: Article 41 requires taking security into account. If an open source solution fails to meet the necessary security standards for a specific use case, it should not be adopted. Security is a binding constraint, not a flexible guideline. The "encouragement" is conditional on meeting all objective criteria.
Misconception: Open source is automatically more secure under CADA.
- Reality: While Recital 81 highlights the benefits of auditability, open source is not inherently secure. Poorly maintained, abandoned, or vulnerable open source projects pose significant risks. CADA requires rigorous security assessments regardless of the licensing model. The transparency of the code is a tool for verification, not a guarantee of safety.
Misconception: CADA bans proprietary software.
- Reality: CADA encourages open source but does not prohibit proprietary solutions. Proprietary software can be used if it meets the security, functionality, and cost criteria, and if it complies with the relevant Union Assurance Levels. The "open source first" principle is an encouragement to consider open source, not a mandate to exclude proprietary options.
Misconception: Security requirements are lower for open source components.
- Reality: The security bar is uniform. Open source components must meet the same cybersecurity certification and audit requirements as proprietary ones, especially for higher Union Assurance Levels. The transparency of open source may facilitate audits, but it does not lower the standards or the need for a "positive" audit opinion.

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