Summary Under the proposed Cloud and AI Development Act (CADA), cloud providers seeking Union assurance levels 2, 3, or 4 must implement rigorous controls over third-country software components to prevent remote tampering, disruption, or unauthorized access. Specifically, providers must block remote features that could materially tamper with systems, subject security-relevant third-country components to source code audits, and maintain documented migration plans in case of vendor failure or third-country restrictions. At Union assurance level 4, the requirement tightens significantly: providers must demonstrate that no third country exercises "effective control" over the design, development, maintenance, or evolution of the software components. These rules apply even to open-source software if remote disruption mechanisms are present.

Detail

CADA introduces a tiered sovereignty framework designed to mitigate risks associated with dependencies on non-European cloud and AI technologies. For cloud computing service providers aiming to be recognized as offering Union assurance levels 2, 3, or 4, the regulation imposes cumulative criteria regarding software supply chain transparency and security. These requirements are detailed in Annex II to the proposed regulation, which sets out the specific criteria for each assurance level. The framework moves from blocking immediate threats at lower levels to ensuring long-term autonomy at the highest level.

Blocking Remote Tampering and Disruption (Levels 2 & 3)

A core obligation for providers seeking Union assurance levels 2 and 3 is the mitigation of "kill switch" risks or remote manipulation capabilities inherent in some third-country software. According to Annex II, Section 2.1(i)(ii), where software components are provided, owned, and licensed by a legal entity established in a third country, the audited provider must implement and document controls to "block any remote features that could materially tamper with or disrupt a device, system, or software (including during updates)."

This requirement extends specifically to "security-relevant components from third-country software manufacturers." Providers must ensure these components are subject to source code audits. Furthermore, providers must have a "documented migration plan in the event that the vendor fails or a third country imposes restrictions." This ensures that if a geopolitical event, commercial failure, or sanctions regime disrupts the software supply, the cloud provider has a viable, tested path to maintain service continuity without relying on the compromised or unavailable third-country component.

The same strictures apply at Union assurance level 3. Annex II, Section 3.1(i)(ii), reiterates that providers must implement controls to block remote tampering features and ensure that security-relevant components from third-country manufacturers are subject to source code audits. Additionally, a documented migration plan remains mandatory in the event of vendor failure or third-country restrictions. The continuity of these requirements across levels 2 and 3 underscores that preventing immediate disruption is a baseline for any sovereign cloud offering above the minimum baseline.

Union Assurance Level 4: The "Effective Control" Threshold

The requirements become significantly more stringent at Union assurance level 4, which is intended for the most critical public sector activities, including those involving classified information. At this level, the focus shifts from merely blocking remote features to ensuring fundamental autonomy over the software's lifecycle.

Annex II, Section 4.1(i)(ii), requires that the audited provider demonstrates measures to "retain effective control over the software components or products." Specifically, the provider must demonstrate that a third country or a legal entity established in a third country "does not hold or exercise effective control over the design, development, maintenance, and evolution of those components or products."

CADA defines "effective control" broadly. It includes the ability to "materially influence the technical evolution, maintenance priorities, security remediation, and long-term continuity of the component." This means that even if a provider successfully blocks remote tampering features (a Level 2/3 requirement), they may not qualify for Union assurance level 4 if a third-country entity retains the power to dictate update schedules, ignore security patches, or discontinue support for strategic reasons. This criterion effectively bars many commercial off-the-shelf third-country software solutions from being used in the most sensitive EU cloud environments unless the EU entity has contractual or technical leverage to override such control.

Open-Source Software Considerations

It is a common misconception that open-source software is exempt from these rules. Annex II, Sections 2.1(j), 3.1(j), and 4.1(j) explicitly state that where software released under an open-source licence is used, the audited provider must demonstrate that it has implemented and documented appropriate controls to prevent the use of any remote features or mechanisms that could be used to materially tamper with or disrupt a device, system, or software.

