Industrial Security / OT – Was Betreiber jetzt wissen müssen
Überarbeitete Fassung · Stand: 31.01.2026
Maschinen und Anlagen werden immer häufiger vernetzt: Remote-Service, VPN-Zugänge, Industrie-PCs, Edge-Gateways, OPC UA, MES/ERP-Anbindung, Robotik, FTS/AGV. Das bringt Tempo – aber auch eine neue Angriffsfläche. Ein Security-Vorfall kann in der OT direkt zu Stillstand, Ausschuss oder gefährlichen Zuständen führen.
Darum wird Industrial Security (OT) gerade von „nice to have“ zu Pflicht: rechtlich, wirtschaftlich und in der Abnahme-Praxis.
1) Warum OT-Security für Betreiber jetzt wichtig ist
OT ist nicht IT
In der IT geht es oft um Daten. In der OT geht es zuerst um Verfügbarkeit und sichere Funktion: Antriebe, Pressen, Hydraulik, Roboter, Schutzeinrichtungen, Steuerungen. Das ändert die Prioritäten: Ein „kleines“ Security-Loch kann große reale Folgen haben.
Angriffe zielen auf Ausfallkosten
In der Industrie sind typische Ziele:
- Produktionsstopp (Erpressung über Stillstand)
- Manipulation (Parameter, Rezepte, Grenzwerte)
- Einfall über Fernwartung oder Dienstleister
Die Frage ist deshalb nicht „ob“, sondern: Wie robust ist der Betrieb, wenn etwas passiert?
Security berührt Safety
Wenn sicherheitsrelevante Funktionen, Parameter oder Daten digital beeinflusst werden können, wird Security schnell zum Safety-Risiko. Das heißt nicht, dass Safety „durch Security ersetzt“ wird – aber: Die digitale Manipulation gehört in die Betrachtung.
2) Was sich rechtlich ändert (und warum das OT betrifft)
Zeitachse (EU)
- Maschinenverordnung (EU) 2023/1230: anzuwenden ab 20.01.2027
- NIS2-Richtlinie (EU) 2022/2555: anzuwenden ab 18.10.2024 (nationale Umsetzung bis dahin)
- Cyber Resilience Act (EU) 2024/2847: veröffentlicht 20.11.2024; Meldepflichten für Hersteller ab 11.09.2026; vollständig anzuwenden ab 11.12.2027
Merksatz: Für Betreiber wird Security damit gleichzeitig Abnahme-Thema, Lieferketten-Thema und Management-Thema.
A) Maschinenverordnung: „Schutz gegen Korrumpierung“ wird prüfbar
Mit der Maschinenverordnung wird Cybersecurity in der Maschinenwelt sichtbarer. Kernpunkt: Schutz vor digitaler Manipulation sicherheitsrelevanter Funktionen (z. B. über Netzwerke, Remote-Zugriffe, angeschlossene Geräte).
Was das in der Praxis heißt:
- Remote-Zugänge so auslegen, dass daraus keine gefährliche Situation entstehen kann
- Sicherheitsrelevante Software/Parameter/Daten identifizieren und gegen unberechtigte Änderungen absichern
- Änderungen müssen erkennbar, nachvollziehbar und beherrschbar sein (Change/Logs)
- Manipulation wird Teil der Risikobetrachtung – nicht erst nach einem Vorfall
Wichtig für Betreiber: Auch wenn neue Maschinen im Fokus stehen, wird das Thema bei Abnahmen, Retrofits und Betreiberpflichten zunehmend mitlaufen. Standards sind im Aufbau (z. B. EN 50742; bis dahin lohnt es sich, am „Stand der Technik“ zu orientieren).
B) NIS2: Cybersecurity wird Management-Pflicht (inkl. Meldefristen)
NIS2 bringt für viele Branchen: Risikomanagement, Verantwortlichkeiten und Meldewege bei erheblichen Vorfällen. In der Umsetzung gibt es Details je Land/Sektor – der Trend ist aber klar.
Praktisch relevant: Bei Vorfällen sind kurze Fristen vorgesehen (z. B. Frühwarnung binnen 24 h, Bericht binnen 72 h). Das funktioniert nur, wenn OT überhaupt „sichtbar“ ist (Assets, Logs, Prozesse).
C) Cyber Resilience Act (CRA): Druck über Produkte und Lieferkette
Der CRA setzt Anforderungen an „Produkte mit digitalen Elementen“. Für Betreiber bedeutet das: Security-Nachweise werden einkaufs- und abnahmefähig – nicht nur ein internes IT-Thema.
Typische Konsequenzen:
- Mehr Fragen zu Supportdauer, Security Updates und Patch-Fenstern
- Mehr Unterlagen: SBOM (Software-Stückliste), Advisories, Hinweise zu Schwachstellen
- Klarere Prozesse bei Schwachstellen (Meldung, Bewertung, Fix, Kommunikation)
D) Deutschland: KRITIS/BSI (falls betroffen)
Wenn ein Betreiber als KRITIS gilt oder in nationale Pflichten fällt, kommen zusätzliche Anforderungen (Nachweise, Mindeststandards, teils Audits/Prüfungen, Meldewege).
3) Was Betreiber praktisch brauchen (Minimum + Nachweis)
Wo es typischerweise kippt
In der Praxis sehe ich fast immer dieselben Baustellen:
- Fernwartung historisch gewachsen (ohne MFA, ohne Freigabeprozess, ohne Protokollierung)
- Flache Netze (Büro-IT und Maschinen „zu nah“ beieinander)
- Alte Systeme (nicht patchbar) ohne Kompensationsmaßnahmen
- Geteilte Accounts/Passwörter, unklare Rollen
- Kein getestetes Restore (Backup ist da, aber Rücksicherung nicht geübt)
Segmentierung: klein anfangen, aber konsequent
Wenn du nur eine Sache sauber machst: Zonen trennen. Ein einfaches Bild ist Purdue: oben Office/IT, unten Produktion/OT, dazwischen eine DMZ für definierte Datenflüsse.
Minimum-Setup:
- IT/OT-Trennung (keine „flachen“ Netze)
- DMZ für Übergänge (Reporting, Historian, Jump Host)
- OT-Zellen als Zonen – mit klaren Conduits (Ports/Protokolle dokumentiert)
- Remote Access nur über definierte Wege (zeitlich begrenzt, MFA, Logging)
Das Minimum, das ein Betreiber heute haben sollte
- Asset-Übersicht OT (Geräte, Softwarestände, Verantwortliche, Zugänge)
- Zonen-/Conduit-Plan (ein Blatt reicht – aber stimmt)
- Remote-Access-Konzept (MFA, Freigabe, Protokollierung, Not-Aus des Zugangs)
- Backup/Restore (inkl. Test der Rücksicherung)
- Patch/Vulnerability Prozess (inkl. Kompensation, wenn nicht patchbar)
- Rollen & Rechte (least privilege, keine Shared Admins)
- Incident-Plan (Kontaktkette, Entscheidungspunkte, Wiederanlauf)
- Lieferantensteuerung (Security-Anforderungen in Angebote/Verträge)
Was Prüfer/Abnehmer gerne als „Nachweis“ sehen
- Zonen-/Conduit-Skizze + Regelwerk (welche Verbindungen sind erlaubt und warum)
- Liste Fernzugänge + wer sie freigibt + wie sie protokolliert werden
- Backup-/Restore-Protokoll (wann getestet, was wiederherstellbar)
- Regel für Schwachstellen/Patches (wie wird bewertet und entschieden)
- Incident-Plan (wer macht was, wann, mit welchen Dienstleistern)
IEC 62443 als Orientierung
IEC 62443 ist die wichtigste Struktur für OT-Security. Du musst nicht alles auswendig können – aber du solltest die Logik kennen:
- Zonen & Conduits
- Security Levels (SL) als Zielniveau pro Zone
- 7 Grundkategorien (Foundational Requirements) als Checkliste
- Betreiberprozesse (Teil 2), System/Risiko (Teil 3), Komponenten (Teil 4)
Schnellstart: 30 Tage, realistisch
- Woche 1: Asset-Liste + alle Zugänge aufschreiben (auch „inoffizielle“)
- Woche 2: IT/OT trennen + DMZ definieren + Regeln dokumentieren
- Woche 3: Remote Access sauber ziehen (MFA, Freigabe, Logging) + Restore testen
- Woche 4: Incident-Plan + Lieferantenanforderungen (Updates, SBOM/Advisories, Supportdauer)
4) Warum es jedes Jahr wichtiger wird
Regulatorik, Vernetzung und Angriffe bewegen sich gleichzeitig. Wer heute die Basics sauber macht (Segmentierung, Fernwartung, Restore, Prozesse), reduziert Ausfallrisiko und wird abnahme- und lieferkettenfähig.
5) Was ich tun kann
Kurzquellen (für Termine/Grundlagen)
https://pohlann.de/industrial-security-ot-in-maschinen-und-anlagen-warum-es-jetzt-zur-pflicht-wird/
Pilz: IEC 62443 Überblick (DE)
https://www.pilz.com/de-DE/support/law-standards-norms/industrial-security-standards-iec-62443
Pilz: Industrial Security (OT) Überblick
https://www.pilz.com/de-DE/produkte/industrial-security
EU Maschinenverordnung (EU) 2023/1230 (EUR-Lex, DE)
https://eur-lex.europa.eu/eli/reg/2023/1230/oj?locale=de
EU NIS2-Richtlinie (EU) 2022/2555 (EUR-Lex, DE)
https://eur-lex.europa.eu/eli/dir/2022/2555/oj?locale=de
EU Cyber Resilience Act (EU) 2024/2847 (EUR-Lex, EN)
https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng
EU Cyber Resilience Act (EU) 2024/2847 (EUR-Lex, DE-Ansicht)
https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng?eliuri=eli%3Areg%3A2024%3A2847%3Aoj&locale=de
DIN Media: DIN EN IEC 62443-2-1
https://www.dinmedia.de/de/norm/din-en-iec-62443-2-1/391454082
DIN Media: DIN EN IEC 62443-2-4
https://www.dinmedia.de/de/norm/din-en-iec-62443-2-4/380674327
Pilz Whitepaper (öffentliches PDF-Preview – kann von deiner Datei-Version abweichen)
https://www.hannovermesse.de/apollo/hannover_messe_2025/obs/Binary/A1408833/Preview_Whitepaper_Industrial_Security_de_low_v0.pdf
DKE Überblick: IEC 62443
https://www.dke.de/iec-62443
BSI: ICS/OT Tools & Empfehlungen
https://www.bsi.bund.de/EN/Themen/Unternehmen-und-Organisationen/Informationen-und-Empfehlungen/Empfehlungen-nach-Angriffszielen/Industrielle-Steuerungs-und-Automatisierungssysteme/Tools/tools.html