NIS2-Richtlinie 2026: Architektur-Implikationen für Mittelständler

Was ist die NIS2-Richtlinie? — In Kürze

Die NIS2-Richtlinie (offiziell: Richtlinie (EU) 2022/2555 über Maßnahmen für ein hohes gemeinsames Cybersicherheitsniveau in der Union) ist die überarbeitete Cybersicherheits-Richtlinie der Europäischen Union. Sie löst die NIS1-Richtlinie aus dem Jahr 2016 ab — deren Geltungsbereich und Anforderungen reichen für die Bedrohungslage 2026 nicht mehr aus. Die Richtlinie trat am 16.01.2023 in Kraft; Mitgliedstaaten mussten sie bis zum 17.10.2024 in nationales Recht überführen.

Drei Punkte tragen das Verständnis der gesamten Richtlinie:

Stark erweiterter Geltungsbereich: Statt weniger Hundert Betreiber kritischer Infrastrukturen sind in Deutschland rund 29.500 Einrichtungen aus 18 Sektoren betroffen (BSI-Schätzung) — Energie, Transport, Gesundheit, digitale Infrastruktur, Verarbeitendes Gewerbe, Lebensmittel, Forschung und mehr.
Verbindliche Mindestmaßnahmen: Artikel 21 schreibt zehn Cyber-Risiko-Management-Maßnahmen vor — von Backup-Management über Lieferkettensicherheit bis Multi-Faktor-Authentifizierung. Technologie-neutral formuliert, ergebnisorientiert.
Persönliche Verantwortung der Geschäftsleitung: Geschäftsführerinnen und Geschäftsführer haften persönlich, wenn Risiko-Management-Pflichten verletzt werden. Bußgelder reichen je nach Einrichtungstyp bis 10 Mio. € oder 2 % des weltweiten Jahresumsatzes.

In Deutschland wurde die Richtlinie durch das NIS2-Umsetzungs- und Cybersicherheitsstärkungsgesetz (NIS2UmsuCG) in nationales Recht überführt — am 13.11.2025 vom Bundestag beschlossen, im Bundesgesetzblatt am 05.12.2025 verkündet, am 06.12.2025 in Kraft getreten. Das Bundesamt für Sicherheit in der Informationstechnik (BSI) ist die zentrale Aufsichtsbehörde. Wer prüfen möchte, ob das eigene Unternehmen in den Geltungsbereich fällt, findet die Antwort im BSI-Selbsttest und in den Anhängen I und II der Richtlinie.

Warum NIS2 jetzt im Mittelstand ankommt

Bis vor Kurzem war „KRITIS“ ein Begriff für Energieversorger, Krankenhäuser und Telekommunikationsbetreiber — ein paar tausend Betreiber kritischer Infrastrukturen, die ohnehin regulatorisch eng geführt waren. Mit der NIS2-Richtlinie und ihrer deutschen Umsetzung verschiebt sich das Bild. Das Bundesamt für Sicherheit in der Informationstechnik (BSI) rechnet mit rund 29.500 betroffenen Einrichtungen in Deutschland — Maschinenbauer, Logistiker, IT-Dienstleister, Lebensmittelhersteller, B2B-Plattformen, mittelständische Softwarehäuser. Die meisten dieser Unternehmen haben sich bisher nicht als kritische Infrastruktur verstanden.

Die Architekturfrage hat sich damit verschoben. Sie lautet nicht mehr „Haben wir eine Perimeter-Firewall?“ — sondern: Wie weisen wir nach, dass wir Cyber-Risiken in unserer Software-Lieferkette systematisch managen? Wie protokollieren wir Vorfälle so, dass eine forensische Auswertung in Stunden — nicht in Wochen — möglich ist? Wie ist die persönliche Verantwortung der Geschäftsleitung in der Architektur sichtbar gemacht? Dieser Beitrag beschreibt, was die Richtlinie tatsächlich verlangt, was die deutsche Umsetzung daraus gemacht hat (Stand Mai 2026), und welche Architekturentscheidungen jetzt anstehen.

Wer betroffen ist — und wer überrascht ist

