How CADA references the Cyber Resilience Act for software definitions

As proposed, the Cloud and AI Development Act (CADA) does not create its own definition of "software." Instead, it explicitly anchors the term to the Cyber

Summary As proposed, the Cloud and AI Development Act (CADA) does not create its own definition of "software." Instead, it explicitly anchors the term to the Cyber Resilience Act (Regulation (EU) 2024/2847). Article 2(13) of CADA defines "software" by reference to Article 3, point (4) of the CRA. This linkage is operationalized in Annex II, which states that "software" within the meaning of the CRA falls within the scope of the Union assurance levels, while "hardware" (defined in CRA Article 3, point (5)) is explicitly excluded. Consequently, compliance with CADA's sovereignty tiers—particularly regarding Software Bills of Materials (SBOMs) and third-country manufacturers—depends entirely on the definitions and requirements established in the CRA.

Detail

The Cloud and AI Development Act (CADA) represents a targeted regulatory intervention in the cloud ecosystem, focusing on sovereignty and operational autonomy rather than general cybersecurity. To avoid regulatory fragmentation and ensure legal certainty, the proposal leverages existing EU digital legislation for its core terminology. The most critical of these cross-references is the definition of "software," which serves as the boundary for the Act's strictest sovereignty requirements.

The Statutory Bridge to the Cyber Resilience Act

The foundation of this approach is found in Article 2 of CADA, titled "Definitions." Paragraph 13 of this article explicitly states: "'software' means software as defined in Article 3, point (4), of Regulation (EU) 2024/2847." Regulation (EU) 2024/2847 is the Cyber Resilience Act (CRA), which establishes horizontal cybersecurity requirements for products with digital elements.

By adopting the CRA's definition, CADA ensures that the scope of "software" for sovereignty audits is identical to the scope for product safety and cybersecurity compliance. This prevents cloud providers from exploiting definitional gaps between different EU laws. If a component is classified as software under the CRA, it automatically falls under CADA's scrutiny for Union assurance levels.

The Scope of Annex II: Software In, Hardware Out

The practical significance of this definition is codified in the opening note of Annex II of CADA, which sets out the "Criteria for Union Assurance Levels." The text is precise:

"For the purpose of the criteria under Union assurance levels 1, 2, 3, and 4, 'software' within the meaning of Regulation (EU) 2024/2847, Article 3, point (4) falls within the scope of this Annex and Annex III to this Regulation. 'Hardware' within the meaning of Regulation (EU) 2024/2847, Article 3, point (5) is outside of the scope."

This distinction is vital for technical architects and compliance officers. It means that the rigorous sovereignty criteria—such as data localization, personnel citizenship, and the absence of third-country control—apply directly to the software stack (including middleware, operating systems, libraries, and application code). Conversely, the physical hardware itself, while subject to general cybersecurity standards, is not subject to the specific sovereignty tests outlined in Annex II. This allows for a focused regulatory approach on the code and logic that drives cloud services, rather than the physical servers hosting them.

Supply Chain Transparency: SBOMs and Third-Country Manufacturers

The CRA linkage extends beyond the definition of software to related concepts critical for supply chain transparency. Article 2(16) of CADA defines "manufacturer" by reference to Article 3, point (13) of the CRA, and Article 2(15) defines "component" by reference to Article 3, point (6) of the CRA. These definitions are the backbone of the software supply chain measures required for Union Assurance Levels 2, 3, and 4.

Under Annex II, paragraph 2.1(i), cloud providers seeking Level 2 recognition must demonstrate specific controls for their software supply chain. Crucially, paragraph 2.1(i)(i) mandates a "complete and up-to-date software bill of materials (SBOM), as defined in Article 3, point (39), of Regulation (EU) 2024/2847." This ensures that the format, granularity, and content of the SBOM are harmonized with the CRA, providing a standardized evidence base for auditors.

The requirements become more stringent when dealing with non-EU entities. Annex II, paragraph 2.1(i)(ii) addresses components provided, owned, or licensed by a legal entity established in a third country. In such cases, providers must:

Implement controls to block any remote features that could materially tamper with or disrupt the system.
Ensure that security-relevant components from third-country manufacturers (as defined in CRA Article 3, point (13)) are subject to source code audits.
Maintain a documented migration plan in the event that the vendor fails or a third country imposes restrictions.

For Union Assurance Levels 3 and 4, the criteria intensify. Providers must not only document dependencies but also prove the ability to migrate to alternative solutions if a third-country vendor becomes inaccessible. Furthermore, Annex II, paragraph 4.1(i)(ii) for Level 4 requires measures to retain effective control over software components, demonstrating that a third country does not hold or exercise effective control over the design, development, maintenance, and evolution of those components.

Audit Evidence and Verification

The definition of software directly dictates the evidence required for independent audits. Annex III of CADA, which outlines "Audit Evidence for the Audit Procedure," references these CRA definitions repeatedly. Under Audit Criterion I, auditors must assess the transparency of the software supply chain by verifying the SBOM (per CRA Article 3, point (39)) and the origin of software modules.

Auditing organizations will use these documents to verify:

The degree of reliance on non-EU vendors.
The visibility into the entire software manufacturer and sub-manufacturer chain.
The existence of alternative solutions and switchover plans.

For Level 3 and 4, the audit must also confirm that the provider has implemented mechanisms to detect if open-source software is acquired by or comes under the control of a third country, as required by Annex III, Audit Criterion J, point (3).

What this means for you

For CTOs, architects, and compliance teams, the integration of CADA with the Cyber Resilience Act means that cloud sovereignty compliance cannot be treated as a separate silo. Your existing CRA compliance efforts—specifically regarding software inventory and SBOM generation—will serve as the primary evidence base for CADA's Union assurance levels.

Unified Definitions: Ensure your internal compliance mappings use the CRA's definition of software. If a component is "software" under the CRA, it is subject to CADA's sovereignty criteria. This includes embedded software, middleware, and libraries, but excludes physical hardware.
SBOM Readiness: You must generate and maintain SBOMs that strictly adhere to the definition in CRA Article 3, point (39). These documents are not optional for Levels 2, 3, and 4; they are mandatory evidence for independent audits. Incomplete or inaccurate SBOMs will likely result in a negative audit opinion.
Third-Country Risk Management: If your stack relies on software from third-country manufacturers (as defined by CRA Article 3, point (13)), you must implement the specific controls mandated by CADA Annex II. This includes source code audits for security-relevant components and documented migration plans. For Level 4, you must prove that third countries do not hold effective control over the software's evolution.
Hardware Exclusion: While hardware is excluded from the specific sovereignty criteria in Annex II, it must still meet general cybersecurity standards. Focus your sovereignty efforts on the software layer, ensuring that remote access features and update mechanisms are controlled and auditable.

Common misconceptions

Misconception: CADA creates a new, independent definition of software.
- Reality: CADA explicitly adopts the definition from the Cyber Resilience Act (Article 3, point (4) of Regulation (EU) 2024/2847). There is no separate CADA-specific definition; compliance with one generally informs the other.
Misconception: Hardware is subject to the same sovereignty criteria as software.
- Reality: Annex II of CADA explicitly states that "hardware" (as defined in CRA Article 3, point (5)) is outside the scope of the Union assurance level criteria. While hardware must be secure, the specific sovereignty tests (like personnel citizenship or data localization) apply to the software stack.
Misconception: SBOMs are optional for lower assurance levels.
- Reality: While Level 1 relies on self-assessment, Levels 2, 3, and 4 require independent audits where the SBOM (defined by CRA Article 3, point (39)) is a mandatory piece of evidence. Even for Level 1, transparency around subcontractors and software dependencies is required.
Misconception: Third-country software is automatically banned.
- Reality: Third-country software is not banned outright. However, for Union Assurance Levels 2 and 3, it triggers strict requirements, including source code audits, blocking of remote tampering features, and migration plans. For Level 4, the criteria are even stricter, requiring proof that third countries do not hold effective control over the design and evolution of the software components.

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