Summary As proposed, the Cloud and AI Development Act (CADA) does not replace the Cyber Resilience Act (CRA) but builds a "sovereignty stack" on top of it. CADA explicitly borrows key definitionsβ€”'software', 'hardware', 'component', and 'manufacturer'β€”directly from the CRA (Regulation (EU) 2024/2847) in Article 2 to ensure regulatory consistency. While the CRA mandates baseline technical cybersecurity for products with digital elements, CADA introduces a four-tier "Union assurance level" framework that requires cloud providers to meet additional sovereignty standards, including strict data localization, supply chain transparency, and personnel controls, to serve the public sector. Compliance with the CRA is a prerequisite for the technical security baseline, but it is insufficient for CADA's higher assurance levels.

Detail

The relationship between CADA and the Cyber Resilience Act is one of definition alignment and functional complementarity. CADA is a proposal (COM(2026) 502 final) aimed at strengthening Europe's cloud and AI ecosystem by addressing dependencies on third-country providers and ensuring data sovereignty. The CRA is an existing regulation that sets horizontal cybersecurity requirements for products with digital elements. The two instruments operate at different layers of the technology stack: the CRA secures the components (hardware and software), while CADA secures the service and its governance.

Definition Borrowing and Regulatory Consistency

CADA explicitly aligns its terminology with the CRA to prevent fragmentation and ensure that supply chain obligations are coherent across the EU legal framework. Article 2 of the CADA proposal defines several critical terms by direct reference to the CRA:

  • 'Software' is defined as in Article 3, point (4), of Regulation (EU) 2024/2847 (the CRA).
  • 'Hardware' is defined as in Article 3, point (5), of the CRA.
  • 'Component' is defined as in Article 3, point (6), of the CRA.
  • 'Manufacturer' is defined as in Article 3, point (13), of the CRA.

This borrowing ensures that when CADA discusses supply chain transparency or Software Bills of Materials (SBOMs), it relies on the established legal meanings of the CRA. For instance, Annex II of CADA, which sets out the criteria for Union assurance levels, requires providers to demonstrate software supply chain measures, including maintaining a "complete and up-to-date software bill of materials (SBOM), as defined in Article 3, point (39), of Regulation (EU) 2024/2847." This creates a seamless link where the technical documentation required by the CRA becomes the evidentiary baseline for CADA audits.

Technical Cybersecurity vs. Sovereignty Assurance

