Summary Under the proposed Cloud and AI Development Act (CADA), cloud computing service providers seeking Union assurance level 3 recognition must maintain a complete and up-to-date Software Bill of Materials (SBOM) and document all identified dependencies. As proposed in Annex II, Section 3.1(i), providers must implement controls to block remote tampering features in third-country software components and ensure these components undergo source code audits. Crucially, if a provider is subject to third-country control (via the Article 18 derogation), they must guarantee "reasonable access to the code" to demonstrate that no external laws compel them to report software vulnerabilities before those vulnerabilities are publicly known or exploited.

Detail

The Cloud and AI Development Act (CADA), as proposed in COM(2026) 502 final, establishes a tiered sovereignty framework to mitigate risks associated with dependence on non-European providers. Union assurance level 3 represents a high tier of trust, intended for public sector activities where data sensitivity and operational autonomy are critical, including the secure hosting of EU classified information. To achieve this recognition, providers must undergo independent third-party audits against strict criteria outlined in Annex II of the proposal.

The supply chain requirements for Level 3 are among the most rigorous in the proposal, moving beyond simple data localization to deep technical transparency and control over the software stack.

SBOM and Dependency Documentation

At the core of the Level 3 supply chain requirements is the mandate for total transparency regarding software components. Annex II, Section 3.1(i) explicitly requires that the audited provider demonstrates that specific software supply chain measures are in place. The first cumulative criterion under this section states that:

"a complete and up-to-date SBOM and a list of identified dependencies relevant to the provision of the service are documented and made available to the auditing organisation."

This requirement goes beyond a simple inventory list. The SBOM must be comprehensive, covering all software components used in the provision of the service, including open-source software. Furthermore, the provider must maintain a detailed list of identified dependencies. This documentation serves as the primary evidence for auditors to assess the provider's visibility into its own software stack and its reliance on external, potentially high-risk components. Without this granular visibility, a provider cannot prove that their service is free from hidden backdoors or unmanaged risks.

Controls on Third-Country Components

The proposal recognizes that the complete elimination of third-country software components may not always be feasible for Level 3 services. However, CADA imposes rigorous controls when such components are used. According to Annex II, Section 3.1(i)(ii), where software components or products are "provided, owned, and licensed by a legal entity established in a third country," the provider must implement and document specific controls. These controls must:

  1. Block Remote Tampering: Implement measures to block any remote features that could materially tamper with or disrupt a device, system, or software, including during updates.
  2. Mandate Source Code Audits: Ensure that security-relevant components from third-country manufacturers are subject to source code audits.
  3. Plan for Migration: Include a documented migration plan in the event that the vendor fails or a third country imposes restrictions.

The requirement for source code audits is particularly significant. It implies that providers cannot rely solely on vendor assurances or "black box" certifications for third-country software. They must have the technical capability and contractual right to inspect the underlying code to verify the absence of backdoors, kill switches, or other mechanisms that could compromise service integrity or data confidentiality. This aligns with the broader CADA objective of ensuring operational autonomy even when using global supply chains.

Reasonable Access to Code and Vulnerability Reporting

A distinct and critical feature of Union assurance level 3, compared to lower tiers, involves stricter rules regarding providers subject to third-country control. Annex II, Section 3.1(g) establishes a general prohibition on providers being subject to the control of a third country or a legal entity established in a third country. However, it provides a specific derogation: a provider subject to such control may still be audited for Level 3 if the Commission has adopted an implementing act under Article 18 identifying the third country as providing sufficient assurances.

For providers falling under this derogation, Annex II, Section 3.1(g)(i) imposes specific obligations. They must demonstrate that the necessary legal, technical, and organizational measures have been implemented to ensure that third-country control does not restrict their ability to perform the service. Critically, the text states:

"The audited provider should allow for reasonable access to the code."

This "reasonable access" requirement is tied to a broader obligation regarding software vulnerabilities. Annex II, Section 3.1(i)(iii) requires that where the provider is subject to third-country control, they must guarantee that:

"there are no existing laws and practices in that third country, demonstrated by independent sources, that require the cloud computing service provider to report information on software vulnerabilities to authorities of that third country prior to those vulnerabilities being known to have been exploited."

