BSI C3A: A Procurement Filter Built on European Fragmentation

On 27 April 2026 the German Federal Office for Information Security published the first version of a sixteen-page document called Criteria enabling Cloud Computing Autonomy, BSI C3A for short. It is the cleanest measuring tape Europe has produced so far for what people mean when they say "sovereign cloud". I think that is exactly the problem.

I spent time reading BSI C3A alongside the EU Cloud Sovereignty Framework (EUCS) that it sits on top of, the BSI's own C5:2026 security baseline that it presupposes, and material that sheds light onto the political backstory. I have also talked to German GRC leads who already have C3A on their desks. This post is my attempt to explain what C3A actually is, how it relates to the broader EU framework and SEAL grading, what other countries are doing, and where the whole national-sovereignty-by-checklist movement starts to drain the continent it is supposed to protect.

BSI C3A is a well-built procurement filter, a dangerous operating doctrine, and a quiet admission that the EU could not agree on a common one. The most expensive thing about it is not the criteria, but the fragmentation in Europe it accelerates.

What C3A is, in twenty lines

C3A is a voluntary criteria catalogue organized into six sovereignty dimensions: strategic (SOV-1), legal and jurisdictional (SOV-2), data (SOV-3), operational (SOV-4), supply chain (SOV-5), and technology (SOV-6). Each dimension has a handful of MUST-criteria, a smaller number of additional criteria a customer can demand on top, and supplementary notes that clarify scope. The framework is explicitly "not binding in itself"; it is a document that cloud providers can use to demonstrate compliance and that customers can reference when they write a tender.

Almost every criterion comes in two flavors: C1 for "EU" and C2 for "Germany only". The customer picks which level to require. SOV-4-01-C2, for example, demands that all personnel with logical or physical access to the cloud be EU citizens with Germany as their main residency. SOV-1-01-C2 demands the provider operate under German jurisdiction. SOV-3-01-C4 demands customer data be stored and processed exclusively in Germany. Pick the German variants and you have elevated the bar past what the EU baseline asks for.

Five control in C3A do most of the actual work. First, SOV-4-09-C / SOV-4-10-C: the provider must be able to disconnect from all non-EU network connections without breaking the cloud, and must be able to reconnect within ninety days, with both procedures tested annually. Second, SOV-6-01-C: a complete source-code backup in the EU, refreshed every twenty-four hours, with at least five historical versions, sufficient for independent operation. Third, SOV-3-02-C and SOV-3-02-AC: external key management for IaaS and PaaS, extended to SaaS as an additional criterion. Fourth, SOV-1-04-C: ninety days advance notice to customers of ownership, shareholding, or governance changes that could undermine the controls. Fifth, SOV-2-03-C1: in the event of an EU member state declaring a state of defense, the provider must enable that state to take over the capabilities required to operate the cloud, including physical assets and personnel, within the framework of legal possibilities. Read that last one as a managed services provider and the contractual implications are quite something.

C3A does not cover security. The BSI is explicit that the C5:2026 catalogue already does that job, and C3A presupposes a provider meets C5. I have written a separate piece on what C5 actually is, and what the 2026 revision changed.

Where C3A sits in the European stack

C3A is the German national interpretation of the EU Cloud Sovereignty Framework, published by the European Commission in October 2025. The EU CSF defines eight Sovereignty Objectives, SOV-1 through SOV-8, and five Sovereignty Effective Assurance Levels, from SEAL-0 (no sovereignty) through SEAL-4 (full digital sovereignty). A customer sets a minimum SEAL per objective in its tender, then computes a single Sovereignty Score by weighting each objective's normalized result. The weights in the CSF formula are SOV-1 Strategic 15%, SOV-2 Legal and Jurisdictional 10%, SOV-3 Data and AI 10%, SOV-4 Operational 15%, SOV-5 Supply Chain 20%, SOV-6 Technology 15%, SOV-7 Security 10%, SOV-8 Environmental 5%.

That 10% for Legal and Jurisdictional has been the central critique: a provider exposed to extraterritorial law can still post a high overall Sovereignty Score by piling up points in the other categories.

