Summary As proposed, the Cloud and AI Development Act (CADA) does not write its own definition of "software." CADA Article 2(13) imports it from the Cyber Resilience Act (CRA, Regulation (EU) 2024/2847), Article 3, point (4). That CRA definition expressly includes firmware, so firmware is software under CADA. AI model weights are harder: they are not separately defined, and whether they count as "software" turns on whether they are read as executable instructions or as data — a genuinely unsettled question. In practice, CADA's audit and supply-chain criteria would likely pull weights into scope regardless of how that legal debate resolves.

Detail

To see whether firmware and AI model weights fall within CADA's software definition, you have to follow the cross-reference — CADA does not define the term standalone.

The legal basis: CADA Article 2(13) and the CRA

Article 2(13) of CADA provides that "'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 any analysis of what counts as software under CADA starts with the CRA definition, which (as proposed to be imported) frames software as a set of computer instructions — expressly including firmware — intended to cause a hardware device to perform tasks or achieve results.

That definition is broad and functional. It hinges on two things: the form (a set of computer instructions) and the function (intended to make hardware perform tasks or solve problems).

Firmware: clearly included

Firmware is explicitly named in the CRA definition imported by CADA Article 2(13). Firmware — instructions stored in ROM or flash that control hardware behaviour — is software, not hardware, even though it resides on hardware. This matters for cloud infrastructure, where hypervisors, BIOS/UEFI, and embedded controller firmware sit deep in the stack. Where a provider pursues a higher Union assurance level and must show software-supply-chain controls under Annex II, firmware falls squarely within that scope.

AI model weights: the "code vs data" edge case

The status of model weights is less settled, and it is a real interpretive problem for CTOs and architects.

1. The argument for inclusion (weights as code): trained models consist of parameters that, at inference time, are loaded into memory and drive the hardware (GPUs/TPUs) to produce a result. Read this way, the weights function as the operative "instructions" of the system and could be argued into the CRA's notion of computer instructions intended to achieve a specific result.

2. The argument for exclusion (weights as data): weights are the numerical output of training, stored in files (e.g. .pt, .safetensors, .bin). They contain no imperative control flow; they parameterise a fixed computational graph. On a strict reading, if weights are merely data consumed by the inference software (the actual code), they may not themselves be "software."

3. The CADA framing: AI systems vs software: separately, Article 2(3) of CADA imports the AI Act's definition of an "AI system" (Regulation (EU) 2024/1689). CADA's sovereignty criteria in Annex II apply to "cloud computing services," which may host or deliver AI systems. Annex II requires scrutiny of the software supply chain and software components but does not state that model weights are software. Still, where a provider offers an AI model as part of its service, the whole delivery mechanism — weights included — is what an auditor assesses. If the weights are proprietary and essential to the service, they are likely to be treated as part of the audited software asset even while their formal classification under the CRA definition remains debatable.

Implications for the software supply chain

Annex II, Section 2.1(i) (Union assurance level 2) would require providers to demonstrate that software-supply-chain measures are in place, including a complete and up-to-date software bill of materials (SBOM) — itself defined by reference to CRA Article 3, point (39) — and a list of dependencies. How the CRA defines "software" therefore shapes what must appear in that SBOM. If firmware is software, it must be listed. If weights are treated as part of a software component, their origin, licensing, and security status come into play — a real burden for providers building on third-party foundation models.

What this means for you

For CTOs and architects scoping CADA readiness:

  1. Treat firmware as software. Ensure SBOMs capture firmware (BIOS/UEFI, hypervisors, embedded controllers). For higher assurance levels, be ready to show the supply chain is controlled and, under Annex II, that controls block remote features able to tamper with or disrupt a device, system, or software.
  2. Document weight provenance. Whatever the legal label, the audit reality will likely treat weights as critical components. Record whether your weights are open, proprietary, or third-party, and be able to show you control them and that they carry no hidden remote/tamper features.
  3. Make your SBOM granular enough. It should capture both traditional code and AI artefacts. If an auditor argues weights are "instructions," show provenance; if they are treated as data, still show a secure, untampered data/weight pipeline.
  4. Pin down contracts. In procurement for AI models, state whether weights are licensed as "software" or as "data" — it affects how you report them in CADA compliance documentation.

Common misconceptions

Misconception 1: "AI weights are just data, so they fall outside CADA." Their functional role as the model's learned logic means they may be treated as part of the audited software supply chain regardless of file format, especially under the CRA's broad framing of computer instructions intended to achieve a result.

Misconception 2: "Firmware is hardware, not software." Firmware is expressly software under the CRA definition imported by CADA Article 2(13). It resides on hardware but is managed, updated, and audited as software.

Misconception 3: "CADA has its own unique definition of software." It does not. It imports the CRA definition, so any analysis starts with CRA Article 3, point (4); if that definition is interpreted differently over time, CADA's scope tracks it.

Official sources

Related

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