CADA Level 3 vs Level 2: Critical Architecture & Personnel Changes

Summary As proposed, the Cloud and AI Development Act (CADA) Level 3 imposes significantly stricter architectural and operational constraints than Level 2. The most critical shifts involve personnel: Level 3 mandates that all personnel involved in service provision must be Union citizens, whereas Level 2 only requires such personnel to be available if a public body requests it. Furthermore, Level 3 requires that technical support be performed exclusively by Union residents and by entities not subject to third-country control, eliminating the conditional safeguards allowed in Level 2. Level 3 also generally prohibits third-country control entirely, permitting it only via a specific Commission derogation for "associated third countries" under Article 18. These changes demand a fundamental restructuring of global support chains, identity management systems, and software supply chain controls, including mandatory source-code access and SBOM transparency.

Detail

The Cloud and AI Development Act (CADA), as proposed in COM(2026) 502 final, establishes a four-tier "Union assurance" framework to safeguard the Union's public order and strategic autonomy. While Level 2 establishes a baseline of sovereignty with conditional safeguards, Level 3 represents a qualitative leap toward absolute operational independence. The architectural and operational distinctions are explicitly codified in Annex II of the proposal, specifically in the comparison between Section 2 (Union assurance level 2) and Section 3 (Union assurance level 3).

1. Personnel Citizenship: From Conditional to Mandatory

The most immediate and impactful architectural change for Level 3 concerns the nationality and legal status of the workforce.

Level 2 (Annex II, Section 2.1(d)): The requirement is conditional. It states that "if the public sector body determines that imposing additional personnel screening and Union citizenship requirements are necessary, the audited provider should ensure that personnel meeting those requirements are available." This implies that, by default, a Level 2 provider may employ non-EU citizens, provided they can scale up a Union-citizen workforce if specifically requested by a client.
Level 3 (Annex II, Section 3.1(d)): The requirement is absolute and mandatory. The text stipulates that "the personnel, including the personnel of the subcontractors which are involved in the provision of the audited service are Union citizens." Additionally, where appropriate, these personnel must hold necessary national security clearances issued by a Member State when handling classified information.

Architectural Impact: Providers cannot rely on a global pool of engineers for routine operations. The architecture must enforce identity verification and location checks at the access layer. Systems must be designed to log and verify the EU citizenship status of any individual with access to infrastructure, assets, or data. This likely requires integrating with national identity verification systems or maintaining rigorous, auditable HR records linked directly to system access controls (IAM). The "just-in-time" availability model of Level 2 is replaced by a "always-on" citizenship requirement for Level 3.

2. Technical and Operational Support Chains: Residency and Control

Level 2 allows for some flexibility regarding the location and control of support personnel, whereas Level 3 imposes strict geographic and jurisdictional boundaries.

Level 2 (Annex II, Section 2.1(h)): Requires that technical and operational support, including sub-outsourcing, are "initiated and performed exclusively within the Union." However, it does not explicitly restrict the citizenship or third-country control status of the support personnel beyond the general establishment requirements.
Level 3 (Annex II, Section 3.1(h)): Tightens this significantly. Support must be "initiated and performed exclusively within the Union, by personnel that are Union residents, and by third parties that are not subject to the control of a third country or a legal entity established in a third country."

Architectural Impact: This necessitates a complete decoupling of support functions from any global support centers located outside the EU or staffed by non-residents. The architecture must include:

Geo-fencing of Administrative Access: All administrative interfaces (e.g., for incident response, backup handling, or security operations) must be accessible only from within the EU.
Residency Verification: Access control systems must verify not just citizenship but residency for support staff.
Supply Chain Segregation: Subcontractors providing support must be vetted to ensure they are not controlled by third-country entities. This requires architectural visibility into the subcontractor's ownership and control structures, as defined in Annex III, Audit Criterion G.

3. Third-Country Control and the Article 18 Derogation

Level 2 provides a pathway for providers controlled by third countries to achieve certification, provided they demonstrate specific safeguards. Level 3 removes this general pathway, creating a near-total prohibition.

Level 2 (Annex II, Section 2.1(g)): Allows providers and subcontractors subject to third-country control to qualify if they demonstrate that legal, technical, and organizational measures ensure:
- Control is not exercised to restrict service delivery.
- Access by a third country to customer data is prevented.
- Disruption of service continuity is prevented.
- The provider is not obliged to implement third-country restrictive measures (e.g., sanctions/embargoes) unless legitimate under EU law.
Level 3 (Annex II, Section 3.1(g)): States that the audited provider and subcontractors "are not subject to the control of a third country or a legal entity established in a third-country."

