IEC 62443 einfach erklärt: Aufbau, Zonen, Security Levels und der Einstieg in die Praxis

Was IEC 62443 ist und was nicht

Die Reihe trägt den Titel „Security for industrial automation and control systems“. Gemeint sind industrielle Automatisierungs- und Steuerungssysteme, kurz IACS. Wichtig ist, wie weit dieser Begriff gefasst ist: Ein IACS ist nach der Definition, die ISA in ihrem Überblick verwendet, eine Gesamtheit aus Personal, Hardware, Software und Richtlinien, die am Betrieb des industriellen Prozesses beteiligt ist und dessen sicheren und zuverlässigen Betrieb beeinflussen kann. Es geht also nicht nur um Firewalls und Steuerungen, sondern auch um Menschen, Abläufe und Zuständigkeiten.

Laut ISA beschreibt die Reihe Anforderungen und Prozesse, um elektronisch sichere IACS einzuführen und zu betreiben, und bietet einen Weg, das erreichte Sicherheitsniveau zu bewerten. Eingesetzt wird sie nicht nur in der Prozessindustrie, sondern unter anderem in der Gebäudeautomation, in der Energieerzeugung und -verteilung, bei Medizingeräten und im Transportwesen. 2021 hat die IEC die Reihe als horizontale Norm eingestuft, also als branchenübergreifend anwendbar.

Warum braucht es dafür eigene Normen, wenn es doch ISO/IEC 27001 gibt? Die ISA Global Cybersecurity Alliance (ISAGCA) beschreibt es in ihrem Quick Start Guide so: Das ISA99-Komitee hat anfangs geprüft, ob IT-Normen reichen, und festgestellt, dass sie es nicht tun. Die Folgen eines Angriffs auf ein IACS sind grundlegend andere. Neben Datenverlust und finanziellem Schaden können Menschen verletzt, die Umwelt geschädigt, die Anlage beschädigt oder die Produktqualität beeinträchtigt werden. Dazu kommen Eigenschaften, die ich aus dem Anlagenalltag gut kenne: hohe Verfügbarkeit, deterministisches Zeitverhalten, seltene Wartungsfenster und Komponenten, die laut Teil 2-1 länger als zwanzig Jahre im Einsatz sein können.

Was IEC 62443 nicht ist: kein Gesetz, kein Produktsiegel und keine fertige Checkliste. Verbindlich wird die freiwillige Reihe erst, wenn ein Vertrag, eine Ausschreibung oder eine Behörde sie fordert. Und sie ist kostenpflichtig: Im IEC-Webstore kostet zum Beispiel Teil 2-1:2024 als Basispublikation 405 Schweizer Franken. Ich zitiere in diesem Artikel deshalb keine Normtexte, sondern stütze mich auf öffentliche Zusammenfassungen von ISA, IEC, BSI und NIST. Wo die Details nur in der Norm stehen, sage ich das dazu.

Von ISA99 zur IEC 62443

Die International Society of Automation (ISA) hat das Komitee ISA99 im Jahr 2002 gegründet, ursprünglich mit Blick auf die kritische Infrastruktur in den USA. Seitdem entwickelt ISA99 die Reihe gemeinsam mit der Arbeitsgruppe 10 des IEC-Technikkomitees 65 (TC 65/WG 10). Die Dokumente erscheinen bei beiden Organisationen: als „ISA-62443-x-y“ bei ISA und als „IEC 62443-x-y“ bei der IEC. Laut ISAGCA sind die Inhalte bis auf das nicht normative Vorwort identisch. Die meisten Teile entstehen primär bei ISA99 und werden von beiden übernommen; Teil 2-4 ist die Ausnahme, er wurde in der IEC-Arbeitsgruppe entwickelt und von ISA übernommen.

Der älteste Teil, 1-1 mit Begriffen, Konzepten und Modellen, erschien 2007 bei ISA und 2009 als IEC-Technische Spezifikation. Frühe IEC-Teile wie 1-1 und 3-3 tragen noch den alten Reihentitel „Industrial communication networks – Network and system security“; gemeint ist dieselbe Reihe. ISA-/IEC-Normen haben einen fünfjährigen Überprüfungszyklus, deshalb sind laut ISAGCA viele Teile gleichzeitig in Überarbeitung.

Aufbau der Normenreihe in vier Gruppen

Die Dokumente sind in vier Gruppen geordnet, jeweils nach Schwerpunkt und Zielgruppe. Die Nummer verrät die Gruppe: Bei IEC 62443-3-3 steht die erste Ziffer für die Gruppe „System“, die zweite für den Teil innerhalb der Gruppe.

