NIS2 und KRITIS-Dachgesetz: Was Unternehmen in KRITIS-Sektoren jetzt technisch umsetzen müssen

Die Fristen sind durch. Das NIS2-Umsetzungsgesetz ist seit Dezember 2025 in Kraft, betroffene Unternehmen mussten sich bis zum 6. März 2026 beim BSI registrieren. Das KRITIS-Dachgesetz gilt seit dem 17. März 2026, die Registrierung beim BBK war bis zum 17. Juli 2026 Pflicht. Für die meisten Betroffenen ist damit die Formalie erledigt, die eigentliche Arbeit fängt jetzt erst an: die technische und organisatorische Umsetzung der Anforderungen in der eigenen IT-Infrastruktur.

Genau an dieser Stelle sehen wir in Projekten mit Unternehmen aus KRITIS-Sektoren wie dem Transportwesen immer wieder dieselbe Lücke: Die Registrierung ist gemacht, aber niemand hat eine klare Vorstellung davon, was BSI- und KRITIS-Vorgaben konkret für Kubernetes-Cluster, Container-Plattformen und Cloud-Infrastruktur bedeuten.

Was hat sich mit NIS2 und dem KRITIS-Dachgesetz konkret geändert?

NIS2 erweitert den Kreis der regulierten Organisationen erheblich: statt rund 4.500 KRITIS-Betreibern nach altem Recht sind jetzt über 29.000 Einrichtungen aus 18 statt bisher 10 Sektoren betroffen. Bei Verstößen drohen Bußgelder bis zu 10 Millionen Euro, zusätzlich gilt eine 24-Stunden-Frist zur Erstmeldung von Sicherheitsvorfällen.

Das KRITIS-Dachgesetz ergänzt das um die physische Resilienz kritischer Anlagen, zusätzlich zur IT-Sicherheit müssen Betreiber also auch Zugriffsschutz, Ausfallsicherheit und Notfallplanung für ihre Standorte und Systeme nachweisen.

Für IT-Verantwortliche heißt das in der Praxis: zwei Gesetze, ein gemeinsamer Kern – belastbare, dokumentierte, auditierbare technische Sicherheitsmaßnahmen.

Hinweis: Dieser Artikel ersetzt keine Rechtsberatung. Ob und in welchem Umfang Ihr Unternehmen konkret betroffen ist, sollte mit einer auf IT- und Regulierungsrecht spezialisierten Kanzlei oder direkt über die BSI-/BBK-Portale geklärt werden.

Wen betrifft das – und wen nicht?

NIS2 betrifft "wesentliche" und "wichtige" Einrichtungen in Sektoren wie Energie, Transport, Gesundheit, Wasser, digitale Infrastruktur und einigen mehr. Die genaue Sektorenliste und Schwellenwerte (meist ab 50 Mitarbeitenden oder 10 Millionen Euro Umsatz) entscheiden über die Betroffenheit. Das KRITIS-Dachgesetz richtet sich enger an Betreiber kritischer Anlagen im engeren Sinn. Viele dieser Betreiber sind privatwirtschaftlich organisierte Unternehmen, etwa Energieversorger, Logistik- und Transportunternehmen oder Betreiber digitaler Infrastruktur, keine klassischen Behörden.

Wer unsicher ist: Die Registrierungspflicht beim BSI bzw. BBK ist der verlässlichste Indikator. Wer sich registrieren musste, ist in aller Regel auch zur technischen Umsetzung verpflichtet.

Welche technischen Anforderungen stecken dahinter?

Aus unserer Projekterfahrung mit Unternehmen im KRITIS-Kontext lassen sich die Anforderungen in vier Bereiche gliedern, die sich direkt auf moderne Container- und Cloud-Infrastruktur anwenden lassen:

Hardening von Container-Plattformen nach BSI-Vorgaben. Kubernetes- und OpenShift-Cluster müssen gegen die einschlägigen BSI-Sicherheitskataloge (u. a. BSI 100-4) gehärtet werden, von restriktiven Pod-Security-Standards über Netzwerksegmentierung bis zur Absicherung der Control Plane.

Policy Enforcement statt manueller Kontrolle. Statt Sicherheitsrichtlinien in Dokumenten zu verwalten, lassen sie sich technisch erzwingen, etwa über Policy-Engines, die nicht-konforme Deployments automatisch blockieren, bevor sie überhaupt in Produktion laufen.

Monitoring, Logging und Schwachstellenmanagement. NIS2 verlangt eine 24-Stunden-Meldefrist bei Vorfällen. Das ist ohne durchgehendes Telemetrie- und Alerting-Konzept sowie automatisiertes Schwachstellen-Scanning der Container-Images kaum realistisch umsetzbar.

Identity- und Zugriffsmanagement nach Zero-Trust-Prinzip. RBAC, durchgängige Multi-Faktor-Authentifizierung und eine PKI mit sauberem Zertifikats-Lifecycle-Management sind sowohl für NIS2 als auch für klassische BSI-Grundschutz-Audits zentrale Prüfpunkte.

