Cloud sovereignty according to C3A: Is open source in IAM the solution?

With the C3A, the BSI has defined for the first time what "digital sovereignty" really means in a cloud context. Anyone reading the six criteria will realize that open source structurally fulfills most of them—not as a promise, but as a technical property. However, a closer look is necessary.

"Sovereign" is the new "secure" in the cloud industry—a term that almost every provider now claims for itself, even though it hasn't been verifiable. That has changed.

On April 27, 2026, the Federal Office for Information Security (BSI) published the C3A criteria catalog— Criteria enabling CloudComputing Autonomy. The document is not regulatory, but it has quickly become a reference framework for procurement processes, risk assessments, and strategic cloud decisions in companies and government agencies.

A closer look reveals that the requirements formulated there do not coincidentally describe the areas where open-source solutions structurally excel. Digital sovereignty not through certificates, but as an architectural principle.

What the C3A measures—and why open source provides a structural answer

The C3A complements the existing BSI C5 catalog: While C5 answers whether a cloud service is technically secure , C3A asks: Can this service also be used autonomously ? A highly secure system that I cannot leave, cannot inspect, and whose terms I cannot negotiate is, from a sovereignty perspective, a dependency—not a solution.

The catalog structures this question into six areas, the so-called Sovereignty Objectives (SOV):

‍

 SOV-1: Strategic sovereignty: Under which jurisdiction does the provider operate? Does the US CLOUD Act apply, for example?

SOV-2: Data sovereignty: Control over storage location, processing, and access to your own data

SOV-3: Operational sovereignty: Can the service continue to operate independently?

SOV-4: Technological sovereignty: Open standards, transparency, and no hidden dependencies

SOV-5: Economic sovereignty: Flexibility in contract terms and pricing models

SOV-6: Personnel sovereignty: Building internal expertise rather than relying solely on external dependencies

‍

Open source does not solve these requirements through better contracts, but through architecture. Visible code, free choice of operator, open standards, and vendor portability are not features that can be added later. It is a question of the fundamental model. Proprietary solutions can meet individual C3A criteria through exit clauses or certified operations. Open source is not a guarantee for SOV-4, but it is an essential prerequisite for fully independent auditability. Closed source code fundamentally precludes this form of auditability.

This is especially true for Identity & Access Management (IAM) systems. Authentication flows, role assignments, and access data are the nervous system of any infrastructure—if this layer is not transparent and portable, the entire stack is critical to sovereignty.

Where operations get difficult in practice

Keycloak is the most widely used open-source IAM foundation and structurally fulfills the C3A requirements: OpenID Connect, OAuth 2.1, SAML 2.0, Kubernetes operator, and horizontal scaling. But the devil is in the details of operation—in very specific areas.

SOV-3 – Operational sovereignty: Keycloak releases around twenty updates per year and generally only supports the current version. Testing, approving, and rolling out every update—including regression testing and rollback planning—must be organized internally. In production environments, this alone requires at least one full-time position. The Infinispan configuration for high availability is on top of that: cache replication and session handling under load require precise fine-tuning, and errors often only appear when it is too late.

SOV-4 – Technological sovereignty: The enormous configuration depth of Keycloak is both a strength and a risk, because Keycloak is built by developers for developers. Incorrectly configured auth flows create MFA loopholes; in the worst case, a faulty browser flow can lock out all users. Sovereignty in the sense of SOV-4 is only guaranteed if the configuration is actually understood and documented—a Keycloak instance that no one in the company fully understands does not meet the criterion.

SOV-6 – Personnel Management Sovereignty: Keycloak does not natively offer SCIM, automated lifecycle workflows for onboarding and offboarding, recertification, or time-limited access rights. The need-to-know principle – a GDPR requirement and C3A prerequisite – can only be implemented to a limited extent. Extensions are possible, but they create their own maintenance overhead and dependencies.

The Practical Dilemma

Keycloak structurally meets sovereignty criteria – but in enterprise practice, a self-hosted instance is rarely fully hardened, consistently maintained, and equipped with the necessary functional scope. Sovereignty on paper is not sovereignty in operation.

‍

The sweet spot is therefore not "self-host or buy proprietary," but a third way: a Keycloak core that secures structural sovereignty properties, combined with enterprise-grade operations, lifecycle management, and functional scope. Commercial Open Source – the structural openness of open source without the full operational burden. This should not be confused with simple Keycloak hosting by a third-party provider that merely makes the current Keycloak version available. That usually only exacerbates the problem, as you have even less control over the software while still bearing the responsibility of "the community" yourself. Commercial Open Source goes further by providing essential (operational) extensions and taking responsibility for the open-source core. Fully auditable.

Conclusion

The C3A is not a regulatory sledgehammer. It is a mirror – it makes visible what many organizations feel but have rarely been able to measure. Open source is the structural answer to its criteria. The decisive question is not "open source or not," but: Is the open-source core also operated in an enterprise-ready manner? Sovereignty does not mean building everything yourself. It means avoiding structural dependencies – while still working professionally.

For your next step

→ Download the BSI C3A PDF and discuss it internally – especially sections SOV-3 and SOV-4

→ Use Identity and Access Management as your first test case: Is your IAM portable and auditable?

→ Explicitly include C3A compliance as a criterion in tenders

This article is based on the official BSI document C3A – Criteria enabling Cloud Computing Autonomy, published on April 27, 2026, under the Creative Commons license CC-BY-ND 4.0. All cited criteria are taken from the English-language original.

‍