How does open source support security and auditability under CADA?

Under the proposed Cloud and AI Development Act (CADA), open source is positioned as a strategic lever for security and auditability, not merely a licensin

Summary Under the proposed Cloud and AI Development Act (CADA), open source is positioned as a strategic lever for security and auditability, not merely a licensing preference. Recital 81 explicitly states 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." Article 41 mandates that the Union and Member States encourage public sector bodies to use open standards and components released under open source licenses, provided that functionalities—including security, total cost, and other relevant, duly justified objective criteria—are taken into account. This establishes a framework where transparency is a security enabler, but security remains the decisive factor in procurement.

Detail

The proposed Cloud and AI Development Act (CADA), COM(2026) 502 final, fundamentally shifts the perception of open source from a cost-saving measure to a core component of the EU's technological sovereignty and security architecture. For technical leaders, this means that the ability to inspect code is no longer just a developer preference but a regulatory expectation for public sector digital infrastructure.

The Legal Mandate: Article 41 and Recital 81

The cornerstone of this approach is Article 41, titled "Promoting open source solutions and open source first." This article imposes a binding obligation on the Union and Member States to "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."

However, this encouragement is strictly conditional. Article 41 clarifies that the choice of software must be made "taking into account functionalities, including security, total cost, and other relevant, duly justified objective criteria." This phrasing is critical: it prevents a rigid "open source only" mandate that could compromise security. Instead, it creates a balanced evaluation framework where open source is the default preference, but only if it meets the required security standards. If a proprietary solution offers superior security or cost-efficiency that is objectively justified, it may still be selected.

The policy rationale is explicitly detailed in Recital 81, which serves as the interpretative guide for Article 41. The recital states: "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." It further argues that "Promoting the use of open source is therefore essential to support innovation, ensure better value for public expenditure and strengthen the Union's digital autonomy."

For security architects, the link between access to source code and auditability is the most significant element. In high-stakes environments, the ability to independently verify the integrity of software is a prerequisite for trust. CADA formalizes this by recognizing that transparency through open source is a mechanism to enhance security, rather than a risk to be mitigated.

Open Source as a Security and Auditability Mechanism

Under the proposed CADA framework, open source supports security and auditability through three distinct mechanisms derived from the text of Recital 81 and the operational requirements of Article 41:

Auditability through Source Code Access: Recital 81 explicitly notes that "access to the source code enables auditability." In the context of CADA, this means that public sector bodies can independently verify security controls, data handling practices, and algorithmic logic. This is particularly vital for AI systems and cloud stacks where "black box" operations can obscure vulnerabilities or bias. By encouraging open source, CADA promotes an environment where the codebase can be scrutinized for backdoors, vulnerabilities, or non-compliance with Union law. This aligns with the broader sovereignty framework, where independent audits are required for higher assurance levels.
Collaboration and Reuse: The recital highlights that open source "fosters collaboration and reuse." For the public sector, this translates to a collective defense model. Instead of relying on a single vendor's proprietary support cycle, public bodies can leverage security patches, improvements, and innovations developed by a broader community. This collaborative model enhances the overall resilience of the software ecosystem, allowing for faster responses to emerging threats and reducing the time-to-patch for critical vulnerabilities.
Reduction of Vendor Lock-in: Vendor lock-in is identified in Recital 81 as a risk that open source mitigates by "reducing dependency on a single vendor." From a security and sovereignty perspective, lock-in creates a single point of failure. If a public body is dependent on a single proprietary vendor, it may lack the leverage to demand urgent security updates, migrate away from a compromised system, or switch providers if the vendor's geopolitical alignment changes. Open source solutions, by definition, allow for portability and independent maintenance, thereby mitigating these strategic risks and ensuring operational continuity.

Integration with the Sovereignty Framework

While Article 41 focuses on procurement and development choices, it operates in tandem with CADA's broader Title IV sovereignty framework. The sovereignty framework establishes four "Union assurance levels" for cloud computing services, with strict criteria for higher levels (2, 3, and 4).

Although open source status alone does not automatically grant a specific assurance level, the transparency it provides is a powerful tool for demonstrating compliance. Annex II of CADA sets out criteria for Union assurance levels, including requirements for software supply chain transparency (e.g., Software Bill of Materials) and the absence of remote features that could tamper with systems. Open source components, when properly managed, provide the visibility needed to satisfy these criteria.

Furthermore, Article 44 establishes a network of Open Source Programme Offices (OSPOs). This network is tasked with facilitating the exchange of information and best practices regarding the "licensing, security, maintenance and procurement of open-source software." This institutionalizes the security aspect of open source, ensuring that public sector bodies have access to expert guidance on how to securely implement and maintain open source solutions.

What this means for you

For CTOs, architects, and software providers targeting the EU public sector, CADA's approach to open source has several concrete implications:

Security is a Mandatory Justification Criterion: When proposing open source solutions, you cannot rely on the license type alone. Article 41 requires that security be a "duly justified objective criterion." Your technical documentation must explicitly demonstrate how the open source nature of your solution enhances security through auditability, community review, and transparency. Conversely, if you are proposing a proprietary solution, you must provide objective evidence that it offers superior security or cost-efficiency to justify its selection over an open source alternative.
Audit Readiness is Non-Negotiable: Recital 81 links source code access directly to auditability. Public sector bodies will increasingly require evidence that your open source dependencies are regularly updated, free of known vulnerabilities, and compliant with EU cybersecurity standards. Be prepared to provide a complete Software Bill of Materials (SBOM) and demonstrate your process for monitoring and patching third-party components.
Positioning Against Vendor Lock-in: Your value proposition should emphasize interoperability and the reduction of dependency. Highlight how your architecture allows the public sector body to retain control over its data and software, even if the original provider ceases support. This aligns directly with CADA's goal of strengthening digital autonomy and reducing reliance on single vendors.
Engage with the OSPO Network: The OSPO Network (Article 44) will become a central forum for discussing open source security and governance. Providers should monitor developments within this network to stay aligned with emerging best practices, guidance on procurement, and potential updates to security standards for open source components.
Total Cost of Ownership (TCO) Analysis: Article 41 explicitly mentions "total cost" as a criterion. Be prepared to provide a holistic TCO analysis that goes beyond licensing fees (which may be zero). This must include costs for integration, maintenance, security auditing, and training. Public sector bodies will need to justify their choices based on a comprehensive view of cost and value, ensuring that the "free" nature of the software does not mask high operational costs.

Common misconceptions

"CADA mandates the use of open source in all cases." This is incorrect. Article 41 uses the term "encourage" and explicitly conditions the choice on functionalities, security, total cost, and other objective criteria. If a proprietary solution demonstrably offers better security or cost-efficiency for a specific use case, it can still be chosen, provided the decision is objectively justified.
"Open source automatically equals higher security." CADA does not make this claim. Instead, Recital 81 states that access to source code enables auditability. Poorly maintained, unvetted, or abandoned open source software can pose significant security risks. The regulation requires that security be an explicit criterion in the decision-making process, meaning the quality and security posture of the open source component must be verified, not assumed.
"CADA only applies to large enterprises." While the public sector is the primary focus of Article 41, the regulation's emphasis on reducing vendor lock-in and fostering a competitive EU cloud ecosystem benefits SMEs. SMEs that provide secure, auditable open source solutions are well-positioned to participate in public procurement, especially given the regulation's focus on supporting SMEs in innovation procurement (Article 33).
"Open source means no intellectual property rights." CADA respects intellectual property rights. The regulation encourages the use of components released under open source licenses, which are legal instruments that define the rights and obligations of users and contributors. It does not advocate for the use of unlicensed or infringing software.

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