Sustaining the Commons in an Age of Digital Sovereignty

Sovereignty without weakening the commons

Digital sovereignty has become one of the defining ideas in technology policy. Governments and regions are asking difficult questions about dependency, jurisdiction, cloud infrastructure, artificial intelligence (AI) capabilities, semiconductors, data, cybersecurity, supply chains and the resilience of public services. These are legitimate questions. No society wants its critical digital functions to depend on too few providers, too few jurisdictions, or too few points of failure.

The challenge is to answer those questions in a way that strengthens the Internet’s shared coordination layer and the commons that depends on it. That means building capacity, resilience and meaningful choice without turning sovereignty into isolation or replacing one form of dependency with another.

The Internet’s strength has always come from a model based on distributed coordination rather than central control. Independently operated networks interconnect through open standards, shared protocols, globally unique identifiers, operational norms, routing and institutions with narrow and trusted roles. Around that technical core, digital economies, cloud platforms, content delivery networks (CDNs), AI systems, public services and social applications have developed.

That is why sovereignty debates need to begin with a careful question: are we strengthening the commons that makes all of this possible, or are we weakening it in the name of control?

Starting from the right layer

The Internet is not the web, not social media, not our favourite apps, and not the wider digital economy. It is the global network of networks that makes those things possible. Its core is made up of the protocols, services and coordination structures needed for end-to-end global connectivity.

That distinction matters when sovereignty enters the discussion.

Many concerns now described as “Internet centralisation” are not always centralisation of the Internet’s coordination layer. They may be centralisation of cloud infrastructure, content delivery, software supply chains, certificate issuance, AI compute, data-centre capacity or public procurement. These are real concerns, but they do not all sit at the same layer, and they do not all require the same response.

A cybersecurity policy may need stronger defences, clearer responsibilities and better incident response; it should not create centralised control points for routing or naming that weaken global interoperability. A data-sovereignty policy may need clearer rules on data location, access and jurisdiction; it should not spill over into Internet number resource registration or other shared coordination functions that keep Internet resources globally unique and interoperable.

The Internet works because its coordination functions are shared, narrow and predictable. This is especially important for registries, identifiers, routing coordination and standards processes. Their legitimacy depends on being reliable sources of coordination, not broad instruments of political enforcement.

Neutrality in registry operations is not a political stance, but a practical requirement for maintaining a single, interoperable Internet. Once coordination functions are treated as tools for unrelated policy objectives, trust in the common layer is weakened.

The same logic applies to sovereignty. The more we confuse the Internet’s core with what is built on top of it, the greater the risk that we try to solve problems at the wrong layer.

That is how we risk weakening the commons while trying to protect it.

Scale is not the enemy

A balanced discussion about centralisation has to begin by acknowledging that scale can be useful.

Large network operators, cloud providers, content delivery networks, software companies, equipment vendors and security providers have contributed significantly to the Internet’s growth. Economies of scale can lower costs, improve performance, increase reliability, absorb attacks, accelerate deployment and make advanced services available to organisations that could not build them alone.

A school, hospital, municipality, startup or civil society organisation may be far more secure using a professional cloud, DNS, CDN or Distributed Denial-of-Service (DDoS) mitigation provider than trying to build everything itself.

Large providers can also accelerate technical transitions. IPv6 deployment, for example, has benefited from major content providers, CDNs, mobile operators and hyperscalers deploying at scale and creating demand across the ecosystem.

So the argument is not that large providers should disappear.

The argument is that scale becomes a problem when it removes meaningful alternatives.

Scale is beneficial when it increases capability while preserving choice. It becomes dangerous when users, operators, governments or whole markets cannot realistically switch, interoperate, audit, recover or negotiate.

This is where centralisation becomes dependency.

And dependency is often invisible until something fails. An organisation may believe it has a diverse architecture because it uses many services. But several of those services may depend on the same upstream provider, the same control plane, the same software stack, the same legal jurisdiction, the same cloud region or the same operational assumptions.

