Summary Under the proposed Cloud and AI Development Act (CADA), vendor lock-in is elevated from a commercial inconvenience to a critical dependency vulnerability that threatens the Union's public order and operational autonomy. Article 29 mandates that Member States and Union entities conduct risk assessments to determine the appropriate "Union assurance level" for cloud services. Crucially, Article 29(9) explicitly requires these assessments to consider whether a multi-vendor or multi-cloud strategy is appropriate to mitigate risks. By framing lock-in alongside embargos and sanctions in Recital 50, CADA forces public authorities to evaluate exit barriers and concentration risks, ensuring that cloud procurement does not create irreversible ties to single providers, particularly those subject to third-country control.

Detail

The proposed Cloud and AI Development Act (CADA) represents a paradigm shift in how the EU regulates cloud computing dependencies. While previous instruments, such as the Data Act, focused primarily on technical portability and reducing switching costs, CADA reframes vendor lock-in as a fundamental issue of technological sovereignty and security. The proposal posits that reliance on a single providerβ€”especially one controlled by a third countryβ€”creates structural vulnerabilities that can be exploited for political leverage, economic coercion, or service disruption.

Vendor Lock-In as a Dependency Vulnerability

The legal foundation for treating vendor lock-in as a security risk is explicitly laid out in Recital 50 of the CADA proposal. This recital details the risks arising from the Union's dependence on a limited number of cloud computing service providers, particularly those subject to the control of third countries. It categorizes these risks into three distinct buckets: misuse, access to information, and dependency vulnerabilities.

Recital 50 explicitly defines "dependency vulnerabilities" to include:

  • Political and/or economic coercion;
  • Vendor or technology lock-ins;
  • Embargos or sanctions;
  • Monopoly pricing damaging the financial interest of the Union and Member States.

By listing "vendor or technology lock-ins" in the same breath as embargos and sanctions, CADA signals that lock-in is not merely a contractual friction point or a market inefficiency. Instead, it is a strategic threat to public order. If a public authority is locked into a single provider's proprietary ecosystem, it loses the agility to pivot in response to geopolitical shifts, supply chain disruptions, or unilateral decisions by a provider to degrade service quality or restrict access. In the CADA framework, the inability to switch providers due to technical or economic barriers is viewed as a failure of operational autonomy.

The Role of the Risk Assessment (Article 29)

The primary mechanism for addressing these risks is the mandatory risk assessment outlined in Article 29. Member States and Union entities are required to carry out these assessments to determine which Union assurance level (1 through 4) is appropriate for their specific cloud services. However, the scope of this assessment extends far beyond simple data classification; it requires a holistic evaluation of the operational and strategic context of cloud usage.

Article 29(2) mandates that assessors consider several critical factors:

  • The sensitivity, criticality, and magnitude of the non-personal and personal data processed.
  • The risk of unlawful access by a third country or a legal entity established in a third country.
  • The risk and consequent impact on public order of possible service disruption.

Crucially, Article 29(9) introduces a specific, actionable mitigation requirement regarding architectural strategy. It states: "In their risk assessments, Member States and Union entities shall consider whether a multi-vendor or multi-cloud strategy is appropriate as part of their procurement of cloud computing services."

This provision is the linchpin for addressing vendor lock-in. It mandates that risk assessors actively evaluate whether reliance on a single vendor creates an unacceptable concentration of risk. If a provider's proprietary formats, closed APIs, or complex integration layers make migration prohibitively expensive or technically unfeasible, this constitutes a failure in the risk assessment's mitigation planning. The assessment must therefore drive procurement decisions toward architectures that preserve the freedom to switch, effectively neutralizing the threat of vendor lock-in identified in Recital 50.

Multi-Vendor Strategies as Mitigation

The explicit reference to multi-vendor or multi-cloud strategies in Article 29(9) serves as the practical lever CADA provides to combat lock-in. A multi-cloud approach distributes workloads across different providers, ensuring that no single entity holds a monopoly over critical operations. This architectural choice directly reduces the "dependency vulnerability" identified in Recital 50.

If a risk assessment reveals that a current or proposed cloud setup relies heavily on proprietary technologies that cannot be replicated elsewhere, the assessment must flag this as a high-risk area. The required mitigation would involve:

  1. Adopting Open Standards: Prioritizing services built on open-source components and open standards, aligning with the "open source first" principle in Article 41.
  2. Contractual Safeguards: Ensuring contracts include clear data export formats and transition assistance clauses, reinforcing the spirit of the Data Act's switching rules while addressing the broader sovereignty concerns of CADA.
  3. Architectural Decoupling: Designing systems so that core logic is not tied to a specific provider's unique hardware or software stack, thereby reducing the "lock-in" effect.

By making the consideration of multi-vendor strategies a mandatory part of the risk assessment, CADA ensures that CTOs and architects cannot ignore the long-term strategic cost of proprietary lock-in. It forces a business case for portability, ensuring that the ease of initial deployment does not come at the expense of future autonomy.

What this means for you

For CTOs, architects, and SMEs providing cloud services to the public sector, CADA's approach to vendor lock-in has immediate and profound implications for product design, sales strategies, and compliance planning.

For Public Sector CTOs and Architects:

  • Audit Your Exit Strategy: When conducting your Article 29 risk assessment, you must explicitly document how you are mitigating vendor lock-in. If you rely on a single hyperscaler, you must provide a robust justification for why a multi-cloud strategy is not appropriate. Be prepared to demonstrate that your architecture allows for feasible migration without prohibitive cost or technical barriers.
  • Prioritize Interoperability: Your risk assessment will likely favor providers who support open standards and containerized workloads that are easily portable. Proprietary, closed ecosystems will be viewed as higher risk due to the "dependency vulnerability" classification in Recital 50.
  • Budget for Multi-Cloud Complexity: The requirement to consider multi-vendor strategies means you may need to invest in abstraction layers or middleware that decouple your applications from specific provider APIs. This upfront cost is a necessary mitigation against the strategic risks of lock-in and must be factored into your procurement planning.

For Cloud Providers and SMEs:

  • Highlight Portability as a Selling Point: In public procurement, you can leverage CADA's risk assessment requirements by demonstrating how your services reduce lock-in. Show that your APIs are open, your data formats are standard, and your migration tools are robust. Position your solution as a key enabler of the "multi-vendor strategy" that CADA encourages.
  • Support Multi-Cloud Environments: SMEs that offer interoperable, lightweight cloud services or open-source middleware are well-positioned to help public bodies comply with Article 29(9). Your ability to integrate with diverse ecosystems is a competitive advantage.
  • Avoid Proprietary Traps: If your service relies on deep integration with a single larger ecosystem, you may face scrutiny in risk assessments for high-assurance levels (2-4). Ensure you have clear pathways for customers to extract their data and move their workloads without prohibitive technical barriers, as failure to do so could disqualify you from public contracts.

Common misconceptions

Misconception 1: CADA bans single-cloud deployments. CADA does not prohibit using a single cloud provider. However, it requires that the decision to do so be the result of a rigorous risk assessment under Article 29. If a single-cloud setup creates an unacceptable dependency vulnerability (e.g., for critical national infrastructure), the risk assessment must either mandate a higher assurance level (which may restrict third-country providers) or require a multi-vendor mitigation strategy. The law demands justification, not prohibition.

Misconception 2: Vendor lock-in is only about data portability. While the Data Act focuses on the technical ability to move data, CADA expands this to include operational and strategic autonomy. Lock-in under CADA includes the inability to switch due to proprietary APIs, specialized hardware dependencies, or complex contractual terms that create economic coercion. It is a broader sovereignty concern, not just a data export issue.

Misconception 3: Multi-cloud is always the solution. Article 29(9) requires authorities to consider whether a multi-vendor strategy is appropriate. It does not mandate it in every case. For lower-risk activities, a single-provider strategy with strong contractual safeguards and open standards may be sufficient. The risk assessment must balance the complexity and cost of multi-cloud architectures against the actual risk of dependency and disruption. The goal is proportionate risk management, not blanket multi-cloud adoption.

Official sources

Related

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