C3A takes the CSF's first six objectives, SOV-1 to SOV-6, and turns each into concrete auditable MUST-statements. It drops SOV-7 because C5:2026 already does that work, and SOV-8 because environmental sustainability falls outside the BSI's mandate. The cleanest way to read the relationship is this: CSF and SEAL are the procurement language an executive uses to write "we require SEAL-3 minimum on SOV-1 to SOV-6"; C3A is the audit language an assessor uses to actually sign off the controls. A provider C3A-conformant under the German variants will, in practice, score very high on SEAL-3 or SEAL-4 across SOV-1 to SOV-6, while leaving SOV-7 to its C5:2026 attestation.

Why C3A had to exist: the quiet collapse of EUCS

The story often skipped is why Germany ended up publishing a national framework at all. The short version is that the EU spent three years trying to harmonize cloud certification across all member states and could not. C3A is what Germany did after losing that fight at the European level.

The vehicle was the European Cybersecurity Certification Scheme for Cloud Services, EUCS, drafted by ENISA from December 2020 onwards. In July 2021, France, Spain, Italy, and Germany jointly proposed adding immunity from foreign law and EU-localization criteria to the EUCS, provisions explicitly modeled on the French SecNumCloud scheme. France led the push. Macron had set the political register a year earlier: "to build the Europe of tomorrow, our standards cannot be under American control, our infrastructures, ports and airports under Chinese capital and our digital networks under Russian pressure". The French national cloud strategy framed the threat in straightforward market-share terms: foreign actors concentrate 69% of the European cloud market.

The Netherlands led the opposition. It was joined by what Dutch officials called the "digitally like-minded countries": Denmark, Estonia, Greece, Ireland, Lithuania, Poland, and Sweden. The 2021 Dutch Digitalization Strategy explicitly avoids the word "sovereignty", preferring "digital autonomy", because, in the strategy's own words, "digital sovereignty" is European jargon and "we are referring to the digital dimension of strategic autonomy". This is a substantive disagreement about whether the goal is to insulate European companies from American legal reach or to attract foreign cloud investment that helps Dutch high-tech clusters grow. The Polish national cloud, Chmura Krajowa, is openly designed as a collaboration with private firms including AWS and Google. Polish preferences look much more like Dutch ones than French ones, despite the easy "Eastern Europe skeptical of Big Tech" caricature.

Germany was the swing state. The government initially supported France. Then it changed position. The change was driven by globally-oriented German businesses, organized through the Federation of German Industries (BDI), whose 17 June 2022 position paper attacked the sovereignty provisions and echoed the pan-European employers' federation Business Europe, which put the argument in plain terms: "these requirements will restrict choice and quality in the European cloud market... hampering their growth and competitiveness... This is a political discussion, not a technical one". The BDI lobbied. The German government flipped.

In the March 2024 draft of EUCS, the digital sovereignty provisions were removed and replaced with mandatory transparency requirements: information on storage location and data processing methods, but no immunity from foreign law, no localization. Airbus, OVHcloud, Orange, Telecom Italia, and Deutsche Telekom wrote a joint letter urging member states to reject any EUCS without sovereignty provisions. Two years and one month after that draft leaked, the BSI published C3A.

The two events are not formally connected, but the political logic is hard to miss. The German government could not get sovereignty provisions into a binding EU certification because German industry did not want them there. So the BSI built a voluntary technical-criteria document that achieves much of the same outcome through procurement language, while leaving German global businesses free to reject the German variants when they operate elsewhere. That is the most plausible reading of why C3A exists in this form, on this timeline.

There is a name for this pattern, and it is not unique to Germany. Antonio Calcara, in a 2026 study of European cloud policy, argues that the repeated failure to agree a common scheme is not an accident the EU keeps trying to fix. It is a mechanism called Failing Forward. Member states use the partial, unresolved progress at the European level as cover to protect and promote their own national cloud ecosystems, so failure at the EU level, in his phrase, is designed to lead to national success. The certifications do not even have to exclude the American hyperscalers to do their work; they force them to the table, into the joint ventures and bilateral deals with national champions that S3NS and Bleu already are. And as leverage it has not worked, at least not yet. Calcara's figures show European providers growing revenue by 167% between 2017 and 2022 while still losing 14% of market share to Amazon, Microsoft, and Google. A decade of sovereign-cloud initiatives has coincided with deeper dependence, not less.

