Summary Under the proposed Cloud and AI Development Act (CADA), a "component" would not be defined in the proposal's own words. Article 2(15) imports the definition from Article 3, point (6), of Regulation (EU) 2024/2847 — the Cyber Resilience Act (CRA). Under the CRA, a component is, broadly, software or hardware that forms part of a product with digital elements. For CTOs and architects this matters because the components in your cloud or AI stack help determine the supply-chain evidence you would need at the higher Union assurance levels.

Detail

CADA aims to strengthen Europe's cloud and AI ecosystem and reduce dependency on non-EU providers. To keep its vocabulary consistent with the rest of EU digital law, it cross-references existing definitions rather than inventing new ones.

The legal definition: borrowed from the Cyber Resilience Act

The direct answer is in Article 2(15) of the proposal:

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

Regulation (EU) 2024/2847 is the Cyber Resilience Act, which sets horizontal cybersecurity requirements for products with digital elements. The CRA text is not reproduced in the CADA corpus, so its precise wording should be read from that Regulation; in general terms, a component under the CRA is software or hardware that forms part of a larger product with digital elements. That is broad enough to cover both software components (libraries, frameworks, middleware, application code) and hardware components (processors, memory, networking equipment) — and, crucially, a component is an element of a larger product rather than a standalone product in its own right.

CADA imports this definition alongside its sibling terms: software (Article 2(13), Article 3, point (4) of the CRA), hardware (Article 2(14), Article 3, point 5), and manufacturer (Article 2(16), Article 3, point (13)). Reading them together lets CADA reason about the full stack with established cybersecurity vocabulary.

Why the definition matters in CADA

While CADA's headline subjects are cloud computing services, AI systems and data centres, "component" plays a supporting role in several places:

  1. Supply-chain sovereignty. CADA's sovereignty framework (Title IV) would require providers seeking Union assurance levels 2–4 to demonstrate control over their software and hardware supply chains. Annex II, Section 2.1(i) explicitly defines software components by reference to Article 3, point 6, of Regulation (EU) 2024/2847 when it sets out the controls required over third-country-owned components — so the CRA component concept feeds directly into the sovereignty criteria.
  2. Open cloud stacks. CADA would support the development of open cloud computing stacks (Article 4(2)(a)). Those stacks are assembled from hardware and software components, so a shared definition keeps expectations clear across the stack.
  3. Provider and manufacturer roles. The CRA places obligations on the manufacturer of a product with digital elements. A cloud provider that also integrates or builds hardware (for example, custom accelerators) may sit at the overlap of CADA's provider obligations and the CRA's manufacturer obligations.

Practical implications for supply chains

For the higher Union assurance levels, the security and provenance of underlying components affect a provider's ability to obtain a positive audit opinion. That creates a ripple effect:

  1. Procurement. Buyers will increasingly ask for evidence about the underlying components.
  2. Development. Architects benefit from selecting components whose provenance and security posture are documentable.
  3. Compliance. Suppliers of components to the EU cloud market will find that documentable security and control over those components becomes a precondition for their customers' assurance-level recognition.

What this means for you

For CTOs, architects and SMEs:

  • Audit your supply chain. Inventory the hardware and software components in your cloud or AI offering and be ready to document their origin.
  • Document component origins and control. For level 2, Annex II, Section 2.1(i) would require controls over third-country-owned components, including source-code audits of security-relevant third-country software and a documented migration plan. For level 4, Annex II, Section 4.1(i) would require you to show that no third country holds effective control over the design, development, maintenance and evolution of those components.
  • Favour documentable provenance. CADA promotes open standards and Union-developed technologies; choosing components you can fully document simplifies the evidence you would need.
  • Track how the proposal evolves. CADA is a proposal, so watch how the CRA cross-references are finalised through the legislative process.

Common misconceptions

  • "CADA defines its own term for component." Incorrect. Article 2(15) imports the CRA definition. There is no separate CADA-specific definition.
  • "Only hardware counts as a component." Incorrect. The CRA definition covers both software and hardware. In cloud and AI contexts, software components are at least as relevant as hardware.
  • "CADA replaces the Cyber Resilience Act." No. CADA would complement the CRA. The CRA sets baseline cybersecurity requirements for products with digital elements; CADA addresses sovereignty, resilience and the deployment of cloud and AI services.

Related

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