Summary As proposed, CADA imports the definitions of "software," "hardware," "component," and "manufacturer" from the Cyber Resilience Act (CRA, Regulation (EU) 2024/2847) via Article 2(13)–(16). This cross-referencing keeps CADA's sovereignty and supply-chain obligations for cloud services aligned with the EU's product-security framework. For counsel, it means CADA compliance for the higher assurance levels involves mapping cloud architectures against CRA-defined elements, especially the provenance and control of underlying digital elements.

Detail

The Commission published the proposed CADA on 3 June 2026 (COM(2026) 502 final) to strengthen Europe's cloud and AI ecosystem by addressing dependence on third-country providers and building domestic compute. A key mechanism is harmonising technical terminology across the EU digital stack — so CADA does not coin standalone definitions for core technology terms but imports them from the CRA.

The legal cross-reference

Article 2 of CADA ties the Regulation to the CRA:

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

Adopting these by reference keeps the scope of CADA's sovereignty framework — particularly the Union assurance levels in Annex II — technically consistent with the EU's baseline product-security rules.

Coherence with the CRA

The CRA sets a horizontal cybersecurity framework for products with digital elements placed on the EU market. CADA builds on that foundation at the service layer (cloud computing) and the strategic layer (AI and compute sovereignty).

Shared definitions create a coherent ecosystem. When CADA's Annex II requires providers to demonstrate software-supply-chain measures and control over components, it relies on the CRA's precise meanings of "software" and "component." Indeed, Annex II's SBOM requirement is itself tied to the CRA: the software bill of materials is defined by reference to CRA Article 3, point (39), and third-country "software components" and "manufacturer" are read through CRA Article 3 points (6) and (13). Without a shared vocabulary, providers could face conflicting views of what falls within audit scope.

Shaping the cloud and AI supply chain

This alignment affects the supply chain in three ways:

  1. Traceability: the higher assurance levels require rigorous audits of the software supply chain. Using the CRA's "component" definition extends audit attention to libraries, frameworks, and other digital elements integral to the service, whose origin must be traceable to assess third-country control.
  2. Manufacturer responsibility: the CRA's "manufacturer" concept helps identify who is responsible for the security and provenance of underlying elements. Where a provider relies on third-party hardware or software, the audit assesses whether the manufacturer's position implies control that could undermine the provider's autonomy.
  3. Mitigating third-country control: CADA aims to mitigate extraterritorial access and disruption risk. The CRA definitions help delineate where EU jurisdiction meets third-country influence — and because the CRA's "software" reaches firmware and embedded code, Annex II's requirements cover those layers, not just application code.

Implications for compliance

For compliance teams, the upshot is that CADA and CRA compliance cannot be siloed. Maintain a unified view of your digital-product portfolio so the elements identified for CRA conformity also feed CADA's sovereignty assessment — mapping component provenance, manufacturer independence, and supply-chain agreements against both regimes.

What this means for you

For in-house counsel and compliance officers:

  • Unify your frameworks. Align CADA preparation with existing CRA obligations; the same inventory of software, hardware, and components can serve as the baseline for CADA audits at the higher assurance levels.
  • Supply-chain due diligence. Review supplier contracts. For the higher levels you would need to show that suppliers/manufacturers do not exert control that compromises sovereignty — which may call for new clauses on third-country access, vulnerability handling, and operational autonomy.
  • Audit preparation. Auditors will scope assessments using CRA definitions. Ensure your SBOM and hardware inventories are comprehensive, covering all "components" (including open-source libraries and third-party dependencies) as the CRA defines them.
  • Timeline awareness. As a proposal, CADA is not yet in force; prepare for the assurance-level regime as Member States designate national competent authorities (within one year of entry into force) and as audits for levels 2–4 begin to rely heavily on CRA-defined supply-chain elements.
  • Penalty risk. Under Article 24, Member States would lay down effective, proportionate, and dissuasive penalties for infringements by cloud providers. Amounts are left to national law; the non-exhaustive criteria include the nature, gravity, scale and duration of the infringement and the party's annual turnover in the preceding financial year in the Union.

Common misconceptions

  • Misconception 1: CADA and the CRA are entirely separate regimes.
    • Reality: They are interconnected. CADA imports core definitions from the CRA, so compliance with one informs the other, especially on supply-chain transparency.
  • Misconception 2: Only "critical" CRA products are relevant to CADA.
    • Reality: CADA applies to cloud computing services regardless of whether underlying hardware is "critical" under the CRA. The CRA's definitions of "software" and "component" apply broadly, so even non-critical digital elements must be accounted for in CADA audits.
  • Misconception 3: Open-source software is exempt from CADA supply-chain rules.
    • Reality: Even where the CRA provides certain open-source treatment, CADA's sovereignty framework still expects transparency. The higher assurance levels require documented controls over components — open-source included — to block remote tampering or disruption.
  • Misconception 4: The "manufacturer" is always whoever physically makes the hardware.
    • Reality: The CRA's "manufacturer," imported by CADA Article 2(16), broadly covers an entity that develops or manufactures a product, or has it designed or manufactured, and markets it under its own name or trademark — which in the cloud context can include software vendors or providers that brand and control the digital elements.

Related

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