In normal times, that looks like efficiency. During an outage, a policy change, a sanctions event, a routing incident, a software supply-chain compromise or a commercial dispute, it may become clear that the diversity was thinner than it appeared.

The issue is not only market concentration. It is dependency topology: the often-hidden map of who and what must continue to function for a service, community or country to remain connected.

This is why efforts such as the Internet Society’s Pulse work on Internet concentration are useful. They help make visible where dependency is forming across services such as hosting, DNS, content delivery and other parts of the Internet ecosystem.

There is a similar lesson in the standards community. RFC 9518, “Centralization, Decentralization, and Internet Standards”, reminds us that centralisation is not a simple binary: some forms can bring efficiency or coordination benefits, while others create avoidable points of control. The same discipline is needed in sovereignty debates. The goal is not decentralisation for its own sake, but preserving meaningful choice.

Before we regulate, subsidise or localise, we need to measure where dependency actually sits; otherwise both sovereignty and centralisation remain slogans rather than operational realities.

Sovereignty as capacity

Digital sovereignty is often described as the ability of a state or region to act independently in the digital world. That is a legitimate goal. Governments have responsibilities to protect citizens, critical infrastructure, public services, economic competitiveness, democratic institutions and national security.

But independence should not be confused with isolation.

A country does not become more sovereign by cutting itself off from the global Internet. A region does not become more resilient by replacing open standards with local variants. A public administration does not become safer simply because a provider has the right ownership structure. A national cloud does not automatically create national capability. Data localisation does not automatically create resilience.

Sovereignty should be measured by the quality of choices available.

Can public services understand their dependencies? Can they move workloads? Can they use open standards? Can they avoid lock-in? Can they maintain local skills? Can they route traffic efficiently? Can they continue operating when one provider, one cable, one cloud region, one software component or one jurisdiction becomes unavailable?

If the answer is yes, sovereignty has practical meaning.

If the answer is no, sovereignty may be only a label.

The goal should not be “more control” in the abstract. Control can be centralised in ways that reduce resilience. The goal should be more agency: the ability to understand, choose, switch, interoperate, recover and participate.

A more sovereign society should be a more capable participant in the global Internet, not a more isolated one.

Put differently, digital sovereignty should mean the capacity to make informed, meaningful and reversible choices about the digital systems a society depends on, while preserving the interoperability of the global Internet.

Looking at the European debate

The European Union’s current technological sovereignty agenda shows both the opportunity and the challenge. Europe is not unique in facing these questions; it is simply a useful example because its current policy agenda makes the trade-offs visible.

On 3 June 2026, the European Commission presented the European Technological Sovereignty Package, a set of measures to strengthen Europe’s capacity in semiconductors, artificial intelligence (AI), cloud and open source. The package includes two legislative proposals, the Chips Act 2.0 and the Cloud and AI Development Act, as well as the EU Open Source Strategy and a Strategic Roadmap for Digitalisation and AI in Energy.

The diagnosis is understandable. Europe is concerned about structural dependencies in cloud, AI, semiconductors, software, public-sector technology and critical digital infrastructure. These concerns are real.

There is much to welcome if this agenda creates more credible options. The proposed Cloud and AI Development Act aims to strengthen Europe’s cloud and AI ecosystem, address barriers around sustainable data-centre, cloud and computing capacity, and reduce over-reliance on non-EU cloud providers while keeping the market open to partners.

The EU Open Source Strategy is also important. The Commission presents it as a cornerstone of the Tech Sovereignty package, linking open source to technological sovereignty, interoperability, reduced lock-in, public-sector reuse, security, maintenance and skills.

But open source only strengthens sovereignty when it is sustained. Code without maintainers, funding, security review and local skills can become another fragile dependency. Open source should therefore be treated as part of the commons, not merely as a cheaper substitute for proprietary systems.

These are constructive directions. But implementation will determine whether the result is more choice or merely a new form of concentration.

