This article is part of an ongoing series developed by the author alongside their participation in the OpenInfra Foundation’s 2026 Digital Sovereignty Working Group.
Digital sovereignty is often framed as a matter of policy. Data residency requirements, compliance frameworks, jurisdictional boundaries. These are important, but they are not where sovereignty is decided (or breaks).
In practice, sovereignty is determined much lower in the stack. It lives in the infrastructure layer. In the control planes you rely on, the architectures you build, and the operational choices you make over time. If those are dependent on external systems you do not control, or cannot inspect, modify, and operate independently, then sovereignty is limited regardless of where your data resides.
This gap between intention and implementation is where many organizations struggle. They aim for independence but build on foundations that make it difficult to achieve true sovereignty.
The Illusion of Sovereignty
A workload running in a data center inside your borders is not sovereign if the orchestration layer above it answers to a legal regime you cannot influence. A “sovereign cloud” branded service is not sovereign if its operator can be compelled to disclose data, restrict access, or change terms unilaterally, whether the compulsion comes from a foreign government, your own, or a court order in a third country where the parent entity is incorporated.
Compliance documentation is not sovereignty either. It is a record that certain controls existed at a point in time. It says nothing about who holds the keys when conditions change.
The label unfortunately has the danger of becoming a marketing term. Providers attach it to regional deployments, encryption schemes, and contractual assurances, and customers accept the framing because it simplifies a difficult problem. The simplification is the trap.
Sovereignty is not just a certificate. It is a property of the system, decided by who can change what, and under whose authority. Jurisdiction sets the floor of exposure. Architecture decides what remains when the legal instrument arrives.
Where Sovereignty Breaks in Practice
If sovereignty is defined by control, then its failure points are predictable. Three patterns recur across organizations that believed they had solved for it.
The first is control plane dependency.
The workload may run on hardware you own, but the systems that schedule it, network it, secure it, and observe it often do not. Proprietary management layers, identity providers, and API gateways become silent points of dependency. When a vendor changes pricing, deprecates an interface, or is subject to a legal order, you discover how much of your operation runs through their plane rather than yours. The data was never the leverage. The control surface was.
The second is architectural lock-in.
Sovereignty is not about today’s vendor. It is about whether the architecture survives without them. Workloads designed around proprietary databases, serverless runtimes, and managed services accumulate dependencies that stay invisible until you try to move. Migration stops being a project and becomes a rebuild.
If you cannot leave, you are not sovereign.
The third is economic dependency.
Cost predictability is a sovereignty issue, not a finance issue. When pricing models, egress fees, or commitment structures determine whether your business can function, the provider has acquired operational authority over you. CFOs tend to feel this first, often before CTOs name it. The bill is the symptom. The dependency is the cause.
What Real Sovereignty Looks Like
Digital sovereignty starts with owning your data and controlling where it lives and runs. It extends to who can access it and under what conditions. But real control goes further. It requires the ability to understand the systems involved, to modify them when needed, and to innovate without waiting for permission.
Sovereign infrastructure has a recognizable shape, and it is typically built on technologies that prioritize transparency, interoperability, and the ability to operate independently. The control plane is open and operable by your team or a partner of your choosing.
OpenStack is the canonical example, forming the foundation of many independent cloud environments. Alongside it, projects like Kata Containers, StarlingX, and Zuul extend control across compute isolation, edge infrastructure, and automation pipelines. The storage layer follows the same principle. Ceph and comparable systems give you direct authority over how data is placed, replicated, and retrieved.
Workloads are portable by construction. They run on standard interfaces, package in standard formats, and depend on services that exist in more than one place. Portability is not a migration plan. It is a default state.
Infrastructure-level control means root access to the systems that matter, the ability to inspect and modify the stack down to the hardware boundary, and the option to run on owned, leased, or rented capacity without rewriting the architecture. Operational transparency means you can answer, without calling a vendor, where a workload is running, who has touched it, and what it depends on.
None of this is complexity for its own sake. It is what it takes to be able to say no.
The Trade-Off
Sovereignty has a cost, and it is dishonest to pretend otherwise. The convenience of a fully managed environment is real. Teams move faster when they do not have to think about the layer below.
The trade is long-term flexibility. Every convenience compounds into a dependency, and every dependency narrows the set of decisions available later. The right question is not whether to accept convenience, but where to accept it.
A useful test is whether a dependency is bounded or compounding.
A bounded dependency sits behind a stable interface and can be replaced without changing the architecture above it. Object storage, content delivery, message queues, often even the compute layer. In these cases, the provider becomes interchangeable, and the convenience arrives without strategic cost.
Compounding dependencies are different. They shape the architecture rather than slotting underneath it. The control plane is the clearest example, but identity systems, the primary data model, and any service whose proprietary interface leaks into application code belong in the same category. The longer the system runs on a compounding dependency, the more expensive it becomes to remove.
At a certain point, the cost of leaving exceeds the cost of accepting whatever terms the provider sets. By then, the decision has already been made.
Open standards are what convert compounding dependencies into bounded ones. Without them, the bounded category does not exist.
Some layers are safe to outsource. Others define your strategic posture for a decade. Treating them the same is the mistake most organizations make and the one most expensive to reverse.
By the time most teams ask whether they are sovereign, the question has already been answered by infrastructure decisions made years earlier.
The Open Source Foundation
Open source governance under foundations like the OpenInfra Foundation provides what proprietary stacks cannot: a code base no single party can withdraw, a community that maintains it across vendor cycles, and a license that survives any individual contributor leaving. This is the load-bearing layer that makes long-term sovereignty possible.
Open infrastructure follows a set of principles often described as the “four opens”: open source, open design, open development, and open community. These are not philosophical ideals. They are practical mechanisms that ensure no single party controls the direction, access, or availability of the system.
But to be very honest open source alone is not sovereignty. The deployment model decides.
The same open components can produce very different outcomes depending on who holds the control surface. An operator who retains the credentials, the upgrade path, and the administrative boundary has produced a closed system, regardless of what the source code says. An operator who hands those over, on infrastructure that can be audited and rebuilt, has produced a sovereign one.
This is why in my opinion “managed” is too coarse a category to evaluate. The question is not whether a third party operates infrastructure on your behalf. The question is what you can do without them.
If the answer is “rebuild from the same open components, on different capacity, without rewriting the architecture,” the arrangement preserves sovereignty. If the answer is “negotiate,” it does not.
Open source widens the option space. The deployment model determines whether you can exercise it.
Sovereignty is chosen, not granted.
What Holds
The organizations that will hold their ground over the next decade are the ones treating infrastructure as a strategic surface rather than a procurement decision.
They are not building everything themselves, and they are not rejecting managed services on principle. They are deciding, deliberately, where control must live, and building the architectural and operational capacity to keep it there.
Sovereignty, ultimately, is optionality. The ability to change provider, change region, change architecture, or change posture without rebuilding the business.
That optionality is not given by a contract or a label. It is built, layer by layer, and critically n the choices made about the infrastructure foundation.
The technologies that make this possible already exist. What matters is how they are used, and whether organizations are willing to build on foundations that preserve their ability to control, adapt, and evolve.
Most of the time, that foundational work is invisible. When it matters, it is the only thing that does.