Three years ago, most “cloud strategy” discussions in Europe sounded the same:
Where are the best engineers?
Which vendor gives the biggest discount?
Can we move fast without upsetting procurement?
In January 2026, the conversation has a new line item: What happens if the network becomes a geopolitical chokepoint?
A concrete signal of that shift: on January 15, 2026, AWS announced a new “European Sovereign Cloud” designed to address European concerns about sovereignty, legal jurisdiction, and operational separation.
Whatever you think of the move (genuine commitment, smart marketing, or both), the message is unmistakable:
Cloud, compute, and software supply chains are no longer “neutral infrastructure.” They’re contested territory.
From “benign interdependence” to stress-tested dependencies
Political scientists Henry Farrell and Abraham Newman coined a phrase that’s become painfully useful: “weaponized interdependence.” The idea is simple: if global networks have hubs, whoever controls the hubs can monitor, throttle, or deny access—especially under crisis conditions.
You can see the pattern across the tech stack:
Semiconductors and advanced equipment have become a toolkit for export controls and bargaining power.
Cloud and platforms concentrate operational leverage in a few providers and jurisdictions.
AI compute and foundation models create “capability gravity wells” that shape who sets defaults, safety regimes, and developer norms.
This doesn’t mean Europe should retreat into romantic self-sufficiency. It means Europe needs a strategy that starts from one hard truth:
In a crisis, “dependence” stops being an economic efficiency and starts being a political constraint.
Europe’s uncomfortable baseline: strong niches, weak breadth
Denmark is a useful microcosm of the broader European situation: a high-trust society, strong institutions, and real technical excellence—yet still vulnerable in critical technologies.
ATV’s recent analysis (prepared with the Danish Technological Institute) makes it explicit: Denmark has lost ground in 12 of 16 critical technology areas over the last decade, measured through quality-patenting performance.
At the same time, Denmark retains clear strengths—notably energy technology, food technology, and audio technology—and additional areas where Denmark is above global averages depending on the benchmark.
Zoom out, and the picture becomes even more strategic: Europe’s challenge is not only invention, but translation—turning research into scaled capabilities, industrial capacity, and resilient supply chains. DIGITALEUROPE’s “Critical Tech Gap” report frames this as an economic security problem: strong R&D signals, but weaker commercialisation and manufacturing muscle in several critical domains.
So the question is not whether Europe has talent. It does. The question is whether Europe has dependable, stress-tested capabilities it can access and shape when conditions deteriorate.
Sovereignty, made operational: capability under stress, not autarky
“Sovereignty” is often argued at the level of slogans—either heroic (“we must control everything”) or dismissive (“this is protectionism in disguise”).
The more useful definition is operational:
Digital sovereignty is the ability to maintain continuous access to dependable technological capabilities, including under hostile or unstable conditions.
That framing matters because it breaks the false binary.
Europe does not need to build everything. Europe does need to decide which dependencies are acceptable, which must be governed, and which are simply too risky.
The leverage point Europe underuses: software and open ecosystems
Here’s the uncomfortable part: Europe cannot replicate hyperscaler scale or leading-edge fab capacity in one investment cycle.
But Europe can reshape something faster—and it affects every one of those domains:
Software architectures, open ecosystems, standards, and security practices.
Modern systems are built on dense component networks. Sonatype’s 2024 supply-chain report notes that open-source components can make up up to 90% of modern applications.
That’s a sovereignty issue, not just a developer experience detail.
Because sovereignty isn’t only about where code runs. It’s also about:
Who governs the upstream components you depend on
Who can audit them
Who funds their maintenance
Who can credibly respond when they become attack surfaces
This is why regulation is now converging with industrial policy.
Europe’s policy stack is real—and it’s accelerating
The EU has started assembling a capability architecture that mixes regulation with investment:
Chips Act (entered into force September 2023) to strengthen Europe’s semiconductor ecosystem.
STEP (Strategic Technologies for Europe Platform) to coordinate funding across strategic domains (digital, clean tech, biotech).
Digital Europe Programme to fund deployment capacity in HPC, AI, cybersecurity, and skills.
AI Act (entered into force August 1, 2024) with staged obligations now rolling in through 2026–2027.
Cyber Resilience Act (entered into force December 10, 2024; key obligations apply from December 2027, with reporting earlier) pushing “security as a product property.”
A forthcoming Cloud and AI Development Act planned for Q1 2026.
You can debate the details (and you should). But the direction is consistent:
Europe is trying to turn sovereignty from rhetoric into enforceable infrastructure choices.
A practical compass: four layers of the digital stack
To make sovereignty actionable in software work, I use a simple four-layer model. Different layers have different realistic “control ceilings” for Europe.
1) Physical + compute
Chips, data centres, networks, edge devices. Europe can strengthen capacity—but scale and geopolitics make full parity unlikely in the near term.
2) Platforms
Cloud primitives, orchestration, core databases, identity, CI/CD platforms. Europe’s market reality is still concentrated: European providers have hovered around ~15% share of the European cloud infrastructure market in recent years, while much growth has been captured by the major US hyperscalers.
3) Foundations
Open-source libraries, security tooling, middleware, and (increasingly) foundation models. This is where governance, funding, and maintenance become strategic power—not just licensing.
4) Applications + data domains
Sector systems: energy, health, transport, agriculture, public administration. This is where Europe (and Denmark) can achieve the highest autonomy: domain models, datasets, and operational control—even if lower layers remain partly external.
The sovereignty decision that teams can actually make
When the debate becomes ideological, teams freeze.
One camp says: “We must build a European hyperscaler tomorrow.” Another says: “Sovereignty is a fantasy; just optimise cost and delivery.”
In practice, both extremes often converge on the same failure mode: they ignore the middle of the stack—the software foundations, portability constraints, supply-chain security, and governance realities that determine whether you have options later.
So here’s a decision framework engineers and leaders can use tomorrow:
Step 1: Classify systems by “stress sensitivity”
Ask: if access were constrained for 30 days—by law, sanctions, vendor policy, or security incidents—what breaks?
Critical infrastructure / public sector core systems
Safety-relevant industrial systems (energy, water, health)
Sensitive research and national capability platforms
Everything else
Step 2: Demand portability where it matters
For stress-sensitive systems:
multi-region exit plans
open standards and tested migration paths
contractual and technical independence where possible
Step 3: Treat software supply-chain security as sovereignty work
The CRA is not “compliance paperwork”; it’s a competitive and resilience baseline.
Concretely
SBOMs by default
provenance and signed builds
dependency risk tiers (what you trust, what you verify, what you isolate)
upstream engagement for your most critical dependencies
Step 4: Invest upstream, not only downstream
If open-source is critical infrastructure, fund it like it is.
Not with symbolic sponsorships—but with:
maintainers’ time
security audits
shared European governance and stewardship capacity
Where Denmark (and similar economies) can win
Denmark can’t outspend great powers across the full stack. But Denmark can compound its influence by combining:
sector niches (energy systems, food/agri, audio/med-tech) with
horizontal software capabilities (secure supply chains, open foundations, data governance, and talent pipelines)
That is what “dependable capability” looks like in a small, open economy: selective depth, real operational control, and managed interdependence elsewhere.
Final thought: Don’t Treat Sovereignty Like a Slogan — Treat It Like a System You Can Audit
If there’s one message in this article, it’s this:
Dependencies are inevitable. Uncontrolled dependencies are optional.
Europe can’t (and shouldn’t) rebuild the entire global tech stack inside its borders. But we can stop making sovereignty decisions by accident — through procurement defaults, inherited architectures, and unexamined platform lock-in.
The move now isn’t “buy European” as a reflex. It’s this:
Treat technological sovereignty like a set of measurable, stress-testable capabilities — and audit them like you would audit security.
That means:
mapping your real dependency graph across cloud, software supply chain, data, and governance — not just your vendor list,
distinguishing what’s critical under stress from what’s merely convenient,
and building credible exit paths where the risk is non-negotiable (public administration, critical infrastructure, safety-relevant systems).
Most organisations don’t have a sovereignty problem. They have an observability problem:
They can’t explain which systems would fail first under legal or geopolitical constraints.
They don’t know which dependencies are “single points of policy failure”.
They can’t show, in a board room or a ministry, that their choices are defensible.
So what’s your next move?
If you build and ship (engineer / architect / platform lead)
Pick one system that matters and do a Sovereignty Trace:
List the top 20 external dependencies (cloud services, identity, CI/CD, package registries, model APIs, key OSS libs).
Mark each one as: replaceable in 30 days / 90 days / not realistically replaceable.
For the “not replaceable” group, answer one hard question:
“If this dependency is constrained, what is our minimum viable operating mode?”
Bring that to your next architecture review. If you can’t describe a degraded mode, you don’t have resilience — you have hope.
If you lead people (EM / Head of Engineering / Director)
Run a 90-minute Capability Under Stress workshop with staff engineers and security:
Choose one critical domain (identity, data platform, build pipeline, or cloud runtime).
Map:
End by agreeing on:
Write it down. Treat it like an engineering policy — not a slide deck.
If you own the roadmap and budget (CTO / CIO / public-sector lead)
Make sovereignty a gate for major initiatives:
Don’t just ask “Is it compliant?” — ask:
Is it auditable?
Is it portable where it needs to be?
Do we know which external actor can stop this from working — and under what conditions?
Do we have a credible alternative for the systems we cannot afford to lose?
Reserve part of your budget specifically for sovereignty audits and remediation, the same way you reserve budget for pentests and incident response readiness.
Because if you can’t show where you have dependable capability under stress, you don’t have a sovereignty strategy — you have a collection of assumptions.
If this article had one underlying argument, it would be this:
You wouldn’t run critical infrastructure without monitoring, threat modelling, and disaster recovery. Don’t run critical digital dependencies that way either.
That’s where I can help.
I work with engineering organisations to:
audit dependency and sovereignty risk across cloud, software supply chain, data, and governance,
identify where critical systems rely on fragile single points (vendor, jurisdiction, platform policy, maintainer risk),
design pragmatic mitigation plans (portability, open foundations, procurement criteria, secure supply-chain practices),
and build clear evidence leaders can use to make defensible decisions — without turning delivery into bureaucracy.
If you want help turning “we hope our dependencies are fine” into “we’ve audited our exposure, prioritised the risks, and we have credible options,” start here: 👉 https://www.danielrusso.org/evidence-based-organizational-change/ (Si apre in una nuova finestra)
Data
30/01/2026
