“Sovereign” has become the most oversold word in enterprise infrastructure. Almost every hyperscaler and vendor now offers a “sovereign” option. Most of them fail a single test: who holds root?
The three conditions
Real digital sovereignty requires all three of the following. Drop any one and you have a marketing claim, not sovereignty.
1. Open code you can audit
If you cannot read the source, you cannot verify what your infrastructure does. A closed-source “sovereign” platform asks you to trust that there is no telemetry, no backdoor, no kill switch. Open source replaces trust with verification: the code is auditable by construction, and the supply chain can be inspected, rebuilt, and pinned.
2. Software you self-host
Sovereignty means the software runs on infrastructure you control — private cloud, on-premises, bare metal, or fully air-gapped — not as a tenant on a platform someone else operates. If the vendor operates it for you, the vendor can be compelled, can change terms, or can withdraw.
3. No foreign root access
This is the condition most “sovereign” offerings quietly fail. An “EU region” of a US hyperscaler still runs on the provider’s control plane, under the provider’s operational staff, subject to the provider’s home jurisdiction. Under the US CLOUD Act, a US-headquartered provider can be compelled to produce data regardless of where it is stored. Location does not change jurisdiction.
Why “datacenter in-country” is not enough
Data residency answers where the bytes sit at rest. Sovereignty answers who can compel, access, or disable the system. Those are different questions:
- A local datacenter operated on a foreign vendor’s control plane is not sovereign.
- Encryption “at rest” held by a provider who also holds the keys is not sovereign.
- An in-country region whose operators sit under foreign legal compulsion is not sovereign.
If you can’t audit it, you don’t control it. If someone else holds root, you don’t own it.
The test to apply
For any platform that calls itself sovereign, ask:
- Can I read and rebuild the source? (Open code)
- Can I run it entirely on my own infrastructure, disconnected? (Self-hosted)
- Is there any foreign vendor, operator, or jurisdiction that could access, compel, or disable it? (No foreign root access)
Three yes-no-yes answers is sovereignty. Anything else is a spectrum of dependency that should be named honestly.
How this maps to the platform
Everything on this site ladders up to that definition. Secure Operations is self-hosting Kubernetes fleets — up to fully air-gapped. Sovereign VMs removes the foreign hypervisor-licence dependency. Secrets & Zero-Trust removes the foreign vault dependency. All of it is open source you can audit.