Summary Vendor lock-in is a dependency vulnerability where switching costs, proprietary architectures or lack of interoperability prevent a customer from changing cloud providers without significant technical or financial loss. Under the proposed Cloud and AI Development Act (CADA), this is a sovereignty risk because it can enable a third-country-controlled provider to exert economic or political coercion, undermining operational autonomy and public order. While the Data Act addresses the mechanics of switching, CADA would add demand-side measures — risk assessments, sovereignty criteria and procurement criteria — that push public sector bodies toward interoperable, sovereign solutions.
Detail
Vendor lock-in is not merely an inconvenience; in the context of EU digital sovereignty it is a structural vulnerability. It occurs when a provider uses proprietary formats, closed ecosystems or complex integration dependencies that make switching technically difficult, financially prohibitive or operationally risky.
CADA as proposed identifies this as a threat to public order. Recital 50 lists "dependency vulnerabilities (i.e. political and/or economic coercion, for example by using vendor or technology lock-ins, embargos or sanctions, monopoly pricing damaging the financial interest of the Union and Member States)". This reframes lock-in from a contract issue to a matter of strategic autonomy: if a public authority or critical-infrastructure operator is locked into a provider subject to third-country jurisdiction, that provider — or the government controlling it — could degrade service, restrict access or impose prohibitive costs, threatening the continuity of essential services.
The roles of the Data Act and CADA
The EU's approach to lock-in is two-pronged:
- The Data Act (mechanical switching). The Data Act provides technical and legal tools to reduce lock-in — data portability, interoperability and switching rights for cloud services. As the CADA explanatory memorandum notes, however, while measures such as the Data Act remove key sources of vendor lock-in, they do not by themselves shape a more competitive offer of European cloud services or encourage the entry of a more diverse set of providers.
- CADA (sovereign assurance and demand-side measures). CADA would add a demand-side framework that discourages lock-in for public sector bodies. Through the Union assurance levels (Article 16 and Annex II), providers seeking the higher levels would have to demonstrate operational autonomy and the absence of third-country control that could lead to disruption or data access.
How CADA would mitigate lock-in risks
1. Risk assessments and multi-cloud strategies Article 29 would oblige Member States and Union entities to conduct risk assessments determining the appropriate assurance level, considering the risk and impact on public order of possible service disruption (Article 29(2)(c)). Article 29(9) would require those assessments to consider whether a multi-vendor or multi-cloud strategy is appropriate, and Recital 65 encourages this to enhance resilience and limit dependency on a single provider — directly countering lock-in by architectural design.
2. Sovereign cloud criteria (Annex II) To reach the higher assurance levels, providers would have to meet criteria in Annex II. For example, at level 2 and above, the criteria include that customer data remains exclusively within the Union (unless the public sector body explicitly requires otherwise); that technical and operational support is initiated and performed exclusively within the Union; and that software-supply-chain controls block remote features that could materially tamper with or disrupt the service and provide a documented migration plan in the event the vendor fails or a third country imposes restrictions (Annex II, point 2.1(i)). These criteria support sovereignty and reduce the risk of being held hostage by a third-country legal regime.
3. Public procurement and open source Article 32 would require contracting authorities, in procurement for innovative cloud and AI services, to include non-price award criteria evaluating the tenderer's contribution to a European cloud and AI ecosystem, including strengthening the Union's digital supply chain. Separately, Article 41 would have the Union and Member States encourage public bodies to use open standards and open-source components, and Article 43 would establish an EU Open Source Solutions Catalogue — measures that can inherently reduce lock-in by favouring solutions less tied to a single proprietary vendor.
What this means for you
For CTOs, architects and SMEs, the question shifts from "can we switch?" to "how do we prove we are not locked in?"
- Architectural decoupling. If you serve public sector or critical-infrastructure clients, design for portability — open APIs, standardised data formats and clear exit strategies. Monolithic, proprietary stacks will struggle against the higher assurance levels.
- Document migration paths. Under the level 2+ software-supply-chain criteria (Annex II, point 2.1(i)), you would need to document a migration plan and demonstrate controls blocking remote tampering features. Auditors will look for evidence you can migrate workloads if a vendor fails or a third country imposes restrictions.
- Procurement readiness. Public buyers would assess lock-in as a dependency vulnerability. In tenders, explicitly address how your solution mitigates it — interoperability, open-source components and multi-cloud compatibility.
- SME opportunities. The open-source emphasis (Articles 41 and 43) creates room for European SMEs to compete with hyperscalers by offering solutions that are inherently less prone to lock-in and better aligned with sovereign requirements.
Common misconceptions
- "The Data Act solves vendor lock-in." The Data Act provides the right to switch and technical portability, but it does not guarantee operational autonomy or protect against third-country coercion. CADA would address the strategic and sovereignty dimensions the Data Act leaves open.
- "Open source automatically means no lock-in." Not necessarily. Open-source software can still be delivered as a proprietary managed service that creates operational lock-in. CADA's assurance levels focus on service characteristics — data location, support location, control — not just the software licence.
- "Vendor lock-in is only a public sector concern." CADA would mandate risk assessments for public sector bodies, but Article 31 allows entities listed in Annex I of the NIS2 Directive that are not public sector bodies to carry out similar impact assessments. Public-procurement signals are also likely to drive private-sector adoption of low-lock-in, sovereign solutions.
Official sources
Related
- What is a sovereignty risk assessment under CADA?
- Why is cloud sovereignty important for critical infrastructure? CADA
- Why is sovereignty described as layered or nuanced in CADA?
- CADA Sovereignty: Why Assessment is Per Service, Not Per Provider
- Why is sovereignty a competitiveness issue, not just a security one? | CADA
This is general information about a draft EU regulation, not legal advice.