Is Sovereignty as a Service a Category Error We Need to Retire?

I am starting to believe that ‘Sovereignty’ is becoming one of the most misused words in modern technology discourse. As digital infrastructure becomes geopolitical, vendors increasingly promise Sovereignty as a Service. The phrase is reassuring and often wrong.

Let me start by providing some clarity, we need a clean and simple taxonomy. In the absence of which let me volunteer a starter for ten and assume:

1. Sovereignty of = Ultimate authority and legal supremacy (law, courts, coercive power etc). This is non-delegable.
2. Sovereignty over = Control of assets such as data, keys, operations and personnel.
3. Sovereignty from = Reduced exposure to foreign jurisdictions, laws or enforcement risk.
4. Sovereignty within = Autonomy exercised inside constraints set by a higher authority.

Only the first is true sovereignty. The rest are important but different and therein lies the challenge.

It is also important to acknowledge initiatives such as the European Unions (EU) Cloud Sovereignty Framework criteria SEAL (Sovereignty Assurance Level), a graduated assurance model used in European policy and procurement thinking to describe how far a cloud or AI service actually achieves sovereignty outcomes not just whether it meets security or compliance controls. It represent a genuine attempt to move the conversation away from marketing language and toward verifiable execution controls. SEAL does not claim to confer sovereignty in the constitutional sense; instead, it focuses on sovereignty-preserving mechanisms, notably trusted execution environments, cryptographic attestation and enforceable execution boundaries that constrain what code can run, where and under whose control.

Properly understood, SEAL sits firmly in the domains of sovereignty over and sovereignty within, it reduces technical and operational risk, increases auditability and limits discretionary access by vendors or operators. What it does not and should not be presented as doing is resolving questions of ultimate legal authority or extraterritorial compulsion. Its value lies precisely in this restraint. SEAL is most credible when framed as an evidence-producing trust primitive, not as a substitute for state authority or customer governance. Think of SEAL as answering – If things go wrong politically, legally or operationally, who is actually in control?

When a private technology company claims to offer Sovereignty as a Service, yet remains answerable to multiple states, capital markets and extraterritorial laws (US Cloud Act + The Foreign Intelligence Surveillance Act), it cannot deliver sovereignty of. It can only offer sovereignty over, from orwithin. Collapsing these distinctions into the singular use of sovereignty is not innovation it is a category error and I suspect will soon become a contractual breach as sovereignty expectations find there way into service agreements.

This matters because sovereignty is not about uptime, encryption or data residency alone. It is about who ultimately decides when things go wrong. Courts, sanctions, subpoenas, executive liability and political pressure do not disappear because an architecture diagram looks tidy.

There is, however, a coherent and valuable proposition hiding behind the hype, I call this sovereignty-preserving architecture. This means bounded autonomy, explicit threat models, structural separation, host-state override rights and honest acknowledgment of residual risk.

The future of digital sovereignty will not be delivered as a service. It will be designed, governed and enforced with technology as an enabler, not a substitute for authority. Technology service providers need to get to grips with this and be trustworthy in how they deliver sovereignty. 

The danger is not that vendors exaggerate what they sell,  it is that customers and states outsource what they cannot afford to lose. Sovereignty risk is non-transferable, much like fiduciary duty.