IEC 62443
in der Praxis.
DevSecOps für OT.
Was die Normenreihe von Betreibern, Integratoren und Herstellern verlangt, wann sie verpflichtend ist und wie eine CI/CD-Pipeline die Nachweise für das Audit gleich mitliefert, ohne die Produktion auszubremsen.
AI
Andreas Schönfeld
Geschäftsführer & DevOps-Berater, Comquent GmbH
DevOps, CI/CD und Industrial Automation seit 2006.
Stand: 17.09.2026 · NIS2UmsuCG in Kraft seit 06.12.2025 · CRA-Meldepflicht seit 11.09.2026 · IEC 62443-2-1 Ausgabe 2024
Was ist die IEC 62443?
Die IEC 62443 ist die internationale Normenreihe für Cybersecurity in industriellen Automatisierungs- und Steuerungssystemen (IACS). Sie teilt die Verantwortung auf Betreiber, Systemintegratoren und Komponentenhersteller auf, legt vier Security Levels (SL 1–4) und sieben Foundational Requirements fest und segmentiert Anlagen in Zonen und Conduits. DevSecOps macht diese Anforderungen prüfbar, als Security-Stages und Gates direkt in der CI/CD-Pipeline.
Security.
Nicht am Ende.
In jeder Stufe.
Dieser Artikel geht in der Reihenfolge vor, in der die Fragen im Projekt auftauchen: Warum OT eigene Regeln braucht, welche Normteile für Ihre Rolle gelten und ob Sie überhaupt müssen. Danach folgen Security Levels und Zonen, und zum Schluss, wie CI/CD-Pipelines die geforderten Nachweise erzeugen.
Wer nur die Kurzfassung braucht, findet die Definition im Glossar-Eintrag zur IEC 62443.
Ist DevSecOps nach IEC 62443 bei Ihnen gerade ein Thema?
Wir fragen kurz, wie dringend das Thema bei Ihnen gerade ist. Je nach Antwort zeigen wir Ihnen direkt den passenden nächsten Schritt — ganz ohne Formular.
Warum lässt sich IT-Security nicht einfach auf OT übertragen?
Weil eine Industrieanlage andere Prioritäten hat. In der IT steht die Vertraulichkeit vorn, in der OT die Verfügbarkeit und die Sicherheit von Menschen. Eine Steuerung läuft 15 bis 30 Jahre, ein Patch braucht einen geplanten Stillstand, und viele Feldprotokolle kennen keine Verschlüsselung.
In der IT ist DevSecOps eingespielt. Security-Checks laufen automatisch in der Pipeline, Container werden bei jedem Build gescannt, eine Schwachstelle ist oft am selben Tag gepatcht. Diese Arbeitsweise heißt Shift Left: Security beginnt beim ersten Commit.
In der Halle sieht es anders aus. Dort läuft eine SPS seit zwölf Jahren mit demselben Programmstand, weil jede Änderung eine Abnahme braucht. Im Schaltschrank hängt ein Fernwartungsrouter, den der Maschinenlieferant bei der Inbetriebnahme eingebaut hat, und wer genau darauf zugreift, weiß im Werk niemand mehr sicher. So sehen die meisten Anlagen aus, die wir zum ersten Mal zu Gesicht bekommen. Genau daran setzt die Norm an.
Das gilt auch fürs Messen. DORA-Metriken brauchen in der Industrie eigene Zielwerte, etwa Deployments pro Wartungsfenster statt mehrmals am Tag. Die kulturelle Seite des Unterschieds beschreibt der Artikel zum IT/OT-Kulturwandel.
Welche Angriffe haben Industrieanlagen schon lahmgelegt?
Zwei der drei bekanntesten Fälle begannen in der Büro-IT. Die Produktion stand trotzdem, weil niemand sicher sagen konnte, ob der Angriff schon in der Anlage war. Genau diese Frage sollen Zonen und Conduits beantwortbar machen.
- 2021Colonial Pipeline
DarkSide-Ransomware trifft die IT. Der Betreiber stoppt die größte Kraftstoff-Pipeline der USA vorsorglich für mehrere Tage.
- 2019Norsk Hydro
LockerGoga verschlüsselt das Firmennetz, Werke fahren teilweise im Handbetrieb. Schaden allein im ersten Quartal: 400 bis 450 Mio. NOK.
- 2017TRITON / TRISIS
Schadsoftware greift in einer petrochemischen Anlage das Safety Instrumented System an, also genau die Steuerung, die Menschen schützen soll.
Aus welchen Teilen besteht die IEC 62443?
Die Reihe hat vier Gruppen: Grundlagen (Teil 1), Betreiber und Dienstleister (Teil 2), System (Teil 3) und Komponente (Teil 4). Welche Teile Sie betreffen, hängt an Ihrer Rolle im Lebenszyklus der Anlage, nicht an Ihrer Branche.
- /1-x
Grundlagen
Alle
Begriffe, Konzepte und Modelle. Hier stehen die Definitionen, auf die sich alle anderen Teile beziehen, darunter Zonen, Conduits und Security Levels.
- /2-x
Betreiber und Dienstleister
Asset Owner, Service Provider
2-1 verlangt vom Betreiber ein Security-Programm mit Rollen, Change- und Patch-Management (zweite Ausgabe 2024). 2-4 legt fest, was Integrations- und Wartungsdienstleister an Security-Fähigkeiten nachweisen müssen.
- /3-x
System
Systemintegrator, Betreiber
3-2 beschreibt die Risikoanalyse und die Aufteilung in Zonen und Conduits. 3-3 legt die technischen Systemanforderungen fest und ordnet sie den Security Levels zu.
- /4-x
Komponente
Hersteller
4-1 regelt den sicheren Entwicklungsprozess, 4-2 die technischen Anforderungen an die fertige Komponente. Für DevSecOps ist 4-1 der Teil, der sich am direktesten in eine Pipeline übersetzen lässt.
Was ist der Unterschied zwischen IEC 62443-4-1 und 4-2?
4-1 fragt, wie Sie entwickeln: Anforderungen, Threat Modeling, sichere Implementierung, Tests, Umgang mit Schwachstellen, Updates. 4-2 fragt, was die fertige Komponente kann, etwa Benutzerverwaltung, Protokollierung oder gesicherte Updates. Der Prozess nach 4-1 ist die Voraussetzung dafür, dass Sie die Eigenschaften nach 4-2 bei jedem Release wieder belegen können.
Was regelt die IEC 62443-2-4?
2-4 richtet sich an Integratoren und Wartungsdienstleister, also oft an den Maschinenbauer, der nach der Auslieferung per Fernzugriff nachbessert. Der Teil regelt Fernzugänge, Patches, Backups und Konfigurationsänderungen. Betreiber geben diese Anforderungen zunehmend in ihren Verträgen an Lieferanten weiter.
Welcher IEC-62443-Weg passt zu Ihrer Rolle?
Die IEC 62443 adressiert Betreiber, Hersteller und Integratoren mit unterschiedlichen Normteilen — der richtige Einstieg hängt an Ihrer Rolle. Wählen Sie sie aus, und Sie sehen, welche Teile der Norm für Sie zählen.
Welche Rolle haben Sie im Anlagen-Lebenszyklus?
Ist die IEC 62443 verpflichtend?
Die IEC 62443 ist selbst kein Gesetz, aber faktisch verbindlich. Gesetze wie das BSI-Gesetz und der Cyber Resilience Act verlangen den Stand der Technik oder Security by Design, und für OT-Umgebungen ist die IEC 62443 der Maßstab, an dem Behörden, Auditoren und Kunden das messen.
Seit dem 6. Dezember 2025 gilt die NIS2-Richtlinie in Deutschland über das neue BSI-Gesetz. § 30 Abs. 2 BSIG verlangt von wichtigen und besonders wichtigen Einrichtungen, dass ihre Maßnahmen „den Stand der Technik einhalten, die einschlägigen europäischen und internationalen Normen berücksichtigen“. Für Steuerungs- und Automatisierungstechnik ist das die IEC 62443.
Ob Ihr Unternehmen darunter fällt, entscheiden Mitarbeiterzahl, Umsatz, Bilanzsumme und Sektor nach § 28 BSIG. Die Grundbegriffe zu NIS2 stehen im Glossar.
Der EU Cyber Resilience Act gilt für Produkte mit digitalen Elementen. Seit dem 11. September 2026 müssen Hersteller aktiv ausgenutzte Schwachstellen melden, ab dem 11. Dezember 2027 gilt die Verordnung vollständig, einschließlich Security by Design und SBOM.
CENELEC passt die EN IEC 62443-4-1 und -4-2 derzeit mit Änderungen (A11) an die CRA-Anforderungen an. Eine harmonisierte CRA-Norm mit Vermutungswirkung steht noch nicht im Amtsblatt. Wer heute nach 4-1 entwickelt, baut trotzdem genau den Prozess auf, den der CRA prüft.
Betreiber kritischer Anlagen und große Konzerne schreiben die IEC 62443 in ihre Lastenhefte. Für Integratoren und Maschinenbauer entscheidet das oft früher über den Auftrag als jedes Gesetz.
Wer die Norm umsetzt, erfüllt also nicht die Norm um ihrer selbst willen, sondern die gesetzliche Sorgfaltspflicht dahinter. Wie wir Unternehmen dabei begleiten, beschreibt die Leistung DevSecOps & Compliance.
Was bedeuten die Security Levels SL 1 bis 4?
Ein Security Level beschreibt, gegen welchen Angreifer eine Zone geschützt ist, von der zufälligen Fehlbedienung (SL 1) bis zum Angreifer mit großen Ressourcen und tiefem Anlagenwissen (SL 4). SL 0 heißt, dass keine besonderen Anforderungen gelten. Nicht jede Zone braucht SL 4. Welches Level passt, entscheidet die Risikoanalyse.
- SL 1
Zufällige Verletzung
Grundhygiene.
Schutz gegen unbeabsichtigte Fehlbedienung und zufällige Verletzungen. Standardpasswörter ändern, Basis-Firewall, physischer Zugangsschutz.
- SL 2
Gezielter Angriff mit einfachen Mitteln
Rollen, Verschlüsselung, Audit-Logs.
Schutz gegen Angreifer mit allgemeinen IT-Kenntnissen, wenig Ressourcen und geringer Motivation. Rollenbasierte Zugriffe, verschlüsselte Kommunikation, protokollierte Änderungen.
- SL 3
Angriff mit IACS-Wissen
MFA, Intrusion Detection, Härtung.
Schutz gegen Angreifer, die Automatisierungssysteme kennen und moderate Ressourcen einsetzen. Multi-Faktor-Authentifizierung, Intrusion Detection, Security-Monitoring, gehärtete Konfigurationen.
- SL 4
Angriff mit umfangreichen Ressourcen
Zero Trust, Anomalie-Erkennung, unidirektionale Gateways.
Schutz gegen Angreifer mit tiefem IACS-Wissen, großen Ressourcen und hoher Motivation, in der Praxis meist staatlich unterstützte Gruppen. Zero-Trust-Architektur, Anomalie-Erkennung, unidirektionale Gateways.
SL-T, SL-C, SL-A: Welches Level ist gemeint?
In Gesprächen mit Lieferanten geht das oft durcheinander. Die Norm unterscheidet drei Blickwinkel auf dasselbe Level.
- SL-TTarget
- Das Ziel. Die Risikoanalyse legt es für jede Zone und jeden Conduit fest.
- SL-CCapability
- Was ein System (3-3) oder eine Komponente (4-2) bei richtiger Konfiguration leisten kann.
- SL-AAchieved
- Was in der laufenden Anlage tatsächlich erreicht ist.
Ein Switch mit SL-C 3 ergibt deshalb noch kein SL-A 3, wenn er mit Werkspasswort in Betrieb geht. Die Lücke zwischen SL-C und SL-A schließt die Konfiguration, und die lässt sich in einer Pipeline prüfen.
Wie teilt man eine Anlage in Zonen und Conduits ein?
Komponenten mit ähnlichem Schutzbedarf kommen in eine gemeinsame Zone. Zonen sprechen nur über definierte, kontrollierte Übergänge miteinander, die Conduits. Jede Zone bekommt aus der Risikoanalyse ihr eigenes Ziel-Security-Level.
Wie läuft die Risikoanalyse nach IEC 62443-3-2 ab?
Die IEC 62443-3-2 beschreibt sieben Schritte, die mit „ZCR“ nummeriert sind (Zone and Conduit Requirements). Am Ende steht ein Dokument, das je Zone sagt, welches Level gilt und warum, freigegeben vom Betreiber.
Rechnen Sie für eine mittelgroße Linie mit mehreren Workshops, nicht mit einem Nachmittag. Der Aufwand steckt selten in der Methode, sondern darin, erst einmal vollständig zu erfassen, was in der Anlage alles verbaut und angeschlossen ist.
- ZCR 1System abgrenzen
Was gehört zum betrachteten System, wo sind seine Grenzen und Zugänge?
- ZCR 2Erste Risikobewertung
Grob abschätzen, welcher Schaden im schlimmsten Fall entsteht.
- ZCR 3Zonen und Conduits bilden
Komponenten mit ähnlichem Schutzbedarf zusammenfassen, Übergänge festlegen.
- ZCR 4Mit tolerierbarem Risiko vergleichen
Liegt das Risiko über dem, was das Unternehmen tragen will, geht es in die Tiefe.
- ZCR 5Detaillierte Analyse je Zone
Bedrohungen, Schwachstellen, Folgen und daraus das Ziel-Security-Level (SL-T).
- ZCR 6Anforderungen dokumentieren
Security-Anforderungen, Annahmen und Randbedingungen je Zone und Conduit.
- ZCR 7Freigabe durch den Betreiber
Der Asset Owner bestätigt das Ergebnis und trägt damit das Restrisiko.
Was hat das Purdue-Modell mit Zonen zu tun?
Das Purdue-Modell ordnet eine Anlage in Ebenen, von den Feldgeräten auf Level 0 bis zur Unternehmens-IT auf Level 4 und 5, meist mit einer Industrial DMZ auf Level 3.5. Die Ebenen sind ein guter erster Entwurf für Zonen. Die IEC 62443 schreibt sie aber nicht vor. In der Grafik liegt die Safety-SPS auf derselben Ebene wie die übrige Linie und bekommt trotzdem eine eigene Zone mit höherem Ziel-Level.
Was heißt das für die Pipeline?
Eine Pipeline, die bis auf die Steuerung ausrollt, darf die Segmentierung nicht aufweichen. Bewährt hat sich ein Agent in der Werkszone, der signierte Stände selbst aus der DMZ holt, statt dass die IT hineinschreibt. Wie das technisch aussieht, erklärt der Glossar-Eintrag zum OT-Proxy-Agent.
Wie werden die sieben Foundational Requirements zur Pipeline-Aufgabe?
Die IEC 62443 gliedert alle technischen Anforderungen in sieben Foundational Requirements (FR). Jede FR lässt sich auf konkrete Prüfungen in der CI/CD-Pipeline abbilden. Die Tabelle zeigt das Mapping, das wir in Industrieprojekten verwenden.
Wie sieht eine DevSecOps-Pipeline nach IEC 62443 aus?
Sieben Stages, jede mit einem Gate. Jede Stage prüft einen Teil der Foundational Requirements und deckt eine Praxis des Entwicklungsprozesses nach IEC 62443-4-1 ab. Was nicht besteht, erreicht die Anlage nicht.
- /01
Secure Commit
FR 1 · 4-1: sichere Implementierung
Pre-Commit-Hooks prüfen jeden Commit auf Secrets und Zugangsdaten. API-Keys und Passwörter erreichen das Repository gar nicht erst.
git-secrets, detect-secrets, pre-commit hooks
- /02
Static Analysis (SAST)
FR 3 · 4-1: sichere Implementierung
Die statische Code-Analyse findet unsichere Funktionsaufrufe und Regelverstöße, bevor der Code gebaut wird.
SonarQube, Semgrep, Fortify, eigene Regeln
- /03
Dependency Scanning
FR 3 · 4-1: Umgang mit Schwachstellen
Jede Abhängigkeit wird gegen CVE-Datenbanken geprüft. Aus demselben Lauf entsteht die SBOM des Releases.
OWASP Dependency-Check, Trivy, Grype, Syft (SBOM)
- /04
Build & Sign
FR 3 · 4-1: Security-Updates
Die Pipeline baut in einer kontrollierten Umgebung und signiert jedes Artefakt. Auf der Anlage läuft nur, was diese Signatur trägt.
Jenkins, GitLab CI, cosign, Sigstore, Notation
- /05
Dynamic Testing (DAST)
FR 5 · 4-1: Security-Tests
Das laufende System wird in einer Testumgebung auf offene Ports, unsichere Konfigurationen und umgehbare Anmeldungen geprüft. Aktive Scans gehören nie in die laufende Produktion.
OWASP ZAP, Nessus, OpenVAS, OT-fähige Scanner
- /06
Compliance Gate
Alle FRs · 4-1: Security-Anforderungen
Policy-as-Code prüft, ob das Release die Anforderungen der Zielzone erfüllt. Fällt eine Prüfung durch, stoppt die Pipeline.
Open Policy Agent (OPA), Prüfskripte, Audit-Reports
- /07
Deploy & Monitor
FR 6 · FR 7
Ausgerollt wird über die Conduits und im Wartungsfenster. Danach überwachen Security-Monitoring und Anomalie-Erkennung den neuen Stand.
SIEM, Wazuh, Grafana, Prometheus, OT-IDS
AIWer die Nachweise von Hand pflegt, kennt das Muster: Drei Wochen vor dem Audit sammelt jemand Screenshots, Scan-Reports und Freigabe-Mails zusammen, und beim nächsten Release ist die Hälfte davon schon wieder veraltet. Die Pipeline oben erzeugt dieselben Belege bei jedem Lauf, datiert und dem Release zugeordnet.
Wer hat das wann freigegeben?
Die IEC 62443 verlangt mit dem Betreiber-Teil 2-1 ausdrücklich eine Organisation, kein Werkzeug: ein dokumentiertes Security-Programm mit benannten Rollen und Verantwortlichkeiten, nachgewiesener Kompetenz und Awareness der Beteiligten, geregeltem Change- und Patch-Management sowie einem definierten Umgang mit Vorfällen. Wer die technischen Anforderungen erfüllt und die organisatorischen nicht, besteht kein Audit. Umgekehrt gilt dasselbe.
Im Audit zählt nicht, was jemand erinnert, sondern welche Spur die Änderung hinterlassen hat. Kommt die Frage nach der Freigabe-Historie, dauert die Antwort einen Vormittag oder mehrere Wochen. Das hängt daran, ob Commit, Review, Testergebnis, signiertes Artefakt und Deployment-Log eine zusammenhängende Kette bilden oder als Screenshots in fünf Postfächern liegen.
AIAn dieser Stelle scheitern Zertifizierungsvorhaben nach unserer Erfahrung häufiger als an fehlender Technik. Es fehlt eine Zusammenarbeit zwischen IT und OT, die diese Nachweise im Alltag nebenbei erzeugt. Wie ein Team schrittweise dorthin kommt, beschreibt der Artikel DevOps-Kultur im Unternehmen etablieren. Eine Fehlerkultur ohne Schuldzuweisung ist in regulierten Umgebungen kein weiches Thema: Wer eine Fehlkonfiguration meldet, statt sie still zu korrigieren, erzeugt genau den Nachweis, den das Audit später sehen will.
Wie läuft eine IEC-62443-Zertifizierung ab?
Eine IEC-62443-Zertifizierung hat vier Schritte: Rolle und Scope festlegen, Gap-Analyse, Audit durch eine akkreditierte Stelle und regelmäßige Überwachungsaudits. Eine automatisierte DevSecOps-Pipeline liefert die Nachweise für das Audit gleich mit.
- /01Rolle und Scope festlegen
Hersteller (4-1, 4-2), Systemintegrator (3-3, 2-4) oder Betreiber (2-1). Die Rolle bestimmt, welche Teile geprüft werden.
- /02Gap-Analyse
Den Ist-Stand gegen die Anforderungen prüfen. Bei 4-1 sind das die acht Praktiken vom Security Management bis zu den Security-Updates.
- /03Audit durch eine akkreditierte Stelle
Zertifizierer wie TÜV oder die Stellen im ISASecure-Programm prüfen Prozesse, Dokumentation und technische Umsetzung.
- /04Überwachungsaudits
Das Zertifikat gilt nicht unbegrenzt. Wiederkehrende Audits prüfen, ob der Prozess gelebt wird.
Was sind Maturity Levels?
Bei Prozessnormen wie 4-1 und 2-1 bewertet das Audit neben dem Ob auch das Wie gut, in vier Maturity Levels von „initial“ bis „verbessernd“. Viele Hersteller zielen zuerst auf Level 2 oder 3: Der Prozess ist beschrieben und wird nachweisbar gelebt.
Das Programm ISASecure bietet eigene Zertifizierungen für Entwicklungsprozess, Komponente und System an. Welche Sie brauchen, hängt an der Rolle aus Schritt 01.
Womit fangen Sie morgen an?
Sie müssen nicht die ganze Norm auf einmal umsetzen. Diese fünf Maßnahmen bringen spürbar mehr Sicherheit bei überschaubarem Aufwand, und drei davon sind in einem Tag erledigt.
- /01
Secrets aus dem Repository entfernen
Aufwand: NiedrigInstallieren Sie git-secrets oder detect-secrets als Pre-Commit-Hook. Kosten: 30 Minuten. Wirkung: sofort. Kein Credential landet mehr im Repository.
- /02
Dependency Scanning aktivieren
Aufwand: NiedrigTrivy oder OWASP Dependency-Check in die bestehende Pipeline einbauen. Ein zusätzlicher Stage, der alle Abhängigkeiten gegen CVE-Datenbanken prüft.
- /03
SBOM generieren
Aufwand: NiedrigMit Syft oder CycloneDX bei jedem Build eine Software Bill of Materials erzeugen. Der EU Cyber Resilience Act verlangt sie von Herstellern.
- /04
Netzwerk-Segmentierung der Build-Umgebung
Aufwand: MittelJenkins-/GitLab-Server in ein eigenes VLAN. OT-Netzwerk nur über definierte Schnittstellen erreichbar. Kein direkter Zugriff aus dem Build-Netz auf Produktionsanlagen.
- /05
Security-Retrospektive einführen
Aufwand: NiedrigEinmal pro Quartal: Was waren unsere Security-Incidents? Welche Schwachstellen wurden gefunden? Was können wir verbessern? Gemeinsam mit IT und OT.
Der erste Ertrag ist meist noch am selben Tag sichtbar. Der erste Dependency-Scan liefert eine konkrete Liste verwundbarer Bibliotheken, und aus der abstrakten Norm wird ein Arbeitsstand, den das Team abarbeiten kann.
Danach lohnt der Schritt zur Risikoanalyse aus Abschnitt 07, denn erst sie sagt, welches Level jede Zone wirklich braucht. Parallel wächst ein systematisches Schwachstellenmanagement für die OT, gespeist aus der SBOM jedes Builds. Wie das im Maschinenbau mit SPS-Steuerungen aussieht, zeigt der Anwendungsfall.
Auf welche Quellen stützt sich der Artikel?
- International Society of Automation (ISA)
- International Electrotechnical Commission (IEC)
- Bundesministerium der Justiz
- Amtsblatt der Europäischen Union
- Amtsblatt der Europäischen Union
- CEN-CENELEC
- Cybersecurity and Infrastructure Security Agency (CISA)
- Computer Weekly
- Mandiant / Google Cloud
- MITRE Corporation
- National Institute of Standards and Technology
Häufige Fragen zur IEC 62443 und zu DevSecOps in der Industrie
- Q.01Was ist die IEC 62443 und für wen gilt sie?
- Die IEC 62443 ist die internationale Normenreihe für Cybersecurity in industriellen Automatisierungs- und Steuerungssystemen (Industrial Automation and Control Systems, IACS). Sie richtet sich an drei Rollen: Betreiber (Asset Owner), Systemintegratoren und Dienstleister sowie Komponentenhersteller. Für jede Rolle legt ein eigener Normteil fest, was sie nachweisen muss.
- Q.02Ist die IEC 62443 verpflichtend?
- Die IEC 62443 ist selbst kein Gesetz, aber faktisch verbindlich. § 30 Abs. 2 BSIG verlangt von Einrichtungen unter NIS2, bei ihren Sicherheitsmaßnahmen den Stand der Technik einzuhalten und einschlägige europäische und internationale Normen zu berücksichtigen, und für OT ist das die IEC 62443. Der EU Cyber Resilience Act (CRA) fordert von Herstellern Security by Design, was sich mit IEC 62443-4-1 und -4-2 belegen lässt. Viele KRITIS-Betreiber und Ausschreibungen setzen die Norm zusätzlich voraus.
- Q.03Aus welchen Teilen besteht die IEC 62443?
- Die Reihe hat vier Gruppen. Teil 1 legt Begriffe und Modelle fest. Teil 2 richtet sich an Betreiber und Dienstleister, darunter 2-1 (Security-Programm des Betreibers) und 2-4 (Anforderungen an Integrations- und Wartungsdienstleister). Teil 3 betrifft das System, darunter 3-2 (Risikoanalyse, Zonen und Conduits) und 3-3 (Systemanforderungen und Security Levels). Teil 4 betrifft Komponenten, mit 4-1 (sicherer Entwicklungsprozess) und 4-2 (technische Anforderungen an die Komponente).
- Q.04Was ist der Unterschied zwischen IEC 62443-4-1 und 4-2?
- Die IEC 62443-4-1 legt den sicheren Entwicklungsprozess eines Herstellers fest, die IEC 62443-4-2 die technischen Sicherheitsanforderungen an die fertige Komponente. 4-1 beschreibt also, wie entwickelt wird, 4-2, was das Produkt können muss. Für DevSecOps ist 4-1 der wichtigere Teil, weil sich der geforderte Prozess in einer CI/CD-Pipeline automatisieren lässt.
- Q.05Was regelt die IEC 62443-2-4?
- Die IEC 62443-2-4 legt fest, welche Security-Fähigkeiten Dienstleister nachweisen müssen, die Automatisierungslösungen integrieren oder warten, also typischerweise Systemintegratoren und Maschinenbauer im Service. Dazu gehören etwa der Umgang mit Fernzugriffen, Patches, Backups und Konfigurationsänderungen. Betreiber nutzen den Teil, um diese Anforderungen vertraglich an ihre Lieferanten weiterzugeben.
- Q.06Was sind die Security Levels (SL 1–4) der IEC 62443?
- Die Security Levels beschreiben, gegen welchen Angreifer ein System geschützt ist. SL 1 schützt gegen zufällige Fehlbedienung, SL 2 gegen gezielte Angriffe mit einfachen Mitteln, SL 3 gegen Angreifer mit IACS-Kenntnissen und moderaten Ressourcen, SL 4 gegen Angreifer mit umfangreichen Ressourcen und hoher Motivation. SL 0 bedeutet, dass keine besonderen Anforderungen gelten. Welches Level eine Zone braucht, ergibt die Risikoanalyse nach IEC 62443-3-2.
- Q.07Was ist der Unterschied zwischen SL-T, SL-C und SL-A?
- SL-T (Target) ist das Ziel-Level, das die Risikoanalyse für eine Zone oder einen Conduit festlegt. SL-C (Capability) ist das Level, das ein System nach IEC 62443-3-3 oder eine Komponente nach IEC 62443-4-2 bei richtiger Konfiguration erreichen kann. SL-A (Achieved) ist das Level, das in der laufenden Anlage tatsächlich erreicht ist. Eine Komponente mit SL-C 3 bringt also noch kein SL-A 3, wenn sie mit Standardpasswort in Betrieb geht.
- Q.08Wie läuft die Risikoanalyse nach IEC 62443-3-2 ab?
- Die IEC 62443-3-2 beschreibt sieben Schritte. Das betrachtete System wird abgegrenzt, eine erste Risikobewertung durchgeführt und die Anlage in Zonen und Conduits aufgeteilt. Danach wird das Risiko mit dem tolerierbaren Risiko verglichen, für jede Zone und jeden Conduit eine detaillierte Risikoanalyse mit Ziel-Security-Level (SL-T) erstellt, die Anforderungen dokumentiert und vom Betreiber freigegeben. Das Ergebnis ist die Grundlage für alle technischen Maßnahmen.
- Q.09Was ist das Zonen-und-Conduits-Modell der IEC 62443?
- Die IEC 62443 teilt eine Anlage in Sicherheitszonen mit ähnlichem Schutzbedarf, die nur über definierte, kontrollierte Übergänge (Conduits) miteinander kommunizieren. Jede Zone erhält aus der Risikoanalyse ihr eigenes Ziel-Security-Level. Das Modell ist die Grundlage für OT-Netzwerksegmentierung und für sichere Deployments aus einer CI/CD-Pipeline.
- Q.10Was hat das Purdue-Modell mit der IEC 62443 zu tun?
- Das Purdue-Modell ordnet eine Industrieanlage in Ebenen von den Feldgeräten (Level 0) bis zur Unternehmens-IT (Level 4 und 5), meist mit einer Industrial DMZ auf Level 3.5 dazwischen. Viele Unternehmen nutzen diese Ebenen als ersten Entwurf für ihre Zonen. Die IEC 62443 schreibt das Modell aber nicht vor: Zonen folgen dem Schutzbedarf aus der Risikoanalyse, und eine Safety-Steuerung bekommt oft eine eigene Zone, obwohl sie auf derselben Ebene liegt wie die übrige Linie.
- Q.11Wie läuft eine IEC-62443-Zertifizierung ab?
- Eine IEC-62443-Zertifizierung hat vier Schritte: Rolle und Scope festlegen (Produkt nach 4-1/4-2, System nach 3-3 oder Betrieb nach 2-1), Gap-Analyse gegen die relevanten Anforderungen, Audit durch eine akkreditierte Stelle (zum Beispiel TÜV oder ein Zertifizierer im ISASecure-Programm) und regelmäßige Überwachungsaudits. Eine automatisierte DevSecOps-Pipeline liefert die Nachweise für das Audit gleich mit.
- Q.12Welche Anforderungen stellt die IEC 62443-4-1 an den Entwicklungsprozess?
- Die IEC 62443-4-1 verlangt einen sicheren Entwicklungs-Lebenszyklus in acht Praktiken: Security Management, Spezifikation der Security-Anforderungen, Secure by Design, sichere Implementierung, Security-Tests, Umgang mit Schwachstellen, Security-Updates und Security-Dokumentation für Anwender. Die Reife des Prozesses wird in vier Maturity Levels bewertet. In einer CI/CD-Pipeline lassen sich viele dieser Praktiken als automatisierte Stages und Gates abbilden.
- Q.13Was ist DevSecOps in der Industrie?
- DevSecOps in der Industrie bedeutet, Cybersicherheitsprüfungen nach IEC 62443 automatisiert in die CI/CD-Pipeline einzubauen, von der ersten Code-Zeile bis zum Deployment auf die Anlage. Statt Security am Ende von Hand zu prüfen, erkennt jede Pipeline-Stage Schwachstellen dort, wo sie entstehen (Shift Left). Jeder Lauf hinterlässt dabei einen Nachweis, den das Audit später sehen will.
- Q.14Wie integriert man IEC 62443 in eine CI/CD-Pipeline?
- Jede Pipeline-Stage bekommt einen Security-Check: Pre-Commit-Hooks für Secrets-Scanning, SAST und Dependency Scanning beim Build, Signatur und SBOM für jedes Artefakt, DAST im Test und ein Compliance-Gate vor dem Release. Die IEC-62443-Anforderungen stehen als Policy-as-Code im Repository und werden bei jedem Lauf automatisch geprüft. Ausgerollt wird über die Conduits, die die Zonen-Architektur vorgibt.
- Q.15Welche organisatorischen Anforderungen stellt die IEC 62443?
- Mit dem Betreiber-Teil 2-1 verlangt die IEC 62443 ausdrücklich eine Organisation: ein dokumentiertes Security-Programm mit benannten Rollen und Verantwortlichkeiten, nachgewiesener Kompetenz und Awareness der Beteiligten, geregeltem Change- und Patch-Management sowie einem definierten Umgang mit Vorfällen. Technik allein erfüllt die Norm also nicht. Gefordert ist eine Arbeitsweise, in der jede Änderung einen Verantwortlichen, eine Begründung und eine Spur hat. Deshalb scheitern Zertifizierungsvorhaben nach unserer Erfahrung seltener an fehlenden Werkzeugen als an einer Zusammenarbeit zwischen IT und OT, die diese Nachweise im Alltag nicht erzeugt.
- Q.16Wer muss eine Änderung an einer Anlage freigeben, und wie weist man das nach?
- Die Freigabe liegt beim Betreiber, der dafür im Security-Programm nach IEC 62443-2-1 Rollen und Verantwortlichkeiten festlegt. Bei sicherheitsgerichteten Funktionen kommt die Freigabe aus dem Safety-Prozess hinzu. Für den Nachweis zählt nicht die Erinnerung der Beteiligten, sondern die Spur: wer was wann auf welcher Grundlage freigegeben hat. Am verlässlichsten entsteht diese Spur als Nebenprodukt der Pipeline. Commit, Review, Testergebnis, signiertes Artefakt und Deployment-Log ergeben zusammen eine Kette, die im Audit ohne Nacharbeit vorzeigbar ist.
- Q.17Warum kann man IT-Security-Maßnahmen nicht 1:1 auf OT übertragen?
- OT-Systeme laufen unter anderen Bedingungen: Lebenszyklen von 15–30 Jahren, Verfügbarkeitsanforderungen bis 99,999 %, oft unverschlüsselte Protokolle und die Gefahr von Personenschäden bei Fehlfunktionen. Ein Patch braucht meist einen geplanten Stillstand. Security-Maßnahmen dürfen deshalb weder die Verfügbarkeit noch die funktionale Sicherheit der Anlage beeinträchtigen.
- Q.18Was ist der Unterschied zwischen Safety und Security in der OT?
- Safety schützt Menschen und Umwelt vor Gefahren, die von der Maschine ausgehen (funktionale Sicherheit). Security schützt die Maschine vor absichtlichen Angriffen und Manipulation (Cybersicherheit). Beide gehören zusammen, weil ein Angriff die funktionale Sicherheit aushebeln kann, wie der TRITON-Angriff auf ein Safety Instrumented System 2017 gezeigt hat.
- Q.19Was ist eine SBOM und warum ist sie für OT-Security wichtig?
- Eine Software Bill of Materials (SBOM) ist die vollständige Liste aller Software-Komponenten eines Produkts, einschließlich Open-Source-Bibliotheken und ihrer Versionen. Erst mit ihr lässt sich bei einer neuen Schwachstelle in Minuten sagen, welche Anlagen betroffen sind. Der EU Cyber Resilience Act verlangt von Herstellern eine SBOM für ihre Produkte.
Wie geht es bei Ihnen mit DevSecOps nach IEC 62443 weiter?
Sagen Sie uns mit einem Klick, wie es bei Ihnen weitergeht. Passend dazu bekommen Sie direkt einen konkreten nächsten Schritt — ganz ohne Formular.
Verwandte Artikel
Cyber Resilience Act im Maschinenbau
Meldepflicht, Security by Design und die Fristen bis Dezember 2027.
NIS2: Wer ist betroffen und wie setzt man sie um?
Schwellenwerte nach § 28 BSIG und die Pflichten wichtiger Einrichtungen.
SBOM erstellen: Software Supply Chain Security für CI/CD
Software Bill of Materials mit Syft und CycloneDX in der Pipeline erzeugen.
Was ist Industrial DevOps? Der komplette Leitfaden
CI/CD für cyber-physische Systeme und Industrie 4.0.
Erstgespräch.
Kostenlos.
90 Tage zum Ergebnis.
Wir klären gemeinsam, wie Sie in 90 Tagen die ersten messbaren Industrial-DevOps-Erfolge erzielen.
Industrie · Automotive · Finance