NIS2 ist in Produktionsbetrieben kein reines IT-Thema mehr, weil die entscheidenden Risiken häufig in der OT liegen. Sobald Remote-Zugänge, Engineering-Stations, SCADA/HMI-Systeme und die Netz-Infrastruktur der Produktion betroffen sind, wird Cybersicherheit zu einer Frage der Anlagenverfügbarkeit. In der Praxis geht es deshalb weniger darum, ob eine Maßnahme „schön“ dokumentiert ist, sondern darum, ob sie den Betrieb tatsächlich stabiler und besser beherrschbar macht, wenn etwas schiefgeht.

Dieser Text ist bewusst praxisnah formuliert und richtet sich an Instandhaltung, Automatisierung und technische Verantwortliche. Er ersetzt keine Rechtsberatung, aber er hilft dabei, OT-seitig die richtigen Prioritäten zu setzen, damit ein NIS2-Programm nicht an den falschen Stellen beginnt.

Warum OT nicht wie IT behandelt werden darf

In IT-Umgebungen ist es üblich, Systeme regelmäßig zu patchen und nach einem festen Hardening-Standard zu betreiben. In OT-Umgebungen ist das deutlich schwieriger, weil Produktionskommunikation deterministisch bleiben muss, Change-Fenster eng sind und die Stabilität des Prozesses Vorrang hat. Wenn man IT-Regeln unreflektiert in OT kopiert, entstehen entweder nur scheinbare Sicherheitsmaßnahmen, die reale Eintrittspunkte unberührt lassen, oder es entstehen Sicherheitsmaßnahmen, die den Betrieb destabilisieren und Serviceprozesse verlangsamen.

Deshalb funktioniert OT-Security am besten, wenn man zuerst die Architektur ordnet. Sobald Zonen, Übergänge und erlaubte Datenflüsse sauber definiert sind, lässt sich Zugriffskontrolle, Logging und Monitoring sinnvoll ergänzen, ohne dass die Produktion „kaputtgesichert“ wird.

Wo NIS2 in der Fabrik OT typischerweise trifft

In der Praxis landet NIS2-Druck in OT fast immer an denselben Stellen. Er trifft Remote-Service, weil Fernwartung oft historisch gewachsen ist und mehrere parallele Kanäle existieren. Er trifft Engineering-Stations, weil Projekte und Backups häufig lokal liegen und nicht als „kritische Systeme“ behandelt werden. Er trifft die Netzwerkarchitektur, weil OT und IT manchmal noch zu flach miteinander verbunden sind und dadurch Vorfälle unnötig weit reichen können. Er trifft schließlich Backups und Wiederanlauf, weil sich im Ernstfall entscheidet, ob ein Stillstand Stunden oder Tage dauert.

Wenn diese vier Bereiche nicht geklärt sind, ist es schwer, in einem Audit oder nach einem Vorfall glaubwürdig zu zeigen, dass Risiken kontrolliert werden und dass die Organisation den Betrieb wiederherstellen kann.

Der 30-Tage-Plan „NIS2-ready in OT“ ohne Produktionsstillstand

Tage 1–7: Sichtbarkeit schaffen, aber nur für das Wesentliche

In der ersten Woche sollte das Ziel nicht eine perfekte Inventarliste sein, sondern ein belastbares Bild der kritischen OT-Bausteine und der Eintrittspunkte. Sinnvoll ist es, die PLC-Kerne, SCADA/HMI-Systeme, Engineering-Stations, OT-Switches sowie alle Remote-Zugänge so zu erfassen, dass klar wird, welche Komponenten für den Produktionsbetrieb wirklich kritisch sind. Parallel dazu sollte man festhalten, über welche Wege IT oder externe Dienstleister überhaupt an OT herankommen, weil genau diese Wege in Vorfällen fast immer eine zentrale Rolle spielen.

Tage 8–14: Zonen und DMZ etablieren, damit OT und IT nicht „direkt“ gekoppelt sind

In der zweiten Woche liegt der größte Hebel in der Segmentierung zwischen OT und IT und in der Einführung eines definierten Übergangs über eine DMZ. In der Praxis bedeutet das, dass produktionskritische Netze nicht direkt aus dem Office-Netz erreichbar sind und dass definierte Systeme in der DMZ die Rolle von Jump-Servern, Update-Repository, Logging-Sammlung oder Historian-Flows übernehmen. Sobald diese Übergänge existieren, kann man erlaubte Datenflüsse sauber begrenzen und nachvollziehbar machen, statt in Ausnahmen und „Any-Any“ zu leben.

Tage 15–21: Remote-Service standardisieren und kontrollieren

In der dritten Woche sollte Remote-Service auf einen kontrollierten Standard gebracht werden, weil hier in vielen Betrieben der größte reale Eintrittspunkt liegt. Eine gute Zielarchitektur ist ein klarer Zugriffspfad über VPN und starke Authentifizierung, der anschließend über einen Jump-Server in der DMZ in OT führt. Entscheidend ist, dass Zugriffe nicht über geteilte Accounts laufen, sondern über nachvollziehbare Identitäten, und dass Sitzungen protokolliert werden. Wenn ihr an diesem Punkt „einen Weg“ habt, reduziert ihr Angriffsfläche und Komplexität gleichzeitig.

Tage 22–30: Backups, Wiederherstellung und Incident-Ablauf so bauen, dass es operativ funktioniert

