Das Sicherheitsprogramm der OT-Dienstleister (IEC 62443-2-4)

Problem in der Praxis

Das Rollenmodell der IEC 62443 trennt Betreiber, Integrator/Dienstleister und Hersteller (ot-001). In der Praxis ist die Dienstleisterseite oft die am schwächsten gesteuerte: Integratoren bauen und ändern Anlagen, Instandhalter greifen regelmäßig und häufig aus der Ferne auf Steuerungen zu, und Wartungsverträge stammen aus einer Zeit, in der Security kein Vertragsgegenstand war.

Ohne ein Referenzwerk für die Dienstleisterseite entstehen typische Muster:

• Jede Ausschreibung erfindet ihre Sicherheitsanforderungen neu; Angebote verschiedener Dienstleister sind nicht vergleichbar.
• Verträge verweisen pauschal auf den Stand der Technik oder auf "IEC 62443" als Ganzes, ohne Teil, Ausgabe und erwartete Nachweise zu benennen.
• Sicherheitszusagen bleiben Behauptungen, weil nicht vereinbart ist, welche Prozesse der Dienstleister nachweist und womit.
• Die Verantwortung zwischen eigenem Betreiberprogramm und den Prozessen des Dienstleisters ist nicht geschnitten; im Vorfall zeigt jeder auf den anderen.

Der Teil 2-4 adressiert genau diese Lücke: ein benennbares Werk, gegen das der Betreiber Erwartungen an Dienstleister formulieren kann, statt sie je Projekt neu zu verhandeln.

CISO-Einordnung

IEC 62443-2-4 trägt den Titel "Security program requirements for IACS service providers" und adressiert im Rollenmodell der Reihe den System Integrator beziehungsweise Service Provider, also Dienstleister, die eine Automatisierungslösung integrieren oder instandhalten. Nach dem frei einsehbaren Herausgeber-Abstract geht es um sicherheitsbezogene Prozesse, die der Dienstleister dem Betreiber anbieten kann; ihre Gesamtheit bildet das Security Program des Dienstleisters für IACS-Betreiber. Drei Einordnungen sind für den CISO wichtig.

Erstens das Spiegelverhältnis zur 62443-2-1: Das Abstract benennt ausdrücklich, dass IEC 62443-2-1 die Anforderungen an das Security-Management des Betreibers selbst beschreibt. Betreiberprogramm und Dienstleisterprogramm sind zwei getrennte Gegenstände: ot-003 beschreibt, wie der Betreiber sein eigenes Programm aufbaut, einschließlich der Dienstleistersteuerung als Programmbestandteil; der Teil 2-4 ist das Werk für die Gegenseite, an dem sich messen lässt, was der Dienstleister mitbringt.

Zweitens die Anschlussfähigkeit in die Technik: Laut Abstract stehen einzelne Anforderungen der 2-4 in Beziehung zu Sicherheitsanforderungen der IEC 62443-3-3 (Systemebene) und IEC 62443-4-2 (Komponentenebene). Prozesszusagen des Dienstleisters und technische Schutzniveaus (ot-002, ot-004) gehören deshalb zusammen gedacht.

Drittens der Profilmechanismus: Das Abstract sieht vor, dass über Profile Teilmengen der Anforderungen für bestimmte Branchen und Organisationen gebildet werden können. Für den Betreiber heißt das: "konform zu IEC 62443-2-4" ist ohne die Angabe, welche Teilmenge gemeint ist, keine belastbare Aussage. Wie die Profilbildung im Einzelnen funktioniert, steht nur im Normtext selbst.

Was dieser Artikel bewusst nicht leistet: Die konkreten Anforderungen im Wortlaut, ihre Begründungen und die Tabellen des Anhangs A stehen ausschließlich im kostenpflichtigen Originaltext. Die Anforderungskennungen und ihre Kategorien führt seit dem 08.08.2026 das Katalogmodul des Navigators als Bewertungsraster für die Lieferantenbewertung; den Anforderungsinhalt trägt es nicht. Wer den Teil 2-4 in Beschaffung oder Prüfung ernsthaft einsetzen will, braucht Zugriff auf den Normtext. Gesetzliche Stichtage kennt die Normenreihe nicht; Verbindlichkeit entsteht über Verträge und über dahinterliegende Regulierung wie NIS-2 (nis2-005).