If sovereignty is reduced to where data is stored, it may miss who controls the software, the management plane, the identity layer, the updates, the supply chain and the incident response process. If sovereignty is reduced to ownership, it may miss whether the provider can actually deliver resilience, security, portability and operational maturity. If sovereignty is reduced to procurement, it may create demand for alternatives, but it may also centralise public-sector demand around a small number of approved providers.

The key question should not be: is this sovereign?

The better question is: does this increase meaningful choice while preserving interoperability?

The trust architecture of sovereignty

The Internet’s trust architecture is the combination of shared norms, open technical coordination, institutional roles and community practices that make distributed cooperation around the Internet’s core possible. Trust is not separate from technical coordination. It is part of the architecture that sustains it.

That lens is essential for digital sovereignty.

Sovereignty is not built only through legislation, data centres, cloud procurement or industrial policy. It is also built in the places where operators meet, exchange traffic, troubleshoot incidents, deploy IPv6, improve routing security, train new engineers, measure the network and build the relationships that allow coordination to survive stress. This is why Internet Exchange Points (IXPs), Network Operator Groups (NOGs) and local Internet governance spaces matter.

Internet Exchange Points are not just traffic optimisation facilities. They are part of the local interconnection commons. They reduce unnecessary dependence on upstream transit, improve latency and resilience, and create operational spaces where networks coordinate directly. Their value is not only technical; they also help build the local relationships and operational habits that make resilience possible.

But IXPs should not be misunderstood either. The goal is not to force all traffic to remain within national borders. The goal is not to create state-controlled chokepoints. The goal is better topology, better choice and better resilience.

Local infrastructure does not become resilient simply by being local. It becomes resilient when it is open, well governed, measured, redundant and connected to the wider Internet.

The same applies to Network Operator Groups and local Internet Governance Forums. These spaces are often treated as community activities, but they are much more than that. They are where local knowledge circulates, where trusted contacts form before incidents happen, and where technical reality can enter policy discussions before policy hardens into obligations.

Communities such as network operator groups, governance dialogues, academic networks and collaborative forums are where trust is renewed in practice and where the Internet becomes locally grounded.

This is not peripheral to sovereignty. It is central to it.

Sovereignty strategies can help create the execution conditions that allow communities to strengthen the Internet commons: funding, removing barriers, setting procurement requirements and aligning incentives.

But they cannot replace the local communities, operational relationships and shared norms that make coordination work in practice. That is where the Internet’s trust capacity comes from.

Digital sovereignty needs both: execution conditions and that trust capacity.

Sustaining the commons

If a region wants sovereignty, it must invest not only in the visible layers of digital infrastructure, cloud, AI, chips and data centres, but also in the coordination layer that makes those investments useful and resilient. That means investing in interconnection, routing security, IPv6 deployment, measurement, open-source maintenance, training and the local communities that sustain trust.

This also means recognising that the commons has costs. Open standards work, open-source maintenance, measurement, training, routing security, local community events and neutral interconnection do not sustain themselves simply because they create public value.

Sovereignty strategies are strongest when they fund not only the visible layers of digital infrastructure, but also the coordination layer that makes those investments resilient.

You cannot procure your way into trust. You cannot legislate your way into operational competence. You cannot declare resilience into existence. You have to build it.

More choices, fewer chokepoints

Digital sovereignty will remain an important policy objective. The question is not whether governments and regions should care about dependency. They should.

The question is whether their response strengthens the Internet commons or weakens it.

A sovereignty strategy that creates more providers, more open technologies, more local interconnection, more operational knowledge, more transparency and more ability to switch can make the Internet stronger.

A sovereignty strategy that creates national chokepoints, protected monopolies, forced localisation, parallel standards or political control over coordination functions can make the Internet weaker, even when it is presented as resilience.

The Internet does not need sovereign islands. It needs capable communities, open coordination, resilient infrastructure and a shared commitment to keeping the network of networks interoperable.

The opposite of dependency is not isolation.

The opposite of dependency is choice.

And sustaining the commons is how we sustain that choice.