Wenn ein Produktionswerk seine SPS-Steuerungen an die Cloud anbindet, hört die Frage „Ist das eigentlich sicher?“ auf, theoretisch zu sein — eine Antwort erwarten Auditor, Versicherer und Endkunde gleichermaßen. IEC 62443 ist die internationale Normenfamilie, die die Sicherheit industrieller Automatisierungssysteme ordnet und faktisch zu der Sprache geworden ist, in der Integratoren, Gerätehersteller und Anlagenbetreiber über Risiken im IIoT sprechen.
Kurz gefasst: IEC 62443 ist eine Normenreihe für die Sicherheit industrieller Automatisierungs- und Steuerungssysteme (IACS), die die Verantwortung zwischen Betreiber, Integrator und Komponentenhersteller aufteilt und eine vierstufige Skala von Security Levels (SL 1 bis SL 4) definiert. Für Hersteller von IIoT-Geräten sind vor allem die Teile 4-1 (sicherer Entwicklungsprozess) und 4-2 (technische Anforderungen an die Komponente) maßgeblich.

Was ist die Norm IEC 62443 und für wen gilt sie?
IEC 62443 ist eine von ISA und IEC erarbeitete Normenreihe, die die Cybersicherheit von IACS beschreibt — vom einzelnen Sensor bis zur gesamten Netzarchitektur eines Werks. Ihr Alleinstellungsmerkmal ist der rollenbasierte Ansatz: dieselben Bedrohungen werden getrennt aus der Perspektive von drei Beteiligten der Wertschöpfungskette betrachtet.
- Anlagenbetreiber (Asset Owner) — Teile 2-x: Richtlinien, Steuerung des Sicherheitsprogramms, Aufrechterhaltung des Betriebs.
- Systemintegrator (Service Provider) — Teile 3-x: Architekturentwurf, Aufteilung in Zonen und Conduits, Systemanforderungen.
- Komponentenhersteller (Product Supplier) — Teile 4-1 und 4-2: Lebenszyklus der Produktentwicklung sowie technische Anforderungen an das Gerät.
Diese Struktur hat eine praktische Konsequenz: Der Hersteller eines Sensors oder Gateways kann nicht „das ganze Werk zertifizieren“, wohl aber nachweisen und dokumentieren, dass sein Produkt die Komponentenanforderungen auf dem erklärten Niveau erfüllt.
Security Level: Wie funktioniert die Skala SL 1 bis SL 4?
Das Security Level misst die Widerstandsfähigkeit gegenüber einem Angreifer mit definierten Ressourcen und definierter Motivation — es ist keine kontextfreie Bewertung der „Qualität“ von Schutzmaßnahmen. Die Norm definiert vier Stufen:
- SL 1 — Schutz vor zufälliger oder fehlerhafter Bedienung durch Anwender.
- SL 2 — Widerstandsfähigkeit gegen gezielte Angriffe mit einfachen Mitteln, geringer Motivation und Allgemeinwissen.
- SL 3 — Widerstandsfähigkeit gegen Angriffe mit ausgefeilten Werkzeugen und IACS-spezifischem Fachwissen.
- SL 4 — Widerstandsfähigkeit gegen Angreifer mit erweiterten Ressourcen, typischerweise staatliche Akteure.
In der industriellen Praxis zielen die meisten Projekte auf SL 2, kritische Zonen auf SL 3. Das Niveau wird für jede der sieben Foundational Requirements separat erklärt: Identifikations- und Authentifizierungskontrolle, Nutzungskontrolle, Systemintegrität, Vertraulichkeit der Daten, eingeschränkter Datenfluss, zeitgerechte Reaktion auf Ereignisse sowie Verfügbarkeit der Ressourcen.
Zonen und Conduits: Fundament einer sicheren OT-Architektur
Eine Zone ist eine Gruppe von Assets mit gemeinsamen Sicherheitsanforderungen, ein Conduit der kontrollierte Kommunikationspfad zwischen Zonen. Die Segmentierung wiegt in dieser Norm schwerer als jeder einzelne kryptografische Mechanismus.
Eine typische Aufteilung im Werk orientiert sich an den Ebenen des Purdue-Modells: Steuerungszone (SPS, Antriebe), Leitzone (SCADA, HMI), industrielle DMZ und IT-Zone. Ein IIoT-Gateway landet nahezu immer in der DMZ und übernimmt die Rolle des einzigen Conduits nach außen — seine Konfiguration entscheidet daher über das reale Risikoniveau. Hier lohnt es sich, Protokolle mit nativem Sicherheitsmodell einzusetzen, etwa OPC UA im industriellen IoT, statt ungesicherte Feldbusse einfach zu tunneln.
Bei Retrofits älterer Anlagen endet der Conduit meist in einer Protokollkonvertierung — das haben wir am Beispiel der Integration von Modbus RTU/TCP mit der Cloud ausführlicher beschrieben.
Teil 4-2: Was verlangt die Norm vom Gerät?
Teil 4-2 übersetzt die allgemeinen Anforderungen in konkrete technische Funktionen der Komponente. Für das Firmware-Team bedeutet das eine Liste von Eigenschaften, die von Anfang an entworfen und nicht am Projektende nachgerüstet werden müssen.
- Eindeutige Geräteidentität und zertifikatsbasierte Authentifizierung statt gemeinsam genutzter Passwörter.
- Rollen und Berechtigungen (RBAC) mit Trennung von Service- und Bedienkonto.
- Softwareintegrität: signierte Firmware, Prüfung beim Start und sicheres Update.
- Verschlüsselung der Übertragung (TLS 1.2/1.3) und Schutz ruhender Daten.
- Protokollierung sicherheitsrelevanter Ereignisse mit manipulationssicherem Zeitstempel.
- Kontrolliertes Session-Management, Sperren der Debug-Ports und Abschalten nicht genutzter Dienste.
Die Integritätsanforderungen werden hardwareseitig umgesetzt — Ausgangspunkt ist Secure Boot als sicherer Startvorgang des Geräts, gestützt auf einen im OTP-Speicher des Mikrocontrollers verankerten Schlüssel.
Wie hängt IEC 62443 mit Cyber Resilience Act und NIS2 zusammen?
IEC 62443 ist eine technische Norm, CRA und NIS2 sind Rechtsakte — die Norm liefert einen erprobten Weg, die Erfüllung regulatorischer Pflichten nachzuweisen. Der CRA verlangt von Herstellern von Produkten mit digitalen Elementen unter anderem eine Risikoanalyse, den Umgang mit Schwachstellen über den gesamten Unterstützungszeitraum und die Bereitstellung von Sicherheitsupdates.
Praktisch deckt sich das mit Teil 4-1 der Norm, der den sicheren Entwicklungslebenszyklus (SDL) beschreibt: Bedrohungsmodellierung, Sicherheitsanforderungen, Tests, Schwachstellenmanagement und das Verfahren zur Produktabkündigung. Den rechtlichen Kontext vertiefen wir im Beitrag über die Pflichten von IoT-Herstellern nach dem CRA, die Inventarisierung der Komponenten im Text über SBOM für IoT-Geräte.
Häufig gestellte Fragen (FAQ)
Ist IEC 62443 verpflichtend?
Die Norm selbst ist rechtlich nicht verpflichtend, wird aber zunehmend vertraglich gefordert — in Ausschreibungen der Industrie und der Energiewirtschaft sowie in den Lieferketten der Automobilbranche. Zusätzlich gilt sie als anerkannter Weg, die Konformität mit Regelwerken wie NIS2 oder dem Cyber Resilience Act nachzuweisen, und wirkt damit faktisch wie eine Marktanforderung.
Wie lange dauert eine Komponentenzertifizierung nach Teil 4-2 und was kostet sie?
Für eine einzelne Komponente dauert ein typisches Projekt 6 bis 12 Monate, abhängig von der Reife des Prozesses und der Zahl technischer Lücken. Der größte Kostenblock ist nicht das Audit der Zertifizierungsstelle, sondern die Umsetzung von Teil 4-1, also eines dokumentierten Entwicklungsprozesses mit Bedrohungsmodellierung, Tests und Schwachstellenmanagement.
Worin unterscheidet sich IEC 62443 von ISO 27001?
ISO 27001 beschreibt ein Managementsystem für Informationssicherheit in der Organisation, mit Priorität auf der Vertraulichkeit von Daten. IEC 62443 betrifft Steuerungssysteme, in denen Verfügbarkeit und Integrität des physischen Prozesses Vorrang haben. Die Normen ergänzen einander: ISO 27001 ordnet die Organisation, IEC 62443 liefert die technischen Anforderungen an Geräte und OT-Architektur.
Fazit und wichtigste Erkenntnisse
IEC 62443 ist keine Checkliste, die man vor dem Audit abhakt, sondern eine Art, industrielle Systeme vom ersten Architekturentwurf an zu gestalten. Drei praktische Schlussfolgerungen: Legen Sie das angestrebte Security Level für jede Zone fest, bevor Sie Hardware auswählen; behandeln Sie Teil 4-1 als Prozessprojekt, denn dort entsteht der größte Arbeitsaufwand; und bauen Sie Geräteidentität und signierte Firmware von Beginn an ein, weil ein späteres Nachrüsten in der Regel ein Redesign bedeutet.
Bei FSS Technology entwickeln wir industrielle Geräte und Gateways nach genau diesen Anforderungen — von der Auswahl des Mikrocontrollers mit Secure Boot über Firmware mit RBAC und TLS bis zum Backend, das die Flotte protokolliert. Wenn Sie ein Produkt oder ein IIoT-Projekt planen, das dieser Norm entsprechen muss, lernen Sie unsere Leistungen im Bereich vernetzter Geräte kennen und sprechen wir über Ihre Architektur.