The CRA focuses on the technical security of individual products (e.g., routers, smart home devices, software libraries) to prevent cyberattacks and ensure vulnerability management. CADA focuses on the sovereignty and operational autonomy of cloud services. The explanatory memorandum notes that while the Cybersecurity Act (and by extension, the CRA's ecosystem) addresses technical cybersecurity criteria, it is "not suited for addressing sovereignty concerns that go beyond these technical elements."

CADA introduces a four-tier "Union assurance level" system (Levels 1–4) in Article 16. To achieve these levels, cloud providers must meet criteria that go significantly beyond basic product security:

  • Level 1: Requires the provider to be established in the Union, with infrastructure and data remaining exclusively in the Union unless the public sector body explicitly requires otherwise. It also requires compliance with "state-of-the-art cybersecurity standards."
  • Levels 2–4: Require independent third-party audits and increasingly strict controls. These include:
    • Prohibiting third-country control over the provider (with limited derogations for Level 3 under Article 18).
    • Personnel controls: Ensuring personnel are Union citizens (mandatory for Levels 3 and 4, conditional for Level 2 if the public body requires it).
    • Data usage: Preventing the use of customer data to train or fine-tune AI systems operated by third countries.
    • Support location: Ensuring technical and operational support is initiated and performed exclusively within the Union.

The "Sovereignty Stack": How They Interact

The interaction creates a layered compliance model often described as a "sovereignty stack":

  1. The Base Layer (CRA): Manufacturers of the hardware and software components used in the cloud infrastructure must comply with the CRA. This ensures the underlying products are secure, have SBOMs, and undergo vulnerability management.
  2. The Service Layer (CADA): Cloud providers aggregating these components must prove that the service itself is sovereign.
    • Annex II (Criteria for Union Assurance Levels) explicitly references CRA definitions. For example, under Level 2, 3, and 4, providers must document controls for "software components... provided, owned, and licensed by a legal entity established in a third country."
    • Providers must demonstrate that third-country software components are subject to source code audits and have a documented migration plan in the event the vendor fails or a third country imposes restrictions.
    • Annex III (Audit Evidence) requires auditors to assess these supply chain measures, using the CRA's definition of "component" to scope the audit.

This means a cloud provider cannot simply claim "our software is CRA-compliant" to satisfy CADA. They must prove that the CRA-compliant components are deployed in a manner that satisfies CADA's sovereignty criteria (e.g., no third-country control, EU-based personnel, data localization).

What this means for you

For in-house counsel, compliance officers, and cloud service providers, the interaction between CADA and the CRA creates a layered compliance obligation. You must satisfy the horizontal product security rules of the CRA while simultaneously meeting the vertical sovereignty rules of CADA.

1. Harmonize Your Definitions and Documentation

Ensure your internal compliance frameworks use the CRA's definitions for software, hardware, and components. When preparing for CADA's assurance level assessments, your SBOMs and supply chain documentation must align with CRA standards.

  • Action: Verify that your SBOMs include the specific data points required by the CRA (e.g., origin of software, dependencies).
  • Risk: Discrepancies in how you define a "component" under CRA vs. CADA could lead to audit failures, as CADA auditors will rely on the CRA definition to scope their review.

2. Assess Your Assurance Level Eligibility

If you target public sector clients, you must determine which Union assurance level your service meets.

  • Level 1: You can self-assess. You must prove EU establishment, data localization, and state-of-the-art cybersecurity compliance. Note that "state-of-the-art" implies adherence to standards that likely overlap with CRA requirements.
  • Levels 2–4: You must undergo independent third-party audits. These audits will scrutinize not just technical security (CRA overlap) but also:
    • Corporate control: Who owns the provider? (CADA specific).
    • Personnel nationality: Are your engineers EU citizens? (CADA specific).
    • Data usage: Is your data used to train foreign AI? (CADA specific).

3. Prepare for Supply Chain Audits

CADA's Annex III (Audit Evidence) requires auditors to assess software supply chain measures in depth. You must be ready to provide:

  • A complete SBOM for all software components, including open-source software, as defined in the CRA.
  • Evidence of risk-based processes to identify dependencies on external manufacturers.
  • Documentation proving that third-country software components are subject to source code audits and have migration plans if the vendor fails or imposes restrictions.
  • Proof that open-source software is monitored for control by third-country entities (e.g., if a third country acquires the foundation maintaining the code).

4. Monitor Deadlines and Penalties

  • Deadlines: Member States must designate national competent authorities within one year of CADA's entry into force. Public bodies must complete risk assessments (Article 29) within one year of entry into force to determine which assurance levels are required for their activities.
  • Penalties: Article 24 of CADA requires Member States to lay down penalties for infringements. These must be "effective, proportionate and dissuasive." Criteria for penalties include the nature of the infringement, previous infringements, and the provider's annual turnover in the Union. While specific fine amounts are left to Member States, the emphasis on dissuasiveness suggests significant financial exposure for non-compliance, particularly for intentional or negligent supply of incorrect information.

Common misconceptions

"CADA replaces the CRA for cloud providers." Incorrect. The CRA applies to all products with digital elements, including the hardware and software components that make up cloud infrastructure. CADA applies to cloud services and adds sovereignty requirements. You must comply with both if you provide cloud services using CRA-regulated hardware or software. The CRA ensures the product is secure; CADA ensures the service is sovereign.

"Cybersecurity compliance is enough for CADA Level 1." Incorrect. While Level 1 requires compliance with "state-of-the-art cybersecurity standards," it also requires EU establishment, data localization, and transparency on subcontractors. A non-EU provider with perfect cybersecurity (CRA compliant) cannot achieve Level 1 unless it meets the sovereignty criteria (e.g., being established in the Union).

"Open-source software is exempt from CADA audits." Incorrect. Annex II explicitly requires providers to demonstrate controls for open-source software, including monitoring for third-country control (e.g., if a third-country entity acquires the foundation) and ensuring no remote tampering features exist. The CRA's definition of "software" includes open-source, and CADA builds on this.

"CADA only cares about the final service, not the components." Incorrect. CADA's supply chain criteria (Annex II) explicitly reference CRA definitions and require audits of third-country software components. If a critical component is CRA-compliant but controlled by a third country in a way that violates CADA's "no third-country control" rule for Level 3/4, the service cannot achieve that level.

Official sources

Related

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