OT-Security für Betreiber bedeutet nicht, klassische IT einfach in die Produktion zu kopieren. Es geht darum, Maschinen, Anlagen, Netze und Zugänge so zu betreiben, dass Ausfälle, Manipulationen und Sicherheitsvorfälle beherrschbar bleiben.
In der Praxis geht es vor allem um vier Dinge:
- typische Bedrohungen verstehen
- regulatorische Anforderungen richtig einordnen
- Zuständigkeiten im Betrieb klären
- Risiken als wiederholbaren Betreiberprozess behandeln
Angriffsziele, Bedrohungsszenarien und wirtschaftliche Folgen
Angriffe auf OT- und Automatisierungssysteme zielen in der Praxis meist auf drei Bereiche:
Verfügbarkeit
Stillstand einzelner Maschinen oder ganzer Linien, Produktionsunterbrechung, Lieferverzug und erschwerter Wiederanlauf.
Integrität
Manipulation von Parametern, Programmen, Kommunikation, Messwerten oder Systemzuständen.
Vertraulichkeit
Abfluss von Rezepturen, Produktionsdaten, Qualitätsdaten, Zugangsdaten und technischem Know-how.
Typische Bedrohungsszenarien entstehen oft nicht durch spektakuläre „High-Tech-Angriffe“, sondern aus normalen Betriebsabläufen heraus: gewachsene Fernwartungszugänge, Service-Laptops, USB-Datenträger, lange Update-Zyklen, ungeklärte Zuständigkeiten, gemeinsame Accounts, Phishing, Social Engineering oder exponierte Komponenten.
Wirtschaftlich wirkt das schnell in den Betrieb hinein: Stillstand, Wiederanlauf, Wiederherstellung, Forensik, Neuaufsetzen von Systemen, Lieferprobleme, Vertragsstrafen und Imageschäden. Selbst wenn ein Vorfall zunächst wie ein IT-Problem aussieht, kann die OT indirekt mitbetroffen sein, weil Identitäten, zentrale Dienste, Planung oder Logistik mit der Produktion verbunden sind.
Warum Betreiber handeln müssen
Mehrere EU-Regelwerke erhöhen den Druck auf Betreiber — teils direkt über Pflichten für Unternehmen, teils indirekt über Anforderungen an Produkte, Lieferketten und Beschaffung.
Die NIS-2-Richtlinie musste von den Mitgliedstaaten bis zum 17.10.2024 in nationales Recht umgesetzt werden. In Deutschland gelten die Registrierungs- und Meldepflichten aus dem NIS-2-Umsetzungsgesetz seit dem 06.12.2025.
Der Cyber Resilience Act ist am 10.12.2024 in Kraft getreten. Die Reporting-Pflichten gelten ab dem 11.09.2026, die wesentlichen Pflichten insgesamt ab dem 11.12.2027.
Die Maschinenverordnung (EU) 2023/1230 gilt ab dem 14.01.2027.
Für Betreiber heißt das praktisch: OT-Security darf nicht aus Einzelmaßnahmen bestehen. Sie muss als steuerbarer, dokumentierter und im Alltag tragfähiger Prozess aufgebaut sein.
NIS2: Was für Betreiber praktisch relevant ist
NIS2 betrifft nicht pauschal „alle Betreiber“, sondern Unternehmen und Einrichtungen, die nach Sektor, Größe und gegebenenfalls besonderen Kriterien in den Anwendungsbereich fallen.
In der Praxis ist das für viele Industrieunternehmen relevant, vor allem dann, wenn sie in kritischen oder wichtigen Bereichen tätig sind oder als Teil der Lieferkette Ausfallfolgen verstärken.
Für betroffene Unternehmen zählt vor allem Folgendes:
- Cyberrisiken müssen systematisch bewertet und behandelt werden.
- Es müssen technische und organisatorische Maßnahmen umgesetzt werden.
- Sicherheitsvorfälle müssen gemeldet werden.
- Lieferkettenrisiken müssen berücksichtigt werden.
- Verantwortlichkeiten, Abläufe und Nachweise müssen klar definiert sein.
- Die Wirksamkeit der Maßnahmen muss überprüfbar sein.
NIS2 macht Cybersicherheit damit ausdrücklich zu einer Management- und Betreiberaufgabe.
CRA und Maschinenverordnung: Warum das Betreiber indirekt trifft
Der Cyber Resilience Act richtet sich in erster Linie an Hersteller von Produkten mit digitalen Elementen. Für Betreiber wirkt er aber unmittelbar über Beschaffung, Ersatzteilstrategie, Lifecycle-Fragen und Lieferkette.
Relevant sind vor allem:
- Secure-by-Design
- Schwachstellenmanagement
- Updates
- Transparenz zu Sicherheitsproblemen
- Konformitätsfragen
Die Reporting-Pflichten gelten ab dem 11.09.2026, die volle Anwendung ab dem 11.12.2027.
Die Maschinenverordnung wird für Betreiber vor allem dann relevant, wenn Maschinen neu beschafft, umgebaut, modernisiert oder nachgerüstet werden. Cyberrisiken müssen dort berücksichtigt werden, wo sie sicherheitsrelevante Funktionen beeinflussen können.
Der praktische Bezug liegt deshalb in:
- Beschaffung
- Retrofit
- Abnahme
- sicherem Betrieb
Organisation und Zuständigkeiten beim Betreiber
OT-Security ist kein reines Technikthema. Ohne klare Rollen, Freigaben und Zuständigkeiten wird sie im Alltag umgangen oder bleibt Stückwerk.
Die grundlegenden Rollen sind:
Betreiber / Asset Owner
Verantwortet Betrieb, Instandhaltung, Regeln, Freigaben, Risikoentscheidungen und die Steuerung externer Dienstleister.
Hersteller
Liefert Produktinformationen, Hinweise zu Schwachstellen, Updates und Informationen über den Lebenszyklus der Komponenten oder Maschine.
Integrator
Plant, baut und implementiert die Lösung und übersetzt Anforderungen in eine real umsetzbare Architektur.
Dienstleister
Übernimmt je nach Fall Wartung, Inbetriebnahme, Fernzugriff oder zeitweisen Betrieb im Auftrag des Betreibers.
Ein typischer Schwachpunkt sind privilegierte Zugänge. Fernwartung muss deshalb wie ein kritischer Prozess behandelt werden: mit klaren Regeln, sauberen Freigaben und dokumentierten Verantwortlichkeiten.
Was organisatorisch stehen muss
Beim Betreiber müssen mindestens vier Dinge belastbar geregelt sein:
Erstens: die Koordination zwischen IT und OT.
Wer entscheidet? Wer priorisiert? Wer meldet? Wer steuert Dienstleister?
Zweitens: ein wiederholbarer OT-Security-Prozess statt einzelner Sonderaktionen.
Drittens: klare Regeln und Schulung für eigenes Personal und externe Dienstleister.
Viertens: Kennzahlen oder Reviews, die zeigen, ob Maßnahmen tatsächlich wirken.
Ohne diese organisatorische Basis bleibt auch gute Technik instabil.
ISMS und OT-Security: Wie das zusammengehört
Ein ISMS macht Informationssicherheit steuerbar. Es regelt Verantwortlichkeiten, Risikomanagement, Prozesse, Dokumentation und Nachweise. Für viele Unternehmen ist das bereits vorhanden oder im Aufbau.
Für OT reicht ein allgemeines ISMS allein aber nicht aus. Produktion und OT haben andere Randbedingungen als klassische IT:
- lange Laufzeiten
- Echtzeitkommunikation
- Safety-Bezug
- Wartungsfenster
- Altsysteme
- Fremdfirmenzugänge
- hohe Anforderungen an Verfügbarkeit
ISMS-Vorgaben müssen deshalb für OT übersetzt werden.
Praktisch heißt das:
- Zugriffe und Fernwartung müssen mit Freigaben, Mehrfaktor-Authentifizierung, VPN, Jump-Systemen und Protokollierung geregelt sein.
- Änderungen an PLC, HMI und Netzstrukturen müssen dokumentiert und freigegeben werden.
- Patch- und Schwachstellenmanagement muss mit realen Wartungsfenstern funktionieren.
- OT-Vorfälle müssen als eigene Kategorie verstanden und behandelt werden.
- Lieferanten- und Dienstleistersteuerung muss Teil des Sicherheitsrahmens sein.
Merksatz:
Das ISMS ist der organisatorische Rahmen. Das OT-Security-Programm ist die betriebliche Umsetzung dieses Rahmens in der Produktion.
Maturity Level (ML): Wann Prozesse wirklich tragfähig sind
Technik allein reicht nicht. Entscheidend ist, ob die Organisation die zugehörigen Prozesse dauerhaft betreiben kann. Genau dafür ist der Maturity Level wichtig.
ML1 – Initial
Security wird grundsätzlich verstanden, vieles ist aber personenabhängig. Prozesse beginnen, sind aber noch nicht stabil.
ML2 – Managed
Grundlegende Prozesse sind definiert. Zuständigkeiten sind klar. Schulung und Kompetenz sind organisiert. Verfahren und Dokumente existieren und werden genutzt.
ML3 – Defined
Die Prozesse laufen verlässlich und nach einem Standard. Änderungen, Zugriffe, Vorfälle und Dienstleisterzugänge werden nicht ad hoc, sondern regelbasiert behandelt.
ML4 – Optimised
Wirksamkeit wird messbar gemacht. Kontinuierliche Verbesserung ist Teil des Betriebs. Security wird aktiv geführt und nicht nur im Ereignisfall reaktiv bearbeitet.
Die praktische Aussage ist einfach: Eine technische Zielarchitektur bringt wenig, wenn die Organisation die nötigen Prozesse dafür nicht dauerhaft tragen kann.
Ablauf der Risikoanalyse als Betreiberprozess
Eine saubere OT-Risikoanalyse ist kein einmaliges Dokument. Sie ist ein wiederkehrender Betreiberprozess.
1. Faktenbasis schaffen
Zuerst wird der Umfang festgelegt: Maschine, Zelle, Linie oder Standortteil.
Danach folgt die Ist-Aufnahme:
- Architektur
- Inventar
- Kommunikationswege
- Zugänge
- Fernwartung
- externe Services
- Dienstleister
- Abhängigkeiten zwischen IT und OT
2. Initial bewerten und priorisieren
Dann wird definiert, welches Risiko tolerierbar ist. Auf dieser Basis werden die größten Risiken und die wichtigsten Hebel priorisiert.
Ziel ist nicht Vollständigkeit um jeden Preis, sondern eine belastbare erste Priorisierung.
3. Struktur schaffen
Danach wird das System in Zonen und definierte Kommunikationswege zwischen diesen Zonen aufgeteilt. Das schafft die Grundlage für Segmentierung und Defense in Depth.
Entscheidend ist, welche Kommunikation wirklich notwendig ist — und welche nicht.
4. Bei Bedarf vertiefen
Detailliert bewertet wird dort, wo das initiale Risiko über der Toleranz liegt. Nicht jede Anlage braucht sofort dieselbe Tiefe. Die Analyse folgt der Risikolage.
5. Anforderungen dokumentieren
Am Ende muss klar beschrieben sein,
- was technisch umgesetzt werden muss,
- was organisatorisch geregelt werden muss,
- unter welchen Annahmen und Randbedingungen das Ganze gilt.
6. Managemententscheidung treffen
Zum Schluss wird entschieden,
- welche Risiken akzeptiert werden,
- welche reduziert werden,
- welches Restrisiko verbleibt.
Greifbare Ergebnisse
Am Ende eines solchen Prozesses sollte der Betreiber nicht nur eine Bewertung, sondern nutzbare Ergebnisse in der Hand haben:
- ein belastbares Architekturdiagramm und ein aktuelles Inventar
- ein Zonen- und Kommunikationsmodell als Grundlage für Segmentierung
- priorisierte Risikopunkte und konkrete Handlungsfelder
- technische und organisatorische Anforderungen
- ein dokumentiertes Restrisiko und eine Managemententscheidung zur Risikoakzeptanz
Das ist der Punkt, an dem OT-Security von einer Idee zu einer betreibbaren Struktur wird.
Typische erste Maßnahmen mit hoher Wirkung
Oft lassen sich schon ohne großen Umbau deutliche Verbesserungen erreichen.
Fernwartung aufräumen
Klare Regeln, klare Freigaben, saubere Nachvollziehbarkeit, privilegierte Zugänge gezielt absichern.
Segmentierung Schritt für Schritt verbessern
Saubere Übergänge, definierte Kommunikationspfade, unnötige Verbindungen entfernen.
Zugänge und Accounts ordnen
Wer darf was, warum und wie wird das nachvollziehbar dokumentiert?
Basis-Hygiene sichern
Inventar, Versionsstände, Backups und Wiederanlauf als echte Betriebsrealität aufbauen.
So unterstütze ich
Ich unterstütze Betreiber pragmatisch dabei, OT-Security im laufenden Betrieb umzusetzen: mit klarer Ist-Aufnahme, priorisierten Risiken, einem umsetzbaren Zonen-/Kommunikationsmodell und einer sauberen Anforderungsspezifikation als Grundlage für technische und organisatorische Maßnahmen.
Hinweis: keine Rechtsberatung. Schwerpunkt ist technische und organisatorische Umsetzung inklusive nachvollziehbarer Dokumentation.