NIS2 und IEC 62443: Der praktische Leitfaden für die Umsetzung in OT-Umgebungen

NIS2 und IEC 62443 sind für viele Industrie- und KRITIS-Betreiber 2026 die zwei Referenzpunkte, an denen OT-Umsetzung gemessen wird. NIS2 verlangt in Artikel 21 konkrete Risikomanagement- und Sicherheitsmaßnahmen — ohne OT-spezifische Detailvorgaben. IEC 62443 liefert genau diese Detailtiefe: Zonen, Conduits, Security Levels und Foundation Requirements für industrielle Automatisierungssysteme.

Der praktische Hebel liegt in der Verzahnung: NIS2 definiert was organisationale Verantwortung bedeutet; IEC 62443 beschreibt wie das in Werken, Anlagen und Lieferketten operationalisierbar wird. Wer beide getrennt plant, produziert parallele Excel-Listen. Wer sie verbindet, gewinnt auditfähige Nachweise und betriebsnahe Prioritäten.

NIS2 Artikel 21: Die Lücke in OT-Kontexten

Artikel 21 NIS2 nennt zehn Maßnahmenbereiche — von Risikoanalyse über Incident Handling bis Lieferkettensicherheit. Für OT-Betreiber entsteht die eigentliche Herausforderung nicht beim Lesen der Liste, sondern bei der Übersetzung:

• Risikoanalyse muss SPS, HMI, Safety-Systeme und Fernwartung gemeinsam betrachten — nicht nur Office-IT.
• Business Continuity kollidiert mit Wartungsfenstern und Prozess-Safety-Freigaben.
• Lieferkettensicherheit umfasst OEM-Komponenten, Integratoren und Update-Pfade — ein Schnittpunkt zum Cyber Resilience Act.

Viele Unternehmen haben NIS2-Programme auf Konzern-IT-Ebene gestartet. OT bleibt als „späterer Workstream“ hängen — obwohl dort der physische Schaden entsteht. Unser NIS2-FAQ-Artikel zeigt die Betroffenheitslogik; dieser Leitfaden fokussiert die OT-Brücke.

IEC 62443 als Brücke — nicht als Ersatz

IEC 62443 ersetzt NIS2 nicht und umgekehrt. Die Normenreihe strukturiert Industrial Cybersecurity entlang von:

• 62443-2-1 — Security-Management-System für IACS-Betreiber und Integratoren,
• 62443-3-3 — System-Security-Requirements und Security Levels,
• 62443-4-x — Komponenten-Anforderungen (4-1 Entwicklung, 4-2 Integration).

In der Praxis bedeutet das: NIS2-Artikel-21-Maßnahmen lassen sich auf 62443-Controls mappen — Risikoanalyse auf FR1 (Identifikation), Schutzmaßnahmen auf FR2 (Schutz), Incident Response auf FR6 (Reaktion). So entsteht ein gemeinsames Vokabular für Audit, Betrieb und Engineering.

System under Consideration und Security Level

Bevor Maßnahmen priorisiert werden, muss der System under Consideration (SuC) stehen: Welche Anlage, welches Werk, welche Produktionslinie ist Gegenstand des Programms? Zu breite SuC-Definitionen erzeugen unrealistische SL-Anforderungen; zu enge vernachlässigen Abhängigkeiten über Conduits.

Für viele Fertigungs- und Versorgungsumgebungen ist SL2 ein pragmatischer Startpunkt: Schutz gegen gelegentliche oder absichtliche Verletzung mit moderaten Ressourcen — ohne SL3/SL4-Komplexität, die Integrationsprojekte überfordert. SL-Ziele müssen pro Zone dokumentiert und mit betrieblicher Kritikalität begründet werden.

Gap Assessment entlang FR1, FR2, FR6

Ein belastbares Gap Assessment priorisiert drei Foundation Requirements:

1. FR1 — Identifikation und Authentifizierung: Wer darf an welches OT-Asset — Engineering-Station, HMI, Fernwartung?
2. FR2 — Systemintegrität: Wie werden unautorisierte Änderungen an Logik, Parametern und Konfiguration erkannt?
3. FR6 — Ressourcenverfügbarkeit und Reaktion: Wie reagiert das Team unter Störung — ohne Safety zu gefährden?

Typische Lücken: geteilte Engineering-Accounts (FR1), fehlende Integritätsüberwachung an SPS (FR2), und Incident-Playbooks ohne OT-Verantwortliche (FR6). Das Assessment sollte Ergebnisse in Maßnahmen mit Owner, Frist und Evidenzart übersetzen — nicht in generische „comply“-Checkboxen.

62443-2-1 / 3-3 / 4-x — wer ist verantwortlich?

2-1: Programmverantwortung, Policies, Schulung, Lieferantensteuerung — oft Konzern-OT-Security oder Werk-CISO.

3-3: Zonenarchitektur, Conduit-Regeln, SL-Nachweis pro SuC — OT-Architekt plus Integrator.

4-x: Komponenten-Härtung, Secure Development — Hersteller und Product Security; Betreiber prüfen Konformität in der Lieferkette.