Everyone has one: the international landscape

C3A is not a German peculiarity. Every major economic bloc has built or is building a national cloud assurance scheme. The schemes do not compose, do not substitute, and have started to diverge even in vocabulary.

France got there first and remains the strictest. SecNumCloud, run by ANSSI, is binding for sensitive public-sector workloads and is famously hard on the immunity-to-foreign-law point. The qualification effectively excludes any provider exposed to the US CLOUD Act unless it operates through a legally insulated joint venture. The Cloud de Confiance label sits on top. S3NS (a Thales/Google JV) and Bleu (Capgemini/Orange/Microsoft) are the well-known constructions trying to thread that needle.

The United States runs FedRAMP High and the DoD Impact Level 4/5/6 tiers. Same logical structure as BSI C3A (citizenship requirements for personnel, vetted infrastructure, audited controls), opposite political vector. AWS GovCloud and Azure Government are the canonical examples of what the Deochake/SentinelOne taxonomy calls Sovereign Regions. The "sovereign" jurisdiction in this case is the United States itself.

The United Kingdom runs lighter. The NCSC Cloud Security Principles plus the Government Security Classifications are outcome-based and less prescriptive than SecNumCloud or C3A. The UK has chosen, so far, not to play the national-catalogue game at this depth.

Every major bloc has built a national scheme. None of these schemes were designed to interoperate with the others. They are defensive instruments, and the world is getting more of them, not fewer.

Four ways to be sovereign (and what each costs)

If C3A tells you what a sovereign cloud has to do, the question is how a provider would actually build one. A 2026 paper Saurabh Deochake lays out a taxonomy of four patterns that managed services providers have implemented.

1. The first is Sovereign Regions, where the hyperscaler operates physically isolated infrastructure inside the target jurisdiction. AWS GovCloud and Microsoft Azure Government are the canonical examples. Cost premium 20% to 40% over the equivalent commercial deployment, feature lag of six to eighteen months behind the global service catalogue, 80% to 90% service coverage. Residual risk: the parent company sits in a non-EU jurisdiction and remains exposed to foreign legal compulsion no matter how well the local controls are written. This pattern struggles to satisfy the SOV-1 and SOV-2 criteria a strict C3A reading would demand under C2.
2. The second is Trusted Operator, where a local entity licenses the hyperscaler's technology stack and runs it under contractual and technical air-gap. T-Systems Sovereign Cloud running Microsoft Azure under German control is the model. So is S3NS. Cost premium 40% to 60%, feature lag twelve to twenty-four months, 50% to 70% service coverage. Residual risk: supply chain opacity. The local operator receives binaries and signed updates from the hyperscaler without source visibility, and a compromised update can introduce vulnerabilities the local operator cannot detect. This is the pattern that maps cleanest to the German C3A variants, and the one that costs the most.
3. The third is Open Sovereign, an open-source stack the customer or a community operates themselves. Gaia-X and the Sovereign Cloud Stack are the reference initiatives. Cost is variable but small operators can exceed hyperscaler pricing per unit. Feature lag twenty-four to thirty-six months or more, 30% to 50% service coverage, and hidden cost: twenty-five to fifty specialised FTEs to integrate and maintain a dozen open-source components, each with its own security advisory cadence. This is the only pattern that genuinely satisfies SOV-6 technology-sovereignty in spirit, because the stack is fully auditable. It is also the pattern with the highest operational-error risk.
4. The fourth is Cryptographic Sovereignty: external key management, customer-controlled HSMs, Confidential Computing on hyperscaler infrastructure. Google's Assured Workloads is the cleanest implementation. Cost premium 5% to 15%, 90% to one 100% service coverage, feature lag zero to three months. The risk: metadata leakage is structural (filenames, access patterns, IP addresses remain visible to the provider), TEE vulnerabilities keep emerging (Foreshadow, Spectre and variants), and availability is coupled to the customer's own key-management system. If the HSM goes down, the workload goes down. This pattern handles SOV-3 cleanly and fails SOV-4 operational-residency requirements outright.

