BSI C5:2026 Is a Technology Forecast

I opened the new C5 and instinctively was searching for the differences to the 2020 version. What I found reads more like a forecast.

When the BSI published C5:2026 this spring, I did what most people with the document on their desk did. I put it next to the 2020 version and started looking for what changed.

The catalogue grew from 124 pages to 222. The criteria count went from 121 to 168, spread across the same seventeen domains as before. Nothing about the architecture changed. What changed is that the BSI took a position on which technologies will define the next five years of cloud risk, and wrote those positions into an auditable standard. Read that way, C5:2026 is less a security update and more a forecast. It tells you what the German state thinks matters next.

What C5 actually is, in twenty lines

C5 is a security criteria catalogue, 168 criteria across seventeen domains in the 2026 version, covering everything from physical data-centre controls to cryptography, identity, and operations. Each criterion now splits into basic criteria, the baseline every audited provider meets, and additional criteria, which come in two flavors: "sharpening", a stricter version of a basic criterion, and "complementing", a new requirement bolted on top. It is voluntary. A provider uses it to demonstrate that its cloud is operated securely, and a customer references it when writing a tender.

The crucial thing to understand is that C5 is an attestation, not a certificate. The BSI writes the criteria and never audits against them. An independent auditor does that and issues either a type 1 report, that the controls are suitably designed at a point in time, or a type 2 report, that they operated effectively over a period, usually a year. The output is a report a customer reads, not a stamp a regulator grants. "C5 certified", the phrase that ends up in procurement templates, is a small convenience fiction. There is no certificate. There is an attestation report, and its scope and exceptions matter more than the headline.

C5 covers security and nothing else. It sets objectives rather than implementations, saying what must be achieved and leaving the how to the provider. It says nothing about who can legally compel access to your data, or whether you can keep running if a foreign supplier is cut off. That is sovereignty, and it is C3A's job, not C5's. The one place the wall between the two is cracking is the new opt-in partition tier, which I come back to below.

The European lineage is worth getting straight. C5:2020 was solid enough that ENISA used it as the basis for the security requirements of the EUCS Substantial level, the middle tier of the stalled pan-European cloud security certification scheme. CEN/CENELEC reworked those requirements, and the BSI folded the result back into the 2026 revision, which it now keeps deliberately compatible with EUCS Substantial. So EUCS and C5 are the same security bar wearing two badges, one pan-European and certificate-based but politically stuck, one German and attestation-based and actually shipping. None of that is sovereignty. The sovereignty requirements people tried to bolt onto EUCS were fought over for three years and stripped out of the draft in 2024. They reappeared separately, in the EU Cloud Sovereignty Framework the Commission published in 2025, which Germany then turned into C3A. C5 is the security floor all of this stands on, which is exactly why my C3A post could presuppose it and never explain it. This is that explanation.

What the BSI decided to bet on

The BSI is unusually direct about this. The introduction lists the key changes, and the first bullet names four areas of "current technical developments and advances": container management, supply chain management, post-quantum cryptography, and confidential computing.

Take post-quantum cryptography. C5:2026 now requires a documented PQC strategy: an inventory of the cryptographic mechanisms in use, each prioritized by the impact and probability of a quantum attack, plus the use of hybrid cryptography that stays secure against both classical and quantum adversaries, plus defined trigger events and transition plans, reviewed at least annually. The catalogue spells out the threat it is defending against by name, "store now, decrypt later", the idea that an adversary harvests encrypted traffic today and decrypts it once a quantum computer exists. It also asks for crypto-agility, the ability to swap a cryptographic mechanism without re-architecting around it, and points to the BSI's own TR-02102-1 for the details. None of this existed in 2020.

Confidential computing gets the same treatment. The 2020 catalogue never mentions it; the 2026 one adds dedicated criteria for it, including a specific requirement for remote attestation, the technically verifiable proof that the code running inside a trusted execution environment is the code you think it is. Container management gets two new criteria of its own, and the general weight of the topic shows in the raw count: mentions of containers and Kubernetes went from eleven to fifty-eight. Supply chain runs through the catalogue too, with software-bill-of-materials requirements referencing the BSI's TR-03183.

These are good calls. I am "so and so" of a lot of European regulatory activity, and I will get to that, but this is not bureaucracy inventing work for itself. Post-quantum migration is a real problem with a real clock on it. Confidential computing and remote attestation are how you actually protect data in use rather than just at rest and in transit. Containers are how cloud software is built now, so a 2020 catalogue that barely acknowledged them was overdue for the update. The BSI built it on top of the EUCS Substantial work, ISO 27001:2022, NIS2, and version 4 of the CSA Cloud Controls Matrix.

AI is not missing, it is frozen in 2021

In 222 pages the term shows up exactly once, and only to say that if you use an AI tool to run a penetration test you have to document it. As a catalogue for securing AI workloads, C5 says nothing. But the BSI is not silent on AI, it put AI in a separate book.

