Germany’s KRITIS framework for protecting critical infrastructure has just gone through its most significant overhaul in a decade. The NIS2 Implementation Act — Gesetz zur Umsetzung der NIS-2-Richtlinie, or NIS2UmsG — entered into force on 6 December 2025, substantially revising the BSI Act (BSIG) that has governed IT security obligations for critical infrastructure operators since 2009.
For organisations operating in sectors like energy, water, healthcare, transport, or IT and telecommunications, this is not a minor update. The scope of who is regulated, what they must do, and how they must prove it has changed in concrete ways. This article explains what has changed, what stays the same, and what it means in practice when choosing a cloud platform.
What KRITIS Is and What It Now Means Under the New Law
KRITIS — short for Kritische Infrastrukturen — is the German federal designation for critical infrastructure. Operators of KRITIS-relevant facilities have long been subject to specific IT security obligations under the BSIG, overseen by the BSI (Bundesamt für Sicherheit in der Informationstechnik).
Under the new law, the terminology has shifted. The revised BSIG no longer speaks of “Kritische Infrastrukturen” as the primary category. Instead, it regulates besonders wichtige Einrichtungen (particularly important entities) and wichtige Einrichtungen (important entities). Operators of what are now called kritische Anlagen (critical facilities) are a subset of the first group and still face the most stringent requirements. The obligations they held under the previous BSIG are largely carried forward, but restructured and, in some areas, tightened.
The sectors covered remain broadly the same: energy, transport, finance, health, water, food, IT and telecommunications, space, and waste management. What has changed is the threshold logic, some sector-specific rules, and the overall scope of who is caught by the framework — not just KRITIS operators, but tens of thousands of organisations across the broader NIS2 categories.
One notable structural change: the finance sector has been split into two — Finanzwesen (Finance) and Leistungen der Sozialversicherung sowie Grundsicherung für Arbeitsuchende (Social benefits and basic income for jobseekers). Private insurance providers are no longer included. Organisations subject to the EU’s DORA regulation are exempted from certain BSIG reporting and audit obligations, as the two frameworks overlap significantly.
What Operators of Critical Facilities Must Now Do
For operators of kritische Anlagen, the core obligations — registration, incident reporting, implementing appropriate technical and organisational measures, and providing regular evidence of compliance — remain in place. But several details have changed.
Registration is now two-track. Existing KRITIS operators must register not only in the existing MIP portal (Melde- und Informationsportal), which they have used until now, but also as a besonders wichtige Einrichtung in the new BSI portal. The deadline for those already registered is three months from 6 December 2025 — that is, 6 March 2026. New operators must do both registrations from the outset.
The audit cycle has lengthened. Previously, operators had to submit compliance evidence every two years. Under the new BSIG, the cycle is every three years. The BSI has directly notified existing operators of their new individual deadlines.
Incident reporting follows the NIS2 structure. The previous KRITIS reporting obligation is now fully absorbed into the NIS2 framework. Operators who report via MIP do not need to duplicate the report in the BSI portal — the BSI has confirmed this transitional arrangement will remain in place at least until 31 July 2026.
Attack detection systems remain mandatory. The requirement to deploy systems capable of detecting security-relevant events — introduced by IT-SiG 2.0 in 2021 — is carried forward under §31 BSIG for operators of critical facilities specifically. The BSI has published guidance on what these systems must be able to do (Orientierungshilfe zum Einsatz von Systemen zur Angriffserkennung), available via the BSI downloads page.
Shared contact points (GÜAS) are abolished. Operators who previously shared a common contact structure with peers in the same sector must now each maintain their own direct contact arrangements with the BSI.
Why Cloud Platform Choice Is a KRITIS Compliance Decision
The revised BSIG explicitly requires operators to assess the trustworthiness of their technology suppliers — including the platforms on which their critical workloads run. This is not new, but it is now more formally embedded in the framework. For cloud infrastructure specifically, this raises questions that go beyond certifications and SLAs.
Hyperscale public cloud platforms — AWS, Azure, GCP — carry structural characteristics that are difficult to reconcile with KRITIS requirements. Data routing decisions are made dynamically, making it technically difficult to guarantee that data never leaves Germany or the EU. Their internal systems — hypervisors, networking stacks — cannot be independently audited, which creates friction with supply chain assessment requirements. And US-headquartered providers remain subject to the CLOUD Act (18 U.S.C. § 2713), which can compel data disclosure regardless of where data is stored — a direct conflict with data sovereignty obligations under the BSIG framework.
None of this means a hyperscaler cannot be part of an operator’s infrastructure. But it does mean that for workloads classified as critical, the platform question carries regulatory weight, not just operational weight.
What to Look for in a Compliant Cloud Platform
Based on the requirements set out in the revised BSIG and BSI guidance, a cloud platform supporting KRITIS-regulated workloads needs to demonstrably address several areas:
High availability by architecture — not just contractually promised uptime, but redundancy built into compute, storage, and networking layers, with no single points of failure.
On-premises or private deployment with full data residency control — the operator must be able to verify where data is processed and stored, with no undisclosed external routing.
Encryption at rest and in transit, key management under the operator’s control, and strict network segmentation between tenants.
Attack detection capability that meets the BSI’s guidance — real-time monitoring, anomaly detection, and integration with SIEM tooling.
Full audit logging — every API call, every configuration change, every administrative action, exportable for BSI inspection and the three-yearly compliance evidence submission.
An auditable software supply chain — open-source foundations with a published software bill of materials (SBOM), so operators can conduct the trustworthiness assessment the law requires.
How FishOS Addresses KRITIS Requirements
FishOS, developed by Sardina Systems, is a cloud management platform that integrates OpenStack, Kubernetes, and Ceph into a single automated stack. It is designed for on-premises and private cloud deployment, which means operators retain direct control over where their data resides and is processed — with no dependency on external cloud infrastructure or foreign jurisdiction.
On the availability side, FishOS includes a proprietary Health Monitoring Component that continuously analyses real-time metrics and log data. According to Sardina Systems, it uses what they describe as a “computer immunology” approach — identifying not just failed states but degraded “sick” states before they cause outages. This is distinct from conventional monitoring tools.
On the security and audit side, FishOS provides centralised audit logging covering user and system-level actions across the infrastructure, and supports SIEM integration. According to third-party reviews of the platform, FishOS includes an integrated SIEM capability for detecting and responding to security threats within the environment.
On supply chain transparency, FishOS is built on open-source components — OpenStack, Ceph, Kubernetes — with publicly auditable codebases. Sardina Systems provides SBOM documentation, which directly supports the supply chain trustworthiness assessment required under the revised BSIG.
FishOS supports migration from VMware and other legacy platforms through its FishOS Move It appliance, using either a minimal-downtime approach or change block tracking (CBT) for live environments. Both methods have a proven track record at production sites.
FishOS provides the architectural foundation — on-premises sovereignty, open-source auditability, high availability, and the operational tooling — that operators need to build and demonstrate compliant infrastructure.
Where to Start with KRITIS
If your organisation is potentially in scope under the revised BSIG — either as an existing KRITIS operator or as a newly regulated entity under the NIS2 categories — the immediate priorities are:
First, verify whether you qualify as a Betreiber kritischer Anlagen under the updated BSI-KritisV, or as a besonders wichtige or wichtige Einrichtung under the broader NIS2 framework. The BSI has published a self-assessment tool for this purpose.
Second, if you are already registered in MIP as a KRITIS operator, initiate registration in the new BSI portal as a besonders wichtige Einrichtung before 6 March 2026.
Third, assess your current infrastructure against the technical requirements of §30 and 31 BSIG — particularly around attack detection, audit logging, and supply chain documentation.