The Derogation Exception: Level 3 includes a narrow, specific derogation. A provider subject to third-country control may be audited for Level 3 only if the Commission has adopted an implementing act under Article 18 (titled "Associated third countries") identifying that third country as providing sufficient assurances. Even then, the provider must demonstrate the same safeguards as Level 2 (preventing data access, preventing disruption, etc.). Note that Article 18 is the correct cross-reference for this derogation; earlier drafts or summaries sometimes incorrectly cited Article 19.

Architectural Impact: For providers not from an "associated third country," the architecture must prove absolute independence from third-country control. This involves demonstrating, via Annex III, Audit Criterion G, that no third-country shareholder, board member, or commercial/financial link exerts control. Architecturally, this means implementing technical barriers that make it impossible for third-country entities to access data or disrupt service, even if they hold equity. This may require air-gapped management planes or cryptographic controls that render third-country keys ineffective.

4. Software Supply Chain: SBOMs, Remote Features, and Source Code

Both levels require rigorous software supply chain management, but Level 3 intensifies the scrutiny on third-country components and mandates deeper transparency.

SBOM and Dependencies (Annex II, Section 3.1(i)): Level 3 requires a complete and up-to-date Software Bill of Materials (SBOM) and a list of identified dependencies.
Third-Country Software Components (Annex II, Section 3.1(i)(ii)): Where software components are provided by a third-country entity, controls must be implemented to:
- Block remote features that could tamper with or disrupt the system (including during updates).
- Ensure security-relevant components are subject to source code audits.
- Have a documented migration plan if the vendor fails or a third country imposes restrictions.
Source Code Access (Annex II, Section 3.1(g)(i)): For providers subject to third-country control (under the Article 18 derogation), the audited provider "should allow for reasonable access to the code." While Level 2 does not explicitly mandate this level of code transparency for third-country controlled entities, Level 3's derogation path implies a higher degree of auditability.

Architectural Impact: Providers must maintain an auditable SBOM for all software in the stack. For any third-country software, the architecture must include mechanisms to:

Disable Remote Features: Implement network controls or code modifications to block "phone-home" capabilities or remote kill switches.
Facilitate Source Code Audits: Ensure that source code for security-relevant components is accessible to auditing organizations. This may require escrow arrangements or dedicated audit environments.
Migration Readiness: Architectural designs must support rapid migration away from third-country software components, implying modular design and standardized interfaces.

5. Data Localization and AI Training

Both levels require data to remain in the Union, but Level 3 reinforces the prohibition on using customer data for AI training by third parties.

Level 2 (Annex II, Section 2.1(f)): Data generated by the service must not be used to train/fine-tune AI systems operated by a third country and must not be transferred outside the Union.
Level 3 (Annex II, Section 3.1(f)): Identical requirement: data must not be used to train/fine-tune AI systems operated by a third country and must not be transferred outside the Union.

Architectural Impact: While the requirement is textually similar, the enforcement under Level 3 is stricter due to the overall higher assurance level. The architecture must include technical controls (e.g., data loss prevention, encryption with key management strictly within the EU) to prevent any leakage of data to third-country AI training pipelines.

What this means for you

For CTOs and architects evaluating CADA Level 3, the shift from Level 2 is not merely procedural; it is structural.

Restructure Support Operations: You must move all technical support, including subcontracted support, to EU-based personnel who are Union residents. Global support centers outside the EU cannot be used for Level 3 services.
Audit Personnel Citizenship: Implement systems to verify and log the EU citizenship of all staff and subcontractor personnel with access to the service. This is a hard requirement, not a best practice.
Decouple from Third-Country Control: If your provider or key subcontractors are controlled by third-country entities, you must either:
- Restructure ownership to remove third-country control.
- Rely on the Commission's derogation for "associated third countries" (currently undefined in the proposal but expected to be limited).
- Accept that you cannot offer Level 3 assurance.
Enhance Software Supply Chain Visibility: Prepare for rigorous source code audits of third-country software components. Ensure your architecture allows for the blocking of remote tampering features and supports rapid migration from third-country software.
Invest in Identity and Access Management (IAM): Your IAM systems must support geo-fencing for administrative access and integration with citizenship and residency verification processes.

Common misconceptions

"Level 3 is just Level 2 with more paperwork." Incorrect. Level 3 mandates EU citizenship for personnel and EU residency for support staff, which are structural changes, not just documentation updates.
"Third-country controlled providers can easily get Level 3." Incorrect. Level 3 generally prohibits third-country control. Only providers from "associated third countries" (as defined by the Commission under Article 18) may qualify, and even then, they must demonstrate strict safeguards.
"Support can be outsourced to non-EU EU-citizens." Incorrect. Level 3 requires support personnel to be Union residents, not just citizens. Location matters.
"SBOM is enough for software supply chain compliance." Incorrect. Level 3 also requires blocking remote tampering features, source code audits for third-country components, and documented migration plans.

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

CADA Level 3 vs Level 2