• 1-x Allgemeines: Begriffe, Konzepte, Modelle, Glossar, Metriken und Lebenszyklus. Gilt für alle.
• 2-x Richtlinien und Verfahren: Sicherheitsprogramme für Betreiber und Dienstleister, Patchmanagement.
• 3-x System: Sicherheitstechnologien, Risikobeurteilung, Anforderungen an das Gesamtsystem.
• 4-x Komponente: sichere Produktentwicklung und technische Anforderungen an einzelne Komponenten.

Für die Praxis sind sieben Teile besonders wichtig. Die Tabelle zeigt ihren Stand laut IEC-Webstore am 19. Oktober 2026.

Dazu kommen Technische Reports wie 2-3 zum Patchmanagement (IEC TR 62443-2-3:2015) und 3-1 zu Sicherheitstechnologien (IEC TR 62443-3-1:2009). Mehrere geplante Teile, etwa 1-2 (Glossar), 1-3 (Konformitätsmetriken), 1-4 (Lebenszyklus und Anwendungsfälle), 2-2 (Bewertung von Sicherheitsprogrammen) und 2-5 (Umsetzungsleitfaden für Betreiber), waren laut ISAGCA-Übersicht mit Stand Juni 2025 noch nicht als ISA/IEC 62443 veröffentlicht.

Laut ISAGCA leiten sich alle anderen Teile aus 2-1 ab, dem Sicherheitsprogramm des Betreibers. Teil 3-2 liefert die Ziel-Security-Levels je Zone, und mit diesen beschaffst du Systeme und Komponenten, deren Fähigkeiten in 3-3 und 4-2 beschrieben sind.

Drei Rollen: Betreiber, Dienstleister, Hersteller

Ein Grundprinzip der Reihe ist geteilte Verantwortung. Kein Beteiligter kann ein IACS allein absichern. Die Reihe unterscheidet im Kern drei Rollen:

• Betreiber (Asset Owner): Die Organisation, die für das IACS verantwortlich und rechenschaftspflichtig ist und es betreibt. Der Betreiber baut ein Sicherheitsprogramm auf (2-1), teilt das System in Zonen und Conduits und bewertet die Risiken (3-2), dokumentiert die Anforderungen und beschafft passende Produkte und Leistungen. Er bleibt am Ende verantwortlich, auch wenn er Arbeit an Dienstleister vergibt.
• Dienstleister (Service Provider): Die Reihe unterscheidet Integrationsdienstleister, die eine Automatisierungslösung entwerfen, installieren, konfigurieren, testen, in Betrieb nehmen und übergeben, und Wartungsdienstleister, die sie im Betrieb unterstützen. Für beide gilt Teil 2-4. Integratoren unterstützen laut ISAGCA oft auch bei Zonierung und Risikobeurteilung.
• Hersteller (Product Supplier): Wer Hardware- und Softwareprodukte herstellt und pflegt, also Steuerungssysteme, eingebettete Geräte wie SPSen, Host-Geräte wie Bedien- und Engineering-PCs, Netzwerkgeräte und Softwareanwendungen. Für sie gelten vor allem 4-1, 4-2 und, bei Systemprodukten, 3-3.

Hilfreich finde ich die Unterscheidung zwischen Produkt, Automatisierungslösung und IACS. Das Produkt kaufst du, die Automatisierungslösung ist seine konkrete Umsetzung an deinem Standort, und das IACS umfasst zusätzlich die Betriebs- und Wartungsverfahren. Eine sicher entwickelte Komponente garantiert also noch keine sichere Anlage.

Automatisierungspyramide, Purdue-Modell und DMZ

Bevor es um Zonen geht, lohnt ein Blick auf das Modell, in dem die meisten von uns Anlagen denken. Das BSI beschreibt im ICS-Security-Kompendium die Automatisierungspyramide mit fünf Ebenen:

• Ebene 0, Feldebene: Sensoren und Aktoren wie Endschalter, Messwertaufnehmer, Analysegeräte, Ventile, Stellglieder und Motoren, dazu Remote-I/O. Hier läuft die Signalübertragung in Echtzeit.
• Ebene 1, Steuerungsebene: SPSen und andere Steuerungen, die Signale deterministisch verarbeiten.
• Ebene 2, Prozessleitebene: Bedien- und Beobachtungsstationen (HMI), SCADA- und Prozessleitsysteme, Engineering- und Wartungsstationen, Archivserver. Diese Systeme verarbeiten keine Echtzeitdaten, sind für die Prozessführung aber wichtig.
• Ebene 3, Betriebsführungsebene: Manufacturing Execution Systems (MES), Planungs- und Engineering-Werkzeuge. Ebene 3 ist die Schnittstelle zwischen betriebswirtschaftlicher Organisation und Produktion.
• Ebene 4, Unternehmensebene: ERP-Systeme, Internet- und Intranetzugänge und Einrichtungen für den Fernzugriff.

