NIS2 und OT: Wenn digitale Sicherheit den physischen Betrieb betrifft
Produzierende Unternehmen haben ihre Maschinen, Linien und Anlagen in den letzten Jahren schrittweise vernetzt: Fernwartung, Sensorik, MES-/ERP-Anbindung, Cloud-Portale, Retrofit. Das hat den Betrieb verbessert — und neue Fragen aufgeworfen, die bisher niemand systematisch gestellt hat.
NIS2 macht die Verbindung zwischen IT, OT, Lieferanten und Betriebsfähigkeit zur Leitungsfrage — nicht zur IT-Aufgabe.
OT war lange abgeschottete Betriebstechnik. Industrie 4.0, Fernwartung, Sensorik, Cloud-Portale und Retrofit haben daraus vernetzte Betriebssysteme gemacht. Unter NIS2 wird genau diese Verbindung zur Managementfrage: Wer darf zugreifen, wer betreibt, wer meldet — und wie bleibt der physische Betrieb im Ereignisfall kontrollierbar?
IT-Sicherheit und OT-Betriebsfähigkeit gehören heute in dieselbe Risikobetrachtung. Die Schnittstelle zwischen beiden ist der Ort, an dem NIS2 ansetzt.
OT steuert physischen Betrieb — nicht nur Informationen
IT verarbeitet Informationen. OT — Operational Technology — steuert oder überwacht physische Vorgänge: Maschinen, Produktionslinien, Anlagen, Gebäude- oder Versorgungssysteme. Der Unterschied ist keine Frage der Technologie, sondern der Wirkung: Ein IT-Vorfall betrifft Daten und Prozesse. Ein OT-Vorfall kann Produktion, Versorgung oder die Sicherheit von Menschen direkt betreffen.
Steuerung und Prozessführung
Übergeordnete Systeme zur Überwachung und Steuerung von Prozessen
Maschinen und Anlagensteuerung
Systeme zur direkten Steuerung und Regelung von Maschinen und Anlagen
Produktionsplanung und Betrieb
Systeme zur Planung, Steuerung und Auswertung der Produktion
Für OT-Umgebungen gilt IEC 62443 als international anerkannter Strukturrahmen — er adressiert genau diese Eigenheiten: Security Levels, Zonen- und Konduit-Konzepte, Lieferantenverantwortung und Systempflege in Produktionsumgebungen. NIS2 setzt keine spezifische Norm voraus, verweist aber auf anerkannte Standards als Nachweisoption.
Eine besondere Eigenheit der OT: Safety und Security sind hier keine getrennten Themen. Sicherheitsmaßnahmen dürfen den physischen Betrieb nicht destabilisieren. Ein Patch, der in der IT routinemäßig ausgerollt wird, kann in der OT einen Produktionsstopp bedeuten — oder schlimmer, eine Steuerung in einen undefinierten Zustand versetzen. Das erklärt, warum OT eigene Bewertungskriterien braucht, und warum klassische IT-Sicherheitslogik dort nicht direkt übertragbar ist.
In der klassischen IT gilt: Vertraulichkeit vor Integrität vor Verfügbarkeit. In vielen OT-Umgebungen gilt die umgekehrte Reihenfolge: Verfügbarkeit und Prozessstabilität zuerst — weil Produktionsstopp, unkontrollierter Anlagenzustand oder Safety-Ereignisse unmittelbare Konsequenzen haben können.
OT und IT sind längst keine getrennten Welten mehr
Die NIS2-Relevanz entsteht häufig nicht an der isolierten Maschine, sondern an der Verbindung: Fernwartung, Engineering Workstations, MES-/ERP-Anbindung, Historian, Cloud-Portale, Sensorik, Gateways und Retrofit schaffen Übergänge zwischen IT und OT. Aus früher abgeschotteten Anlagen werden erreichbare Betriebssysteme.
An diesen Verbindungspunkten entsteht die NIS2-Relevanz: nicht an der Maschine selbst, sondern am Zugang zu ihr — und an der Frage, wer diesen Zugang unter welchen Bedingungen nutzen darf.
Maschinenbauer und Integratoren greifen über VPN oder dedizierte Verbindungen direkt auf Steuerungen zu
Produktionsdaten fließen zwischen Steuerungsebene und kaufmännischen Systemen
Herstellerplattformen greifen auf Anlagendaten zu — oft mit eigenem Zugangsmanagement
Ältere Maschinen werden nachträglich mit Gateways und Sensoren ans Datennetz angebunden
Viele OT-Risiken wurden schrittweise mitgekauft
OT-Risiken entstehen selten durch eine einzelne Entscheidung. Fernwartungsverträge, neue Sensorik, MES-Anbindungen, Herstellerportale — sie kommen einzeln, über Jahre, aus verschiedenen Abteilungen. Produktion, Instandhaltung, IT und Integratoren haben oft unterschiedliche Sicht auf dieselbe Anlage. Die Verantwortungskette ist entsprechend verteilt — und selten vollständig dokumentiert.
Genau hier setzt §38 BSIG an: nicht mit der Erwartung, dass die Geschäftsführung jede Steuerung kennt, sondern mit der Pflicht, kritische Abhängigkeiten, Fernzugriffsregelungen und Wiederanlauffähigkeiten nachvollziehbar zu führen.
Die Geschäftsführung muss Cybersicherheitsrisiken verstehen, Maßnahmen billigen und Umsetzung überwachen. Für OT bedeutet das: nicht jede technische Entscheidung, aber die wesentlichen Abhängigkeiten, Risiken und Wiederanlauffähigkeiten gehören auf die Leitungsagenda.
OT-Risikofelder: gewachsene Strukturen, neue Anforderungen
Fernwartungszugänge
Hersteller- und Integratorkonten mit privilegierten Rechten, oft ohne regelmäßige Prüfung oder zeitliche Begrenzung
Privilegierte Rechte auf Steuerungssystemen
Administrative Zugänge auf Engineering Workstations oder SPS ohne Rollenmodell und Audit-Trail
Fehlende IT-/OT-Segmentierung
IT- und OT-Netze ohne ausreichende Trennung — Angriffe im IT-Netz können direkt auf Steuerungssysteme wirken
Eingeschränkte Patchbarkeit
Alte Steuerungssysteme und Betriebssysteme, die nicht oder nur mit Produktionsstopp aktualisiert werden können. Schwachstellenmanagement in OT bedeutet deshalb: bekannte Lücken bewerten, kompensierende Maßnahmen dokumentieren und Wiedervorlagen setzen — nicht zwingend sofort patchen.
Ungetestete Backups und Wiederanlaufpläne
Backup-Konzepte vorhanden, aber selten unter realen Produktionsbedingungen geprobt
Hersteller- und Integratorabhängigkeit
Keine Exit-Regelung, kein Wiederanlauf ohne Herstellerunterstützung — bei kleinen Nischenanbietern besonders kritisch
Cloud-Portale ohne klare Verantwortungsgrenze
Hersteller-Plattformen mit Zugriff auf Anlagendaten — Konfiguration, Zugriff und Meldewege liegen beim Kunden
Unklare Meldewege bei Vorfällen
Kein geregelter Informationskanal zwischen Produktion, IT-Abteilung und externen Dienstleistern im Ereignisfall
Was unter NIS2 dokumentierbar werden muss
§30 BSIG verlangt technische und organisatorische Maßnahmen — aber auch deren Nachweis. Für OT-Umgebungen fehlt dieser Nachweis in der Praxis häufig nicht wegen mangelnder Maßnahmen, sondern wegen fehlender Dokumentation: Wer hat welchen Zugang? Welche Abhängigkeit besteht? Was passiert im Ausfall? Diese Fragen müssen schriftlich beantwortet sein.
Anlagen und Systeme: Übersicht kritischer Anlagen, Steuerungssysteme und ihrer Betriebswirkung bei Ausfall.
Schnittstellen: IT-/OT-Verbindungen, Datenflüsse, Fernwartungszugänge, Berechtigungskonzept und Protokollierung.
Lieferanten und Integratoren: Wer hat Zugriff, wer beeinflusst den Betrieb, welche Subunternehmer und Herstellerplattformen sind eingebunden?
Betriebsfähigkeit: Getestete Backup- und Wiederanlaufpläne, Notbetriebskonzept, Prioritätenreihenfolge.
Meldewege und offene Punkte: Incident-Kommunikation zwischen Produktion, IT und Dienstleistern — mit Verantwortlichkeit und Wiedervorlage.
Wo NIS2 konkret anschließt
Drei Paragrafen des BSIG schaffen den konkreten Rahmen für OT-relevante Pflichten.
Risikomanagementmaßnahmen
Technische und organisatorische Maßnahmen für Anlagen, Fernzugänge, Lieferantenbewertung, Verfügbarkeit und Wiederanlauf. OT-Systeme sind Teil dieser Bewertung, wenn sie Betriebskritikalität oder Lieferantenabhängigkeit aufweisen. Das umfasst Segmentierung, Fernzugriffskontrolle, Schwachstellenmanagement und dokumentierte Nachweise.
Meldepflichten bei erheblichen Vorfällen
Ein OT-Vorfall gilt nach §32 BSIG als meldepflichtig, wenn er erhebliche Auswirkungen auf Systeme, Dienste oder die Versorgung Dritter hat. Für produzierende Unternehmen bedeutet das: Produktionsausfälle mit breiter Betriebswirkung, Störungen sicherheitsrelevanter Anlagen oder Vorfälle mit externen Auswirkungen fallen in diesen Bereich. Die 24h-Erstmeldung setzt voraus, dass Erkennungs- und Eskalationsprozesse vor dem Ereignisfall geregelt sind — nicht im Ernstfall erst aufgebaut werden.
Leitungsverantwortung
Die Geschäftsleitung muss nicht jede technische OT-Komponente steuern, aber kritische Abhängigkeiten, Restrisiken, Verantwortlichkeiten und Wiedervorlagen nachvollziehbar führen können. Billigung und Überwachung der Maßnahmen sind Leitungspflichten.
Ein Produktionsunternehmen hat mit einem Maschinenbauer einen Fernwartungsvertrag geschlossen. Der Anbieter nutzt einen VPN-Zugang zur SPS und kann Konfigurationen ändern. Es gibt keine schriftliche Regelung zu Meldewegen, Subunternehmern oder Reaktionszeiten im Störfall.
Unter §30 Abs. 2 Nr. 4 BSIG ist dieser Anbieter ein sicherheitsrelevanter Lieferant: direkter Systemzugriff, Betriebswirkung, kritische Abhängigkeit. Eine Lieferantenbewertung ist erforderlich. Die Freigabe sollte Meldewege, Subunternehmertransparenz und Wiederanlaufinformationen einschließen.
OT-Sicherheit entsteht zu großen Teilen in der Lieferkette
Ein charakteristisches Merkmal der OT-Lieferkette: Maschinenbauer und Integratoren kennen einzelne Anlagenkomponenten oft besser als die interne IT. Der Fernwartungsvertrag ist ihr Zugangsweg — und damit ein sicherheitsrelevanter Bestandteil der eigenen Betriebsinfrastruktur. Welche Vereinbarungen gelten, wenn dieser Zugang in einem Sicherheitsereignis eine Rolle spielt?
Hinzu kommt die Subunternehmerkette: Viele Maschinenbauer und MSPs setzen selbst auf spezialisierte Anbieter für Teile der Leistung. Diese Kette ist in OT-Umgebungen häufig weniger transparent als in klassischen IT-Lieferantenbeziehungen — und oft vertraglich nicht geregelt.
§30 Abs. 2 Nr. 4 BSIG verpflichtet betroffene Unternehmen, sicherheitsbezogene Beziehungen zu unmittelbaren Anbietern und Diensteanbietern zu berücksichtigen. Für OT bedeutet das: Maschinenbauer, Integratoren und Fernwartungsanbieter sind keine Außenstehenden — sie sind Teil des zu bewertenden Risikoraums. IEC 62443-2-1 gibt dafür einen anerkannten Strukturrahmen für Lieferantenbeziehungen in OT-Umgebungen.
Im Ereignisfall zählt kontrollierter Wiederanlauf
Ein Backup ohne getesteten Wiederanlauf bleibt eine Annahme. Die Frage ist nicht, ob ein Backup existiert — sondern ob der Wiederanlauf unter realen Bedingungen jemals geprobt wurde.
Ein Fernwartungsvertrag ohne Meldeweg bleibt eine Lücke. Im Ereignisfall fehlt die Zeit, Kommunikationswege erst zu organisieren.
Eine Anlagenliste ohne Kritikalität bleibt eine Inventur. Der Mehrwert entsteht, wenn bekannt ist, welcher Ausfall welche Konsequenz hat.
Im Ereignisfall entscheidet sich OT-Sicherheit nicht an vollständiger Dokumentation, sondern an der Fähigkeit zum kontrollierten Wiederanlauf: Welche Linie hat Priorität? Welche Freigaben sind erforderlich? Wer koordiniert mit welchem Dienstleister? Und in welchem Zeitfenster muss welche Kommunikation nach außen erfolgen? Diese Fragen sind Managementfragen — und sie müssen beantwortet sein, bevor der Ernstfall eintritt.
Was Unternehmen jetzt prüfen sollten
Die Nachweislandkarte zeigt, was vorhanden sein muss. Diese Schrittliste zeigt, womit man anfängt — und in welcher Reihenfolge.
Kritische Anlagen und Linien benennen
Welche Produktionsbereiche, Anlagen oder Systeme sind für den Betrieb unverzichtbar — und was passiert bei deren Ausfall?
IT-/OT-Schnittstellen erfassen
Wo verbinden sich IT-Netze und OT-Systeme? Welche Verbindungen bestehen über Fernwartung, MES, ERP oder Cloud-Portale?
Fernzugänge dokumentieren und einschränken
Für jeden aktiven Fernwartungszugang: Wer darf zugreifen, auf welches System, über welchen Kanal, mit welcher Authentifizierung — und liegt das schriftlich vor?
Dienstleister nach Zugriff und Betriebswirkung klassifizieren
Welcher Lieferant kann den OT-Betrieb beeinflussen? Welche Nachweise, Meldewege und Exit-Informationen liegen vor?
Wiederanlauf unter realen Bedingungen proben
Nicht nur: Existiert ein Wiederanlaufplan? Sondern: Wurde er getestet — unter Betriebsbedingungen, mit den beteiligten Dienstleistern, in der tatsächlichen Prioritätenreihenfolge?
Meldewege zwischen Produktion, IT und Lieferanten festlegen
Wer informiert wen bei einem OT-Sicherheitsereignis — und in welchem Zeitfenster? Gelten diese Wege auch für externe Dienstleister?
Offene Punkte mit Verantwortlichkeit und Wiedervorlage festhalten
Welche Lücken bestehen? Wer ist für die Bearbeitung verantwortlich? Bis wann, und wann wird erneut geprüft?
Vom OT-Risiko zur Arbeitsgrundlage
OT-Risiken werden unter NIS2 besonders dort relevant, wo Lieferanten, Fernzugriffe, Verfügbarkeit und Wiederanlauf zusammenkommen. Der Einstieg ist eine Lieferantenklassifizierung nach Systemzugriff, Datenbezug, Verfügbarkeitswirkung, Abhängigkeit und Nachweisstand.