Umsetzungsperspektive

Für einen Betreiber liegt der praktische Wert des Teils 2-4 in Beschaffung und Vertragsgestaltung:

• Referenz statt Eigenbau: Ausschreibungen für Integrations- und Instandhaltungsleistungen benennen das Werk mit Teil und Ausgabe (IEC 62443-2-4:2023, Edition 2.0) und fragen ab, welche sicherheitsbezogenen Prozesse der Dienstleister danach anbietet, statt einen eigenen Anforderungskatalog zu erfinden.
• Nachweise vereinbaren: Welche Belege der Dienstleister für seine Prozesse vorlegt (Beschreibung seines Security Programs, Berichte, Bestätigungen Dritter) und in welchem Turnus, ist Vertragsgegenstand; das Werk zu nennen ersetzt keinen Nachweis.
• Teilmenge explizit machen: Wo mit Profilen beziehungsweise Teilmengen der Anforderungen gearbeitet wird, gehört in Angebot und Vertrag, welche Teilmenge gilt und warum.
• Versionsstand fixieren und beobachten: OT-Verträge laufen über viele Jahre. Beim Herausgeber ist bereits ein Nachfolgeprojekt Edition 3.0 gelistet (Status PREPARING, Prognosedatum 31.05.2028); das ist eine verschiebliche Herausgeber-Prognose, kein Termin. Verträge sollten regeln, was bei einem Ausgabenwechsel gilt.
• Anschluss an das eigene Programm: Die Dienstleistersteuerung (Zugänge, Fernwartung, Änderungen, Vorfallmeldung) bleibt Bestandteil des Betreiberprogramms nach ot-003; der Teil 2-4 liefert die Referenz für die Gegenseite, nicht den Ersatz für eigene Steuerung.

Typische Fehler

1. Sicherheitsanforderungen an OT-Dienstleister je Projekt neu erfinden, statt gegen das dafür vorgesehene Werk der Reihe zu formulieren.
2. In Verträgen pauschal auf "IEC 62443" verweisen, ohne Teil, Ausgabe und erwartete Nachweise zu benennen.
3. Rollen verwechseln: vom Dienstleister ein Betreiberprogramm nach 62443-2-1 verlangen oder umgekehrt die eigene Betreiberverantwortung an den Integrator delegieren.
4. "Konform zu IEC 62443-2-4" akzeptieren, ohne die geltende Teilmenge (Profil) und die vereinbarten Nachweise festzuhalten.
5. Annehmen, dieser Artikel oder andere Sekundärquellen ersetzten den Normtext; die Anforderungen selbst stehen nur im kostenpflichtigen Original.
6. Die regulatorische Pflichtenseite vergessen: Lieferkettensicherheit unter NIS-2 (nis2-005) gilt unabhängig davon, ob ein Vertrag die 62443-2-4 nennt.

Risiken und Trade-offs

Der erste Trade-off liegt zwischen Anspruch und Markt: Wer von jedem Dienstleister umfassende Nachweise nach 62443-2-4 verlangt, verkleinert den Bieterkreis und verteuert Leistungen; gerade kleinere, spezialisierte Instandhalter kennen das Werk teils nicht. Abgestufte Anforderungen je Kritikalität der Anlage und des Zugriffs sind meist tragfähiger als ein Einheitsanspruch.

Der zweite Trade-off betrifft die Bindung an den Versionsstand: Eine auf die Edition 2.0 fixierte Vereinbarung ist präzise, muss aber den Ausgabenwechsel regeln; ein gleitender Verweis auf die jeweils aktuelle Fassung importiert künftige, heute unbekannte Anforderungen in laufende Verträge.