Das Purdue-Modell, eigentlich Purdue Enterprise Reference Architecture (PERA), ist mit dieser Pyramide eng verwandt. NIST beschreibt in SP 800-82r3, dass die Normenreihe ISA-95 zur Integration von Unternehmens- und Steuerungsebene aus dem Purdue-Referenzmodell hervorgegangen ist. Das BSI weist auf zwei Ergänzungen gegenüber der Pyramide hin: eine Internet-Ebene oberhalb der Unternehmensebene und vor allem die Übergangszone auf „Ebene 3.5“, die OT-DMZ zwischen Office-IT und Produktion. Als DMZ verhindert sie direkte Kommunikation zwischen beiden Seiten; Daten laufen über Proxysysteme. Idealerweise baut die Seite mit dem höheren Schutzbedarf die Verbindung auf. Das BSI nennt als Beispiel einen Historian in der DMZ, auf den die Steuerungssysteme schreiben und die Office-Systeme nur lesend zugreifen.

NIST empfiehlt, dass nur benachbarte Ebenen oder Zonen miteinander sprechen; Geräte auf Ebene 4 sollen nicht direkt mit Ebene 2, 1 oder 0 kommunizieren. Ausgehende Verbindungen sollen so streng geregelt sein wie eingehende.

Und wie hängt das mit IEC 62443 zusammen? Hier ist Präzision wichtig. Das Purdue-Modell ist ein Referenzmodell für Funktionen und Datenflüsse, kein Teil der Sicherheitsanforderungen. Das BSI schreibt, das Modell sei ursprünglich nicht unter Cybersicherheitsaspekten entworfen worden, bilde aber bis heute die Basis vieler Segmentierungskonzepte und werde unter anderem von der IEC 62443 genutzt. Die eigentliche Sicherheitsarchitektur entsteht in der Reihe aber über Zonen und Conduits, die du aus deiner Risikobeurteilung ableitest. Eine Zone kann sich an einer Purdue-Ebene orientieren, muss es aber nicht. Wie das Referenzmodell in Teil 1-1 genau formuliert ist, steht nur in der kostenpflichtigen Norm. Für die Praxis reicht: Purdue hilft beim Ordnen, die Zonen bestimmt dein Risiko.

Das BSI spricht zudem von einer „Auflösung“ der Hierarchiestufen, etwa durch Cloud-Anbindung und Industrial IoT. Gerade für WLAN, Cloud und Fernzugriff musst du Zonen bewusst planen.

Zonen und Conduits

Zonen und Conduits sind das Herzstück der Reihe. Die Definitionen laut ISAGCA:

• Zone: eine Gruppierung logischer oder physischer Assets nach Risiko oder anderen Kriterien wie Kritikalität, betrieblicher Funktion, physischem oder logischem Ort, erforderlichem Zugriff oder zuständiger Organisation.
• Conduit: eine logische Gruppierung von Kommunikationskanälen mit gemeinsamen Sicherheitsanforderungen, die zwei oder mehr Zonen verbindet.

Assets mit ähnlichen Sicherheitseigenschaften bekommen gemeinsame Anforderungen, jeder Übergang wird bewusst kontrolliert. Das begrenzt auch, wie weit sich ein Angriff ausbreiten kann. Teil 3-2 verlangt oder empfiehlt laut ISAGCA, bestimmte Assets getrennt zu halten: Business- und Steuerungsassets, sicherheitsgerichtete Assets (Safety), temporär angeschlossene Geräte, drahtlose Geräte und Geräte, die über externe Netze angebunden sind.

Ein Conduit ist dabei nicht einfach ein Kabel oder ein VLAN, sondern die Summe der Kommunikationswege zwischen Zonen. Das BSI fordert im IT-Grundschutz-Baustein IND.1, dass ein aktueller Netzplan Zonen, Zonenübergänge (Conduits), Protokolle und Außenschnittstellen dokumentiert, und zwar einschließlich manueller Datentransfers, etwa über Wechseldatenträger. Der USB-Stick des Servicetechnikers gehört also auch ins Modell.