Die NIS2-Richtlinie (Richtlinie (EU) 2022/2555) trat am 16.01.2023 in Kraft, mit Umsetzungsfrist für die Mitgliedstaaten bis zum 17.10.2024. Der Geltungsbereich ist weit: Anhang I führt elf Sektoren mit hoher Kritikalität — Energie, Transport, Bankwesen, Finanzmarktinfrastrukturen, Gesundheit, Trinkwasser, Abwasser, digitale Infrastruktur, Verwaltung von IKT-Diensten, öffentliche Verwaltung, Weltraum. Anhang II ergänzt sieben weitere kritische Sektoren — Post- und Kurierdienste, Abfallwirtschaft, Chemie, Lebensmittel, verarbeitendes Gewerbe, Anbieter digitaler Dienste, Forschung. Achtzehn Sektoren insgesamt.

Die Größenschwelle wirkt zunächst klar: ab 50 Mitarbeitenden oder 10 Mio. € Jahresumsatz fällt eine Einrichtung grundsätzlich in den Anwendungsbereich. Sektor-spezifische Ausnahmen erweitern den Kreis darüber hinaus — bestimmte digitale Dienste etwa fallen unabhängig von der Größe in den Geltungsbereich. In der Praxis bedeutet das für viele Mittelstands-Unternehmen: Sie sind drin, auch wenn ihr Hauptgeschäft kein klassisch „kritisches“ ist.

Die Richtlinie unterscheidet zwei Stufen. Wesentliche Einrichtungen — in der deutschen Umsetzung „besonders wichtige Einrichtungen“ — sind in der Regel große Unternehmen aus Anhang I (ab 250 Mitarbeitende oder 50 Mio. € Umsatz und 43 Mio. € Bilanzsumme). Sie unterliegen proaktiver Aufsicht und höheren Bußgeldern. Wichtige Einrichtungen umfassen mittelgroße Unternehmen aus Anhang I sowie alle erfassten Unternehmen aus Anhang II — sie unterliegen reaktiver Aufsicht. Das BSI schätzt die Verteilung in Deutschland auf etwa 8.250 besonders wichtige und rund 21.600 wichtige Einrichtungen.

Wenig diskutiert, aber für die Architektur entscheidend: Wer einer NIS2-betroffenen Einrichtung Software liefert, wird Teil von deren Lieferkettensicherheit. Auch ohne eigene Registrierungspflicht treffen Sie als Software-Lieferant die Anforderungen Ihrer Kunden — über Verträge, SBOM-Anfragen, Sicherheits-Attestierungen, Incident-Handling-SLA. Das ist die zweite Welle, die viele Software-Häuser unterschätzen.

Was NIS2 tatsächlich verlangt

Artikel 21 der Richtlinie listet zehn Mindestmaßnahmen für das Cyber-Risiko-Management. Sie sind technologie-neutral und ergebnisorientiert formuliert — die Richtlinie schreibt vor, was erreicht werden muss, nicht wie:

(a) Konzepte für Risikoanalyse und Sicherheit für Informationssysteme
(b) Bewältigung von Sicherheitsvorfällen
(c) Aufrechterhaltung des Betriebs — etwa Backup-Management, Notfallwiederherstellung, Krisenmanagement
(d) Sicherheit der Lieferkette, einschließlich sicherheitsbezogener Aspekte der Beziehungen zu unmittelbaren Anbietern und Diensteanbietern
(e) Sicherheit bei Erwerb, Entwicklung und Wartung von Netz- und Informationssystemen — einschließlich Schwachstellenmanagement und -offenlegung
(f) Konzepte und Verfahren zur Bewertung der Wirksamkeit der Risikomanagement-Maßnahmen
(g) Grundlegende Verfahren der Cyber-Hygiene und Schulungen
(h) Kryptografie und gegebenenfalls Verschlüsselung
(i) Personalsicherheit, Zugriffskontrollkonzepte, Verwaltung von Anlagen
(j) Multi-Faktor-Authentifizierung oder kontinuierliche Authentifizierung, gesicherte Sprach-, Video- und Textkommunikation, gegebenenfalls gesicherte Notfallkommunikation

Artikel 23 regelt die Meldepflichten bei erheblichen Sicherheitsvorfällen. Drei gestaffelte Fristen, die sich auch in § 32 BSIG (NIS2UmsuCG) wiederfinden:

Frühwarnung binnen 24 Stunden nach Kenntnisnahme — mit Hinweis darauf, ob ein Verdacht auf rechtswidrige oder böswillige Handlungen oder auf grenzüberschreitende Auswirkungen besteht
Vorfallsmeldung binnen 72 Stunden — mit Erstbewertung, Schwere und Auswirkungen sowie Indicators of Compromise
Abschlussbericht binnen einem Monat nach der Vorfallsmeldung — mit detaillierter Beschreibung, Ursachenanalyse und ergriffenen Maßnahmen

Diese Stufung ist neu gegenüber NIS1 und nimmt die Realität ernst, dass eine fundierte forensische Bewertung Zeit braucht. Sie verändert aber den Anspruch an die Telemetrie: Wer in 24 Stunden eine belastbare Frühwarnung absetzen will, braucht ein Setup, das Anomalien sichtbar macht — und nicht erst beim Aufräumen am Montagmorgen entdeckt.

Die Durchführungsverordnung (EU) 2024/2690 vom 17.10.2024 konkretisiert diese Anforderungen für bestimmte digitale Dienste — DNS-Anbieter, TLD-Registries, Cloud-Anbieter, Rechenzentrumsdienste, Content-Delivery-Networks, Managed-Service-Provider, Online-Marktplätze, Suchmaschinen, soziale Netzwerke, Vertrauensdiensteanbieter. Der Anhang der Verordnung gliedert sich in dreizehn thematische Bereiche und ist deutlich präskriptiver als der Richtlinientext. Wer in einer dieser Kategorien arbeitet, sollte sie als Pflichtlektüre betrachten. Für andere Sektoren bleibt die ENISA-Leitlinie zur technischen Implementierung der zentrale Referenzpunkt.

Architektur-Implikationen für Software-Bauer

Die Mindestmaßnahmen aus Artikel 21 sind Architekturentscheidungen, keine Compliance-Übungen. Sechs Punkte sind aus unserer Sicht die wirksamsten Hebel.

Logging-Architektur — Append-only und forensik-tauglich

Die Frühwarnungs-Frist von 24 Stunden ist nur einzuhalten, wenn Sie einen Vorfall überhaupt zeitnah erkennen. Strukturiertes Logging mit Korrelations-IDs über Service-Grenzen hinweg, ein zentralisierter Log-Stream (Loki, Elastic, oder vergleichbar) und Append-only-Persistenz sind das Fundament. „Append-only“ heißt: Logs werden nach dem Schreiben nicht mehr verändert — die forensische Auswertung kann sich darauf verlassen, dass ein Angreifer keine Spuren überschrieben hat. Eventlogs in der Plattform-Datenbank, die jede sicherheitsrelevante Aktion (Auth-Versuche, Konfigurationsänderungen, privilegierte API-Zugriffe) als Datensatz schreiben, ergänzen das. Der Audit-Trail muss revisionssicher sein — das ist nicht nur ISO-Vokabular, sondern eine konkrete Anforderung, wenn das BSI im Vorfall nachfragt.

Identity & Access — SSO und MFA als Default, nicht als Retrofit

Artikel 21(2)(j) verlangt Multi-Faktor-Authentifizierung „gegebenenfalls“ — in der Praxis: für privilegierte Zugriffe ohne Diskussion, für Endnutzer-Zugriffe je nach Risiko-Profil. Architektonisch heißt das, MFA nicht als zusätzlichen Layer vor das Login zu schrauben, sondern als Teil des Identity-Providers zu denken. OIDC und SAML als Protokollebene, Keycloak, Authelia oder ein Cloud-IdP als Implementierung. Rollen- und Berechtigungsmodell im Datenmodell sichtbar — nicht als nachgelagerter UI-Filter, der sich umgehen lässt. Für Mittelstands-Setups, die historisch mit lokalen Logins gewachsen sind, ist das oft der erste größere Refactor. Lohnt sich.

Netzwerk-Architektur — Segmentierung und Zero-Trust-Muster

Die klassische Burggraben-Architektur — DMZ vorne, vertrauenswürdiges internes Netz dahinter — entspricht nicht mehr dem Stand der Technik. Zero-Trust-Muster gehen davon aus, dass das interne Netz nicht implizit vertrauenswürdig ist. Konkret: Service-zu-Service-Kommunikation wird authentifiziert (mTLS, kurzlebige Tokens), Netzwerksegmente sind kleinteilig (Microsegmentation), Secrets werden über ein eigenständiges Management-System bezogen, nicht aus Umgebungsvariablen im Repo. Für Container-basierte Architekturen liefert ein Service-Mesh (Linkerd, Istio) die Telemetrie und mTLS gleich mit. Für klassische VM-Setups reicht oft eine saubere VLAN-Segmentierung mit hostbasierter Firewall. Die Wahl ist sekundär — die Disziplin ist primär.

Backup-Architektur — Immutable, getestet, in Reichweite der RPO/RTO

Artikel 21(2)(c) verlangt Backup-Management und Notfallwiederherstellung. Die Implementierung wird oft als „läuft, ist gut“ abgehakt — bis ein Ransomware-Vorfall zeigt, dass die Backups verschlüsselt mit verschlüsselt wurden. Immutable Backups — also Sicherungen, die nach dem Schreiben nicht mehr verändert oder gelöscht werden können (Object-Lock, Worm-Storage, Backup-Server in einem getrennten Trust-Zone-Netz) — sind hier die zentrale Maßnahme. Wiederherstellungsziele (Recovery Point Objective, Recovery Time Objective) müssen pro System definiert sein und regelmäßig getestet werden. Ein einmal pro Jahr trockengelaufenes Restore ist mehr wert als ein nie geprüftes Backup-Konzept.

Software-Lieferkette — SBOM-Pflege wird zum Standard

Artikel 21(2)(d) und (e) verlangen Lieferkettensicherheit und Schwachstellenmanagement. NIS2 fordert keinen SBOM explizit — der Cyber Resilience Act tut das für vernetzte Produkte ab 2027. Die Verbindung ist eng: Wer für seine eigenen Produkte einen SBOM in der CI-Pipeline erzeugt (Syft, CycloneDX-Tooling, Trivy), kann die Lieferkettensicherheit gegenüber NIS2-betroffenen Kunden mit demselben Artefakt belegen. Automatisierte CVE-Überwachung gegen NVD/OSV, ein Quality-Gate, das kritische bekannte Schwachstellen blockiert, ein dokumentiertes Patch-Management — das sind keine NIS2-spezifischen Konzepte, sondern saubere DevOps-Praxis, die unter NIS2 zur regulatorischen Pflicht wird.

Monitoring, Alerting und Architektur-Dokumentation

Sentry für Application-Errors, Grafana mit Prometheus oder vergleichbar für Metriken, ein Alerting, das tatsächlich einen Bereitschafts-Verantwortlichen erreicht — das ist die operative Seite. Die regulatorische Seite verlangt darüber hinaus den Nachweis, dass diese Maßnahmen bewusst entschieden wurden. Architecture Decision Records (ADRs) — kurze, datierte Dokumente, die eine Architekturentscheidung mit Begründung und verworfenen Alternativen festhalten — werden so von Engineering-Hygiene zu juristischer Hygiene. Sie sind der Beleg, dass die Geschäftsleitung Risikomanagement-Maßnahmen tatsächlich gebilligt und überwacht hat — wozu § 38 NIS2UmsuCG sie verpflichtet.

Stand der deutschen Umsetzung (Stand Mai 2026)

Deutschland hat die Umsetzungsfrist vom 17.10.2024 verfehlt. Das NIS-2-Umsetzungs- und Cybersicherheitsstärkungsgesetz (NIS2UmsuCG) blieb über mehrere Kabinettsfassungen im Verfahren, wurde durch den Bruch der Ampel-Koalition Ende 2024 weiter verzögert und nach Bundestagswahl und Regierungswechsel neu eingebracht. Der Bundestag hat das Gesetz schließlich am 13.11.2025 verabschiedet, der Bundesrat hat ihm am 20.11.2025 zugestimmt. Die Verkündung im Bundesgesetzblatt (BGBl. 2025 I Nr. 301) erfolgte am 05.12.2025, das Gesetz trat am 06.12.2025 in Kraft. Eine Übergangsfrist ist nicht vorgesehen — die Pflichten gelten seit Verkündung.

