Sovereignty Is a Direction, Not a Destination

Europe is not debating digital sovereignty anymore. It is starting to buy against it.

That is the shift Nick Howell pointed me toward this week. The surface story is familiar enough: Microsoft licensing pressure, European public-sector frustration, better open-source and regional alternatives, and a growing appetite to reduce dependence on American hyperscalers.

All true.

But the more interesting part is what happens when frustration turns into procurement. Complaints are easy for large vendors to survive. Every major platform company has weather systems built for that. Procurement is different. Procurement turns the complaint into a scorecard.

That matters because sovereignty has spent the last few years floating around enterprise technology with a dangerous amount of hand-waving attached to it. Everyone wants the word. Nobody wants the harder follow-up questions.

Sovereign against what?

At what level?

With which dependencies still intact?

Nick put the larger implication cleanly:

"The same questions every CIO of consequence in the US and APAC is going to be answering by 2028. The Europeans are just doing it first."

That line has been sitting with me. Not because 2028 is some magic cliff edge. It is not. But it is a useful planning horizon, and two years is about how long organizations need to turn a vague strategic concern into an actual set of decisions.

The question is whether they use that time.

Sovereignty Got a Rubric

The European Commission published its Cloud Sovereignty Framework in October 2025. It is, on paper, a procurement document. I realize that sentence may have lowered the room temperature by six degrees, but stay with me.

The useful part is not that the EC has a document. Governments have documents the way airports have carpet. The useful part is what the document does: it defines eight sovereignty objectives and five assurance levels, from no meaningful sovereignty to complete EU control with no critical non-EU dependencies.

In plain English, it gives buyers a way to ask, "When you call this sovereign, what level of sovereign are we actually buying?"

That is new pressure.

For years, a vendor could point to a local data center and call it sovereign. A cloud provider could point to a regional availability zone and call it sovereign. An architecture diagram could put the important boxes inside the right border and leave the awkward dependencies tucked away in a corner, usually in a font size known only to compliance teams and people with excellent monitors.

The framework does not solve all of that. No framework does. But it makes the conversation harder to fake.

It also exposes the trap in how many people talk about sovereignty. We keep treating it like a finish line.

The Finish-Line Problem

When people hear "sovereignty," they often jump straight to the extreme case: total isolation, full local control, no external dependencies, no cloud management plane, no vendor reach-back, no help coming over the wire.

For some organizations, that is not extreme. That is the requirement. Defense, intelligence, critical infrastructure, and certain regulated environments do not get to treat sovereignty as a vibe. It is the admission ticket.

Most organizations are not in that category.

Most are somewhere messier. They have accumulated dependencies over years of perfectly reasonable decisions. A SaaS tool here. A managed service there. A licensing system nobody remembers approving. A cloud dashboard that became operationally essential because it was convenient, and convenience has a way of quietly becoming architecture.

Nobody sat in a room and said, "Let's create a fragile dependency chain that will be painful to unwind later."

They just kept saying yes to things that worked.

That is why purity is the wrong starting point. If the only acceptable answer is complete sovereignty, most organizations will do nothing. The gap is too large, the cost is too unclear, and the business case sounds like someone trying to win an argument in a bunker.

Direction is more useful.

Moving sensitive data into the right jurisdiction is not full sovereignty, but it reduces exposure. Owning your encryption keys is not full sovereignty, but it changes who can act without you. Replacing a hidden cloud dependency in a critical workflow is not full sovereignty, but it may be the difference between operating through a disruption and discovering, at the worst possible moment, that "on-prem" had an asterisk.

That asterisk is where the interesting work lives.

The Test Is Operational

The simplest diagnostic question I know is this:

If external connectivity disappears, what stops working?

Do not start with the vendor brochure. Start with the uncomfortable operational version. Can users still authenticate? Can policy still be enforced? Can the system still be monitored, restored, patched, reconfigured, or even understood by the people responsible for it?

Some systems will pass that test. Some will fail in ways that are annoying but survivable. A few will fail in ways that make the room go quiet.

That list is the work.

Not all of it needs fixing at once. Not all of it needs fixing the same way. But once you know which dependencies matter, sovereignty stops being a slogan and becomes a backlog. Not very cinematic, I know. Also much more likely to survive contact with a budget meeting.

And it is probably how this work actually gets done.

The Smart Path Looks Boring

The organizations that handle sovereignty well probably will not look especially dramatic while they are doing it.

They will make better decisions when a contract renews. They will ask harder questions when a platform reaches end of life. They will notice when a new facility, merger, compliance review, or security incident creates a natural opening to reduce dependency instead of simply recreating the old posture on newer invoices.

That is when sovereignty is cheapest to improve: when something is already moving.

The expensive version is waiting for the forcing function. A licensing shock. A policy change. A geopolitical rupture. A vendor roadmap that quietly removes the deployment model you assumed would always be there.

Then the same work gets renamed urgency, and urgency is notoriously bad at negotiating.

Nick's broader point, at least as I read it, is not that Europe has suddenly become purist. It is that the exit door became usable at the same moment the cost of staying put became harder to defend. Better alternatives changed the math. So did the politics. So did the procurement language.

That combination is what makes this worth watching.

The lesson is not "leave Microsoft." That is too small, and probably wrong for plenty of organizations.

The lesson is: know what it would take to leave anything important.

Not because you are leaving tomorrow. Because the organization with an exit path has choices. The one without an exit path has a vendor relationship it may be calling a strategy.

Sovereignty is not a destination. It is a direction of travel.

The organizations that understand that now will have options later.

The ones that wait will have urgency.