In der vierten Woche sollte der Fokus darauf liegen, Wiederherstellung praktisch zu beherrschen. Dafür reichen „Backups existieren“ nicht, sondern es braucht mindestens einen realen Restore-Test, der zeigt, wie lange ein Wiederanlauf tatsächlich dauert und welche Abhängigkeiten im Weg stehen. Zusätzlich braucht es einen Incident-Ablauf, der Rollen klärt und Entscheidungen ermöglicht, etwa wer eine Zone isoliert, wer den technischen Zustand dokumentiert, wer externe Dienstleister steuert und wie die Kommunikation intern abläuft.

Incident-Meldung und OT-Realität: Warum „Störung“ nicht automatisch „kein Cyber“ ist

In OT sieht ein Cyber-Vorfall oft wie eine gewöhnliche Störung aus, weil Symptome über Kommunikation, Visualisierung oder I/O-Status auftreten. Ohne definierte Eskalationskriterien diskutiert man im Ernstfall zu lange darüber, ob „das wirklich Security“ ist. Sinnvoll ist daher, interne Trigger zu definieren, die automatisch eine Security-Eskalation auslösen, sobald bestimmte Produktionsauswirkungen oder bestimmte Anomalien zwischen Zonen auftreten. So schafft man Geschwindigkeit, ohne jedes Problem als Cyber-Incident zu behandeln.

Lieferkette und Integratoren: Warum das OT-Zugriffsthema nie „nur extern“ ist

In Produktionsbetrieben sind Integratoren und Servicepartner häufig Teil des Betriebsmodells, und damit sind sie auch Teil der Risikooberfläche. Das wird dann gefährlich, wenn Zugriffe auf OT nicht über euren kontrollierten Weg laufen, wenn keine Session-Protokolle existieren oder wenn Projekte und Backups nicht im Zugriff des Betreibers liegen. Ein praktikabler Standard ist daher, dass Remote-Zugriffe nur über euren Zugangspfad erfolgen, dass sie einem Ticket oder einer Freigabe zugeordnet sind und dass die Übergabe von Projektständen und Backups als fester Prozess existiert.

Was NIS2-OT-Programme typischerweise scheitern lässt

Viele Programme scheitern nicht an Technik, sondern an fehlender Reihenfolge. Wenn Segmentierung „später“ kommt und Remote-Service historisch gewachsen bleibt, entstehen zu viele Ausnahmen und zu wenig Kontrolle. Wenn Backups nicht getestet werden, ist die Wiederanlaufzeit im Ernstfall unbekannt. Wenn Incident-Prozesse nur Papier sind, funktioniert die Entscheidungskette nachts nicht. Genau deshalb liefert die Reihenfolge aus dem 30-Tage-Plan in der Praxis oft schneller Stabilität als große Tool-Investitionen.

FAQ

Gilt NIS2 auch für Produktionsunternehmen oder nur für IT-Dienstleister?
NIS2 betrifft viele Unternehmen in kritischen und wichtigen Bereichen, und in Produktionsbetrieben wird OT oft praktisch relevant, weil dort Systeme betrieben werden, deren Ausfall erhebliche Auswirkungen auf den Betrieb haben kann.

Was bedeutet NIS2 konkret für OT/SCADA/PLC in der Instandhaltung?
In der Praxis bedeutet es, dass Remote-Zugänge kontrolliert werden müssen, dass OT und IT sauber segmentiert werden sollten, dass Änderungen nachvollziehbar sein müssen und dass Backups sowie Wiederanlaufprozesse regelmäßig getestet werden sollten.

Womit sollte man in OT anfangen, ohne die Produktion zu gefährden?
Man sollte mit der Erfassung der Eintrittspunkte beginnen, insbesondere Remote-Zugänge und Engineering-Stations, und anschließend die OT/IT-Segmentierung mit DMZ sowie einen standardisierten Remote-Service etablieren, bevor man das Thema Backup-Tests und Incident-Ablauf abschließt.

Warum ist „kein direkter IT-Zugriff auf PLC“ eine so wichtige Regel?
Diese Regel begrenzt die Ausbreitung von Vorfällen und erzwingt definierte Übergänge über DMZ und kontrollierte Zugriffswege, die man technisch steuern und zuverlässig protokollieren kann.

Welche Incident-Fristen sind in NIS2 typisch (praktisch gedacht)?
NIS2 sieht kurze Meldefenster vor, die in der Praxis bedeuten, dass Unternehmen sehr früh nach Kenntnis eines signifikanten Vorfalls eine Erstmeldung abgeben und anschließend weitere Informationen in weiteren, ebenfalls kurzen Zeitfenstern nachreichen müssen.

Wie oft sollte man Backups von PLC/HMI wirklich testen?
Backups sollten regelmäßig und zusätzlich nach relevanten Änderungen getestet werden, weil nur ein realer Restore-Test zeigt, wie lange der Wiederanlauf dauert und welche Abhängigkeiten im Weg stehen.

Was ist der häufigste Schwachpunkt in OT-Umgebungen?
Sehr häufig ist es unkontrollierter Remote-Zugang mit mehreren Kanälen, geteilten Accounts oder fehlendem Session-Logging, kombiniert mit Engineering-Stations, die nicht sauber in Update-, Backup- und Change-Prozesse eingebunden sind.

Wie bindet man Integratoren und Servicepartner NIS2-konform ein?
Man bindet sie über einen kontrollierten Zugriffspfad ein, beispielsweise VPN mit starker Authentifizierung und danach über einen Jump-Server, und man verlangt nachvollziehbare Freigaben, Session-Logging sowie klare Regeln zur Übergabe von Projekten, Backups und zur Durchführung von Änderungen.