BSI C5, Post-Quantum Crypto and Confidential Computing: What German Cloud Platforms Need Running in 2026

Key points:

• BSI C5 is the Cloud Computing Compliance Criteria Catalogue of Germany's Federal Office for Information Security (BSI), and C5:2026 is published. It has 168 criteria in 17 domains plus six general conditions, and it applies to audit periods beginning on or after 1 June 2027 (BSI C5:2026). C5 is an auditor's attestation under ISAE 3000 / IDW PS 951. BSI certifies nothing.
• Post-quantum cryptography is now in C5. CRY-01 makes crypto-agility a basic criterion and adds an optional PQC strategy (inventory, hybrid cryptography, transition plan). The standards behind it are BSI TR-02102-1 (2026-01) and FIPS 203, 204 and 205, which NIST published on 13 August 2024.
• Post-quantum readiness for a cloud platform is mostly a TLS and key-management project. Hybrid X25519MLKEM768 is the default in Chrome, Firefox and OpenSSL 3.5. It already protects about 70% of browser traffic to Cloudflare (Cloudflare, September 2026).
• Confidential computing has its own C5 criteria: OPS-32 (policies and the TEE framework) and OPS-33 (remote attestation). On managed Kubernetes it exists today as Confidential GKE Nodes and AKS confidential VM node pools. On AWS it means SEV-SNP EC2 instances and Nitro Enclaves. For most teams the work is node pool configuration plus attestation plumbing.
• Type 2 controls must run, with evidence, from the first day of the observation period (3 to 12 months). If you want a C5:2026 report in 2027, 2026 is your build year. Running your platform in your own AWS, GCP, Azure or Scaleway account, or your own Kubernetes cluster, keeps keys, logs and regions inside attestations you already hold.

German enterprises now ask their cloud vendors to prove things about cryptography and memory encryption that most platform teams have never inventoried. BSI wrote those questions into C5:2026 this spring.

The deadline also comes sooner than most people expect. A Type 2 attestation covers controls that operated over a past period. So the controls behind a 2027 report have to be designed, deployed and logging well before the auditor arrives. I've seen teams lose an audit cycle over exactly this, and it's avoidable.

What is BSI C5, and which version is actually published in 2026?

BSI C5 is the Cloud Computing Compliance Criteria Catalogue published by Germany's Bundesamt für Sicherheit in der Informationstechnik, and the current edition is C5:2026. BSI published it as a community draft and then as a final version by the end of March 2026. The machine-readable release is dated 7 April 2026 (BSI C5:2026). It replaces C5:2020, which had 121 criteria in 17 domains and itself replaced C5:2016.

Plenty of guides still describe C5:2026 as upcoming. Every control ID I quote below comes from the published C5:2026 PDF.

Lineage. C5:2020 added two domains, Dealing with Investigation Requests from Government Agencies (INQ) and Product Safety and Security (PSS). C5:2026 keeps the 17 domains and renames identity management to IAM. It adds six general conditions (GC-01 to GC-06) covering jurisdiction, availability and certifications. BSI lists its new focus areas as container management, supply chain, post-quantum cryptography, confidential computing, client separation and the technical side of sovereignty.

Structure. Each criterion now splits into subcriteria. Basic subcriteria are the baseline. Additional subcriteria are either "sharpen" (they replace a basic one with a stricter version) or "complement" (they add a new requirement on top). A provider can add individual additional subcriteria to its audit scope, but the report must say why it picked them.

Who is bound in practice. Cloud processing of German health data under § 393 SGB V has required a current C5 Type 2 attestation on the basic criteria since 1 July 2025. Public-sector buyers, BaFin-supervised financial institutions and large enterprises put C5 into vendor questionnaires as standard. BSI also recommends that customers request their provider's C5 report and analyse it every year.

Who already holds C5.

• AWS lists Frankfurt, Ireland, London, Paris, Milan, Stockholm, Zurich, Spain and Singapore in scope (AWS BSI C5).
• Google Cloud holds a C5:2020 attestation (Google Cloud).
• Microsoft assesses C5:2020 within its Azure SOC 2 Type 2 programme (Microsoft Learn).
• STACKIT claims Type 2 across all basic and additional criteria (STACKIT).
• Open Telekom Cloud lists C5 Type II (T Cloud Public).
• IONOS received a C5:2020 Type 1 in May 2026 (IONOS).

As of 1 November 2026, none of these pages announces a C5:2026 attestation.

Why would BSI add post-quantum cryptography and confidential computing to C5 now?

BSI added them because the rest of the standards world already moved. BSI's own TR-02102-1 (version 2026-01) recommends classical-only key agreement only until the end of 2031. NIST IR 8547, final since 27 October 2026, deprecates RSA and elliptic-curve schemes after 2030 and disallows them after 2035.

What C5:2026 actually asks for.

• CRY-01.01B (basic) requires a cryptography policy that covers "crypto-agility to allow for efficient substitution of implemented cryptographic mechanisms".
• CRY-01.02B (basic) requires checking that policy against TR-02102 or NIST guidance.
• CRY-01.01AC to 03AC (additional) require a documented PQC strategy. It must include a prioritised cryptographic inventory, use of hybrid cryptography, trigger events and transition plans, and an annual review.

Hybrid, not replacement. TR-02102-1 "currently only recommends the hybrid use" of quantum-safe schemes alongside classical ones, naming ML-KEM-768/1024 and FrodoKEM-976/1344. The joint statement from 18 EU member states of 27 November 2024, signed by BSI and ANSSI among others, says the same. In TLS terms, you keep X25519 and add ML-KEM alongside it.

EU dates. The NIS Cooperation Group's coordinated PQC roadmap (June 2025) has three milestones. First steps and national roadmaps by end of 2026, high-risk use cases migrated by end of 2030, and medium-risk ones by end of 2035.

Harvest now, decrypt later in German terms. § 257 HGB keeps books and annual statements for 10 years, and so does § 147 AO for tax-relevant records. § 630f BGB keeps patient records for 10 years after treatment. A ledger written in 2026 must stay confidential until 2036, past NIST's 2035 cutoff. The Global Risk Institute's 2025 report puts a cryptographically relevant quantum computer at 28 to 49% likely within ten years.

Confidential computing closes the "data in use" gap. Encryption at rest and in transit does nothing while a process holds plaintext in memory, and that is where operator access and foreign legal requests (the US CLOUD Act being the one German buyers raise) bite. In a hardware TEE, the provider cannot read your memory. That is exactly what OPS-32.03B requires: that "neither the cloud service provider nor any other unauthorised entity shall be able to access the cloud service customer data or the keys".

Both topics end up as the same engineering problem: crypto-agility. You decide it once at the platform layer, or you fight it in every repository.

What does post-quantum readiness actually require from a cloud platform?

Post-quantum readiness means four things: a cryptographic inventory, hybrid key exchange wherever TLS terminates, a dated plan for signatures and PKI, and crypto-agility written into the architecture. Most of this does not touch application code. OpenSSL 3.5.0 (8 April 2025) offers X25519MLKEM768 by default (OpenSSL), so every terminator built on it gets hybrid TLS without new code.

Step 1: the cryptographic bill of materials. List every TLS terminator (CDN, load balancer, ingress controller, service mesh), every KMS or HSM key, every signing key, every VPN and private link, every backup encryption key and every pinned certificate. NIST's SP 1800-38 (still a preliminary draft) found that each discovery tool reports in its own format. Budget time to normalise the output, because the scan itself is the easy part. This inventory is the exact artefact CRY-01.02AC asks for.

Step 2: turn on hybrid key exchange where it already works.

• Chrome 124 enabled Kyber by default and Chrome 131 moved to ML-KEM (Google). Firefox 132 shipped mlkem768x25519 (Mozilla).
• On the server side, AWS ALB and NLB "PQ" security policies, CloudFront and Google Cloud Load Balancing all support X25519MLKEM768.
• The cost is small but not zero. Chrome measured a 4% slowdown in TLS handshake time from about 1.1 kB of extra data per direction (Cloudflare).

Step 3: signatures and PKI come later, but they need a date. ML-DSA and SLH-DSA mean larger certificates and chains, which affects handshake size and code signing. AWS KMS has offered ML-DSA keys since June 2025 (AWS), so you can start testing code signing now. Don't make the key-exchange rollout wait for this.

Step 4: make crypto-agility an architecture requirement. Cipher suites and key specs belong in platform configuration as code, not in each service's TLS library. Then a swap is a single change with a single review.

Honest limits. Managed databases, third-party SaaS, embedded clients and hardware appliances will lag behind. Write them down as dated exceptions with compensating controls. CRY-01's risk-based approach accepts a dated plan, and auditors penalise silence. Your auditor will ask for four things: the inventory, the key rotation logs, the cipher configuration as code, and the transition plan tied to the EU and NIST dates.

Can you actually run Kubernetes on confidential computing today, and on which clouds?

Yes, you can run Kubernetes on confidential computing today. Confidential GKE Nodes have been GA since June 2022, and AMD SEV-SNP and Intel TDX became GA on GKE on 27 May 2025 (GKE release notes). AKS runs confidential VM node pools on AMD SEV-SNP (Microsoft Learn). AWS offers SEV-SNP EC2 instances and Nitro Enclaves. For most teams this is a node pool change plus attestation work.

The three states of data. At rest is covered by disk and KMS encryption, and in transit by TLS. "In use" needs a TEE. The CPU-level options are AMD SEV-SNP, Intel TDX, Intel SGX and ARM CCA, and NVIDIA H100 GPUs add a confidential mode for AI workloads.

Remote attestation is what the auditor wants to see. OPS-33 requires attestation "rooted in trusted hard- and software" and an interface the customer can use to verify it. C5 ranks the setups. When the customer retrieves evidence and verifies it in its own trusted environment, C5 calls that "very strong". When the provider verifies and only hands back a result, C5 calls it "weak". Decide where your evidence is produced, stored, retained and reviewed. That trail is the operating evidence for a Type 2 report.

Trade-offs with numbers.

• Google says the overhead ranges "from nothing to minimal" depending on workload (Google). An H100 study measured under 7% for typical LLM queries (arXiv).
• Pricing differs by cloud. Google charges a per-vCPU and per-GiB surcharge (pricing). AWS adds 10% for SEV-SNP on shared tenancy (AWS). Azure's DC4as_v5 costs the same as D4as_v5 in Germany West Central ($0.208/h, Azure Retail Prices API, read 1 November 2026).
• Instance families are restricted, and most managed databases have no confidential option at all.

Scope it. Put confidential node pools under workloads that process regulated personal data or secrets, not under the whole estate. Record that scoping decision, because it is your OPS-32.01B evidence.

The operational cost. Confidential nodes use different images and stricter OS support. On GKE, once you enable the feature at cluster level you can't turn it off. Without live migration, nodes go NotReady during host maintenance. Upgrades get harder, and OPS-32.01AC explicitly requires regular updates to the TEE's trusted computing base.

What should a German enterprise do before a 2027 C5 report, and in what order?

Work backwards from the observation window, not the report date. Under section 3.5 of C5:2026, C5:2026 applies to Type 2 periods beginning on or after 1 June 2027. A period that begins earlier and ends later stays entirely on C5:2020, with no mixing. Every control must operate from the first day of a period that runs at least three months.

Two details pull the work into 2026. First, if your C5:2020 period ends on or after 28 February 2027, your system description must already list your planned control changes. Second, BSI's own web page phrases the rule as periods ending on or after 1 June 2027, which differs from the catalogue. Agree the interpretation with your auditor in writing, and plan for the earlier one.

Sequence. Inventory first, then hybrid TLS at the edge and ingress, then KMS and rotation policy, then confidential node pools for in-scope workloads, then the attestation evidence pipeline, then an auditor dry run.

Evidence artefacts you will be asked for. The cryptographic inventory, key rotation logs, node pool configuration as code, enclave attestation reports, change records (CRY-02 and DEV-03), access logs, and RBAC assignments per environment.

The shared responsibility split is where audits stall. C5 lists "corresponding" criteria that the customer must meet at the interface to each cloud service. § 393 SGB V requires those customer-side criteria to be implemented. Get your provider's C5 report early, map every corresponding criterion to an owner, and file the report in your evidence pack.

Sovereignty controls. These are EU regions, EU-based support staff, key custody (BYOK under CRY-19, external KMS under CRY-18), and a control plane with a small blast radius. GC-01 now requires providers to disclose applicable law, jurisdiction and locations.

The failure mode I see most. A team designs its controls well but switches on logging and attestation collection a month before the audit. Design without operating evidence fails Type 2.

How does your platform choice change your C5 audit scope?

Your platform layer has more influence on audit scope than any other decision. A multi-tenant PaaS that runs workloads in its own cloud account adds a third party and its sub-processors to your scope (SSO criteria), and you usually can't choose confidential node pools there. A platform that deploys into your own account keeps the infrastructure, keys, logs and regions inside the contracts and C5 attestations you already hold.

There are three real models. You can build on a hyperscaler with an in-house platform team, which gives full control but costs headcount. You can use a multi-tenant PaaS such as Heroku, Render or Vercel, which starts fastest but runs your code in the vendor's infrastructure. Or you can run a BYOC or self-hosted internal developer platform, where workloads stay in your own account and you inherit your cloud provider's C5 attestation for the IaaS underneath.

Where Qovery fits. Qovery is an internal developer platform that deploys into your own AWS, GCP, Azure or Scaleway account, or onto your existing Kubernetes cluster. EU region choice, KMS keys and ingress TLS settings stay under your control. On your own cluster, confidential node pools are yours to configure. On Qovery-managed clusters, check which instance types are supported before you plan around them.

Developers get git-push deployments, a preview environment per pull request, auto-stop for non-production environments, managed cluster upgrades, RBAC per environment, and databases backed by managed cloud services. Your team runs Kubernetes without operating it directly, and you can ship without a dedicated DevOps hire.

The honest limit. No platform makes you C5 compliant, and Qovery doesn't hold a C5 attestation. What a BYOC platform gives you is a smaller audit scope and fewer third-party dependencies.

On competitors.

• Upsun (Platform.sh) offers EU regions, including Germany (Upsun).
• Northflank (BYOC) and Porter also deploy into your own cloud account.
• Humanitec and Backstage are toolkits you assemble yourself, and you still own Kubernetes.
• Cycloid positions itself as an IDP with a strong European public-sector story.

German buyers often prefer a sovereign provider: STACKIT, Delos Cloud (SAP's Azure-based sovereign cloud for the public sector), IONOS, OVHcloud or Open Telekom Cloud. Bitkom's 2026 Cloud Report found 98% of German companies say the provider's country of origin matters. With a sovereign provider you give up managed service breadth, regional footprint and tooling maturity, and confidential computing is often bare-metal-only or on request.

How do I inspect and harden my clusters for this from Claude Code or Cursor?

Install the Qovery Agent Skills once, and your coding agent can inspect, deploy and optimise environments in your own cloud account from plain-language prompts. The MCP Server is read-only by default, and you approve every write action.

curl -fsSL https://skill.qovery.com/install.sh | bash

# Or scoped to this repository only
curl -fsSL https://skill.qovery.com/install.sh | bash -s -- --project

# Qovery MCP Server in Claude Code (OAuth, read-only by default)
claude mcp add --transport http qovery https://mcp.qovery.com/mcp --callback-port 4242

# Write access, only when you want it (also enable it in the Qovery Console)
claude mcp add --transport http qovery "https://mcp.qovery.com/mcp?read_write=true" --callback-port 4242

The skills (qovery-onboard, qovery-deploy, qovery-preview, qovery-troubleshoot, qovery-optimize, qovery-speedup, qovery-terraform) handle setup and deployment, and the MCP Server operates what already exists. Then ask, for example: "deploy this service to my own AWS eu-central-1 account with Qovery and show me the ingress TLS configuration". See the AI agent quickstart and the Claude Code integration.

An agent speeds up configuration and review. Attestation evidence, control narratives and auditor sign-off are still human work.