Materiell ist das NIS2UmsuCG eine umfassende Novelle des BSI-Gesetzes (BSIG). Die zentralen Mechaniken: Registrierungspflicht beim BSI, Risikomanagement-Maßnahmen analog Artikel 21, gestufte Meldepflichten analog Artikel 23, Aufsichtsbefugnisse für das BSI, persönliche Verantwortung der Geschäftsleitung in § 38. Das BSI hat sein Registrierungs-Portal am 06.01.2026 freigeschaltet. Die Erst-Registrierungsfrist endete am 06.03.2026. Nach BSI-Angaben hatten zu diesem Zeitpunkt etwa 38,5 % der geschätzten 29.500 betroffenen Einrichtungen registriert — wer die Frist verpasst hat, kann verspätet nachregistrieren, jeder Tag erhöht aber das Bußgeld-Risiko.

Parallel ist am 06.03.2026 das KRITIS-Dachgesetz beschlossen worden — Bundestag am 29.01.2026, Bundesrat am 06.03.2026. Es regelt nicht die IT-Sicherheit, sondern die physische Resilienz kritischer Anlagen (CER-Richtlinie der EU) und betrifft etwa 2.000 Betreiber, die sich bis zum 17.07.2026 beim Bundesamt für Bevölkerungsschutz und Katastrophenhilfe (BBK) registrieren müssen. NIS2UmsuCG und KRITIS-Dachgesetz sind getrennte Regelwerke mit teils überlappendem Adressatenkreis — wer beides betrifft, hat doppelte Registrierungspflichten und teils unterschiedliche Aufsichtsbehörden.

Persönliche Verantwortung der Geschäftsleitung

Artikel 20 der NIS2-Richtlinie verpflichtet die „Leitungsorgane“ wesentlicher und wichtiger Einrichtungen, die Risikomanagement-Maßnahmen nach Artikel 21 zu billigen, ihre Umsetzung zu überwachen und an Cybersicherheits-Schulungen teilzunehmen. Diese Verantwortung kann nicht delegiert werden — operative Umsetzung schon, strategische Verantwortung nicht.

Die deutsche Umsetzung in § 38 NIS2UmsuCG geht in einem Punkt explizit über die Richtlinie hinaus: Ein Haftungsverzicht durch Gesellschaftsvertrag oder Satzung ist gesetzlich ausgeschlossen. Die Geschäftsleitung haftet persönlich nach den Regeln des Gesellschaftsrechts für Verstöße gegen die Risikomanagement-Pflichten. Bußgelder gegen die Einrichtung können bis zu 10 Mio. € oder 2 % des weltweiten Jahresumsatzes (besonders wichtige Einrichtungen) bzw. 7 Mio. € oder 1,4 % (wichtige Einrichtungen) erreichen. Architektonisch hat das eine konkrete Konsequenz: Die Geschäftsleitung braucht Belege, dass sie ihre Pflichten erfüllt hat. Dokumentierte Architekturentscheidungen, dokumentierte Risiko-Assessments, dokumentierte Maßnahmen-Reviews — das ist nicht „Compliance-Theater“. Es ist die Form, in der Sorgfaltspflicht nachweisbar wird.

Was 2026 konkret zu tun ist

Für ein Greenfield-Projekt ist die Antwort einfach: bauen Sie die Mindestmaßnahmen aus Artikel 21 von Anfang an in Datenmodell, API-Schicht und CI-Pipeline. SBOM in der Build-Pipeline. Append-only Eventlog pro relevante Geschäftseinheit. SSO mit MFA für privilegierte Zugriffe. Immutable Backups mit dokumentierten RPO/RTO. Strukturiertes Logging mit Korrelations-IDs. Monitoring mit echtem Alerting. Architecture Decision Records.

