BSI C3A: When Is a Cloud Actually Sovereign?
For years, "digital sovereignty" was a debate without a yardstick. Everyone had an opinion; nobody had a checklist.
In 2026, the BSI changed that. Not with another political statement, but with a list of concrete, testable criteria. Here is what they say, and where we stand.
What the BSI Actually Published
The framework is called C3A. "Criteria Enabling Cloud Computing Autonomy." Instead of arguing about whether a provider is "independent enough," it lets an organization check a cloud service against specific, written requirements.
It builds on the existing C5 security catalogue and points in the same direction as the EU's planned Cloud and AI Development Act (CADA). It is not legally binding today. But criteria like these tend to reach procurement requirements long before they become law.
The Core Criteria
Four requirements do most of the work:
- Disconnect capability (SOV-4-09-C): The cloud has to keep working after it is cut off from any non-EU infrastructure. Availability, integrity, authenticity and confidentiality intact. Providers must document the procedure and test the disconnection once a year.
- EU personnel (SOV-4-01-C1): Everyone with access to the systems must be an EU citizen resident in the EU. The stricter tier (C2, for defence and security use) requires German citizens resident in Germany.
- Jurisdiction: The provider may not operate under non-EU legal jurisdiction. Critical maintenance has to be performed from within the EU.
- Defence contingency: The framework includes provisions to hand operations over to German federal authorities in a constitutional defence situation.
Why This Goes Further Than "Data Stays in the EU"
A "sovereign cloud" badge from a US hyperscaler usually means one thing: EU data residency, maybe EU staff. C3A asks harder questions.
Can the service survive being disconnected from non-EU infrastructure? Who has access, and under which citizenship? Whose courts can compel the operator? Those are questions a US parent company cannot answer the way C3A wants. No matter where the servers sit.
We covered why server location alone isn't enough in Digital Sovereignty in Europe: What Actually Matters.
Where Zero Services Stands
We'll be precise here, because vague claims are exactly the problem C3A was written to solve.
- Jurisdiction: We are a German GmbH under German law, with no US parent company. There is no non-EU jurisdiction that can compel us.
- Own infrastructure: We run our own network (AS215197) and our own datacenters. We don't sit on top of a hyperscaler, so "operate after disconnection from non-EU infrastructure" isn't a contingency we would have to engineer; it is how we already run.
- Operations and staff: Services are self-hosted; operations and the people who run them are EU-based.
That puts us structurally on the right side of several C3A criteria. Jurisdiction, infrastructure independence, EU operations.
What We Don't Claim
We are not "C3A-certified." C3A is a set of criteria, not a label we hold, and conflating it with our §3 BSIG DDoS-mitigation qualification (a separate matter entirely) would be dishonest.
Some criteria are organizational rather than inherent: documented annual disconnection tests, formal defence-handover provisions. And complete technological independence doesn't exist for anyone. Our servers run on Intel or AMD processors, Supermicro hardware, Nvidia GPUs.
What we offer is simpler and verifiable: a German contract partner, German law, no US parent, and our own infrastructure in European datacenters. For organizations that actually have to demonstrate sovereignty, that is where the C3A conversation starts.