That book is AIC4, the AI Cloud Service Compliance Criteria Catalogue, published in February 2021. It is built as an extension of C5: its first criterion requires a valid C5 attestation before any AI-specific control even applies. So the shape is the one you already know from C3A. C5 is the foundation, AIC4 is the AI story, C3A is the sovereignty story, and each is a separate audit stacked on the same base.

Here is the part that should bother you. The BSI has decided not to update AIC4, and it has said why: the international work on how to test AI is still moving too fast to settle into criteria. I think that is an honest call. A standard can only audit what holds still long enough to be tested, and AI does not hold still. It is harder to pin down than ordinary software, because its security properties resist the model C5 runs on. C5 attests that a control is designed and operating effectively, which assumes the control behaves the same way twice. A model's output is probabilistic, so "the safety filter works" is not a fact you can attest the way you attest that multi-factor authentication is enforced. And the attacks that matter most in 2026, prompt injection that turns retrieved data into instructions, or model extraction that leaks the asset through its own authorized answers, are not the ones a deterministic-software catalogue was written to catch.

So my reading of the AI point is not that the BSI is behind. It is that the BSI runs a catalogue family in which the layer most exposed to the fastest-moving threats is the one frozen five years ago by deliberate choice.

The quiet part: C5 starts importing sovereignty

There is a fifth change alongside the technology bets: the BSI lists "more detailed consideration of multi-tenancy and the technical implementation of sovereignty". C5 has always presented itself as a security baseline. Sovereignty, the question of who can compel access to your data and whether you can operate without a foreign party, lived one layer up, in the framework I wrote about in my post on BSI C3A. It starts pulling some of that logic down into the security catalogue itself.

That is worth pausing on, because security and sovereignty are not the same kind of idea. Security is precise enough to audit. Sovereignty is not: in a qualitative study of seventy-nine EU legal texts, Anand and colleagues found that digital sovereignty suffers from a lack of conceptual agreement. Its scope is steadily expanding while the intensity with which it is enforced narrows. C5 is starting to import a concept that is politically potent and legally fuzzy, and fuzziness is a strange thing to bake into a standard whose whole value is that an auditor can sign it.

The mechanism is a new set of partition criteria, PSS-12. In their opt-in form, they let a customer select a partition where privileged access to production, logging and monitoring, and cryptographic key management are all confined to the geographic boundary of that partition. The same restrictions also extend to any service organization involved in operating the cloud, not just the provider's own staff. That is a sovereignty control wearing a security catalogue's clothing.

Two things to consider: First, it is opt-in. The catalogue is explicit that it "does not require the cloud service provider to offer multiple regions or partitions". The baseline of C5 remains technology-neutral. Second, the heavy version of this logic still lives in C3A, not C5. But the direction of travel is set. The security baseline is beginning to carry the autonomy agenda, and once you see that, the most consequential question about C5:2026 is not about cryptography. It is about supplier choice.

Does the complexity make you safer?

Mostly, the technology bets do. A provider that runs a real PQC migration, attests its trusted execution environments, and keeps an software bill of materials is more secure in 2026 than one that does not, and the catalogue is right to ask for all three. If it were only its technology chapters, I would recommend it without much hesitation.

The cost is not in those chapters. It is in the autonomy overlay the catalogue is starting to foreshadow and that C3A makes explicit. That overlay does not buy you security. It buys you political resilience, the ability to keep running if a foreign jurisdiction turns hostile, and it charges for that resilience in foregone tooling and slower engineering. The BSI is careful never to claim otherwise. Its own framing is that C5 gives customers "a sound basis for making sovereign decisions". That is decision support, not a safety guarantee, and the distinction is easy to lose when an executive writes "must be C5 certified" into a procurement template and treats the checkbox as the end of the conversation. Even heise.de, reviewing the catalogue, noted that official certification is extensive and costly, and therefore mostly within reach of more established companies. The standard becomes a moat as much as a measure.

The macro picture is not encouraging for the strategy this sits inside. Antonio Calcara, studying two decades of European cloud policy, found that between 2017 and 2022 European providers grew revenue by 167 per cent and still lost 14 per cent of market share, while Amazon, Microsoft, and Google climbed past 72 per cent of the European market. A run of sovereignty initiatives has not loosened the dependence it was built to cure.

My take is simple: Opt into the sovereignty tier if you must, when a customer or the regulator leaves you no choice. Do not opt in if you can avoid it. The technology chapters of C5:2026 are Europe doing the right thing on the frontier, and you should adopt them on their merits, certificate or not. The autonomy overlay is a different bargain, and its full version lives one layer up in C3A. Take it on voluntarily and you carry deadweight you did not need, while cutting yourself off from tools and angles that are almost certainly relevant to the problem you are actually trying to solve.

I have spent more time than is probably healthy reading these catalogues line by line lately, and I have opinions about where the line between security and sovereignty should actually fall. I am happy to talk it through. You can find me on LinkedIn or reach me via mail.