All posts

Sovereignty Washing: How to Tell a Real Sovereign Cloud From a US Cloud With an EU Sticker

Most "sovereign clouds" sell you a data centre postcode and call it independence. Three due-diligence questions — ownership, ultimate parent jurisdiction, who can be compelled — tell the real ones from the relabelled US services.

Sovereignty washing, defined

Sovereignty washing is selling data residency — "your files sit in an EU data centre" — as if it were sovereignty. It isn't. Sovereignty is about who controls the company holding your data and which government can compel that company, not where the disks spin. A US-owned service with a Frankfurt region and an EU sticker is still reachable under the CLOUD Act. The address changed; the chain of command didn't.

The word has teeth now because Europe is buying sovereignty in bulk. On 17 March 2026, CISPE — the trade body for European cloud infrastructure providers — wrote to the Commission over its draft Cloud and AI Development Act, warning it not to let hyperscalers redefine the term, and rejecting the idea of a blended "sovereignty score" with the line that there is "no such thing as 75% sovereign." Sovereignty, they argued, is measured by control, not by whether a vendor merely keeps a presence inside the EU. That is the whole fight in one line.

The S3NS own goal

In April 2026 the Commission awarded four bids a slice of a €180m sovereign-cloud procurement framework. One of the four winners was a consortium led by Proximus that ran in part on S3NS — a joint venture between French defence group Thales and Google Cloud. A sovereignty tender handed a slot to a stack half-owned by a US hyperscaler, and that bid was assessed at SEAL-2 while the three fully European-built bids reached SEAL-3. The framework's own scoring flagged the gap.

S3NS makes the strongest version of the residency argument, which is exactly why it's worth reading closely instead of dismissing. The entity is French and controlled by Thales. Staff are European nationals in France. Contracts are signed with S3NS directly, and Google is not a party. Operations run on S3NS personnel, with only limited supervised help from Google and no standing system access. Its PREMI3NS offering cleared France's hardest bar, SecNumCloud 3.2, in December 2025 — the first time ANSSI qualified IaaS, PaaS and CaaS at once — and by mid-2026 Thales and Google were cloning the model into a region near Berlin.

That is a serious build, not a marketing brochure. But look at what the defence is actually made of: an org chart, a contract structure, an operating discipline. None of it changes the fact that the platform underneath is Google's, with a US parent upstream of the IP and the roadmap. The structure makes compulsion hard. Real sovereignty makes it impossible, because there is no US entity left in the chain to compel. That gap is the entire debate, and it's why "we're a French JV" still reads to critics as a very sophisticated sticker.

How do you actually test for sovereignty washing?

Stop reading the marketing page and read the cap table and the contract. Two questions about ownership and one about compulsion separate substance from branding, and a DPO can answer all three during due diligence without taking the vendor's word for anything.

  1. Who owns the company? Not where it's incorporated — who holds the shares. A joint venture with a US hyperscaler, a US-owned holding parent, or a vendor that can be acquired tomorrow all fail here. If a US entity holds a controlling or even meaningful stake, CLOUD Act exposure travels up the cap table to it.
  2. Whose law sits over the ultimate parent? Follow the ownership chain to the top. The binding jurisdiction is the one over whoever ultimately controls the operating company. A German GmbH that's a wholly-owned subsidiary of a Delaware corp is, for compulsion purposes, a Delaware corp with a German accent.
  3. Who can be legally compelled to hand over data or keys? The only question a courtroom cares about. If any entity in the chain falls under US (or any foreign) jurisdiction and can technically reach plaintext, it can be served and gagged. The test isn't "would they?" It's "could they be made to, without telling you?"

There's a fourth question that quietly collapses the first three: does the provider hold keys that can decrypt your files? If encryption happens on your device and the server only ever sees ciphertext, most of the compulsion risk evaporates no matter who owns whom. You can't surrender plaintext you're mathematically unable to produce. Jurisdiction stops being the last line of defence and becomes a second one.

Where beebeeb lands on its own checklist

A checklist is only worth anything if it cuts both ways, so here's beebeeb run through it.

Testbeebeeb
Who owns the company?Initlabs B.V., a Dutch company (KvK 95157565). No hyperscaler stake, no US holding parent.
Whose law sits over the parent?The Netherlands. The top of the chain is the operating company.
Who can be compelled?A Dutch entity, under EU and Dutch law. No US person sits anywhere in the chain.
Does the provider hold your keys?No. AES-256-GCM encryption runs on your device; the key that protects your account is stretched from your password with Argon2id (256 MiB of memory, on the login and recovery path — not server-side). The server stores ciphertext and never sees a key.

The fourth row is the one that carries the weight. Data lives in Falkenstein, Germany, which satisfies residency — but residency is the weakest claim on the list, so it isn't where we plant the flag. The flag goes on the math: zero-knowledge on every tier, no exceptions. A subpoena served on Initlabs produces encrypted blobs and nothing usable. If you'd rather check the claim against the mechanism than the brochure, the key handling and threat model are written up in plain language on our security architecture page.

Why "we don't hold the keys" beats "your data is in the EU"

Residency is a promise that can break quietly — a subsidiary restructure, a parent acquisition, one gag order. Zero-knowledge encryption is a property that holds whatever the corporate weather does. It's also the cleanest line between a real sovereign service and a relabelled US one. Ask Dropbox, which is US-headquartered and holds your encryption keys, whether it can read your files; the honest answer is yes, which is the gap we walk through in the beebeeb versus Dropbox comparison. Ask a zero-knowledge provider the same thing and the answer is no — not "we promise not to," just no.

None of which makes jurisdiction irrelevant. It makes jurisdiction a backstop instead of the whole wall. Even privacy-first peers hedge on geography: Proton — an open-source, audited provider that is a genuinely good service — is moving most of its physical infrastructure out of Switzerland into Germany and Norway, a roughly CHF 100m move, over a proposed Swiss surveillance law it called a threat it won't be held hostage to. Good engineers don't trust one jurisdiction to stay friendly forever. They make the data unreadable first and pick the friendliest jurisdiction second.

So when a vendor calls itself sovereign, skip the argument about the data centre's postcode. Ask who owns them, whose law governs the people who own them, and whether anyone in that chain can be made to hand over your plaintext. Clean answers, and it's sovereignty. An answer that points at a map, and it's the sticker.

Files only you can read

Beebeeb is end-to-end encrypted, zero-knowledge cloud storage — stored in Falkenstein, Germany, open source, with a 14-day free trial on every plan. Encryption happens on your device; we only ever hold ciphertext we can’t read.

Start a 14-day trial See pricing How the encryption works