Summary Under the proposed Cloud and AI Development Act (CADA), "manufacturer" is not defined independently. As proposed, Article 2(16) imports the definition from the Cyber Resilience Act (CRA): a manufacturer is the entity that develops or manufactures a product with digital elements and places it on the market under its own name or trademark. For cloud providers and data-centre operators, this definition matters because CADA's sovereignty audits for the higher Union assurance levels require mapping the software supply chain — and the manufacturer is the accountable entity behind each component.

Detail

CADA (COM(2026) 502 final) is a proposal that integrates with existing EU digital legislation rather than restating its terms. As proposed, Article 2(16) states:

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

Regulation (EU) 2024/2847 is the Cyber Resilience Act (CRA). Its Article 3(13) defines a manufacturer as a natural or legal person who develops or manufactures a product with digital elements, and places it on the market or puts it into service under its own name or trademark, whether for payment or free of charge.

This cross-reference is deliberate. By adopting the CRA definition, CADA keeps a single notion of who is responsible for a digital product across EU law, and ties that accountability into its own sovereignty framework.

The link to hardware, software and components

"Manufacturer" sits alongside three other CRA-derived terms in Article 2:

  1. Software — Article 2(13), by reference to Article 3, point (4), of the CRA.
  2. Hardware — Article 2(14), by reference to Article 3, point (5), of the CRA.
  3. Component — Article 2(15), by reference to Article 3, point (6), of the CRA.

Together these define the products and parts whose origin and control CADA's sovereignty criteria assess.

Why this matters for CADA's assurance levels

CADA's sovereignty framework (Article 16 and Annex II) sets four Union assurance levels. For levels 2, 3 and 4, providers must undergo independent third-party audits (Article 20), and the criteria in Annex II require demonstrable control over the software supply chain. For example, Annex II requires a complete and up-to-date SBOM and a documented list of dependencies; and, where software components or products are provided, owned and licensed by a legal entity established in a third country, it requires documented controls to block remote features that could tamper with or disrupt the system, source-code audits of security-relevant components from third-country manufacturers, and a documented migration plan.

In each case the "manufacturer" is the entity the auditor and provider must identify: not whoever physically assembled or compiled the product, but the entity that placed it on the market under its own name. That entity, and the jurisdiction it sits in, is what the third-country-control analysis turns on.

Applying the test

If a data-centre operator develops its own management software and markets it under its own brand, that operator is the manufacturer of that software. If the operator buys servers from a vendor, that vendor is the manufacturer of the hardware. To pursue a higher Union assurance level, the operator must then map those manufacturers and their dependencies, and show the required controls are in place.

What this means for you

For cloud providers and data-centre operators, the manufacturer definition has direct operational consequences.

  1. Supply-chain mapping: Identify the legal manufacturer of every significant hardware and software component — the entity that developed it and placed it on the market under its own name, not merely the vendor you pay. This matters for white-label and resold offerings.
  2. Sovereignty audits: For Union assurance level 2 or higher, you must produce an SBOM and dependency list (Annex II) and, where third-country manufacturers are involved, evidence of the required controls. Knowing each manufacturer's identity and jurisdiction is the starting point.
  3. Your own products: If you brand your own orchestration or management software, you are the manufacturer of it, and you bear the corresponding documentation and assurance obligations.
  4. Contracts: Define your suppliers' role as manufacturers clearly, so you can obtain the SBOMs, dependency information and source-code audit rights that Annex II contemplates.

Common misconceptions

  • "Manufacturer means the assembler." Under the CRA definition imported by CADA, the manufacturer is the entity that develops the product and places it on the market under its own name. A contract assembler is not the manufacturer; the brand owner is.
  • "Open-source developers are always manufacturers." An entity that takes open-source code, integrates it into a product and places that product on the market under its own name is the manufacturer of that product. The upstream open-source contributors generally are not.
  • "CADA defines manufacturer differently from the CRA." It does not. As proposed, Article 2(16) imports the CRA definition unchanged, to keep EU digital-product rules consistent.

Related

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