Summary Under the proposed Cloud and AI Development Act (CADA), the Union cloud computing sovereignty framework explicitly assesses "software" while excluding "hardware" from its specific assurance criteria. As defined in the opening note of Annex II, "software" falls within the scope of the regulation (referencing Regulation (EU) 2024/2847), whereas "hardware" is explicitly outside the scope. This means compliance focuses on code, libraries, firmware, and supply-chain transparency, rather than the physical origin of servers or chips. However, the physical location of the infrastructure remains a strict requirement for higher assurance levels.

Detail

The CADA proposal establishes a Union cloud computing sovereignty framework comprising four Union assurance levels (Levels 1 through 4). To achieve recognition at any of these levels, cloud computing service providers must meet cumulative criteria set out in Annex II. A fundamental distinction for technical architects, compliance officers, and procurement teams is the precise scope of these criteria regarding the technology stack.

The opening note of Annex II provides the definitive boundary for the assessment:

"For the purpose of the criteria under Union assurance levels 1, 2, 3, and 4, 'software' within the meaning of Regulation (EU) 2024/2847, Article 3, point (4), falls within the scope of this Annex and Annex III to this Regulation. 'Hardware' within the meaning of Regulation (EU) 2024/2847, Article 3, point (5), is outside of the scope."

This cross-reference anchors the definition of software and hardware to the Cyber Resilience Act (Regulation (EU) 2024/2847).

The Scope of "Software"

Under the referenced definition in Article 3, point (4) of Regulation (EU) 2024/2847, software is defined as:

"a set of binary codes and/or source code, including any associated documentation and/or metadata, developed by design to perform specific functions, activities or tasks when appropriately input into, or loaded or installed in, a product with digital elements or a computer."

Consequently, the CADA sovereignty criteria apply to the entire digital stack. This includes:

  • Operating systems and hypervisors.
  • Middleware and management platforms.
  • Application code and libraries.
  • Firmware: Crucially, firmware is considered software under this definition because it consists of binary code loaded into a device to perform specific functions. Therefore, firmware is subject to the same sovereignty scrutiny as application code, including requirements for source code audits and migration plans.

The Exclusion of "Hardware"

Conversely, Article 3, point (5) of Regulation (EU) 2024/2847 defines hardware as:

"a physical device, circuit or machine, including any associated physical components, developed by design to perform specific functions, activities or tasks."

Because Annex II explicitly states that hardware is "outside of the scope," the specific sovereignty criteria regarding design origin, third-country control over development, and software supply chain transparency do not apply to the physical components themselves. The proposal does not mandate that servers, storage arrays, network switches, or processors be designed or manufactured in the Union to meet the assurance levels.

The Interplay: Location vs. Origin

While the origin of the hardware is excluded from the software-centric criteria, the location of the hardware is a critical requirement for Union assurance levels 2, 3, and 4.

  • Location Requirement: Annex II, Section 2.1(b) (Level 2), Section 3.1(b) (Level 3), and Section 4.1(b) (Level 4) require that the "infrastructure, assets, and personnel" of the provider and subcontractors are located in the Union.
  • Implication: A provider can use hardware manufactured in a third country (e.g., servers with chips designed outside the EU), provided those physical assets are physically located within the EU. However, the software controlling that hardware must meet the strict sovereignty criteria, including the absence of third-country control over the software's design, development, and maintenance.

For Union assurance level 4, the criteria are particularly stringent regarding software control. Annex II, Section 4.1(i)(ii) requires providers to demonstrate that a third country does not hold or exercise effective control over the "design, development, maintenance, and evolution" of software components. This creates a scenario where the physical machine may be foreign-made, but the "brain" (software) and its evolution must remain under Union control.

What this means for you

For CTOs, architects, and procurement teams evaluating cloud providers against the proposed CADA tiers, this distinction dictates a specific due diligence strategy. You are not auditing the supply chain of the physical rack; you are auditing the supply chain of the code running on it.

1. Audit the Stack, Not the Rack

When verifying compliance for Union assurance levels 2, 3, or 4, your primary focus must be the software Bill of Materials (SBOM).

  • SBOM Requirement: Annex II, Section 2.1(i)(i) (and equivalent sections for Levels 3 and 4) mandates a "complete and up-to-date software bill of materials (SBOM)."
  • Third-Party Controls: You must verify that the provider has implemented controls to block remote features in third-country software that could "materially tamper with or disrupt a device, system, or software."
  • Firmware Scrutiny: Do not treat firmware as a hardware component. It is software. Ensure the provider has a documented migration plan for firmware in the event a third-country vendor fails or imposes restrictions.

2. Distinguish Origin from Location

A common pitfall is assuming that "sovereign" means "EU-made hardware."

  • Hardware Origin: Irrelevant for the software criteria. Non-EU hardware is permissible.
  • Hardware Location: Critical. For Levels 2–4, the infrastructure must be physically located in the Union.
  • Action: Request proof of data center location (lease agreements, facility logs) alongside the SBOM.

3. Supply Chain Transparency

The proposal requires deep visibility into the software supply chain.

  • Open Source: If open-source software is used, the provider must demonstrate controls to prevent remote tampering (Annex II, Section 2.1(j)).
  • Dependency Management: Providers must document dependencies and demonstrate a plan to migrate to alternative solutions if a third-country vendor imposes restrictions (Annex II, Section 2.1(i)(ii)).
  • Audit Evidence: Auditing organisations will request evidence of these measures under Annex III. Ensure your provider can produce the necessary documentation, including source code audit rights and migration plans.

Common misconceptions

"CADA bans non-EU hardware." This is incorrect. The proposal explicitly excludes hardware from the scope of the assurance criteria in Annex II. There is no requirement for servers or chips to be manufactured in the Union. The restriction applies to the location of the hardware (must be in the EU for Levels 2–4) and the control of the software running on it.

"Firmware is hardware and therefore exempt." This is a critical error. Under the definition in Regulation (EU) 2024/2847 referenced by CADA, firmware is "software" (binary code loaded into a device). Therefore, firmware is fully subject to the sovereignty criteria, including requirements for source code audits, SBOMs, and migration plans.

"Level 1 ignores software origin." While Union assurance level 1 relies on self-assessment rather than third-party audit, it still imposes software-centric criteria. Annex II, Section 1.1(g) requires providers to guarantee that no laws in a controlling third country require the reporting of software vulnerabilities prior to exploitation. The software itself remains the subject of the assessment, even at the baseline level.

Related

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