CRA-Verknüpfung: Produkt- und Betriebsebene

Der Cyber Resilience Act verschiebt Verantwortung für Produkte mit digitalen Elementen — von Maschinensteuerungen bis Fernwartungsmodulen. NIS2 adressiert den Betreiber. In OT kollidieren beide:

• Ein kompromittiertes Update-Modul ist CRA-Produktvorfall und NIS2-Meldepflicht.
• SBOM-Lücken bei OEM-Komponenten erschweren FR2-Nachweise im SuC.
• Support-Enddaten für Feldgeräte betreffen gleichzeitig CRA-Konformität und OT-Verfügbarkeit.

Ein gemeinsames Readiness-Modell — wie in unserem Artikel zu Industrial CRA/NIS2 Readiness — verhindert widersprüchliche Prioritäten zwischen Werk und Konzern-IT.

Umsetzung in vier Phasen

Phase 1 — Scope und SuC

Betroffenheit NIS2 klären, SuC-Grenzen zeichnen, kritische Zonen identifizieren. Parallel: Portfolio digitaler Produkte in der Anlage — Gateways, Edge, Engineering-Tools.

Phase 2 — Gap Assessment

Ist-Zustand gegen FR1/2/6 und Ziel-SL2 spiegeln. Ergebnisse nach Betriebswirkung sortieren — nicht nach Audit-Kapitelnummer.

Phase 3 — Maßnahmen und Rollen

62443-2-1-Programmstruktur aufsetzen, 3-3-Architekturentscheidungen dokumentieren, 4-x-Anforderungen an Lieferanten schreiben. Rollen mit Entscheidungskompetenz besetzen — siehe IEC 62443 im Recruiting.

Phase 4 — Evidenz und Reife

Kontrollwirksamkeit prüfen, Tabletops mit OT-Beteiligung, Lieferanten-Audits stichprobenartig. NIS2-Nachweise und 62443-Artefakte in einer Datenbasis führen.

Personal als Engpassfaktor

Programme scheitern selten an fehlendem Normenwissen, sondern an fehlenden Hybridprofilen: wer FR-Gaps in Wartungsfenster übersetzt, wer Integratoren auf SL2 verpflichtet, wer CRA-Meldewege mit OT-Incident-Ketten verbindet. Der Markt für solche Profile ist eng — frühe Besetzung verbessert Umsetzungsgeschwindigkeit messbar.

Typische Fehler in der Praxis

Drei Muster wiederholen sich in Mandaten, die wir begleiten:

Fehler 1: Normenstapel ohne SuC

Teams kaufen Beratung für NIS2, CRA und 62443 parallel — ohne gemeinsame Systemgrenze. Ergebnis: widersprüchliche SL-Ziele und doppelte Inventurarbeit. Gegenmaßnahme: ein Architekturboard mit SuC als verbindlichem Anker.

Fehler 2: SL3/SL4 als Default

Integratoren verkaufen maximale Security Levels; Betrieb kann sie in Wartungsfenstern nicht halten. Gegenmaßnahme: SL2 begründen, SL-Anhebung an konkrete Bedrohung und Nachweis koppeln.

Fehler 3: Evidenz ohne Betriebsbezug

Policies existieren, aber Engineering-Accounts bleiben geteilt, Fernwartung ungeprüft. Auditoren erkennen das schneller als interne Teams. Gegenmaßnahme: Gap-Assessment-Ergebnisse mit Owner und Quartals-KPI verknüpfen — z. B. Anteil abgeschlossener FR1-Maßnahmen in kritischen Zonen.

KPI-Set für Steuerung

Für Führungsteams reichen wenige Kennzahlen:

• Anteil SuC-Zonen mit dokumentiertem SL und Conduit-Regel,
• offene FR1/2/6-Hochrisiko-Lücken mit Frist und Owner,
• Integratoren-Verträge mit 62443-4-x- und CRA-Klauseln,
• Time-to-Productive neuer OT-Security-Rollen im Werk.

Diese KPI trennen Compliance-Theater von belastbarer Umsetzung. Ergänzend lohnt ein monatlicher Abgleich zwischen Konzern-NIS2-Reporting und Werk-62443-Status — ohne diese Brücke verlieren Führungsteams den OT-Fortschritt aus dem Blick.

Verwandte Vertiefungen

• NIS2 in Unternehmen: Bin ich betroffen und was ist genau zu tun?
• IEC 62443 im Recruiting: Industrial Cybersecurity 2026
• Industrial Security: CRA- und NIS2-Readiness-Projekte

Fazit

NIS2 und IEC 62443 zusammen liefern ein belastbares Umsetzungsmodell für OT: Artikel 21 als organisationale Pflicht, 62443 als technisch-betriebliche Brücke mit SuC, SL2 und FR1/2/6-Gap Assessment. Wer CRA-Produktpflichten in dasselbe Steuerungsmodell integriert, vermeidet Doppelarbeit und gewinnt auditfähige Resilienz in Werken und KRITIS-Kontexten.

Vertiefung: IEC 62443 Recruiting, NIS2-Umsetzung. Besetzung: Cybersecurity Recruiting.