In late April 2026, the Federal Office for Information Security adopted a particularly ambitious set of cloud regulations. The C3A criteria catalog – short for “Criteria enabling Cloud Computing Autonomy” – is intended to define when a cloud provider is truly sovereign. The idea is sound. But the closer you look, the more questions arise. Is this a compass for digital self-determination or a wish list that hardly anyone can fully fulfill?
What C3A aims to achieve and how it differs from C5
Anyone familiar with the BSI is already familiar with the C5 criteria catalog: the established testing framework for cloud security that has served as the basis for audits and certifications for years. In April 2026, the BSI published a new version of C5—and introduced C3A almost simultaneously. This is no coincidence, but rather a matter of system logic: C5 verifies whether a cloud service is secure. C3A verifies whether it is also sovereign. The key difference: C5 is established, auditable, and market-standard. C3A is new and non-binding. It builds upon C5 as a prerequisite.
So anyone who wants to become C3A-compliant isn’t starting from scratch—but they aren’t done after a C5 audit either. C3A adds six new domains: strategic, legal, data, operational, supply chain, and technology sovereignty. Each domain has basic criteria, as well as optional, stricter additional criteria—and dozens of specific requirements.
What C5-certified providers still need
Let’s imagine a European cloud provider that already has a C5:2026 certificate in hand. It has audited its security architecture, documented its processes, and paid its auditor. What’s still missing to achieve C3A compliance? Quite a bit.
Under SOV-1, the provider must demonstrate that it operates under EU jurisdiction, is headquartered in the EU, and is effectively controlled by EU companies. It must ensure transparency and provide 90 days’ notice of any changes. SOV-3 requires external key management, client-side encryption, and an external identity provider—not only for IaaS and PaaS, but eventually for SaaS as well. SOV-4 requires that all operational staff be EU citizens residing in the EU and that administrative access from non-EU countries be technically blocked. In addition, the provider must conduct a genuine disconnect test annually—that is, prove that the service continues to operate without any non-EU connections. SOV-5 requires an SBOM (Software Bill of Materials) for all components used, including their countries of origin. SOV-6 stipulates that source code and deployment toolchains must be backed up daily within the EU.
This isn’t just a minor add-on to C5. It represents a whole different category of requirements—organizational, personnel-related, and architectural.
Realistic or just a regulatory wish list?
This is where the legitimate criticism begins. The EU cloud association CISPE argues that, in its view, C3A does not protect against U.S. laws such as the CLOUD Act, but rather cements dependence on large technology conglomerates. This hits a sore spot: A framework that effectively excludes hyperscalers like AWS, Azure, or Google Cloud—or at least demands significant restructuring from them—is no longer a neutral transparency tool. It is a market architecture.
The operational criteria are particularly demanding. The requirement that all personnel with physical or logical access must be EU citizens residing in the EU is not only logistically complex for globally operating providers; in certain scenarios, it is simply unfeasible. The disconnect requirement—tested annually, fully documented, and independent of non-EU entities—demands a level of infrastructure depth that many providers do not yet possess.
The BSI itself emphasizes: C3A is not a binding set of rules, but rather a guidance framework. Certificates have been announced but are not yet available. It is currently unclear when the market will be able to issue an official C3A certificate.
The Strength of the Framework—and Why It Matters Anyway
Despite all the criticism, it would be wrong to dismiss C3A as an unrealistic bureaucratic exercise. For the first time, the framework establishes a verifiable language for sovereignty. Anyone negotiating with a cloud provider today can ask specifically: Which C3A criteria do you meet, and which do you not? This represents real progress compared to the status quo, where “sovereign” was often just a marketing term with no measurable substance.
The structure of basic and additional criteria also allows for differentiated application. Not every government agency or company needs the strictest level. Anyone who misuses C3A as a checklist has misunderstood the concept. Those who use it as a framework for negotiation create added value.
What This Means for IT Leaders
C3A is coming, whether as a regulatory requirement or a competitive differentiator. Regulated industries such as financial services, healthcare, and critical infrastructure will feel the pressure first, as their regulators will use the framework as a reference. The combination of C5:2026 and C3A will increasingly appear in tenders, contract negotiations, and supplier evaluations.
For IT executives, this means in concrete terms: Anyone who is currently evaluating their cloud provider against C5 should already be keeping an eye on the C3A gap. Which SOV domains are relevant to your own risk architecture? Where are there dependencies on non-EU components that will become a problem in the medium and long term? And: Can the provider actually “disconnect” in an emergency, or is that just theory?
C3A is no cause for panic. But it is a reason to finally have an honest conversation about cloud sovereignty, beyond marketing slides and compliance checkboxes.
What C3A Might Look Like in Practice
To understand what C3A compliance actually means, it’s worth taking a look at providers who don’t treat the framework as an abstract exercise. Link11 is a company established under German law with headquarters in Frankfurt am Main. It operates exclusively under German and European law. Non-European authorities have no access to systems or customer data. This precisely meets the SOV-1 requirements for strategic sovereignty: verifiable EU jurisdiction and no dependence on control by non-EU entities.
Compliance is independently certified. Link11 holds a BSI C5 attestation, a SOC 2 Type 2 attestation, and ISO 27001 certification. This is precisely the foundation upon which C3A is built. The prerequisites are also met in the domains of supply chain sovereignty (SOV-5) and technology sovereignty (SOV-6): software components are tracked with proofs of origin, and the source code and deployment toolchains reside on EU infrastructure and are secured there.
This demonstrates that sovereignty is not a feature that can be added after the fact. It must be embedded in the architecture, legal structure, and operations from the very beginning. For companies seeking a C3A-capable provider today, what matters is not which certifications are available, but how deeply sovereignty actually extends.
To be digitally sovereign, you first need to understand your dependencies. C3A can help you identify these dependencies. Companies like Link11 demonstrate that the answers don’t always remain unknown.
You might also like:
