KRITIS in the Cloud: What Secures the Migration

29 June 2026

6 min read

Since March 17, 2026, the KRITIS Omnibus Act has been in effect. Companies migrating sensitive systems to the cloud must now consider availability, data sovereignty, and compliance obligations from the outset. The migration process will determine whether a future audit becomes a formality or a major headache.

Key Takeaways

The scope expands: Over 30,000 companies now fall under enhanced security obligations due to the NIS2 Implementation Act, with many classifying themselves as important or critical entities for the first time.
C5 gets tougher: The new C5:2026 criteria catalog includes 168 requirements-up from 121-and explicitly addresses containers, supply chain security, and confidential computing for the first time. It becomes mandatory on June 1, 2027.
Order beats speed: Clarifying protection needs before choosing a provider avoids costly rework. Architecture and exit planning determine whether migration remains a compliance burden or becomes a resilience advantage.

Assess Protection Needs Before Choosing a Provider

What is KRITIS? Critical Infrastructure refers to facilities whose failure would endanger public supply-such as energy, water, healthcare, finance, or transportation. Operators are subject to special security and reporting obligations. Since the NIS2 Implementation Act and the KRITIS Omnibus Act, significantly more companies are affected than before.

The most common-and most costly-approach is to pick a hyperscaler first, then ask what needs protecting. For KRITIS operators, this logic is reversed. The starting point is classifying each workload based on protection requirements, criticality to the supply mission, and recovery time objectives. A billing system handling personal data has different needs than an internal wiki. This distinction later determines the deployment model.

In practice, this means categorizing data and services into three classes: What can run in a public region? What requires a sovereign environment? What should remain in-house for now? Drawing this map before the first migration ticket is issued means negotiating with providers based on concrete requirements-not marketing slides.

Data Residency: Where Workloads Actually Reside

Selecting an EU region from a dropdown menu doesn’t guarantee data sovereignty. What matters is who has technical and legal access to the data, where the provider is based, and whether support or maintenance is handled from third countries. For sensitive KRITIS workloads, the key questions are: Who holds the encryption keys-the provider or the customer? Can the provider’s access be technically blocked, for example, through confidential computing or customer-held keys?

The C5:2026 catalog takes these points more seriously than its predecessor. With 168 requirements instead of 121, it now explicitly addresses container management, supply chain security, and confidential computing as distinct focus areas. For migration, this means data residency is an architectural issue that ties together encryption, key management, and operational models. A checkbox on a procurement form won’t cut it.

168 criteria

in the new C5:2026 catalog-up from 121 in the previous version. Mandatory from June 1, 2027, with early adoption recommended.

Source: BSI, C5:2026

A C5 Attestation Opens the Door-Nothing More

A provider’s C5 attestation is often the entry ticket for procurement close to KRITIS. It proves the vendor meets the catalog requirements, but says nothing about whether your own configuration actually leverages that security. Cloud security is a shared responsibility: the provider delivers the attested platform, while the operator configures identities, network segmentation, and logging. A flawless attestation won’t protect you from an exposed storage bucket.

When selecting a provider, a clear-eyed comparison of operating models pays off. Each has its place, depending on the protection class identified in step one.

Operating Model	KRITIS Suitability	Trade-off
Public Cloud, EU Region	Medium to high, depending on key sovereignty	Scalability vs. provider access and third-country risks
Sovereign Cloud	High, with local operations and staff	Data sovereignty vs. narrower service catalog and higher costs
Hybrid with In-House Core	High for the most critical workloads	Full control vs. operational overhead and integration burden

The Exit Plan Determines Availability

For KRITIS, availability carries the weight of the supply mandate. If the service fails, supply fails. A cloud migration only improves resilience if the contingency plan comes before the business-as-usual plan. That starts with lock-in: How quickly can a service be shifted to a second provider or back to your own data center if the vendor fails, prices spike, or an authority demands it?

Building critical services on portable components-like containers and standardized interfaces instead of proprietary managed services-keeps the escape route open. Multi-cloud pays off precisely where the failure of a single provider would jeopardize the supply mandate. For non-critical services, it remains an expensive overhead.

// Core Statement

A migration with no way back only shifts dependency-it doesn’t reduce it.

The Audit Starts Before Migration

Proof of compliance is where good architecture either shines or falls short. Affected organizations must register with the BSI. Under the KRITIS Dachgesetz, physical resilience will require a second registration with the BBK, with a deadline of July 17, 2026. If you only implement logging, asset inventories, and incident processes after migration, you’re documenting gaps-not control.

That’s why evidence gathering belongs in the migration plan: centralized logging, a maintained directory of outsourced services, and clear reporting channels from day one. Then, the audit at the end simply pulls a report from ongoing operations.

Frequently Asked Questions

Are KRITIS operators even allowed to move sensitive data to the public cloud?

There is no blanket ban. What matters are the protection requirements, key sovereignty, and an operating model that limits provider access. Highly critical workloads tend to end up in sovereign or hybrid environments, while less sensitive services can run in an EU region with customer-held keys.

Is a provider’s C5 attestation sufficient for compliance?

It’s a prerequisite for many tenders, but it doesn’t replace your own audit. The attestation refers to the provider’s certification status at a given point in time. If you use it, check the scope: Which services, regions, and cut-off date are covered? No provider checks your own configuration.

What changes with C5:2026 compared to the previous version?

The catalogue expands from 121 to 168 criteria and now explicitly addresses container management, supply chain security, post-quantum cryptography, and confidential computing. Monitoring and incident management requirements are stricter. C5:2026 becomes mandatory on 1 June 2027, but early adoption is recommended.

By when do affected organisations need to register?

Registration with the BSI must be completed no later than three months after a company first meets the criteria. For physical resilience under the KRITIS umbrella law, an additional registration with the BBK is required, with a deadline of 17 July 2026.

Why is an exit plan so critical for KRITIS migration?

In the KRITIS environment, a single provider can itself become a risk. Without a tested fallback, a provider outage or contract termination directly extends your downtime. The exit plan must be tested: Regular dry runs show whether the transition back can be completed within the required recovery time.