The European Commission published its European Technological Sovereignty Package in mid-2026, and most of the English-language coverage I have read has either skipped the substance or framed it as a procurement tweak. The package is neither. It is a structural response to a structural problem: the EU runs roughly 80% of its public digital infrastructure on non-EU-controlled vendors, and the policy environment for the next decade is going to make that dependency more expensive, not less. This is the version of the explainer I would want to have read before I had to make any technology-procurement decision that will outlive the current contract cycle.
I have spent the last several weeks reading the four components of the package and the working documents that sit behind them. The frame the Commission is using is the right one: the question is not “is foreign tech bad,” the question is “what dependencies are acceptable for which categories of infrastructure, and what does acceptable cost.” The package answers that question, and the answer is more specific than the headlines suggest.
Why “sovereignty” is the word the Commission is using
The choice of “sovereignty” is deliberate. The Commission is not claiming that foreign tech is bad, that EU tech is automatically better, or that the package is about building a parallel internet. The claim is narrower: critical public infrastructure (hospitals, energy grids, public records, defense-adjacent systems) should not be dependent on infrastructure that a foreign government can disable, surveil, or legally compel. That is a sovereignty claim in the same sense that a country claims sovereignty over its physical borders: not because the country is hostile to its neighbors, but because the alternative is structural exposure to decisions made elsewhere.
The three risks the package names are kill switches, legal backdoors, and locked-out procurement. Each is a real and well-documented failure mode:
- Kill switches. A foreign government can compel a US-controlled cloud provider to disable or interfere with services. The CLOUD Act (a 2018 US law that lets US authorities compel US-based companies to hand over data, even when it is stored in a non-US data center) and the Executive Order 12333 framework together give US authorities a path to compel infrastructure providers to act against their own customers. The Snowden disclosures in 2013 documented the operational use of similar powers. The dependency risk is not theoretical.
- Legal backdoors. US law applies to US-controlled companies regardless of where the data is physically stored. A US court order can compel a US-controlled cloud provider to hand over data on EU customers, even if the data lives in a Dublin region. GDPR does not change that, because the order comes from a US court, not an EU one. The post-2020 Schrems II decision (a 2020 EU court ruling that struck down the US-EU Privacy Shield, citing exactly this concern) is the legal landmark.
- Locked-out procurement. When critical public contracts (healthcare, energy, defense) are fulfilled by vendors that a foreign government can compel, the EU has no real procurement room to negotiate. The supplier can be told what to do, and the EU’s only recourse is to find a new supplier mid-contract. The package’s procurement rules are an attempt to put real bargaining power back on the EU side.
Commission President Ursula von der Leyen put it in plain language: “We cannot afford to depend on others for the technologies that keep our hospitals running, our energy grids stable and our services secure.” That is the framing the rest of the package hangs on.
The four components of the package
The package is built from four legislative and policy pieces. Each addresses a different layer of the dependency stack.
Chips Act 2.0
The original EU Chips Act (2023) aimed to roughly double Europe’s share of global semiconductor manufacturing capacity to 20% by 2030. The 2026 update (Chips Act 2.0) widens the scope in two ways. First, it adds advanced packaging (a stage of chip production that has become a bottleneck as transistor scaling slows, where multiple chip dies are combined into a single package) to the categories eligible for public investment. Second, it sets a domestic content threshold for chips used in EU-funded public infrastructure: 30% EU-controlled content by 2030, rising to 50% by 2035. The threshold is below where the EU actually wants to be, and the Commission has been clear that it is a floor, not a ceiling.
Realistic interpretation: the Chips Act 2.0 will not make Europe competitive with TSMC (the Taiwanese chipmaker that controls more than half of the world’s advanced chip production) on leading-edge nodes (the most advanced manufacturing processes, currently 3nm and 2nm) in this decade. It will give European fabs (chip fabrication plants) a path to be competitive at trailing-edge nodes (older but still widely used processes, typically 28nm and above, which power most automotive, industrial, and IoT chips) and at advanced packaging. Both are real categories. Most of the chips in your car, your refrigerator, and your factory’s PLC (programmable logic controller, the ruggedized computer that runs industrial equipment) are trailing-edge. The package makes those categories domestic.
Cloud and AI Development Act (CADA)
CADA is the most operationally significant of the four. It does two things at once. First, it requires that “critical” cloud workloads (the category is defined in a Commission working document and includes healthcare, public administration, energy, finance, and defense-adjacent services) be hosted on infrastructure that is EU-controlled. Second, it sets a “sovereignty label” for cloud providers, with three tiers. Tier 1 is fully EU-controlled (headquartered in the EU, no significant non-EU ownership, no operational dependence on non-EU-controlled infrastructure for failover or support). Tier 2 is partially EU-controlled (a path exists, but some operational dependence remains). Tier 3 is non-EU-controlled but compliant with EU data-handling requirements (a holding category for providers that want to keep selling into the EU market but cannot meet the sovereignty bar).
The cutoff date for critical workloads to migrate to Tier 1 or Tier 2 is January 1, 2030. The grace period is roughly 3.5 years from publication. For procurement teams that have not started the sovereignty assessment for their cloud providers, the clock is already short.
EU Open Source Strategy
The Open Source Strategy is the smallest of the four by direct budget, but possibly the most strategically important in the long run. It does four things.
- It sets a “public code” requirement: any software developed under EU public funding must be released as open source under a permissive license (a license that allows reuse with minimal restrictions, such as MIT, Apache 2.0, or BSD).
- It funds a Sovereign Tech Fund-style mechanism (a public investment vehicle that supports critical open-source projects with maintenance, security, and infrastructure costs that commercial sponsorship often does not cover) to maintain critical open-source projects that the EU depends on but that commercial sponsors do not fully support.
- It sets up an EU sovereign vulnerability disclosure process (a formal channel for security researchers to report vulnerabilities to EU-controlled projects, mirroring similar US programs) that does not require routing disclosures through US-controlled intermediaries.
- It establishes a public-sector fork policy: when an open-source project the EU depends on undergoes a governance or licensing change that would compromise EU sovereignty (a US foundation relocating, a license shift to a more restrictive model, a maintainer concentration in a single non-EU jurisdiction), the EU has pre-funded the legal and operational capacity to fork (create an independent copy of the codebase that the EU controls and maintains) the project without scrambling for budget.
Pragmatism is the case for the open source piece: most of the EU’s actual digital infrastructure runs on open source. The Linux kernel, Kubernetes, PostgreSQL, and the rest of the open-source stack are not “EU” or “non-EU” in the sovereignty sense, but the maintainers, the foundations, and the corporate sponsors are predominantly US-controlled. The strategy is an attempt to make the open-source stack less US-dependent without trying to replace it.
Digitalization and AI Roadmap for Energy
The fourth component is the narrowest. It is a sector-specific roadmap for digitalization and AI deployment in the energy sector, with funding for grid management, demand response, and the integration of distributed energy resources. The sovereignty angle here is that energy infrastructure is one of the most exposed categories to the kill-switch risk. A grid management system that depends on a US-controlled cloud provider is a grid management system that can be disabled by a US court order. The roadmap funds EU-controlled alternatives.
What this means for non-EU technology vendors
The package is not a procurement ban. US-controlled cloud providers are not being expelled from the EU market. What is changing is the price of selling into the critical categories. The 2030 migration deadline means any US-controlled provider that wants to keep its EU critical-sector customers needs a path to either become Tier 1 / Tier 2 (which most cannot do without a corporate restructuring) or to convince the customer to move the workload off the critical-tier list (which the Commission has been clear is a narrow door).
The most likely outcome is a market split. Critical public-sector workloads migrate to EU-controlled providers (and the EU-controlled subsidiaries of US providers, where the corporate structure allows for genuine EU operational independence). Non-critical commercial workloads (general business use, consumer services, productivity tools) stay on US-controlled hyperscalers, with EU data-protection requirements continuing to apply. The hyperscalers will lose share in the critical category and keep share in the non-critical category. The net effect on their EU business depends on what fraction of their EU revenue is in the critical category, and the answer varies by provider.
For European businesses that have been treating US-controlled hyperscalers as a neutral infrastructure choice, the package forces the question. The choice is not “EU tech or US tech” in the abstract. The choice is “for this specific workload, in this specific jurisdiction, with this specific regulatory regime, what is the right risk-adjusted answer.” The package makes the answer different for critical public-sector workloads than for general commercial workloads.
What I would tell past me
If I had to summarize the package in three points for a procurement team that is just starting to think about this, I would say the following.
- The 2030 deadline is real, and it is sooner than it looks. A migration from a US-controlled hyperscaler to an EU-controlled provider is a 12-24 month project, not a 6-month project. Teams that start now will have a path. Teams that wait until 2029 will be improvising.
- “Sovereignty” is not the same as “EU headquartered.” A US-controlled cloud provider with a German subsidiary that runs its own data centers is still US-controlled for the purposes of the CLOUD Act. The package is asking about end-to-end control, not about where the data is stored.
- The procurement shift is structural, and the commercial shift is not. The package is changing what the public sector buys. It is not changing what the consumer market buys. Do not read the package as a broader anti-US-tech move, because it is not that.
The honest assessment is that the package will create real costs and real frictions for EU public-sector technology procurement, and the question for the next several years is whether the frictions are worth the sovereignty dividend. The Commission’s bet is that they are. The bet is a reasonable one, and the answer will not be uniform across categories. For some categories (defense, critical energy infrastructure, certain healthcare systems) the sovereignty dividend is large enough to justify the frictions. For others (general productivity software, consumer-facing services) the bet does not apply.
Trade-offs
Time is the first cost. The 2030 migration deadline is going to compress several years of cloud procurement work into roughly four calendar years, and the EU public sector is not staffed for the load. Migration projects require both technical execution and legal review, and the legal review for sovereignty-tier questions is not something most public-sector IT teams have done before. Expect consulting costs to spike and timelines to slip.
Cost is the second trade-off. EU-controlled cloud providers, in general, are more expensive than US-controlled hyperscalers for equivalent compute and storage. The package accepts that premium as a policy choice. Whether the premium is worth it depends on the workload. For a critical hospital information system, the answer is almost certainly yes. For a non-critical public-sector productivity tool, the answer is more like probably not. The package does not try to make the second category Tier 1, which is the right call.
Fragmentation is the third risk. The package does not break the EU’s single market, but it does add a layer of national and sectoral variation in how sovereignty is interpreted. The Commission’s three-tier sovereignty label is a common framework, but the implementation will be in national regulations, and national regulators will interpret the tiers in slightly different ways. A vendor that is Tier 1 in France may be Tier 2 in Germany, not because the vendor changed, but because the German regulator reads the operational-independence requirement more strictly. The fragmentation is manageable, but it is real.
If you are a public-sector procurement team that is just starting on the sovereignty question, the right first move is to inventory your current cloud and SaaS vendors against the three-tier label and identify which of your workloads are in the critical category. The list is smaller than you think, and the migration cost is concentrated in that list. Everything else can stay where it is for now.
If you are a US-controlled cloud provider with significant EU critical-sector business, the right move is to honestly assess whether you can become Tier 1 or Tier 2. If you can, the corporate restructuring is cheaper than losing the market. If you cannot, the 2030 deadline gives you roughly four years to wind down the critical-sector business gracefully and to reposition around the non-critical sector. The two paths are not equivalent in revenue, but they are both real paths.