By Philipp Reisner, CEO LINBIT®
Sovereignty is a word borrowed from statecraft. A sovereign country is independent in its decisions. The term “digital sovereignty” is a more recent invention that applies to organizations and even individuals.
In this article, I discuss what the push for digital sovereignty implies for Linux-focused, open source developers and companies. The framework I use is a European one, because I am Vienna-based and familiar with it. As I discuss later, the implications are not limited to Europe.
A framework for defining and rating digital sovereignty
The European Commission published the EU Cloud Sovereignty Framework (CSF), which breaks sovereignty down into eight objectives:
- SOV-1, Strategic: Ownership and governance are controlled, avoiding external dependencies.
- SOV-2, Legal and Jurisdictional: Protects against external laws and unauthorized access.
- SOV-3, Data and AI: Control and privacy compliance for data and AI models in the cloud.
- SOV-4, Operational: Day-to-day cloud administration, management, and support are handled securely from within.
- SOV-5, Supply Chain: Protects against vendor lock-in and external bottlenecks.
- SOV-6, Technology Openness: Encourages open standards and the freedom to choose technologies.
- SOV-7, Security and Compliance: Aligns cloud services with European cybersecurity standards, frameworks, and compliance audit rules.
- SOV-8, Environmental Sustainability: Adoption of energy-efficient infrastructure, environmentally responsible practices, and activity reporting intended to reduce environmental impacts of technological activity.
Rating technology providers for digital sovereignty compliance
The framework rates providers on two scales: a Sovereignty Effectiveness Assurance Level (SEAL), and a complementary Sovereignty Score for cloud services. The first indicates a minimum level of sovereignty objectives met. The second shows a provider’s strengths and weaknesses across the objectives.
Each objective is rated from SEAL-0 to SEAL-4. SEAL-4 means an EU supply chain, from the physical chips up to the software.
The mechanic I find most interesting is that a provider does not get one SEAL level. It receives eight, and the overall level is the lowest of them. Your weakest objective decides your rating, not your average. Anyone who has ever tuned a storage stack will recognize that logic.
Meeting the technology-openness objective
Open source software can put providers in a strong position to address the technology-openness objective, SOV-6, because customers can inspect the code, operate it independently, and avoid dependencies on proprietary implementation. Because the source is open, that argument does not stop at the EU border. A service provider in the US or in Asia aiming for full SEAL-4 is not held back by choosing open source software.
Open standards need open implementations
SOV-6 specifies two things: open standards and the freedom to choose technologies. In software, an open standard might define an interface that anyone can implement, but if only one vendor has implemented it, a buyer still has a single supplier for it. Depending on a single supplier also weakens a provider on SOV-5, the supply-chain objective, which protects against vendor lock-in. Freedom to choose means being able to substitute one implementation for another.
An example is the Container Storage Interface (CSI), a vendor-neutral storage standard developed under the Cloud Native Computing Foundation (CNCF) and used by Kubernetes. CSI is the standard, LINBIT provides a CSI driver for LINSTOR® and its upstream CNCF project, Piraeus Datastore, and a buyer running Kubernetes can use this driver. Because of the open standard nature of the interface, the buyer can also move between storage back ends. This is freedom for the buyer, motivation for providers to make a better solution, and neutrality from a foundation like the CNCF.
Implications of digital sovereignty for cloud and technology services providers
Digital sovereignty is no longer an exercise on paper. In April 2026, [the European Commission awarded a sovereign cloud contract worth up to €180 million over six years to four European providers](https://commission.europa.eu/news-and-media/news/commission-advances-cloud-sovereignty-through-strategic-procurement-2026-04-17_en), with SEAL-2 as the minimum bar for eligibility. Sovereignty has become a procurement instrument with money attached. Predictably, one of the awards is already being publicly contested as “sovereignty-washing”.
What poured oil on the fire was an incident involving the chief prosecutor of the International Criminal Court. After the US sanctioned court officials, the chief prosecutor reportedly lost access to his Microsoft-hosted email account, and bank accounts in the United Kingdom were frozen. Since these actions, some EU banks with US exposure are preferring to over-comply rather than take any risk. Microsoft disputes the framing and maintains it never suspended services to the ICC as an organization. For me, the detail of who pressed which button matters far less than the lesson: neither the email nor the banking depended on a European decision.
In the US, similar discussions have taken place, only with different verbiage. There it is “economic security” and “supply chain resilience”, mostly aimed at China, and where Europe says “technological sovereignty”, Washington says “technological leadership”. Different branding, same substance.
Conclusion
As digital sovereignty gains weight in technology sourcing decisions, smaller vendors benefit.
A framework that asks, “Who owns you? Whose laws apply? Can I operate this without you, and can I read the source?” rewards exactly the properties a small open source company has by default. The hyperscalers will feel some headwind, though they are not standing still, and “sovereign” regions run by local operating entities are their answer. Whether that clears a SEAL-3 or SEAL-4 bar is the argument of the next few years.
LINBIT already made an investment in developing in the open. An open license is necessary but not enough on its own, because a project can be open and still be controlled by a single company that can relicense it. What makes the openness durable is governance that the original vendor cannot reverse. DRBD® ships in the mainline Linux kernel, and we are working to upstream the current DRBD 9 code. Code in the commons, for example, in the mainline kernel, under a foundation such as the CNCF, or in another home that no single vendor controls, is the strongest answer to SOV-6 I know of. Every project that puts it there widens the set of technology a sovereign buyer can choose from.