This closes potential loopholes where open-source components might be assumed to be inherently safe from remote tampering due to their public nature. The regulation recognizes that even open-source projects can be compromised by malicious actors or influenced by third-country entities that control the primary repository or maintainers. Therefore, the obligation to block remote disruption mechanisms applies regardless of the software's licensing model.

Audit and Evidence Requirements

To prove compliance with these criteria, providers must undergo independent third-party audits for Union assurance levels 2, 3, and 4. The auditing organizations will assess the audit evidence listed in Annex III.

For the software supply chain, Audit Criterion I requires providers to make available a complete and up-to-date software bill of materials (SBOM) and a list of dependencies. Crucially, the provider must provide evidence that they have identified alternative software solutions and implemented tests and switchover plans enabling migration to these alternatives. The auditor must also be granted the right to access and audit the source code of third-country software components to verify that no remote tampering features exist.

Furthermore, Audit Criterion J specifically addresses open-source software, requiring evidence of a risk-based process to identify and mitigate weak ecosystem support, failure to monitor updates, or cases where the software is deprecated. It also mandates that providers identify alternative open-source solutions and implement switchover plans.

What this means for you

For CTOs, architects, and procurement officers evaluating cloud providers or building sovereign cloud offerings, these provisions translate into immediate architectural, contractual, and operational changes.

1. Architecture Review and SBOM Management

You must audit your entire software stack for third-country components. Identify any libraries, frameworks, operating system kernels, or firmware owned by entities outside the EU. Verify if these components contain remote management features, telemetry that could be exploited for disruption, or "kill switches." You must maintain a complete and up-to-date SBOM that maps these dependencies, as this is a primary evidence requirement for auditors.

2. Contractual Leverage and Source Code Escrow

For Union assurance levels 2 and 3, your contracts with third-country software vendors must explicitly prohibit remote tampering and grant you the right to audit source code. You must negotiate clauses that allow for smooth migration if the vendor ceases operations or if their home country imposes sanctions or restrictions. For Level 4, you must assess whether you can demonstrate "effective control." This may require source code escrow arrangements, fork rights, or the acquisition of the intellectual property to ensure you can maintain and evolve the software independently of the third-country vendor.

3. Level 4 Viability and Effective Control

If you are targeting Union assurance level 4 for critical infrastructure or defense-related cloud services, you must assess whether you can demonstrate "effective control" over your software stack. This likely means moving away from proprietary third-country software for core functions and adopting open-source or EU-developed alternatives where you hold the intellectual property or have full contractual control over maintenance and evolution. Blocking remote features is necessary but insufficient; you must prove that no third party can influence the software's future development, security updates, or continuity.

4. Migration Planning and Testing

You must develop and document concrete migration plans. This is not just a theoretical exercise; auditors will expect to see tested switchover procedures to alternative software solutions. This requires significant investment in testing environments and parallel run capabilities to demonstrate that you can migrate away from a third-country component without service disruption.

Common misconceptions

"Open-source software is exempt from these rules." This is incorrect. CADA explicitly requires controls to prevent remote tampering for open-source software as well. The assumption that open code is transparent and therefore safe is not sufficient; you must actively demonstrate that no remote disruption mechanisms are present or enabled, and that you have a viable migration path if the open-source project is compromised or taken over by a third-country entity.

"Blocking remote access is enough for Level 4." No. Level 4 requires "effective control" over the software's evolution and maintenance. Blocking remote features is a Level 2 and 3 requirement. For Level 4, you must prove that no third party can influence the software's future development, security updates, or continuity, regardless of remote access capabilities. This is a qualitative shift from preventing immediate disruption to ensuring long-term autonomy.

"These rules only apply to cloud providers." While the recognition mechanism applies to providers, the demand-side measures mean that public sector bodies will only procure services that meet these assurance levels. Therefore, private sector entities operating in high-criticality sectors (as defined in Annex I of the NIS2 Directive) may face similar pressure through impact assessments and market spillover effects, as they may need to demonstrate similar supply chain resilience to secure contracts or maintain market access.

Related

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