Für Bestandssysteme — der Normalfall im Mittelstand — ist NIS2 ein Refactor-Trigger. Das Gesetz schreibt nicht vor, dass Sie ein 15 Jahre altes ERP neu bauen. Es schreibt vor, dass Sie nachweisen können, wie Sie die Mindestmaßnahmen umsetzen. Pragmatisch: nehmen Sie das Risiko-Inventar als Ausgangspunkt, priorisieren Sie nach Schadenshöhe × Eintrittswahrscheinlichkeit, und gehen Sie die Top-Drei zuerst an. Erfahrungsgemäß sind das in den meisten Mittelstands-Setups Identity & Access (kein zentrales SSO, MFA fehlt, lokale Admin-Konten ohne Audit), Logging (keine zentrale Aggregation, keine Append-only-Sicherung) und Backup (keine Immutability, keine Restore-Tests). Refactor + Erweiterung schlägt in fast jedem Fall den Komplett-Neubau.

Für Software-Lieferanten von NIS2-Unternehmen ist die strategische Aufgabe klar: Ihre Kunden werden Sie ab 2026 strukturiert nach SBOM, Sicherheits-Attestierung, Incident-Handling-SLA und Vulnerability-Disclosure-Prozess fragen. Wer das vorbereitet hat — SBOM in der Build-Pipeline, dokumentierte Vulnerability-Disclosure-Policy, klar definierte Reaktionszeiten —, hat einen Wettbewerbsvorteil gegenüber Mitbewerbern, die bei jeder Anfrage ad hoc reagieren müssen.

Wie wir das angehen

Wir verkaufen keine „NIS2-Compliance-as-a-Service“. Compliance ist kein Produkt — sie ist die Konsequenz einer sauber gebauten Architektur. Was wir tun: wir bauen Plattformen, in denen Audit-Trail revisionssicher, SSO/MFA, Append-only Eventlog und SBOM-Pflege Bestandteil des Fundaments sind, nicht nachträgliche Aufsätze. Refactor-Kompetenz für gewachsene Systeme gehört zum Kern unseres Angebots — End-to-End-Verantwortung von Architektur bis Betrieb, ohne Konzern-Apparat dazwischen.

Das B2B-IoT-Projekt LITE BLOX ist ein Beispiel, in dem dieser Anforderungstyp sichtbar wird: vernetzte Industrieeinheiten im Feld, Lifecycle-Datenmodell mit unveränderlichem Geburts-Snapshot pro Einheit, Append-only Eventlog für sicherheitsrelevante Ereignisse, kontinuierliche Telemetrie über Sentry und Grafana. Wenn Sie ein vergleichbares Vorhaben verantworten — neue Plattform oder Refactor eines Bestandssystems unter NIS2-Pflichten —, sprechen wir gerne über die Architektur, bevor das Pflichtenheft den ersten Sprint erreicht.

Ressourcen

EU-Richtlinie 2022/2555 (NIS2), konsolidierte Fassung: eur-lex.europa.eu/eli/dir/2022/2555
Durchführungsverordnung (EU) 2024/2690 für digitale Dienste: eur-lex.europa.eu/eli/reg_impl/2024/2690
EU-Kommission, NIS2-Übersicht: digital-strategy.ec.europa.eu/en/policies/nis2-directive
BSI, NIS-2-regulierte Unternehmen: bsi.bund.de — NIS-2-regulierte Unternehmen
BSI-Pressemitteilung zum Inkrafttreten am 06.12.2025: bsi.bund.de — NIS-2-Umsetzungsgesetz in Kraft
Bundesregierung, Beschluss zur NIS-2-Umsetzung: bundesregierung.de — NIS-2-Richtlinie Deutschland
BMI, Gesetzgebungsverfahren NIS2UmsuCG: bmi.bund.de — NIS2UmsuCG
Bundesgesetzblatt, NIS2UmsuCG (BGBl. 2025 I Nr. 301): recht.bund.de — BGBl. 2025 I Nr. 301
ENISA, Technische Implementierungs-Leitlinie zu NIS2: enisa.europa.eu — NIS2 Technical Implementation Guidance

Stand: Mai 2026. Die Auslegung einzelner Vorschriften kann sich durch Durchführungsrechtsakte, BSI-Konkretisierungen, harmonisierte Normen und sektor-spezifische Verordnungen weiter ändern. Für eine rechtsverbindliche Beurteilung Ihres konkreten Falls verweisen wir auf qualifizierte Rechtsberatung.