Deutschlands KRITIS-Rahmenwerk zum Schutz kritischer Infrastrukturen hat gerade seine umfassendste Überarbeitung seit einem Jahrzehnt erfahren. Das NIS2-Umsetzungsgesetz — Gesetz zur Umsetzung der NIS-2-Richtlinie, kurz NIS2UmsG — ist am 6. Dezember 2025 in Kraft getreten und hat das BSI-Gesetz (BSIG), das seit 2009 die IT-Sicherheitsanforderungen für Betreiber kritischer Infrastrukturen regelt, grundlegend überarbeitet.
Für Organisationen in Sektoren wie Energie, Wasser, Gesundheitswesen, Verkehr oder IT und Telekommunikation ist dies kein kleines Update. Der Kreis der Regulierten, ihre Pflichten und der Nachweis der Umsetzung haben sich konkret verändert. Dieser Artikel erläutert, was sich geändert hat, was gleich bleibt und was das in der Praxis bei der Wahl einer Cloud-Plattform bedeutet.
Was KRITIS ist und was es nach dem neuen Gesetz bedeutet
KRITIS — kurz für Kritische Infrastrukturen — ist die bundesweite Bezeichnung für kritische Infrastruktur. Betreiber KRITIS-relevanter Anlagen unterliegen seit Langem spezifischen IT-Sicherheitsanforderungen nach dem BSIG, beaufsichtigt durch das BSI (Bundesamt für Sicherheit in der Informationstechnik).
Mit dem neuen Gesetz hat sich die Terminologie verschoben. Das überarbeitete BSIG spricht nicht mehr von „Kritischen Infrastrukturen“ als primärer Kategorie. Stattdessen regelt es besonders wichtige Einrichtungen (particularly important entities) und wichtige Einrichtungen (important entities). Betreiber der nun sogenannten kritischen Anlagen (critical facilities) sind eine Teilmenge der ersten Gruppe und unterliegen weiterhin den strengsten Anforderungen. Die Pflichten aus dem bisherigen BSIG werden weitgehend fortgeführt, jedoch neu strukturiert und in einigen Bereichen verschärft.
Die erfassten Sektoren bleiben weitgehend gleich: Energie, Verkehr, Finanzen, Gesundheit, Wasser, Lebensmittel, IT und Telekommunikation, Raumfahrt sowie Abfallwirtschaft. Geändert haben sich die Schwellenlogik, einige sektorspezifische Regeln und der Gesamtumfang der vom Rahmenwerk erfassten Organisationen — nicht nur KRITIS-Betreiber, sondern Zehntausende Organisationen in den breiteren NIS2-Kategorien.
Eine auffällige strukturelle Änderung: Der Finanzsektor wurde in zwei Bereiche aufgeteilt — Finanzwesen (Finance) und Leistungen der Sozialversicherung sowie Grundsicherung für Arbeitsuchende (Social benefits and basic income for jobseekers). Private Versicherungsanbieter sind nicht mehr enthalten. Organisationen, die der EU-DORA-Verordnung unterliegen, sind von bestimmten Melde- und Auditpflichten nach dem BSIG ausgenommen, da sich beide Rahmenwerke erheblich überschneiden.
Was Betreiber kritischer Anlagen jetzt tun müssen
Für Betreiber von kritischen Anlagen bleiben die Kernpflichten — Registrierung, Meldung von Vorfällen, Umsetzung angemessener technischer und organisatorischer Maßnahmen sowie regelmäßiger Compliance-Nachweis — bestehen. Mehrere Details haben sich jedoch geändert.
Die Registrierung erfolgt jetzt zweigleisig. Bestehende KRITIS-Betreiber müssen sich nicht nur wie bisher im MIP-Portal (Melde- und Informationsportal) registrieren, sondern zusätzlich als besonders wichtige Einrichtung im neuen BSI-Portal. Die Frist für bereits registrierte Betreiber beträgt drei Monate ab dem 6. Dezember 2025 — also bis zum 6. März 2026. Neue Betreiber müssen beide Registrierungen von Anfang an vornehmen.
Der Audit-Zyklus wurde verlängert. Bisher mussten Betreiber alle zwei Jahre einen Compliance-Nachweis einreichen. Nach dem neuen BSIG erfolgt dies alle drei Jahre. Das BSI hat bestehende Betreiber direkt über ihre neuen individuellen Fristen informiert.
Die Vorfallmeldung folgt der NIS2-Struktur. Die bisherige KRITIS-Meldepflicht geht nun vollständig im NIS2-Rahmenwerk auf. Betreiber, die über MIP melden, müssen die Meldung nicht zusätzlich im BSI-Portal einreichen — das BSI hat bestätigt, dass diese Übergangsregelung mindestens bis zum 31. Juli 2026 bestehen bleibt.
Systeme zur Angriffserkennung bleiben verpflichtend. Die Pflicht zum Einsatz von Systemen, die sicherheitsrelevante Ereignisse erkennen können — eingeführt durch IT-SiG 2.0 im Jahr 2021 — wird für Betreiber kritischer Anlagen speziell unter §31 BSIG fortgeführt. Das BSI hat eine Orientierungshilfe dazu veröffentlicht, was diese Systeme leisten müssen (Orientierungshilfe zum Einsatz von Systemen zur Angriffserkennung), abrufbar über die Download-Seite des BSI.
Gemeinsame Ansprechstellen (GÜAS) werden abgeschafft. Betreiber, die zuvor eine gemeinsame Kontaktstruktur mit anderen Akteuren desselben Sektors genutzt haben, müssen nun jeweils eigene direkte Kontaktregelungen mit dem BSI vorhalten.
Warum die Wahl der Cloud-Plattform eine KRITIS-Compliance-Entscheidung ist
Das überarbeitete BSIG verpflichtet Betreiber ausdrücklich, die Vertrauenswürdigkeit ihrer Technologielieferanten zu bewerten — einschließlich der Plattformen, auf denen ihre kritischen Workloads laufen. Das ist nicht neu, aber nun formaler im Rahmenwerk verankert. Speziell für Cloud-Infrastruktur wirft das Fragen auf, die über Zertifizierungen und SLAs hinausgehen.
Hyperscale-Public-Cloud-Plattformen — AWS, Azure, GCP — bringen strukturelle Eigenschaften mit, die sich nur schwer mit KRITIS-Anforderungen vereinbaren lassen. Entscheidungen zur Datenweiterleitung werden dynamisch getroffen, wodurch es technisch schwierig ist zu garantieren, dass Daten Deutschland oder die EU nie verlassen. Ihre internen Systeme — Hypervisoren, Netzwerk-Stacks — können nicht unabhängig auditiert werden, was zu Reibung mit Anforderungen an die Bewertung der Lieferkette führt. Und Anbieter mit Hauptsitz in den USA unterliegen weiterhin dem CLOUD Act (18 U.S.C. § 2713), der eine Datenherausgabe unabhängig vom Speicherort erzwingen kann — ein direkter Konflikt mit den Datensouveränitätsanforderungen im BSIG-Rahmenwerk.
All dies bedeutet nicht, dass ein Hyperscaler nicht Teil der Infrastruktur eines Betreibers sein kann. Es bedeutet jedoch, dass bei als kritisch eingestuften Workloads die Plattformfrage regulatorisches Gewicht hat — nicht nur operatives.
Worauf Sie bei einer konformen Cloud-Plattform achten sollten
Auf Basis der Anforderungen des überarbeiteten BSIG und der BSI-Leitlinien muss eine Cloud-Plattform für KRITIS-regulierte Workloads nachweislich mehrere Bereiche abdecken:
Hohe Verfügbarkeit durch Architektur — nicht nur vertraglich zugesicherte Uptime, sondern Redundanz in Compute-, Storage- und Netzwerkebenen, ohne Single Points of Failure.
On-Premises- oder Private-Deployment mit vollständiger Kontrolle über die Datenresidenz — der Betreiber muss verifizieren können, wo Daten verarbeitet und gespeichert werden, ohne nicht offengelegte externe Weiterleitung.
Verschlüsselung im Ruhezustand und bei der Übertragung, Schlüsselmanagement unter Kontrolle des Betreibers sowie strikte Netzwerksegmentierung zwischen Mandanten.
Fähigkeit zur Angriffserkennung, die die BSI-Leitlinien erfüllt — Echtzeit-Monitoring, Anomalieerkennung und Integration in SIEM-Tools.
Vollständiges Audit-Logging — jeder API-Aufruf, jede Konfigurationsänderung, jede administrative Aktion, exportierbar für BSI-Prüfungen und die dreijährliche Einreichung des Compliance-Nachweises.
Eine auditierbare Software-Lieferkette — Open-Source-Grundlagen mit veröffentlichter Software Bill of Materials (SBOM), damit Betreiber die gesetzlich geforderte Vertrauenswürdigkeitsbewertung durchführen können.
Wie FishOS KRITIS-Anforderungen erfüllt
FishOS, entwickelt von Sardina Systems, ist eine Cloud-Management-Plattform, die OpenStack, Kubernetes und Ceph in einem einzigen automatisierten Stack integriert. Sie ist für On-Premises- und Private-Cloud-Deployments konzipiert, wodurch Betreiber die direkte Kontrolle darüber behalten, wo ihre Daten liegen und verarbeitet werden — ohne Abhängigkeit von externer Cloud-Infrastruktur oder ausländischer Gerichtsbarkeit.
Im Bereich Verfügbarkeit umfasst FishOS eine proprietäre Health Monitoring Component, die kontinuierlich Echtzeit-Metriken und Log-Daten analysiert. Laut Sardina Systems nutzt sie einen Ansatz, den sie als „Computer-Immunologie“ beschreiben — er erkennt nicht nur Ausfälle, sondern auch degradierte „kranke“ Zustände, bevor sie zu Ausfällen führen. Das unterscheidet sich von herkömmlichen Monitoring-Tools.
Im Bereich Sicherheit und Audit stellt FishOS ein zentrales Audit-Logging bereit, das Benutzer- und Systemaktionen über die gesamte Infrastruktur hinweg abdeckt, und unterstützt die SIEM-Integration. Laut unabhängigen Reviews der Plattform umfasst FishOS eine integrierte SIEM-Funktionalität zur Erkennung und Reaktion auf Sicherheitsbedrohungen innerhalb der Umgebung.
In Bezug auf Transparenz in der Lieferkette basiert FishOS auf Open-Source-Komponenten — OpenStack, Ceph, Kubernetes — mit öffentlich auditierbaren Codebasen. Sardina Systems stellt SBOM-Dokumentation bereit, die die im überarbeiteten BSIG geforderte Bewertung der Vertrauenswürdigkeit der Lieferkette direkt unterstützt.
FishOS unterstützt die Migration von VMware und anderen Legacy-Plattformen über sein FishOS Move It Appliance, entweder mit einem Ansatz mit minimaler Downtime oder mittels Change Block Tracking (CBT) für Live-Umgebungen. Beide Methoden haben sich an Produktionsstandorten bewährt.
FishOS liefert die architektonische Grundlage — On-Premises-Souveränität, Open-Source-Auditierbarkeit, hohe Verfügbarkeit und die operativen Tools — die Betreiber benötigen, um konforme Infrastruktur aufzubauen und nachzuweisen.
Wo Sie bei KRITIS anfangen sollten
Wenn Ihre Organisation potenziell unter das überarbeitete BSIG fällt — entweder als bestehender KRITIS-Betreiber oder als neu regulierte Einheit unter den NIS2-Kategorien — sind die unmittelbaren Prioritäten:
Erstens: Prüfen Sie, ob Sie nach der aktualisierten BSI-KritisV als Betreiber kritischer Anlagen gelten oder im breiteren NIS2-Rahmenwerk als besonders wichtige oder wichtige Einrichtung. Das BSI hat hierfür ein Selbstbewertungstool veröffentlicht.
Zweitens: Wenn Sie bereits als KRITIS-Betreiber im MIP registriert sind, starten Sie die Registrierung im neuen BSI-Portal als besonders wichtige Einrichtung vor dem 6. März 2026.
Drittens: Bewerten Sie Ihre aktuelle Infrastruktur anhand der technischen Anforderungen der §§30 und 31 BSIG — insbesondere in Bezug auf Angriffserkennung, Audit-Logging und Lieferkettendokumentation.