Wie das aussehen kann, zeigt das Beispiel in der Grafik. Es ist meine eigene, vereinfachte Darstellung und kein Muster aus der Norm:

• Unternehmenszone: ERP, Büro-IT, E-Mail.
• OT-DMZ: Historian-Spiegel, Patch- und Antivirus-Verteilung, Sprungserver für die Fernwartung.
• Leitebene: SCADA-Server, Bedienstationen, Engineering-Station.
• Zelle A und Zelle B: jeweils SPS, HMI, Antriebe und Feldgeräte einer Linie.
• Safety-Zone: sicherheitsgerichtete Steuerung (SIS) mit eigener, eng begrenzter Anbindung.
• Fernwartung: der externe Dienstleister, der ausschließlich über einen Conduit in die DMZ kommt und dort auf dem Sprungserver landet.

Zwischen den Zonen liegen Conduits mit Firewalls: zwischen Unternehmenszone und DMZ, zwischen DMZ und Leitebene und vor den Zellen. Die Zellen sprechen nicht direkt miteinander. Das passt zum BSI-Baustein IND.1, der eine horizontale Segmentierung in unabhängige Funktionsbereiche verlangt und fordert, dass prozessführende Zonen beim Ausfall anderer Zonen eine definierte Zeit weiterlaufen.

Für die Fernwartung ist der BSI-Baustein IND.3.2 eine gute Ergänzung. Er fordert unter anderem, dass jeder Fernzugriff über eine Sicherheitskomponente in OT-Zuständigkeit abgesichert ist, dass Zugriffe entkoppelt über einen Sprungserver oder ein vergleichbares Application Layer Gateway in einer DMZ laufen und dass jede Sitzung vorab von zuständigen OT-Mitarbeitenden freigegeben wird, und zwar zeitlich begrenzt.

Zonen und Conduits sind die praktische Umsetzung von Defense in Depth: mehrere geschichtete Schutzmaßnahmen, die einen Angriff verzögern oder verhindern, sodass die Anlage geschützt bleibt, auch wenn eine Schicht versagt. Kritisch sind laut ISAGCA einzelne Schwachstellen, die mehrere Schichten zugleich aushebeln, etwa ein gemeinsames Admin-Konto für Office und OT.

Wichtig ist eine Grenze: Sicherheit darf die wesentlichen Funktionen nicht gefährden, also Sicherheitsfunktionen (SIF), Steuerung und die Möglichkeit, die Anlage zu sehen und zu bedienen. Sie müssen auch erhalten bleiben, wenn eine Zonengrenze im Fehlerfall dichtmacht. Bei jedem Conduit frage ich deshalb, was passiert, wenn die Firewall alles sperrt.

Die Risikobeurteilung nach Teil 3-2

Teil 3-2 legt laut IEC-Webstore Anforderungen fest für: die Abgrenzung des betrachteten Systems (System under Consideration, SUC), die Aufteilung in Zonen und Conduits, die Risikobewertung je Zone und Conduit, die Festlegung des Ziel-Security-Levels (SL-T) je Zone und Conduit und die Dokumentation der Sicherheitsanforderungen. Gegliedert ist das in sieben Schritte, die Zone and Conduit Requirements (ZCR):

1. ZCR 1, SUC identifizieren: Grenze des Systems und alle Zugangspunkte festlegen. Eingaben sind Architekturzeichnungen, Inventar, Richtlinien und Vorgaben.
2. ZCR 2, initiale Risikobeurteilung: das ungeminderte Risiko abschätzen, wenn das System kompromittiert würde. Bestehende Gefährdungsanalysen (PHA) und die Risikomatrix des Unternehmens fließen ein.
3. ZCR 3, in Zonen und Conduits aufteilen: nach Risiko, Kritikalität, Datenflüssen und den oben genannten Trennregeln.
4. ZCR 4, Risikovergleich: Liegt das initiale Risiko über dem tolerierbaren Risiko, folgt die detaillierte Bewertung.
5. ZCR 5, detaillierte Risikobeurteilung: je Zone und Conduit Bedrohungen, Schwachstellen, Auswirkungen und Wahrscheinlichkeit bewerten, Gegenmaßnahmen bestimmen, Restrisiko und SL-T festlegen.
6. ZCR 6, Anforderungen dokumentieren: die Cybersecurity Requirements Specification (CRS) mit Systembeschreibung, Zonen- und Conduit-Zeichnungen, Bedrohungsumfeld und Gegenmaßnahmen.
7. ZCR 7, Freigabe durch den Betreiber: Die verantwortliche Leitung prüft und genehmigt das Ergebnis.