Drittens bleibt ein Steuerungsrisiko: Ein benanntes Referenzwerk und vorgelegte Nachweise ersetzen nicht die eigene Kontrolle über Zugänge, Änderungen und Vorfälle. Die Verantwortung des Betreibers für seine Anlage lässt sich nicht auf den Dienstleister abwälzen; gute Verträge ordnen sie, heben sie aber nicht auf.

Entscheidungspunkte

• Welche Dienstleistungsverhältnisse (Integration, Instandhaltung, Fernwartung) sind für welche Anlagen sicherheitsrelevant und werden künftig gegen IEC 62443-2-4 ausgeschrieben?
• Welche Nachweise verlangen wir je Dienstleisterklasse, und wer prüft sie?
• Fixieren wir die Edition 2.0 vertraglich, und was gilt bei einem Ausgabenwechsel, nachdem beim Herausgeber ein Nachfolgeprojekt Edition 3.0 gelistet ist?
• Wer im Haus verantwortet die Dienstleistersteuerung im Betreiberprogramm (ot-003), und wie fließen Erkenntnisse aus Nachweisen dorthin zurück?
• Beschaffen wir den Normtext, und wer arbeitet damit (Einkauf, OT-Security, interne Prüfung)?

Praktische Empfehlungen

1. Inventarisieren Sie alle OT-Dienstleister mit ihren Zugriffswegen (vor Ort, Fernwartung) und ordnen Sie sie den Rollen der Reihe zu.
2. Benennen Sie in Ausschreibungen und Verträgen Teil und Ausgabe (IEC 62443-2-4:2023, Edition 2.0) statt pauschaler 62443-Verweise.
3. Vereinbaren Sie konkret, welche sicherheitsbezogenen Prozesse der Dienstleister anbietet, welche Teilmenge (Profil) gilt und welche Nachweise er in welchem Turnus vorlegt.
4. Führen Sie die Dienstleistersteuerung als Bestandteil des eigenen Betreiberprogramms (ot-003) und verzahnen Sie sie mit Zugriffs- und Änderungsprozessen.
5. Beobachten Sie den Ausgabenstand beim Herausgeber: Nachfolgeprojekt Edition 3.0 mit Status PREPARING und Prognosedatum 31.05.2028 (verschieblich); regeln Sie den Ausgabenwechsel vertraglich.
6. Beschaffen Sie den Normtext lizenzkonform, bevor Sie Anforderungen im Detail vereinbaren oder prüfen; dieser Artikel bleibt reference-only.

Relevante Normreferenzen

• IEC 62443-2-4:2023 (Security program requirements for IACS service providers): Edition 2.0, publiziert am 15.12.2023, Status PUBLISHED. Editionshistorie: Edition 1.0 (30.06.2015) mit COR1:2015 und AMD1:2017, konsolidierte Fassung Edition 1.1 (24.08.2017), alle mit Status REVISED. Nachfolgeprojekt Edition 3.0 mit Status PREPARING und Herausgeber-Prognose 31.05.2028. Quelle: Publikationsseite des IEC-Webstore (Publikation 67631), Abruf 2026-08-05; kostenpflichtig, daher nur konzeptionelle Bezugnahme (reference-only).
• IEC 62443-2-1: Anforderungen an das Security-Management des Betreibers selbst (so das Herausgeber-Abstract der 2-4); Betreiberprogramm in ot-003; kostenpflichtig, reference-only.
• IEC 62443-3-3 und IEC 62443-4-2: laut Herausgeber-Abstract der 2-4 stehen einzelne ihrer Anforderungen in Beziehung zu Sicherheitsanforderungen dieser Teile (System- und Komponentenebene, ot-002, ot-004); kostenpflichtig, reference-only.
• IEC 62443 (Serie): Rollenmodell Asset Owner, System Integrator/Service Provider, Product Supplier (ot-001); kostenpflichtig, reference-only.
• NIS-2-Richtlinie (EU) 2022/2555: regulatorische Pflichten zur Sicherheit der Lieferkette; erklärt in nis2-005.