Why Most Sovereign Stacks Fail the Day-Zero Test

Sanctions, ownership change, an executive order, a contract dispute. Pick your scenario. What happens to your environment?

If your answer involves negotiating with a vendor’s legal team, escalating to a country office, or waiting for a regulatory carve-out, you do not have sovereignty. You have a managed dependency with good packaging. You are vulnerable from day zero.

That is the stress test most sovereign stacks on the market today quietly fail. It is the test buyers across the globe should be asking out loud. This isn’t just a niche concern; according to SUSE’s Navigating Digital Resilience 2026 report, while a staggering 98% of enterprises prioritize digital sovereignty, only 52% are actively taking steps to achieve it. This massive ‘execution gap’ is exactly where vendor-led bundles thrive, offering the label of sovereignty without the operational reality.

This is not just European, Chinese or North American insight, it is also a topic for Africa and the Middle East. It is every business where IT has become mission critical.

Key takeaways

• Sovereignty is a posture, not a product.
• Vendor-led sovereign stacks may still create operational dependency.
• Open source, open standards, portability, and jurisdictional freedom are all required for true sovereignty.
• Buyers should evaluate sovereignty based on architectural independence, not branding alone.

IBM made a recent announcement about IBM Sovereign Core. A software bundle anchored on Red Hat OpenShift, with HashiCorp Vault, IBM Verify, and IBM Concert layered on top. I am sure there is some great software in this bundle, but why is the word Sovereign being used here? These products, either standalone or combined, carry no sovereign properties at all. What is happening here? Have we entered a phase of “sovereign” washing?

Most “sovereign” stacks have a single point of failure: the vendor

A wave of vendor-led sovereignty offerings are flooding the market right now. The marketing pages are confident. Each one promises operational control, continuous compliance monitoring, hybrid deployment, AI-ready infrastructure. All the right phrases.

The cautions are quieter. The full source of these offerings is not always available. The foundation often sits with a single vendor under a jurisdiction that does not respect yours equally. The compliance tooling depends on what the customer and the service provider feed it, which means the buyer still has to trust the vendor and validate themselves.

That last point is the one I keep coming back to. If a sovereign offering still requires you to fundamentally trust your vendor and your managed service provider, you have not removed dependency. You have moved it. Operational visibility into a stack you do not fully control is a useful thing. It is not sovereign; the black box is only partially opened.

Best of breed solutions are not red, blue or purple only!

Inside most of these prescriptive bundles is a second, quieter trap. The platform is marketed as flexible, but the stack mandates a specific identity provider, a specific secrets manager, a specific compliance engine, a specific observability layer, a specific Kubernetes distribution. Each piece is “open-source-based.” None of them can be swapped for other options. If you do, the support you are paying for no longer exists!

European buyers do not get to bring their own components into a bundle like that. They get a vendor’s catalog with a sovereignty label on the front. Choice has been replaced with a curated list, and the curator is the same vendor whose dependency the buyer was trying to escape.

This is what I mean when I say best of breed is not possible when the only color of choice is red, blue or purple. Sovereignty is not a single-supplier exercise. The whole point of building resilience is that no one vendor has an inescapable control over your IT stack. A stack that mandates which encryption tool, which identity provider, and which AI runtime you must use has not delivered choice. The overall solution remains a black box. The better option is a stack based on open standards, where components can be replaced and the entire stack becomes composable.

Open is a four-part test, not a marketing word

The reason every vendor is racing to use the term ‘open’ is clear: 94% of IT leaders now view open-source technology as very or extremely important to their resilience strategy. But as the market matures, the distinction between ‘open-source-based’ and ‘fully open’ becomes a door that’s open only one way.

Here is where SUSE comes at this differently. We hold ourselves to four tests, and we think any buyer doing serious sovereignty work should hold their vendors to the same:

• Open source, with the full source available. Not “open-source-based.” Not “built on” something open. The source the buyer audits is the source that runs in production.
• Open standards. Components have to be swappable. If you cannot replace one piece without invalidating the rest of the terms, you have lock-in dressed as flexibility.
• The ability to run anywhere. No captive cloud, no permission required, even in air-gapped environments.
• Jurisdictional freedom. Software should be supported in your region of choice.

The four are non-negotiable together. Any one of them is missing, and the sovereignty story has a soft spot. All four are how a buyer goes from “we trust this vendor” to “we do not need to.”

Vendors should answer the ugly questions, not handwave around them

What I see across customer conversations around the world right now is real demand for independence colliding with vendor positioning that is racing to keep up. Every stack on the shelf is suddenly “sovereign.” Most of them mean different things by the word, and few of them invite difficult comparisons.

That is the cost of fuzz. Buyers who genuinely want to escape concentration risk get sold the appearance of independence and discover, two or three years in, that the foundational elements are difficult to replace.

The job of vendors right now, including ours, is to answer the ugly questions before the buyer has to ask them:

• Where does the source live?
• Who governs it?
• What happens if the buyer walks?
• Whose jurisdiction applies on the day things get hard?

The vendors that meet those questions head-on are the ones European buyers should be shortlisting.

This shift is already hitting the balance sheet. Research shows that 51% of IT leaders are now formally embedding digital sovereignty as a mandatory requirement in their procurement processes. For these buyers, ‘good enough’ packaging is no longer a substitute for architectural independence.

Sovereignty is a posture, not a product

We built SUSE products for those four tests on purpose. It is open source under our SUSE support model, hardware and cloud independent, upstream-first in the projects it depends on, and supported by the wider community behind Kubernetes and the Cloud Native Computing Foundation.

That is not a feature list, it is a posture. The point is not that SUSE has a sovereign product. The point is that sovereignty is not a product at all. It is a set of architectural choices, governed in the open, that a buyer can audit and reproduce.

If you want to assess what your sovereignty gaps are according to the EU Cloud Sovereignty Framework and understand how to bridge the gap, take the self assessment that SUSE has provided for this.

If your shortlist is forming on those terms, we should talk. If it is not yet, ask the day-zero question first. The answer will tell you what you actually have.

More statistics can be found at https://www.suse.com/navigating-digital-resilience-2026/

FAQ About Digital Sovereignty

What is digital sovereignty?

Digital sovereignty is the ability for organizations to maintain control over their data, infrastructure, operations, and technology choices across jurisdictions and cloud environments.

What is a sovereign cloud platform?

A sovereign cloud platform is designed to support operational independence, data control, compliance requirements, and infrastructure flexibility without creating dependency on a single vendor or jurisdiction.

How do you avoid vendor lock-in in sovereign cloud environments?

Organizations can reduce vendor lock-in by using open-source technologies, open standards, portable architectures, and platforms that allow components and cloud providers to be changed without disrupting operations.

Why are open standards important for digital sovereignty?

Open standards help organizations maintain interoperability, portability, and architectural flexibility, reducing dependency on proprietary technologies and single-vendor ecosystems.