Summary Under the proposed Cloud and AI Development Act (CADA), "software" would not be defined on its own. Article 2(13) of the proposal defines it as "software as defined in Article 3, point (4), of Regulation (EU) 2024/2847" — the Cyber Resilience Act (CRA). In other words, to know what CADA would treat as software, you read across to the CRA. This cross-referencing keeps CADA's sovereignty and audit rules consistent with the EU's wider cybersecurity framework and lets the regulation address the digital layer of cloud infrastructure separately from hardware.

Detail

CADA is built to lean on adjacent EU legislation rather than re-defining settled technical terms. For "software," it does this explicitly through a cross-reference.

The definition in Article 2 The relevant text is Article 2(13) of the CADA proposal:

"'software' means software as defined in Article 3, point (4), of Regulation (EU) 2024/2847;"

Regulation (EU) 2024/2847 is the Cyber Resilience Act. So the operative definition lives in the CRA, not in CADA itself. The CRA text is not reproduced in the CADA corpus, so the precise wording should be read from that Regulation; in general terms, the CRA treats software as the code-based part of a product with digital elements, as distinct from hardware.

Software, hardware and component as a triad CADA imports three related CRA definitions in sequence:

  • Software — Article 2(13), referring to Article 3, point (4), of Regulation (EU) 2024/2847.
  • Hardware — Article 2(14), referring to Article 3, point 5, of the same Regulation.
  • Component — Article 2(15), referring to Article 3, point (6), of the same Regulation.

This triad lets CADA reason about the whole stack with vocabulary that already exists in EU cybersecurity law.

Why the alignment matters Using the CRA's boundary for "software" means a provider preparing for a CADA sovereignty audit draws the same line around "software" as it does for CRA compliance. That reduces ambiguity about which code-based elements fall within scope, and it dovetails with CADA's software supply-chain requirements at the higher Union assurance levels.

For Union assurance levels 2, 3 and 4, Annex II would require providers to demonstrate concrete software supply-chain controls. For level 2, Annex II, Section 2.1(i) would require a complete and up-to-date software bill of materials (SBOM) — itself defined by reference to the CRA — plus documented controls to block remote features in third-country software that could tamper with or disrupt the service, source-code audits of security-relevant third-country components, and a documented migration plan if a vendor fails or a third country imposes restrictions. The level 4 equivalent (Annex II, Section 4.1(i)) goes further, requiring providers to show that no third country exercises effective control over the design, development, maintenance and evolution of those components.

What this means for you

For CTOs, architects and SMEs, the software definition has practical, operational consequences.

1. Align your software inventory with CRA work. Because CADA would borrow the CRA definition, the SBOM and dependency inventory you build for the CRA largely doubles as the foundation for CADA's software-transparency obligations at levels 2–4.

2. Prepare for supply-chain scrutiny. If you intend to sell cloud services to the EU public sector, you would likely need a Union assurance level. For levels 2–4 you would undergo an independent audit (Article 20) that examines your software supply chain: the provenance of components, controls against remote tampering by third-country software, source-code audits of security-relevant third-country components, and a migration plan.

3. Keep code and data distinct. CADA would treat software and data differently. The software definition is about code; data-localisation criteria in Annex II are a separate axis. Where AI models are involved, note that CADA defines "AI system" separately (Article 2(3), by reference to the AI Act), so architect your stack so the executable software layer is auditable independently of model parameters and training data.

4. Plan for source-code access at the top tiers. For level 3, Annex II, Section 3.1(g) would, in the third-country-control derogation scenario, expect the provider to "allow for reasonable access to the code." Build development processes that can support secure, auditable code access without needlessly exposing intellectual property.

Common misconceptions

Misconception 1: CADA defines software independently. Reality: It does not. Article 2(13) imports the CRA definition. There is no standalone CADA definition of software.

Misconception 2: Only open-source software is covered. Reality: CADA's software rules would apply regardless of licence. Open-source software gets specific treatment — for example, Annex II, Section 2.1(j) and Section 4.1(j) would require documented controls to prevent remote features in open-source software from being used to tamper with or disrupt the service — but it is not exempt from sovereignty audits.

Misconception 3: "Software" under CADA includes AI models. Reality: CADA defines "AI system" separately (Article 2(3)) by reference to the AI Act. The software definition is about computer code under the CRA. The distinction matters because software supply-chain rules and AI-related rules are addressed through different provisions.

Official sources

Related

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