Sovereignty is not a configuration option

A new paper in Media, Culture & Society makes a clean argument: Microsoft, AWS, and Google have rebranded themselves as stewards of digital sovereignty, and in doing so have hollowed out the term until it means whatever they're selling that quarter.

Grohmann and Costa Barbosa call it "sovereignty-as-a-service." It's a good name. The argument tracks.

The authors run a discourse analysis on the three hyperscaler programs launched into the European market between 2022 and 2023. AWS Digital Sovereignty Pledge. Microsoft Cloud for Sovereignty. Google's Digital Sovereignty Explorer. Three different framings, one shared move: sovereignty is no longer something you exercise over a platform. It is something the platform grants you, configured to your jurisdiction, billed monthly.

The paper is correct about the capture. It is also incomplete.

What the paper gets right

The discursive capture is documented cleanly. AWS defines sovereignty as "control over digital assets" and then sells you the assets. Microsoft defines data sovereignty as data "under the control of the customer and governed by local law" — and then offers itself as the layer through which that control is administered. Google sells you a diagnostic that recommends Google Cloud.

The structural pattern is the inversion the authors identify. Sovereignty was historically a property of political communities. In this reframing it is a property of a customer's account settings.

The Brazil example they close with is the right one. The Lula government promotes a sovereignty discourse while purchasing "sovereign" cloud services from AWS. That isn't hypocrisy. It's the mechanism working as designed. The discourse and the procurement are the same product.

This is the part of the analysis that has been visible to anyone building in the space for a few years. The paper makes it citable. That is useful.

Where the academy stopped short

The paper treats all corporate sovereignty offerings as a single category of bad-faith capture. That collapse is analytically convenient and architecturally wrong.

There are two different things being sold under the same word, and the difference matters.

The first is sovereignty by configuration. This is what the hyperscalers offer. You are sovereign because the vendor has agreed to keep your data in a particular region, has built an audit log, has signed a contract, and has assured you the keys are yours. The sovereignty is a policy stack on top of infrastructure the vendor fully controls. Every guarantee is a promise.

The second is sovereignty by architecture. The data is encrypted client-side before it reaches the infrastructure. The keys never leave the customer. The ciphertext is sharded across multiple independent providers using erasure coding, so no single provider holds enough to reconstruct anything. The vendor cannot read the data because the math does not permit it. There is no policy layer to audit because there is no policy. There is geometry.

The two architectures answer the same regulatory questions on paper. They answer them very differently when a subpoena arrives.

The CLOUD Act problem the paper does not name

The CLOUD Act allows US authorities to compel US companies to produce data regardless of where that data physically resides. This is not a footnote. It is the load-bearing question for any European, Canadian, or Brazilian customer who wants what the word "sovereignty" used to mean.

A "sovereign region" operated by a US hyperscaler is, under US law, reachable. The flags on the data centre are decorative. The org chart is the jurisdiction.

This is why sovereignty by configuration cannot deliver sovereignty in the sense the authors are defending. It is not a deficiency of sincerity or effort. It is a structural property of who owns the company answering the warrant.

The paper would have been sharper for naming this. The hyperscaler programs are not just discursively captured. They are legally incapable of providing what they claim, regardless of how the discourse is framed.

One disagreement

The authors treat the entire "sovereignty as a service" category as ideological capture, full stop. That framing is too clean.

Some of what gets sold under that banner is exactly what they describe — branding sprayed on hyperscaler defaults. Some of it is architecturally independent of the firms they critique. Lumping the two together makes the category unfalsifiable: any vendor offering sovereignty as a product is, by definition, capturing the discourse. Which leaves the reader with no operational way to tell a marketing exercise from a working alternative.

The honest version of the critique is narrower and more useful: sovereignty provisioned by the same firms that created the dependency cannot resolve the dependency. That holds. It also leaves room for the architectural alternatives the paper does not engage with — open-source, multi-cloud, zero-knowledge, cooperative — including the ones being built commercially.

The authors close by inviting work on "popular digital sovereignty" from below. Good. That work also has to happen at the architecture, not only at the discourse. Otherwise the next generation of sovereignty programs will be the current one with different logos.

The uncomfortable part for builders

The paper's strongest move is refusing to let any vendor off the hook for using the word. That includes the ones who think they've earned it.

If you build in this space, the discipline the paper demands is the right one. You don't get to define sovereignty for your customer. You ship architecture that holds up when the discourse is stripped away — when the subpoena lands, when the provider is acquired, when the region is reclassified, when the marketing site is rewritten.

Sovereignty is not what you say. It is what survives.

https://doi.org/10.1177/01634437251395003

Originally published by Ross Norrie, founder of SkyeConnex, on LinkedIn.

Published May 4, 2026 · More from the SkyeConnex blog