Aus der Praxis: BSI-konforme Containerplattform für den öffentlichen Sektor

In einem Referenzprojekt für eine Behörde in Niedersachsen haben wir genau diese vier Bereiche für eine On-Premise-Containerplattform umgesetzt: Hardening-Standards nach BSI-Vorgaben, automatisierte Policy-Enforcement-Mechanismen und ein Telemetrie- und Alerting-Konzept, das Meldefristen technisch abbildet – ergänzt um Compliance-Anforderungen und Schwachstellenmanagement für die Container-Umgebung.

Die technische Tiefe aus einem solchen Projekt lässt sich unmittelbar auf privatwirtschaftliche Unternehmen mit vergleichbar kritischen Systemen übertragen – etwa auf Betreiber hochverfügbarer, geschäftskritischer Infrastruktur wie im Fall unseres Projekts für die Deutsche Börse AG.

Der gemeinsame Nenner: Compliance ist kein einmaliges Audit-Projekt, sondern muss in der Architektur der Plattform selbst verankert sein – sonst hält sie dem nächsten Audit nicht stand.

Was Unternehmen in KRITIS-Sektoren jetzt konkret tun sollten

Wer die Registrierung bereits abgeschlossen hat, sollte als Nächstes prüfen: Sind die technischen Maßnahmen dokumentiert und nachweisbar? Existiert ein Konzept für die 24-Stunden-Meldefrist bei Vorfällen? Sind Container-Plattformen und Cloud-Infrastruktur bereits gegen die relevanten BSI-Kataloge gehärtet, oder steht das noch aus? Gibt es ein durchgängiges Identity- und Zugriffskonzept, das auch einem externen Audit standhält?

Wer eine oder mehrere dieser Fragen nicht klar beantworten kann, hat an dieser Stelle noch Handlungsbedarf – unabhängig davon, ob die gesetzliche Frist schon verstrichen ist.

Wie wir unterstützen können

Unsere erfahrenen Consultants bringen aus Projekten mit Unternehmen im KRITIS-Kontext und aus mehrjähriger Erfahrung mit Behördenprojekten genau die technischen Bausteine mit, um die es bei NIS2 und dem KRITIS-Dachgesetz im Kern geht: Härtung von Kubernetes- und Container-Plattformen nach BSI-Vorgaben, Automatisierung von Policy-Enforcement, durchgängiges Monitoring und Logging sowie Zugriffs- und Identitätsmanagement nach Zero-Trust-Prinzip.

Diese Themen sind fester Bestandteil unserer Container-Plattform- und Managed-Services-Leistungen – nicht als separates Compliance-Produkt, sondern weil eine sauber gehärtete, überwachte und abgesicherte Infrastruktur ohnehin die Grundlage jeder professionellen IT-Umgebung ist. Für die rechtliche Einordnung der eigenen Betroffenheit empfehlen wir zusätzlich eine spezialisierte Kanzlei.

Wenn Sie Ihre Container- oder Cloud-Infrastruktur auf die technischen Anforderungen von NIS2 und dem KRITIS-Dachgesetz prüfen lassen möchten, sprechen Sie uns an.

Häufige Fragen zu NIS2 und KRITIS-Dachgesetz

Was ist der Unterschied zwischen NIS2 und dem KRITIS-Dachgesetz? NIS2 regelt vor allem die Cybersicherheit und betrifft mit über 29.000 Einrichtungen aus 18 Sektoren deutlich mehr Organisationen als bisher. Das KRITIS-Dachgesetz ergänzt das um Anforderungen an die physische Resilienz kritischer Anlagen und richtet sich enger an Betreiber kritischer Infrastruktur.

Ich habe die Registrierungsfrist verpasst – was jetzt? Die Registrierung sollte umgehend nachgeholt werden, im Zweifel mit rechtlicher Beratung zur Einordnung möglicher Konsequenzen. Unabhängig davon sollten die technischen Maßnahmen parallel angegangen werden, da diese unabhängig vom Registrierungszeitpunkt gefordert sind.

Was fordert BSI 100-4 konkret für Container-Plattformen? BSI 100-4 behandelt Notfallmanagement und Business Continuity; in Kombination mit weiteren BSI-Sicherheitskatalogen ergeben sich Anforderungen an Hardening, Netzwerksegmentierung, Monitoring und Wiederanlauffähigkeit von Kubernetes- und Container-Umgebungen.

Brauchen wir eine komplette ISO-27001-Zertifizierung, um NIS2-konform zu sein? Nicht zwingend – NIS2 selbst schreibt keine ISO-27001-Zertifizierung vor, viele der geforderten Maßnahmen überschneiden sich aber inhaltlich stark mit dem ISO-27001- bzw. BSI-Grundschutz-Rahmenwerk, sodass sich eine Orientierung daran in der Praxis anbietet.

Previous
Previous

VMware-Alternative Proxmox VE 9.2: Lohnt sich die Migration im Jahr 2026?

Next
Next

Cloud Exit: Wann sich der Weg zurück aus der Public Cloud lohnt