Resilience and security are shaped by how cloud services are chosen, configured, and integrated in practice. Concepts such as portability and recoverability only become real through concrete design and contractual choices. Dependencies are therefore created primarily when organisations first adopt a cloud service and become visible when they later try to change provider or recover from disruption. For this reason, this section adopts a lifecycle perspective, focusing on how contractual and technical choices shape long-term flexibility and exit options.
3.1 How Cloud Service Models Shape Resilience
Different types of cloud services create dependency in different ways. When organisations use basic cloud infrastructure, dependency mainly arises from how networks, data storage, and system configurations are designed. Moving such systems later can be slow, costly, or technically difficult. When organisations use development platforms, dependency often arises because applications are built using provider-specific tools that do not easily work elsewhere. When organisations rely on ready-made cloud software, dependency tends to be embedded in data formats, workflows, and business processes that are difficult to transfer to competing services. Table 2 summarises where dependency typically emerges across cloud service models and how this affects practical exit and recovery. In all cases, these constraints are typically embedded during initial adoption and become visible only when organisations attempt to migrate, recover, or reconfigure under stress.
These differences explain why resilience cannot be assessed through a single technical metric. Each layer of the cloud stack creates distinct forms of lock-in with different implications for continuity, recovery, and switching. Using multiple providers can reduce some risks, but it also increases complexity and operational burden. Diversification strengthens resilience only when systems are deliberately designed and governed for flexibility. Operational resilience is therefore defined by the ability to continue operating during disruption and to adapt when conditions change. Concentration alone does not necessarily create fragility. Lock-in alone can already undermine resilience. Systemic risk emerges when concentration coincides with restricted exit and switching costs.
The next section examines how licensing practices shape this interaction. Detailed technical illustrations are provided
Table 2: How different cloud services create dependency and affect resilienceSource: ECIPE
3.2 The Impact of Restrictive Licensing on Resilience and Security
Across all service layers, licensing practices are the primary mechanism through which exit and switching are constrained in practice. Crucially, licensing-related lock-in can occur even prior to cloud adoption. When migrating from on-premise environments, customers may be deterred from selecting competing cloud providers if doing so entails substantial licensing uplifts or mark-ups, thereby shaping provider choice from the outset. Market concentration in cloud and software services is often treated as a proxy for systemic risk. Concentration alone, however, does not determine resilience outcomes. What matters is whether customers retain the practical ability to switch providers, diversify deployments, and reallocate workloads as conditions change. Licensing sits at the centre of this distinction. It shapes resilience twice – first by constraining what can be deployed and integrated at onboarding, and later by determining whether workloads can be duplicated, migrated, or recovered during disruptions or operational pressure.
Licensing practices may contribute to market concentration, but their more significant effect is limiting contestability – making it difficult for competitors to challenge incumbent providers once concentration has emerged. Where customers can move workloads, deploy independent tools, and maintain credible multi-cloud strategies and viable exit options, even highly concentrated markets can remain resilient. Structural fragility emerges when licensing frameworks make adaptation prohibitively costly, technically impractical, or contractually restricted. In this sense, restrictive licensing converts scale into dependency.
This dynamic is often underestimated because cloud contracts appear voluntary. In practice, committed-spend agreements, bundled discounts, and incentive structures progressively narrow real choice once workloads and operational processes become embedded. Decisions that appear commercially efficient at procurement can later become binding constraints during disruption or migration. Restrictions on licence mobility and bring-your-own-licence (BYOL) policies illustrate this effect. Software frequently cannot be reused across competing cloud platforms, forcing repurchase and sharply increasing switching costs. Dual-pricing models and vendor-specific metrics further raise the cost of multi-cloud operation, undermining redundancy and failover strategies for commercial rather than technical reasons. The result is structural lock-in that is often not reflected in market-share metrics, even though it is a key mechanism through which cloud service providers can strengthen and extend their market position, with direct consequences for resilience. From a resilience perspective, the relevant question is not whether alternatives exist in theory, but whether organisations can use them in practice when conditions demand it.[1]
The following section examines the main types of licensing restrictions and the mechanisms through which they constrain customer choice. Crucial to note is that they can constrain customer choices through distinct but overlapping mechanisms. Some restrict movement, others permit switching at prohibitive costs, whilst impose constraints through technical, contractual or compliance related means.
3.2.1 Restrictions Affecting Portability and Workload Mobility
These restrictions include BYOL prohibitions, limitations on licence mobility, and requirements to repurchase licences when migrating workloads. The resilience implications are direct: when licences cannot be reused across cloud environments, organisations face contractual or economic barriers to maintaining parallel deployments for redundancy or rapidly shifting workloads during outages. This undermines standard disaster recovery strategies and increases dependence on a single provider’s resilience posture. The literature consistently associates limited portability with longer recovery times and heightened exposure to provider-level failures.[2] Security risks arise in parallel. Concentrating workloads within a single ecosystem increases correlated failure risk and constrains the ability to diversify security tooling and controls. In addition, where access to extended security updates, enhanced patching, or critical support is tied to premium or cloud-specific licensing tiers, patch management decisions may be distorted, resulting in prolonged exposure to known vulnerabilities.
Table 3: Restrictions affecting portability and multi-cloud useSource: ECIPE
3.2.2 Financial Restrictions that Increase Switching Costs
This category includes architecture-dependent pricing, dual-running penalties during migration, and proprietary licensing metrics that inflate effective capacity requirements on rival clouds. By raising the economic cost of switching, these mechanisms transform nominal customer preference into practical dependency, reducing organisational agility and introducing structural risk. Even where alternative environments exist, the cost of operating workloads in parallel or executing a migration can be sufficiently high that resilience plans become difficult to operationalise in practice, limiting timely responses to prolonged outages or sustained performance degradation. Security outcomes are similarly affected. Elevated switching costs can delay or constrain an organisation’s ability to move workloads away from a provider experiencing a security incident, compliance failure, or deteriorating risk posture where doing so would trigger substantial additional licensing expenditure.
Table 4: Restrictions increasing switching costsSource: ECIPE
3.2.3 Constraints on Interoperability and Integration
Vendors often constrain interoperability by delaying product certification on rival clouds, withholding technical specifications or APIs, or relying on proprietary interfaces. Because modern resilience increasingly depends on automation and coordinated operation across heterogeneous environments, such constraints limit the feasibility and reliability of multi-cloud architectures and impede the automation of failover and recovery processes. As a result, recovery operations tend to become slower, more manual, and more error-prone due to reliance on proprietary interfaces and uncertified configurations. Security outcomes are similarly affected. Reduced interoperability undermines defence-in-depth by limiting the deployment of layered security controls, restricting cross-environment log correlation, and constraining the use of independent monitoring, detection, and forensic tools.
Table 5: Restrictions affecting interoperabilitySource: ECIPE
3.2.4 Commercial and Pricing Arrangements with Structural Effects
Some limitations on customer choice arise from pricing structures such as bundled discounts, loyalty incentives, and spend-commitment contracts that encourage deeper reliance on a single provider’s ecosystem. These arrangements are not, in themselves, evidence of competitive harm. Nevertheless, where bundled discounts are attached to products with strong market positions, they may weaken incentives to diversify or switch, thereby reinforcing dependency over time. The resilience implications are structural: economic incentives often make maintaining parallel or secondary environments difficult to justify, encouraging consolidation and tying continuity planning to the resilience posture of a single provider. From a security perspective, these arrangements frequently concentrate core identity, access management, and security services within the dominant ecosystem. This reduces architectural diversity, increases reliance on vendor-specific security controls, and amplifies systemic risk through correlated failure.
Table 6: Pricing and commercial restrictionsSource: ECIPE
3.2.5 Direct Restrictions on Security and Resilience Support
Certain licensing practices directly affect the level of technical support and the availability of security updates on rival clouds, including reduced support tiers, delayed patch delivery, and the revocation of disaster recovery rights following migration. The resilience implications are material: organisations operating outside the preferred environment may experience slower incident response and reduced ability to maintain equivalent failover or recovery capabilities. Security risks are correspondingly elevated. Unequal access to patches or extended security updates can result in prolonged exposure to known vulnerabilities, while restrictions on integrating external security tools further concentrate risk within a single vendor’s ecosystem.
Table 7: Security and Resilience RestrictionsSource: ECIPE
3.2.6 Geographic and Compliance-Linked Restrictions
Some licensing conditions restrict where workloads may operate through region-locked licences or by limiting sovereign-cloud features to designated infrastructure. From a resilience perspective, these constraints reduce cross-border failover options and limit the ability to distribute risk across jurisdictions, increasing exposure to regional outages or geopolitical disruption. While such measures are often intended to support compliance objectives, they can create forms of “compliance lock-in” that constrain architectural flexibility, impede innovation, and hinder the adoption of multi-cloud security architectures capable of meeting regulatory requirements.
Table 8: Geographic and regulatory restrictionsSource: ECIPE
In sum, these restrictions operate through three practical channels: they limit whether licences can move across environments; they raise the cost and risk of running systems in parallel during migration or recovery; and they constrain interoperability with alternative platforms and security tools. The cumulative effect is that exit remains formally possible but operationally slow, expensive, and risky – precisely when rapid adaptation is most needed.
3.3 Technology and Policy Constraints beyond Licensing
As demonstrated in earlier ECIPE work on cloud customer choice (CCC), barriers to exit are rarely contractual alone.[3] Licensing is the primary mechanism through which exit becomes restricted in practice, but it operates within a broader technical and regulatory environment that can either amplify or mitigate these constraints over the lifecycle. Architectural design choices, practical limits to portability, security tooling integration, and regulatory interventions all shape what can be onboarded, how systems evolve operationally, and whether credible exit and recovery remain feasible over the cloud lifecycle.
Because these constraints emerge through complex technical interactions that evolve rapidly and are often only partially observable even to domain experts, policy intervention must be calibrated carefully. Regulatory measures that directly prescribe technologies, architectures, or standards risk entrenching unintended dependencies, narrowing future design space, and locking in assumptions that may quickly become obsolete. The objective should therefore be to preserve adaptability across the lifecycle rather than to engineer specific technical outcomes.
3.3.1 Rights versus Real Portability
Regulatory initiatives such as the EU Data Act (DA) strengthen formal rights to switching and data access, but operational portability often remains limited.[4] Migrating live systems requires reconfiguring identity, networks, security controls, and application logic. For mission-critical workloads, engineering complexity, downtime risk, and compliance uncertainty frequently make migration slow or impractical. Exit constraints therefore originate in early architectural and onboarding choices, even where contractual rights exist. Portability that requires months of re-engineering offers little resilience in incidents measured in hours or days. This gap between legal entitlement and technical reality (described as the “Hotel California effect”)[5] illustrates how exit constraints emerge from earlier onboarding and architectural choices: organisations can enter cloud ecosystems with relative ease, but once workloads are deeply embedded, exit becomes operationally impracticable.
Standardisation pressures can reinforce this effect. Where regulatory or compliance frameworks steer organisations towards uniform architectures to simplify oversight, they reduce architectural diversity and increase correlated risk. Over time, this can produce technical monocultures in which failures propagate more easily across organisations and sectors. From a resilience perspective, preserving practical exit and architectural diversity matters more than expanding formal switching rights alone.
3.3.2 Technical Architectures and Interoperability
Modern cloud environments increasingly rely on tightly integrated managed services, proprietary interfaces, and provider-native security models. While this improves efficiency and baseline security, it couples workloads closely to individual platforms and limits interoperability across identity systems, networking models, automation frameworks, and monitoring tools. Heterogeneous architectures can reduce correlated failure risk and support reconfiguration under stress, whereas highly standardised environments simplify compliance but concentrate systemic exposure (Table 9).
The use of proprietary APIs, identity and access systems, network security models, automation frameworks, and logging technologies across cloud providers undermines interoperability. This provider-driven heterogeneity forces a compartmentalised approach to multi-cloud security, increasing operational complexity and the risk of misconfiguration and emergent attack surfaces, even where individual platforms are secure in isolation.[6]
From a resilience perspective, architectural diversity can function as risk diversification.[7] Heterogeneous architectures reduce the likelihood that a single failure cascades across systems and providers and tend to rely more on provider-agnostic interfaces, supporting portability and reconfiguration under stress. By contrast, highly standardised architectures simplify oversight but concentrate risk: failures propagate more easily and workloads become tightly bound to proprietary hooks that constrain exit.
Importantly, these architectural interactions are highly complex and continuously evolving. Even specialist engineers rarely maintain full visibility across the entire dependency chain of modern cloud stacks. Regulatory efforts to prescribe specific technical architectures or standards therefore risk hard-coding incomplete assumptions and unintentionally narrowing future design options. Resilience is better supported by preserving flexibility and optionality than by mandating technical uniformity.
An illustrative example is France’s ANSSI cloud sovereignty certification granted to S3NS, a joint venture between Thales and Google.[8] The model combines European governance, operational control, and access restrictions with continued use of Google’s underlying IaaS and PaaS capabilities, including advanced data and AI services. Rather than replacing global infrastructure, resilience is achieved through layered architectural separation and governance controls, demonstrating how hybrid designs can reconcile sovereignty objectives with interoperability, scalability, and access to innovation.
Table 9: Resilience implications of architectural diversity and standardised configurationsSource: ECIPE
3.3.3 Security Tool Integration and Resilience
A critical but often overlooked dimension of cloud resilience is whether organisations can onboard, integrate, and operate independent security tools alongside their cloud provider’s built-in security services. Many organisations rely on third-party tools – such as monitoring systems, threat detection, identity management, encryption, and incident response software – to meet internal risk standards and regulatory requirements.[9] The ability to deploy and operate these tools reliably is essential for maintaining security and operational continuity during disruptions.
Provider-native security tools offer clear practical advantages. They are tightly integrated into the cloud platform and are easy to deploy and manage (Table 10). However, this convenience comes with structural trade-offs. Because these tools typically rely on the same underlying systems as the cloud platform itself, a provider outage, configuration error, or security incident can affect both the application and the security controls protecting it at the same time. Visibility is also limited to what the provider makes available, which can restrict independent monitoring across multiple cloud environments.
Independent security tools operate with greater separation from any single cloud platform. Although they often require more effort to integrate, they reduce shared points of failure and can continue operating even if parts of a cloud environment are disrupted. They also tend to provide broader visibility across systems and providers. From a resilience perspective, this separation enables layered protection and helps organisations maintain oversight and response capability during incidents.
The choice between convenience and independence is therefore not merely a technical decision, but a resilience-relevant design choice made early in the cloud lifecycle. Regulatory or procurement frameworks that implicitly favour vertically integrated security models risk reinforcing dependence on provider-native tools and discouraging independent alternatives. While integrated security can perform well under normal conditions, resilience depends on the ability to layer, substitute, and adapt security controls as risks evolve. Security tool choice is therefore not only a competition issue, but a core capability for operational continuity and recovery.
Table 10: Resilience characteristics of provider-native and independent security toolsSource: ECIPE
3.4 Regulatory Design, Technological Diversity, and Lifecycle Lock-In
Several regulatory frameworks apply horizontal obligations across cloud services with limited differentiation between service layers, deployment models, or risk profiles. These include the EU Data Act, the NIS2 Directive, cloud certification schemes under the EU Cybersecurity Act, and elements of the DORA. While these instruments pursue legitimate objectives in security, resilience, and competition, their uniform application across heterogeneous cloud services creates important design tensions. Regulatory commitments shape not only how systems evolve operationally, but also which architectures organisations feel able to adopt at onboarding, narrowing future exit paths from the outset.
By favouring standardised compliance approaches, such frameworks can incentivise providers to converge on lowest-common-denominator service configurations in order to reduce regulatory uncertainty. In practice, this can limit the availability of specialised cloud environments for sensitive or mission-critical workloads and discourage integration with independent applications and security tools.[10] As a result, organisations face fewer architectural options at onboarding and fewer viable alternatives later when they need to adapt, migrate, or recover from disruption. Portability may exist in legal terms, but switching becomes slow, costly, or operationally risky.
Similar risks arise when regulatory logic developed for public digital platforms or telecommunications infrastructure is applied to cloud services. Instruments such as the Digital Services Act (DSA) and, in parts, the Digital Markets Act (DMA) were designed for consumer-facing platforms, while proposals to extend telecom-style regulation under the European Electronic Communications Code (EECC) to cloud services have raised concerns about regulatory fit.
Imposing telecom-style obligations on cloud and content delivery networks (CDNs) would have significant systemic effects. Telecommunications operators that currently interconnect with cloud and CDN providers largely through domestic peering arrangements would increasingly need to do so at an international level or rely more heavily on transit. Moving away from efficient peering models would likely degrade performance, reduce resilience, and raise costs across the European internet ecosystem, affecting cloud and CDN providers, telecoms operators, and ultimately European businesses and consumers.[11]
Cloud environments support sensitive and mission-critical workloads and depend on differentiated architectures, controlled access, and layered security designs. Obligations aimed at openness, uniform treatment, or extensive disclosure would narrow the range of deployable architectures and discourage specialised configurations and third-party integrations.[12]
From a lifecycle perspective, these effects compound over time. Early onboarding and design choices become increasingly difficult to reverse. Architectural diversity diminishes. Credible exit options narrow as systems mature and dependencies accumulate. What appears to simplify compliance at the point of adoption can translate into structural lock-in when organisations later seek to switch providers, diversify architectures, or respond to incidents. Public procurement frameworks increasingly shape onboarding choices for critical workloads. Embedding portability and licensing neutrality at procurement stage therefore has disproportionate long-term resilience impact.
Autonomy policies follow the same logic. Efforts to expand European cloud capacity can strengthen resilience when they increase interoperable choice and architectural diversity. They risk weakening resilience when autonomy is interpreted as isolation or when national procurement and cybersecurity requirements prioritise location or ownership over portability and interoperability. National or regional solutions can reproduce the same lock-in dynamics if they rely on restrictive licensing, proprietary interfaces, or closed security architectures.[13]
Resilience is therefore strengthened not by technological uniformity or prescriptive regulation, but by preserving diversity, interoperability, and practical exit across the cloud lifecycle. Regulatory frameworks should remain cautious about directly steering technologies or standards in rapidly evolving and highly complex cloud ecosystems, where even technical experts rarely have full visibility over system interactions and long-term effects.
[1] OECD. (2025). Competition in the provision of cloud computing services. OECD Roundtables on Competition Policy Papers, No. 323. Available at: https://www.oecd.org/content/dam/oecd/en/publications/reports/2025/05/competition-in-the-provision-of-cloud-computing-services_f42582ad/595859c5-en.pdf; also see: Jenny, F. (2023). Unfair Software Licensing Practices: A quantification of the cost for cloud customer. CISPE. Available at: https://cispe.cloud/website_cispe/wp-content/uploads/2023/06/Quantification-of-Cost-of-Unfair-Software-Licensing_Prof-Jenny_-June-2023_web.pdf
[2] A 2023 survey found that the three most common reasons organisations seek workload portability are disaster recovery and business continuity, cost savings, and overall resilience. Respondents also highlighted portability as a way to improve optimisation and efficiency, enabling better latency, performance, and scalability. See: Techstrong Research. (2023). Cloud Workload Portability. PulseMeter. Available at: https://www.linode.com/linode/en/documents/white-paper/2025/cloud-workload-portability-techstrong.pdf
[3] ECIPE (2025). Breaking Barriers to Cloud Customer Choice: Unlocking Europe’s AI and Innovation Leadership. Available at https://ecipe.org/publications/unlocking-europes-ai-and-innovation-leadership/.
[4] Portability issues arise due to the lack of open interfaces. As a result, users face difficulties switching between services to obtain the best quality-to-cost ratio. Additionally, because of lack of interoperability between cloud services from different providers, these services cannot be easily combined either. See: Netherlands Authority for Consumers and Markets. (2022). Market Study Cloud services. Case no. ACM/21/050317 / Document no. ACM/INT/440323. Available at: https://www.acm.nl/system/files/documents/public-market-study-cloud-services.pdf.
[5] Concerns about cloud exit costs have often been framed against broader industry observations that storing very large datasets in public cloud environments can be substantially more expensive than equivalent on-premises infrastructure, and that data egress charges for repatriating large volumes of data may run into tens of thousands of pounds. Related evidence was submitted to the UK Competition and Markets Authority (CMA) during its Cloud Services Market Investigation. In Appendix O (Customer views on egress fees), a broadcaster described cloud egress fees as creating a “Hotel California” situation, where data can be moved into the cloud relatively easily, but exiting is operationally and economically difficult, and characterised both the cost of moving data out of the cloud and the use of multiple suppliers as “problematic”. See: Appendix O: Customer views on egress fees. Available at: https://assets.publishing.service.gov.uk/media/67976c05cbd1e3a508a22c72/Appendix_O.pdf.
[6] Duncan, R. (2020). A multi-cloud world requires a multi-cloud security approach. Computer Fraud & Security, 2020(5), 11-12, in Reece, M., Lander Jr, T. E., Stoffolano, M., Sampson, A., Dykstra, J., Mittal, S., & Rastogi, N. (2023). Systemic risk and vulnerability analysis of multi-cloud environments. arXiv preprint arXiv:2306.01862.
[7] A survey conducted by ENISA indicates that approximately 40 % of respondents identify secure cloud architectures including mobile, fog, and edge computing as priority research areas. This emphasis aligns with opportunities outlined in the EU report following the CEO roundtable “Shaping the next generation cloud supply for Europe,” which highlights initiatives such as the cloud-edge continuum (e.g., hardware-based encryption at the edge), energy-efficient cloud infrastructures, cloud-native 5G, an open European ecosystem of cloud applications and toolkits, and greater convergence between information technology (IT) and operational technology (OT). The report also presents Secure Access Service Edge (SASE) as an opportunity for European providers, combining zero-trust network access, cloud access security brokerage (CASB), firewall-as-a-service, and data loss prevention into an integrated security model. See: ENISA. (2023). Cloud Cybersecurity Market Analysis. Available at:
https://www.enisa.europa.eu/sites/default/files/publications/CloudCybersecurityMarketAnalysis.pdf ; also see: European Commission. (2021). European Commission. (2021). European industrial technology roadmap for the next generation cloud-edge offering. https://ec.europa.eu/newsroom/repository/document/2021-18/European_CloudEdge_Technology_Investment_Roadmap_for_publication_pMdz85DSw6nqPppq8hE9S9RbB8_76223.pdf
[8] Euractiv (2025). Google-backed cloud wins France’s strongest sovereignty certification. Available at https://www.euractiv.com/news/google-backed-cloud-wins-frances-strongest-sovereignty-certification/.
[9] In fact, third-party cyber risk management (TPCRM) has emerged as a distinct discipline aimed at addressing the unique cyber risks introduced by vendor and supplier relationships. As third-party ecosystems expand, the external attack surface, including internet-facing assets, configuration weaknesses, and exposed data, has become an increasingly significant component of the overall threat landscape. See: Kost, E. (2025, June 15). TPCRM Framework: Building Digital Trust for Modern Enterprises. UpGuard. Available at: https://www.upguard.com/blog/tpcrm.
[10] CERRE, for example, notes that the absence of common cloud standards does not reflect a lack of technical proposals, but rather the difficulty of capturing the diversity, specialisation, and rapid evolution of cloud services within a single standard. While mandatory standardisation through regulation – such as interoperability requirements under the EU Data Act – may address incentives to favour proprietary solutions, it also risks locking providers and users into pre-defined standards. If applied broadly across service types, such mandates may reduce architectural diversity, constrain innovation, and limit differentiated service implementations (including security tools), with potentially adverse effects on both competition and resilience. See CERRE (2024). Competition and Regulation of Cloud Computing Services: Economic Analysis and Review of EU Policies. Available at https://cerre.eu/wp-content/uploads/2024/02/REPORT.CERRE_.FEB24.CLOUDS.pdf.
[11] Abecassis, D., Ryder, C., William, N., Lechner, L., and Bratty, R. (2024). The European telecoms regulatory framework: not a good fit for the public cloud. Analys Mason. Ref: 658783197-372. Available at: https://www.analysysmason.com/contentassets/d9396955aeb44e7a9898c809a884d69e/analysys-mason-report-for-aws — cloud-and-telecoms-regulation — final — 2024-09-25.pdf
[12] Analogies between cloud services and telecommunications infrastructure risk obscuring a critical distinction. The Commission’s White Paper reflects two related ideas: first, that legacy telecommunications regulatory models might be extended to cloud and digital services; and second, that convergence between networks and cloud infrastructures justifies this extension. However, proposals to extend the European Electronic Communications Code (EECC) to cloud and digital services have already met with resistance. Consultation results indicate that a majority of respondents (54.3 percent) opposed such an extension, reflecting concerns that telecom-style regulation is ill-suited to cloud markets. See European Commission. (2024). White Paper – How to master Europe’s digital infrastructure needs? COM(2024) 81 final. Available at: https://digital-strategy.ec.europa.eu/en/library/white-paper-how-master-europes-digital-infrastructure-needs. Also see Stecher, T. M. (2024). Consultation on the EU’s future connectivity networks: (Again) No support for regulatory intervention. DISCO. https://project-disco.org/european-union/consultation-on-eus-future-connectivity/ as referenced in Markevičiūtė, E. (2024, October 1). Bad ideas resurface: Expanding telco rules to digital and cloud and rebirth of “fair share”. EU Tech Loop. Available at: https://eutechloop.com/bad-ideas-resurface-expanding-telco-rules-to-digital-and-cloud-and-rebirth-of-fair-share/.
[13] Many critics of the proposed European Cybersecurity Certification Scheme (EUCS) have warned that if requirements extend beyond technical cybersecurity criteria into non-technical sovereignty or immunity clauses including restrictions based on supplier ownership, control, or location, they risk excluding otherwise legitimate providers and fragmenting the internal market. This concern is particularly salient in cloud computing, where infrastructure and services are continuously updated, scaled elastically, and modified without physical intervention. Further up the stack, software applications operate in an increasingly abstracted environment, unconstrained by the material safety certification regimes that govern physical goods, and subject instead to contractual, operational, and security assurances. While barriers to entry remain high at the level of hyperscale infrastructure, they are comparatively low at the application and service layers, where success depends less on regulatory compliance than on the ability to solve user problems effectively. Against this backdrop, proponents of the EuroStack initiative advocate a unified European alternative that collapses these heterogeneous layers into a single sovereignty-driven industrial project, often coupled with calls for exclusive or preferential EU-based public procurement. Critics argue that this “Airbus-style” model misconstrues the economics of digital markets by applying vertically integrated industrial policy logic to a modular, globally interdependent cloud ecosystem. See: Kilcoyne, M. (2025, August 22). Why the Airbus Model Won’t Work for European Digital Policy. Center for Data innovation. Available at: https://datainnovation.org/2025/08/why-the-airbus-model-wont-work-for-european-digital-policy/; the resulting policy debate increasingly sits at the intersection of compliance and procurement. In this context, the Commission’s October 2025 tender for sovereign cloud computing services valued at €180 million over six years and implemented through the Cloud III Dynamic Purchasing System (DPS) can be interpreted as an attempt to operationalise sovereignty concerns through procurement without imposing exclusionary eligibility rules. Rather than relying on binary notions of sovereignty, the Cloud Sovereignty Framework evaluates providers across a range of criteria, including legal, operational, and security requirements, supply-chain transparency, technological openness, and environmental considerations. While contested, this multi-criteria approach offers a potential template for Member State cloud procurement that seeks to balance resilience and autonomy objectives with competition, interoperability, and market openness, without resolving the deeper tensions inherent in cloud sovereignty policy. Its practical effects, however, remain uncertain. CISPE has argued that the framework’s breadth and weighting may allow foreign hyperscalers to score as well as, or better than, European providers, raising concerns about whether it can meaningfully advance European cloud sovereignty in practice. See European Commission. (2025). Cloud Sovereignty Framework Version 1.2.1 – Oct. 2025. Available at: https://commission.europa.eu/document/download/09579818-64a6-4dd5-9577-446ab6219113_en; also see the following articles for references: Bomont, C. (2025, November 3). Technical is political: When a cloud certification scheme divides Europe. European Union Institute for Security Studies. Available at: https://www.iss.europa.eu/publications/briefs/technical-political-when-cloud-certification-scheme-divides-europe#endnote-005; Robinson, D. (2025, October 27). EU sovereignty plan accused of helping US cloud giants. The Register. Available at: https://www.theregister.com/2025/10/27/cispe_eu_sovereignty_framework/.