Zwei Punkte werden oft missverstanden. Erstens schreibt Teil 3-2 keine bestimmte Methode vor. Der Betreiber legt sie fest, und sie soll zur Risikomethode des Unternehmens passen; Beispiele mit Risikomatrix sind nur informativ. Zweitens muss die CRS kein eigenes Dokument sein, sie kann auch Teil anderer Anlagendokumente sein. Die Details stehen in der Norm; mit 31 Seiten ist Teil 3-2 für Betreiber meiner Meinung nach der beste Einstieg in die kostenpflichtigen Dokumente.

Security Levels: SL-T, SL-C und SL-A

Ein Security Level ist laut ISAGCA ein Maß für das Vertrauen, dass ein System, eine Zone oder ein Conduit frei von Schwachstellen ist und wie vorgesehen funktioniert. Teil 3-3 beschreibt die Stufen über den Angreifer, gegen den sie schützen sollen, genauer über dessen Mittel, Ressourcen, Fähigkeiten und Motivation:

In vielen Übersichten, etwa in Schulungsunterlagen, taucht zusätzlich SL 0 auf: keine besonderen Anforderungen. Die abgestuften Anforderungen in Teil 3-3 und 4-2 sind den Stufen 1 bis 4 zugeordnet.

Entscheidend ist, dass die Reihe drei Arten von Security Levels unterscheidet. Sie beantworten drei verschiedene Fragen:

• SL-T (Target, Ziel): Welches Niveau braucht diese Zone oder dieser Conduit? Ergebnis der Risikobeurteilung nach 3-2, dokumentiert in der CRS. Damit wählst du Produkte aus und planst zusätzliche Maßnahmen.
• SL-C (Capability, Fähigkeit): Welches Niveau kann ein System (3-3) oder eine Komponente (4-2) bei richtiger Integration und Konfiguration von sich aus erreichen, ohne zusätzliche kompensierende Maßnahmen?
• SL-A (Achieved, erreicht): Welches Niveau hat die Lösung tatsächlich? Gemessen wird das nach der Inbetriebnahme im Betrieb.

Im Alltag vergleichst du das SL-T einer Zelle mit dem SL-C der geplanten Steuerungen, Switches und Bedienstationen. Erreicht ein Produkt das Ziel nicht, etwa weil eine ältere SPS keine Benutzerverwaltung kennt, brauchst du kompensierende Maßnahmen wie eine vorgelagerte Filterung. Ob das wirkt, zeigt erst das SL-A. Security Levels werden dabei nicht als eine einzige Zahl verstanden, sondern pro grundlegender Anforderung; Teil 3-3 behandelt diesen „SL-Vektor“ in einem informativen Anhang. Die genaue Ableitung steht in der Norm.

Nicht jede Zone braucht SL 3 oder SL 4. Ein höheres Ziel kostet Geld und Aufwand; die Risikobeurteilung soll das Niveau dort hoch ansetzen, wo die Folgen gravierend sind.

Die sieben grundlegenden Anforderungen (FR 1 bis FR 7)

Alle technischen Anforderungen der Reihe sind nach sieben Foundational Requirements (FR) sortiert. Sie stammen aus Teil 1-1 und strukturieren sowohl die Systemanforderungen in 3-3 als auch die Komponentenanforderungen in 4-2:

FR 1 und FR 2 werden zusammen oft als Zugriffskontrolle bezeichnet; laut ISAGCA hat man sie getrennt, damit die Zahl der Einzelanforderungen handhabbar bleibt. Unter jeder FR stehen konkrete Anforderungen. In Teil 3-3 heißen sie System Requirements (SR), in Teil 4-2 Component Requirements (CR). Beispiele aus dem öffentlich einsehbaren Inhaltsverzeichnis von 3-3 sind SR 1.1 „Human user identification and authentication“, SR 5.1 „Network segmentation“ und SR 5.2 „Zone boundary protection“. Erweiterungen (Requirement Enhancements, RE) gelten zusätzlich für höhere Security Levels. Welche SR und RE zu welchem Level gehören, ordnet ein Anhang der Norm zu; diese Zuordnung brauchst du für jede Gap-Analyse.

Reifegrade für Prozesse

Security Levels messen die Stärke technischer Maßnahmen. Für Prozesse, also Menschen, Richtlinien und Abläufe, nutzt die Reihe Reifegrade (Maturity Levels). Laut ISAGCA verwenden die Teile 2-1, 2-2, 2-4 und 4-1 dieses Modell. Es lehnt sich an CMMI an, wobei dessen Stufen 4 und 5 zu einer zusammengefasst sind:

• ML 1, Initial: Abläufe sind ad hoc und oft undokumentiert.
• ML 2, Managed: Es gibt schriftliche Richtlinien und geschultes Personal, aber nicht alles wird schon gelebt.
• ML 3, Defined (Practiced): Prozesse sind wiederholbar, werden überall angewendet und sind belegt.
• ML 4, Improving: Prozesskennzahlen steuern Wirksamkeit und kontinuierliche Verbesserung.

Teil 2-1 hat in der Ausgabe 2024 laut IEC-Webstore ein solches Reifegradmodell zur Bewertung der Anforderungen eingeführt, die Anforderungen in Security Program Elements (SPE) neu gegliedert und Doppelungen zu einem Informationssicherheits-Managementsystem (ISMS) entfernt. Wer schon nach ISO/IEC 27001 arbeitet, ergänzt das ISMS also um die OT-Besonderheiten, statt es zu ersetzen.

Sichere Entwicklung (4-1) und Komponenten (4-2)

Teil 4-1 beschreibt Anforderungen an den Secure Development Lifecycle (SDL) für Produkte, die in IACS eingesetzt werden. Laut IEC-Webstore umfasst der Lebenszyklus die Definition der Sicherheitsanforderungen, sicheres Design, sichere Implementierung einschließlich Programmierrichtlinien, Verifikation und Validierung, Fehlermanagement, Patchmanagement und das Produktende. Die Anforderungen gelten für Hardware, Software und Firmware, und zwar nur für Entwickler und Pfleger eines Produkts, nicht für Integratoren oder Anwender. Das öffentliche Inhaltsverzeichnis zeigt acht Praktiken, von Sicherheitsmanagement über Secure by Design und Sicherheitstests bis zu Sicherheitsupdates und Sicherheitsrichtlinien für Anwender. Zentral ist laut ISAGCA die Bedrohungsmodellierung, die über den Produktlebenszyklus aktualisiert wird.

Teil 4-2 enthält die technischen Anforderungen an Komponenten, gegliedert nach den sieben FR und mit Zuordnung zu den Fähigkeitsstufen SL-C(component). SL-T und SL-A liegen laut Webstore ausdrücklich außerhalb des Anwendungsbereichs. Komponenten sind eingebettete Geräte, Host-Geräte, Netzwerkgeräte und Softwareanwendungen. Vor den eigentlichen Anforderungen stehen vier übergreifende Randbedingungen: Unterstützung der wesentlichen Funktionen, kompensierende Maßnahmen, geringste Rechte und ein Softwareentwicklungsprozess, also der Bezug zu 4-1.

Für Betreiber und Integratoren sind 4-1 und 4-2 vor allem Beschaffungskriterien. Statt pauschal „IEC 62443“ zu fordern, ist präziser: SDL nach 4-1, SL-C nach 4-2 mindestens auf dem SL-T der Zielzone, Härtungsanleitung und ein zugesagter Zeitraum für Sicherheitsupdates.

Zertifizierung

Das bekannteste Zertifizierungsprogramm ist ISASecure, betrieben vom ISA Security Compliance Institute (ISCI), einer Tochter der ISA. Laut ISA und ISASecure gibt es diese Programme:

• SDLA (Security Development Lifecycle Assurance): Entwicklungsprozess des Herstellers nach 4-1.
• CSA (Component Security Assurance): Komponenten nach 4-2.
• SSA (System Security Assurance): Steuerungssysteme nach 3-3.
• ICSA (IIoT Component Security Assurance): IIoT-Komponenten und -Gateways.
• ACSSA (Automation and Control System Security Assurance): seit 17. Februar 2026 für Betreiber. Bewertet wird ein laufendes oder betriebsbereites IACS mit seinem Sicherheitsprogramm gegen 2-1, 2-4, 3-2 und 3-3, als Inspektion oder als dreijährige Zertifizierung mit Überwachung.

Daneben bietet auch das IECEE-System der IEC Zertifizierungen auf Basis von Teilen der Reihe an. Ein Zertifikat ist ein Nachweis, kein Freibrief: Ein nach 4-2 zertifiziertes Gerät bringt Fähigkeiten mit, ob sie richtig genutzt werden, entscheidet die Integration. Prüfe außerdem, welcher Teil, welches Level und welche Produktversion bewertet wurden.

