Summary Yes, the proposed Cloud and AI Development Act (CADA) explicitly incorporates definitions from the Cyber Resilience Act (CRA) to ensure a unified technical vocabulary for cloud infrastructure. Specifically, Article 2(13)–(16) of the CADA proposal borrows the definitions of "software," "hardware," "component," and "manufacturer" from Regulation (EU) 2024/2847 (the CRA), referencing Article 3, points (4), (5), (6), and (13) respectively. This alignment ensures that the technical terms used in CADA's sovereignty audits and supply chain assessments match those in the CRA, but it does not merge the two legal regimes. The CRA's cybersecurity obligations remain distinct from CADA's sovereignty framework; a provider must comply with both independently, using the same definitions to satisfy different regulatory goals.

Detail

The Cloud and AI Development Act (CADA), proposed by the European Commission on 3 June 2026 (COM(2026) 502 final), aims to strengthen Europe's cloud and AI ecosystem by reducing dependencies on third-country providers and boosting domestic capacity. A cornerstone of this strategy is the "Union cloud computing sovereignty framework," established under Title IV of the proposal. This framework requires cloud providers to undergo rigorous audits to prove they meet specific assurance levels (Levels 1–4). To conduct these audits effectively, regulators, auditors, and providers must share a precise, legally binding understanding of the underlying infrastructure, particularly the software and hardware components that constitute the service.

CADA achieves this precision by explicitly cross-referencing the Cyber Resilience Act (CRA). Article 2 of the CADA proposal contains the definitions that apply throughout the regulation. Paragraphs 13 through 16 of Article 2 do not create new, standalone definitions; instead, they import existing ones from the CRA to ensure regulatory coherence.

The specific cross-references are as follows:

  • Article 2(13) defines "software" as meaning software as defined in Article 3, point (4), of Regulation (EU) 2024/2847.
  • Article 2(14) defines "hardware" as meaning hardware as defined in Article 3, point (5), of Regulation (EU) 2024/2847.
  • Article 2(15) defines "component" as meaning component as defined in Article 3, point (6), of Regulation (EU) 2024/2847.
  • Article 2(16) defines "manufacturer" as meaning manufacturer as defined in Article 3, point (13), of Regulation (EU) 2024/2847.

This legislative technique serves two primary purposes. First, it ensures regulatory coherence. By using the same legal definitions for "software" and "hardware" across both the CRA and CADA, the EU avoids conflicting interpretations that could arise if each law defined these terms differently. For a cloud provider, this means the "software" subject to CADA's supply chain transparency requirements is the exact same category of product subject to the CRA's cybersecurity essential requirements. This prevents providers from exploiting definitional gaps to exclude certain digital elements from scrutiny.

Second, this linkage directly supports CADA's supply chain scrutiny. The CADA sovereignty framework, particularly for Union Assurance Levels 2, 3, and 4, requires detailed audits of the software supply chain. Annex II of CADA (Criteria for Union Assurance Levels) mandates that providers demonstrate specific software supply chain measures. For instance, under Annex II, Section 2.1(i) and Section 3.1(i), providers must maintain a "complete and up-to-date software bill of materials (SBOM)" and document dependencies. By borrowing the CRA's definition of "software," CADA ensures that auditors are looking at the exact same scope of digital products when assessing whether a cloud service relies on third-country components that might pose sovereignty risks.

However, it is crucial to distinguish between definition and obligation. While CADA uses the CRA's definitions, it does not impose the CRA's obligations, nor does the CRA impose CADA's obligations. The CRA focuses on cybersecurity by design, requiring manufacturers to ensure products are free from known vulnerabilities and meet essential security requirements before being placed on the market. CADA focuses on sovereignty, operational autonomy, and the risk of third-country interference.

A product must comply with the CRA's security standards to be legally placed on the EU market. However, meeting those standards does not automatically grant it a CADA sovereignty assurance level. Conversely, a cloud service might meet CADA's sovereignty criteria (e.g., data remains in the EU, no third-country control) but still need to separately demonstrate compliance with CRA cybersecurity requirements if the underlying software falls under the CRA's scope. The two laws operate in parallel: the CRA ensures the product is secure; CADA ensures the service is sovereign.

What this means for you

For CTOs, architects, legal counsel, and SMEs evaluating the practical impact of CADA, this definitional overlap simplifies compliance preparation but adds layers of documentation requirements.

1. Unified Vocabulary for Audits When preparing for a CADA sovereignty audit (particularly for Levels 2–4), you do not need to debate what constitutes "software" or a "component." The CRA's established definitions apply. If you are already mapping your supply chain for CRA compliance, that same mapping forms the foundation for your CADA SBOM and dependency documentation. This reduces the cognitive load of interpreting new terms but raises the bar for the quality of your existing documentation. Your internal asset inventories must be robust enough to satisfy both the CRA's security requirements and CADA's sovereignty criteria.

2. Enhanced Supply Chain Transparency CADA Annex II requires providers to document dependencies and ensure controls over third-country software. Because CADA uses the CRA's definition of "software," this includes a broad range of digital elements. You must be prepared to identify every software component, including open-source libraries, that is part of your cloud service's infrastructure. The auditor will use the CRA definition to determine if a specific element is a "component" that needs to be listed in your SBOM. If you cannot trace a component back to its origin or verify its security and sovereignty status, you risk failing the CADA audit.

3. Separate Compliance Tracks Do not assume that CRA compliance satisfies CADA requirements, or vice versa. You must maintain two distinct compliance postures:

  • CRA Track: Focus on cybersecurity, vulnerability handling, essential security requirements, and post-market surveillance.
  • CADA Track: Focus on data localization, personnel citizenship (conditional at L2, mandatory at L3/L4), absence of third-country control, and supply chain sovereignty. Both tracks will reference the same "software" assets, but they will ask different questions about those assets. Your internal governance must be able to answer both sets of questions.

4. Impact on SMEs SMEs often rely on third-party software and cloud infrastructure. Under CADA, if you are a cloud provider, you must ensure your subcontractors and their software components meet the sovereignty criteria. If you are a user of cloud services, you benefit from clearer definitions that help you evaluate whether a provider's claim of "sovereign software" is legally robust. However, you should not expect CADA to replace the CRA; you still need to ensure any software you develop or purchase meets CRA cybersecurity standards.

Common misconceptions

Misconception 1: CADA replaces the CRA for cloud services. This is incorrect. CADA and the CRA are complementary regulations. The CRA applies to products with digital elements, including cloud services, focusing on cybersecurity. CADA applies to cloud computing services focusing on sovereignty and strategic autonomy. A cloud provider must comply with both if the service falls within the scope of both regulations. The shared definitions in CADA Article 2(13)–(16) ensure consistency, not substitution.

Misconception 2: Only "cloud" software is affected. CADA's definitions of software and hardware are broad because they are borrowed from the CRA. The CRA covers a wide array of products, from consumer electronics to industrial software. By importing these definitions, CADA ensures that any software component used in a cloud serviceβ€”whether it is a core operating system, a database engine, or a minor libraryβ€”is subject to the same definitional clarity. This prevents providers from excluding certain software elements from sovereignty audits by claiming they are not "core" cloud software.

Misconception 3: Compliance with CRA automatically grants a CADA Assurance Level. No. The CRA certifies that a product is secure. CADA certifies that a service is sovereign. A product can be secure (CRA compliant) but still subject to third-country laws that allow data access (CADA non-compliant for higher assurance levels). Conversely, a service might be sovereign (CADA compliant) but have unresolved security vulnerabilities (CRA non-compliant). Both standards must be met independently.

Official sources

Related

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