The most uncomfortable conclusion is that no single pattern provides strong protection across all attack vectors. The implication, if you take the threat model seriously, is that no managed services provider can today credibly claim to satisfy all of C3A C2. Right now, a C3A-conformant deployment under the German variants is essentially Trusted Operator plus selective Open Sovereign components plus Cryptographic Sovereignty for the data plane. Each of those layers adds its own cost premium.

How I would actually use C3A

C3A is genuinely useful if you do not make it the spine of your operating model and treat it as what it actually is: a procurement filter. I would use C3A that way:

• Apply C3A selectively to workloads. The German C2 variants should govern only the workloads that genuinely need them: federal data, regulated critical infrastructure operations, classified material, certain regulated health data. In most German enterprises that is under 10% of the workload portfolio. Applying C3A C2 across the board is a self-inflicted wound that the BSI itself invites you to avoid. The framework is modular by design, but the cultural reflex inside German GRC teams is to apply new schemes everywhere they could plausibly apply.
• Separate the procurement decision from the operating decision. SEAL and C3A are excellent for picking a provider in an RFP. They are mediocre for designing your day-to-day operating model. The audit catalogue is the wrong thing to build a run-book around. Build the run-book against your actual risk model, then use C3A to verify what you have built.
• Budget the sovereignty tax explicitly. A sovereign deployment carries a cost premium of roughly 40% to 70% over the equivalent non-sovereign one on a five-year horizon, in the engagements I have seen. If that number is not in the business case before the procurement starts, the business case is not honest.
• Do not adopt C3A C2 unless you can absorb the slowdown. Sovereignty costs time, not just money. Feature lag is six to eighteen months for Sovereign Regions, twelve to twenty-four for Trusted Operator, twenty-four to thirty-six or more for Open Sovereign. If your strategic position depends on shipping new capability faster than the incumbents in your category, and for most companies in regulated industries today it does, the right answer to "should we move workload X to a C3A C2 deployment?" is sometimes no, because you cannot afford to be a year behind on what your competitors are deploying.

The harder problem, and the one I want to leave you with, is what C3A is a symptom of.

The EU spent three years trying to harmonize cloud certification and could not get it done. The sovereignty provisions were stripped from EUCS in March 2024. Two years later, the BSI publishes its own scheme. Austria will almost certainly adopt something C3A-shaped, because that is what we do. Italy already runs a parallel ACN scheme. France has had SecNumCloud for years. The Netherlands has explicit transparency-only requirements and explicitly refuses the sovereignty framing.

A European enterprise with workloads in three countries is now paying lawyers and consultants to map between C3A, SecNumCloud, and Dutch transparency requirements. Each scheme has different criteria, different audit cadences, different vendor approval lists, different definitions of what counts as adequate external key management. The cost of that mapping does not show up on any individual framework's impact assessment. It shows up as a slow, steady drag on the velocity of European digital businesses, at exactly the moment when American and Chinese competitors are shipping AI capabilities on a weekly cadence.

EU businesses should be operating against EU standards. Instead they are operating against the union of every national scheme that any member state has bolted onto the EU baseline, and the union is growing. The Cloud and AI Development Act is in the EU pipeline through 2027, with a debut planned for 27 May 2026.

I grew up watching Star Trek and still romanticizing the federation of planets. The European answer to a continent-scale technology question is not supposed to look like this. I am not arguing C3A should not exist; it is a careful document, well drafted, and the procurement-filter use case is very valid. I am arguing that the bigger story is that twenty-seven national variants of "sovereign cloud" is a worse outcome than one shared European standard, even a weaker one, would have been.

If you are sitting at the table where this gets discussed, setting your organization’s sovereignty position, weighing the cost of a sovereign cloud strategy against the speed of execution, or pushing back when the framework du jour wants to apply everywhere, I am happy to compare notes on LinkedIn or by email.