The requirement for reasonable access to the code supports this guarantee. It allows auditors and potentially public sector customers to verify that the provider has not been compelled by foreign law to share vulnerability details prematurely. Premature disclosure of vulnerabilities could expose EU public sector systems to coordinated cyberattacks before patches are available. This creates a high bar for providers with significant third-country ownership or operational ties, requiring them to prove that their codebase remains free from foreign legal coercion regarding security disclosures.

Open Source Software Controls

Annex II, Section 3.1(j) extends these supply chain vigilance requirements to open-source software. Providers must demonstrate that they have implemented and documented appropriate controls to prevent the use of any remote features or mechanisms in open-source components that could be used to materially tamper with or disrupt the service. This ensures that the open-source ecosystem, while valuable for innovation and sovereignty, is not exploited as a vector for supply chain attacks.

Audit Evidence and Verification

The enforcement of these rules relies on the audit process defined in Article 20 and detailed in Annex III. Auditing organizations will request specific evidence, including the SBOM, dependency lists, and documentation of the controls mentioned above. They will verify the provenance of software, the origin of components, and the degree of reliance on non-EU vendors. The audit must confirm that the provider has tested software components to prevent remote tampering and that change management procedures cover firmware, BIOS, and software updates to maintain this security posture.

What this means for you

For CTOs, architects, and compliance officers evaluating cloud providers for critical public sector workloads, CADA Level 3 SBOM requirements signal a fundamental shift from vendor trust to verifiable transparency. You can no longer accept a provider's general security statement; you must be able to audit their supply chain visibility.

Immediate Actions for Providers

  • Automate SBOM Generation: Ensure your CI/CD pipelines automatically generate and maintain a comprehensive SBOM for all services. This SBOM must be readily accessible for audit purposes and updated in real-time.
  • Review Third-Country Contracts: Scrutinize contracts with third-country software vendors. You must have explicit rights to conduct source code audits and to block remote tampering features. If you lack these rights, you may need to replace those components or renegotiate terms before seeking Level 3 recognition.
  • Develop Migration Plans: Document clear, tested migration strategies for all critical third-country software components. Auditors will look for evidence that you can switch vendors or solutions if a third country imposes restrictions.
  • Assess Third-Country Control: If your company has significant third-country ownership, prepare to demonstrate "reasonable access to the code" and prove that no foreign laws compel premature vulnerability reporting. This may require legal opinions and technical audits of your codebase.

For Buyers and Integrators

  • Demand SBOMs: When procuring cloud services for sensitive data, require the provider's SBOM and dependency list as part of the due diligence process.
  • Verify Audit Rights: Ensure your contract allows for independent verification of the provider's supply chain controls, including the right to inspect evidence of source code audits for third-country components.
  • Monitor Open Source Usage: Ask providers how they manage risks in their open-source components, specifically regarding remote tampering and supply chain integrity.

Common misconceptions

Misconception 1: Level 3 requires 100% EU-made software. CADA does not mandate that all software components be designed and manufactured in the Union. It allows for the use of third-country components but imposes strict controls, including source code audits and blocking of remote tampering features. The focus is on risk mitigation and operational autonomy, not absolute geographical origin.

Misconception 2: SBOMs are only for Level 4. While Level 4 has stricter requirements regarding control and personnel, Annex II explicitly mandates a "complete and up-to-date SBOM" for Level 3 as well. The difference lies in the depth of control over third-country components and the prohibition on third-country control at Level 4 (with no derogation), whereas Level 3 allows a derogation with specific safeguards like "reasonable access to the code."

Misconception 3: "Reasonable access to code" means full source code disclosure to all customers. The requirement for "reasonable access to the code" in Annex II, Section 3.1(g)(i) is primarily an audit and verification mechanism to ensure that third-country laws are not being used to coerce vulnerability reporting. It does not necessarily mean that all public sector customers have unrestricted access to the provider's proprietary source code, but rather that the provider must allow sufficient access to auditors and competent authorities to verify compliance with sovereignty and security standards.

Related

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