IEC 62443, NIS2, CRA und Maschinenverordnung

Keine dieser EU-Regelungen schreibt IEC 62443 direkt vor. Trotzdem ist die Reihe für alle drei relevant. Ich trenne hier bewusst zwischen dem, was belegt ist, und meiner Einordnung.

NIS2

Die NIS2-Richtlinie (EU) 2022/2555 ist in Deutschland mit dem NIS-2-Umsetzungsgesetz am 6. Dezember 2025 in Kraft getreten. Laut BSI fallen rund 29.500 Einrichtungen unter die Aufsicht. Besonders wichtige und wichtige Einrichtungen müssen sich registrieren, erhebliche Sicherheitsvorfälle melden (frühe Erstmeldung nach 24 Stunden, Meldung nach 72 Stunden, Abschlussmeldung nach 30 Tagen) und Risikomanagementmaßnahmen umsetzen und dokumentieren. NIS2 nennt keine bestimmte Norm; die Mitgliedstaaten sollen die Nutzung europäischer und internationaler Normen fördern. Im Rolling Plan für IKT-Normung 2026 lädt die EU-Kommission die Normungsorganisationen ausdrücklich ein, die Umsetzung der Reihe EN 62443 für OT-Sicherheit in kritischen Infrastrukturen zu fördern. Meine Einordnung: Fällt dein Unternehmen unter NIS2, ist IEC 62443 ein naheliegender Rahmen für den OT-Teil des Risikomanagements. Eine Zertifizierungspflicht folgt daraus nicht.

Cyber Resilience Act

Der Cyber Resilience Act (Verordnung (EU) 2024/2847) richtet sich an Hersteller von Produkten mit digitalen Elementen, nicht an Betreiber. Laut EU-Kommission gelten die Meldepflichten seit dem 11. September 2026, voll anwendbar ist die Verordnung ab dem 11. Dezember 2027. Produkte, die harmonisierten Normen entsprechen, profitieren von einer Konformitätsvermutung. Dafür hat die Kommission den Normungsauftrag M/606 mit 41 Normungsergebnissen erteilt. Für den OT-Bereich arbeitet laut Rolling Plan das europäische Komitee CLC/TC 65X an Änderungen von EN IEC 62443-4-1, 4-2 und 3-3, damit sie die CRA-Anforderungen abdecken, und an produktspezifischen Normen für industrielle Anwendungsfälle. Welche Fassungen am Ende im Amtsblatt gelistet werden, ist offen. Wer heute nach 4-1 entwickelt und 4-2 umsetzt, hat eine solide Grundlage, sollte die Änderungen aber verfolgen. Betreiber spüren den CRA indirekt über ihre Lieferanten.

Maschinenverordnung

Die Maschinenverordnung (EU) 2023/1230 gilt laut EU-Kommission ab dem 20. Januar 2027 und löst die Maschinenrichtlinie ab. Erstmals enthält sie mit Anhang III Nummer 1.1.9 „Schutz gegen Korrumpierung“ eine Anforderung, die Cybersicherheit direkt betrifft. Sinngemäß: Der Anschluss anderer Einrichtungen, auch per Fernzugriff, darf nicht zu einer gefährlichen Situation führen; sicherheitsrelevante Hardware, Software und Daten sind gegen unbeabsichtigte und vorsätzliche Korrumpierung zu schützen; die Maschine muss die für den sicheren Betrieb nötige Software ausweisen und Nachweise über rechtmäßige und unrechtmäßige Eingriffe sammeln. IEC 62443 wird in der Verordnung nicht genannt. Eine Konformitätsvermutung entsteht nur über harmonisierte Normen mit Fundstelle im Amtsblatt. Meine Einordnung: Für Maschinenbauer sind vor allem 4-1 und 4-2 ein naheliegender technischer Bezugsrahmen; welche Norm die Vermutungswirkung für 1.1.9 liefern wird, solltest du gezielt verfolgen.

Was du jetzt tun solltest

Du musst nicht mit dem Kauf aller Normteile anfangen. Die ersten Schritte gehen auch ohne, und sie entsprechen dem, was 3-2 ohnehin am Anfang verlangt.

1. Umfang und Verantwortung festlegen: Welche Anlage oder Linie betrachtest du zuerst (das SUC)? Wer ist auf Betreiberseite verantwortlich, wer gibt am Ende frei?
2. Asset-Inventar aufbauen: Steuerungen, HMIs, Server, Switches, Firewalls, Feldgeräte mit Netzwerkanschluss, Firmwarestände und Zuständigkeiten. CISA hat dazu 2025 einen Leitfaden für OT-Betreiber veröffentlicht.
3. Kommunikationsbeziehungen erfassen: Wer spricht mit wem, über welches Protokoll, und warum? Außenschnittstellen nicht vergessen: Fernwartung, Cloud-Anbindungen, mobile Router, USB-Sticks.
4. Zonen und Conduits entwerfen: Business von OT trennen, eine OT-DMZ einplanen, Safety, drahtlose Geräte, temporär angeschlossene Geräte und externe Anbindungen in eigene Zonen. Jeder Conduit bekommt Kanäle, Regeln und eine Zuständigkeit.
5. Fernzugriff zuerst aufräumen: nur über einen Conduit in die DMZ, Sprungserver in OT-Zuständigkeit, persönliche Konten mit Mehr-Faktor-Authentifizierung, Freigabe pro Sitzung und zeitlich begrenzt. Das ist oft der größte Gewinn mit dem geringsten Aufwand.
6. Initiale Risikobeurteilung durchführen: Was ist der schlimmste plausible Schaden je Zone? Nutze vorhandene Gefährdungsanalysen und die Risikomatrix deines Unternehmens, statt eine neue Methode zu erfinden.
7. SL-T festlegen: pro Zone und Conduit, begründet und dokumentiert.
8. Gap-Analyse machen: Ist-Zustand gegen das SL-T vergleichen. Dafür brauchst du spätestens jetzt Teil 3-3 mit der Zuordnung der SR und RE zu den Levels. Wo Systeme das Ziel nicht erreichen, plane kompensierende Maßnahmen und den Ersatz.
9. Dienstleister und Lieferanten einbeziehen: In Verträgen und Ausschreibungen konkrete Anforderungen nach 2-4, 4-1 und 4-2 stellen, statt pauschal „IEC 62443“ zu schreiben.
10. Ergebnisse in der CRS festhalten und freigeben lassen: Zonenplan, Conduits, SL-T, Maßnahmen und Restrisiko. Bei jeder Änderung an der Anlage überprüfen.

Mein Rat aus der Praxis: Nimm dir eine Linie vor, nicht das ganze Werk. Ein sauber dokumentiertes Zonenmodell für eine Anlage bringt mehr als ein unfertiges Konzept für alles, und es wird zur Vorlage für die nächsten.

Für Asset-Inventar und Zonenplan musst du nicht bei null anfangen: In meinen OT-Vorlagen findest du unter anderem eine Asset-Liste und einen Zonen- und Conduit-Plan in Anlehnung an IEC 62443-3-2, jeweils mit Beispieldaten.

Häufige Fragen zu IEC 62443

Quellen

• ISA: ISA/IEC 62443 Series of Standards
• ISAGCA: Quick Start Guide – An Overview of ISA/IEC 62443 Standards (PDF)
• IEC Webstore: IEC TS 62443-1-1:2009
• IEC Webstore: IEC 62443-2-1:2024
• IEC Webstore: IEC 62443-2-4:2023
• IEC Webstore: IEC 62443-3-2:2020
• IEC Webstore: IEC 62443-3-3:2013
• IEC Webstore: IEC 62443-4-1:2018
• IEC Webstore: IEC 62443-4-2:2019
• BSI: ICS-Security-Kompendium (PDF)
• BSI IT-Grundschutz: IND.1 Prozessleit- und Automatisierungstechnik (PDF)
• BSI IT-Grundschutz: IND.3.2 Fernwartung im industriellen Umfeld (PDF)
• NIST SP 800-82 Rev. 3: Guide to Operational Technology (OT) Security
• CISA: Foundations for OT Cybersecurity – Asset Inventory Guidance for Owners and Operators
• IECEE: IEC 62443-2-4:2023 als Zertifizierungsgrundlage
• ISS: Projekt IEC 62443-1-1 ED1 (Projektstatus der Neufassung)
• ISASecure: ACSSA Certification
• BSI: NIS-2-Umsetzungsgesetz in Kraft (Pressemitteilung)
• BSI: NIS-2-Pflichten
• EU-Kommission: Cyber Resilience Act – Implementation
• EU-Kommission: Cyber Resilience Act – Standardisation
• Interoperable Europe: Rolling Plan for ICT Standardisation 2026 – Cybersecurity
• EU-Kommission: Machinery (Verordnung (EU) 2023/1230)
• Verordnung (EU) 2023/1230, Anhang III (Textfassung bei gesetze.legal)

Stand: 19. Oktober 2026.