IEC 62443-4-1: sichere Produktentwicklung für Hersteller

Dieser Leitfaden erklärt die acht Practices, die vier Reifegrade und den Bezug zu IEC 62443-4-2 und zum Cyber Resilience Act. Am Beispiel eines Steuerungsherstellers sehen Sie, wie Sie in sechs Schritten anfangen. Die Norm geben wir nur in eigenen Worten wieder, die Beispiele sind erfunden.

Für wen IEC 62443-4-1 gilt

Die Norm richtet sich an Hersteller, in der Reihe „Product Supplier“ genannt: Anbieter von Steuerungen, Gateways, Bedien- und Engineering-Software, Host- und Netzwerkkomponenten. Maschinenbauer mit eigener Steuerungs- oder Softwareentwicklung zählen oft dazu. Die erste Ausgabe erschien 2018 (IEC 62443-4-1:2018, inhaltsgleich ANSI/ISA-62443-4-1-2018).

IEC 62443-4-1 ist keine gesetzliche Pflicht. Kunden verlangen die Norm aber zunehmend in Ausschreibungen, und sie liefert eine naheliegende Grundlage für die Pflichten aus der Verordnung (EU) 2024/2847, dem Cyber Resilience Act (CRA). Wer die Teile der Reihe zuerst einordnen möchte, beginnt mit unserem Leitfaden zum Überblick über IEC 62443.

Die acht Practices im Überblick

Eine Practice ist ein Themenfeld des Entwicklungsprozesses. Die Tabelle nennt die Kürzel, unter denen die Anforderungen in der Norm geführt werden, und die Zahl der Anforderungen je Practice.

Drei Punkte werden in der Praxis oft unterschätzt:

• Fremdkomponenten. Betriebssystem, Kryptobibliotheken und Protokollstacks machen einen großen Teil der Firmware aus. Sie brauchen Auswahl, Inventar und laufende Überwachung, nicht nur bei eigener Software.
• Release-Gate. Kein Produkt und kein Patch geht hinaus, solange bekannte Sicherheitsprobleme offen sind, es sei denn, jemand hat das Restrisiko bewusst und dokumentiert akzeptiert.
• Anwenderdokumentation. Ohne Härtungsleitfaden kann kein Integrator das Schutzkonzept des Herstellers umsetzen. Practice 8 ist deshalb kein Anhängsel, sondern Teil der Sicherheit.

Reifegrade: wie gefestigt der Prozess ist

IEC 62443-4-1 beschreibt vier Reifegrade (Maturity Level, ML). In eigenen Worten:

• ML 1, Initial: Das Ergebnis hängt von einzelnen Personen ab und ist schwer vorherzusagen.
• ML 2, Managed: Der Ablauf ist beschrieben, und die Beteiligten sind geschult. Ein echtes Produkt muss ihn noch nicht durchlaufen haben.
• ML 3, Defined, auch Practiced: Der Ablauf gilt im ganzen Unternehmen gleich und hat sich an mindestens einem Produkt nachweislich bewährt.
• ML 4, Improving: Sie messen, wie gut der Ablauf wirkt, und belegen die Verbesserung mit Kennzahlen.

Der Reifegrad wird je Practice betrachtet und darf sich unterscheiden. Wichtig: Der Reifegrad sagt, wie gefestigt der Prozess ist, nicht, wie viele Anforderungen Sie auslassen dürfen. Was Sie für ein Produkt als anwendbar festlegen, muss erfüllt sein. Welche Mindestreifegrade ein Zertifizierungsprogramm verlangt, klären Sie beim Programmbetreiber.

Bezug zu IEC 62443-4-2

Die beiden Herstellerteile teilen sich die Arbeit. IEC 62443-4-1 beschreibt den Prozess, IEC 62443-4-2 die technischen Fähigkeiten einer Komponente je Security Level, getrennt nach Softwareanwendung, eingebettetem Gerät, Host-Gerät und Netzwerkgerät. Das erreichbare Niveau heißt SL-C (Capability Security Level).

Beide greifen ineinander: 4-2 setzt voraus, dass die Komponente nach einem Prozess gemäß 4-1 entwickelt wurde. Das angestrebte SL-C geht umgekehrt als Anforderung in Practice 2 ein, und die Tests aus Practice 5 belegen es. Mehr zu den Stufen finden Sie im Leitfaden zu Security Levels.

Bezug zum CRA

Der CRA schreibt keine bestimmte Norm vor, deckt sich aber in vielen Punkten mit 4-1. Die Risikobewertung nach Art. 13 Abs. 2 CRA passt zu Practice 2, die Sorgfalt bei Fremdkomponenten nach Art. 13 Abs. 5 zu Practice 1, die Schwachstellenbehandlung nach Anhang I Teil II zu den Practices 5, 6 und 7. Nach unserem Stand vom 10.11.2026 ist keine harmonisierte Norm zum CRA im Amtsblatt veröffentlicht, ein Prozess nach 4-1 begründet deshalb keine Konformitätsvermutung.

Einige Pflichten kommen nur aus dem Gesetz, etwa die Meldungen nach Art. 14, die SBOM in maschinenlesbarem Format und die festgelegte Supportzeit. Den vollständigen Abgleich zeigt unser Leitfaden „CRA und IEC 62443“. Vertiefungen bieten die Leitfäden zum Schwachstellenprozess nach CRA und zur SBOM, die auch die BSI TR-03183-2 einordnet. Den Gesetzestext finden Sie auf EUR-Lex.

In sechs Schritten zum Prozess nach 4-1

1. Geltungsbereich festlegen. Für welche Produkte und Versionen gilt der Prozess? Welcher Komponententyp nach 4-2 ist jedes Produkt?
2. Ist-Stand je Practice erheben. Gehen Sie die acht Practices durch und halten Sie fest, was es schon gibt: Reviews, Testberichte, ein Ticket-System für Kundenmeldungen.
3. Ziel festlegen. Bestimmen Sie den angestrebten Reifegrad je Practice, das SL-C je Komponente und den Nachweisweg: Selbsterklärung, Prozesszertifikat oder Produktzertifikat.
4. Lücken priorisieren. Beginnen Sie dort, wo Kunden und CRA zugleich ansetzen: Fremdkomponenten mit SBOM, Umgang mit Schwachstellen und Security-Updates.
5. An einem Produkt durchlaufen. Ein Ablauf, der nur auf Papier steht, bleibt auf ML 2. Erst ein echtes Projekt zeigt, ob Vorlagen und Freigaben im Alltag tragen.
6. Messen und verbessern. Werten Sie im Feld gefundene Sicherheitsfehler auf ihre Ursache im Prozess aus und passen Sie den Prozess an.

Beispiel: Hersteller von Kompaktsteuerungen

Das Beispiel ist erfunden. Ein Hersteller mit 60 Entwicklerinnen und Entwicklern baut Kompaktsteuerungen und ein Gateway für die Fernwartung. Ein großer Kunde verlangt in einer Ausschreibung den Nachweis eines Prozesses nach IEC 62443-4-1.

• Ist-Stand: Code-Reviews und Funktionstests gibt es seit Jahren. Ein Bedrohungsmodell fehlt, Kundenmeldungen zu Sicherheitslücken landen im allgemeinen Support-Postfach.
• Ziel: ML 3 in allen Practices für das Gateway, SL-C 2 nach 4-2, später ein Prozesszertifikat.
• Erste Schritte: Das Team erstellt für das Gateway ein Bedrohungsmodell mit Datenflüssen und Vertrauensgrenzen. Eine SBOM entsteht nun bei jedem Build. Eine feste Adresse für Sicherheitsmeldungen und ein kleines PSIRT mit Vertretung übernehmen die Bewertung.
• Nach dem ersten Release: Das Release-Gate prüft, ob alle Sicherheitsaktivitäten erledigt sind. Der Härtungsleitfaden liegt der Auslieferung bei. Die Steuerungen folgen im nächsten Zyklus nach demselben Ablauf.

Typische Fehler

• Nur Technik ansehen. 4-1 bewertet den Prozess. Eine sichere Komponente ohne nachvollziehbaren Ablauf erfüllt die Norm nicht.
• Alles auf einmal. Ein Prozess für alle Produkte gleichzeitig überfordert viele Teams. Beginnen Sie mit einem Produkt.
• Fremdcode vergessen. Schwachstellen stecken nicht nur im eigenen Code, sondern auch in zugelieferten Bibliotheken.
• Ausgabe nicht festhalten. Notieren Sie, welche Ausgabe der Norm Sie anwenden, und prüfen Sie, welche ein Zertifizierungsprogramm zugrunde legt.

Checkliste

• Produkte und Versionen im Geltungsbereich sind festgelegt.
• Rollen und Verantwortliche im Entwicklungsprozess sind benannt.
• Die Ausgabe der Norm und der Nachweisweg sind entschieden.
• Ist-Stand und Ziel-Reifegrad je Practice sind dokumentiert.
• Jedes Produkt hat ein Bedrohungsmodell.
• Fremdkomponenten sind je Version in einer SBOM erfasst und werden überwacht.
• Sicherheitsmeldungen haben eine feste Adresse und einen beschriebenen Ablauf.
• Ein Release-Gate verhindert Auslieferungen mit offenen Sicherheitsproblemen.
• Anwender erhalten einen Härtungsleitfaden.
• Der Prozess wird regelmäßig geprüft und verbessert.

IEC 62443-4-1 in Complass

Eine Excel-Liste mit 47 Zeilen zeigt nicht, welcher Nachweis zu welcher Produktversion gehört, und Vorlagen liegen verstreut in E-Mails. In Complass führen Sie den Prozess an einem Ort:

• Modul IEC 62443 für Hersteller. Neun Phasen führen vom Produktziel und Reifegrad über die acht Practices bis zu den Komponentenanforderungen je SL-C.
• Kataloge. Alle 47 Anforderungen der Practices aus 4-1 und die Komponentenanforderungen aus 4-2, jede mit Umsetzungshilfe, Nachweisen und Beispielen aus der Industrie. 4-2 lässt sich nach Komponententyp filtern.
• Herstellervorlagen. Unter anderem SDL-Beschreibung, Bedrohungsmodell, Security-Testplan, PSIRT-Prozess, Update-Konzept, Härtungsleitfaden, SL-C-Erklärung und Abgleich mit CRA Anhang I.
• SBOM und Schwachstellen. SBOM je Produktversion mit automatischem Abgleich gegen NVD, KEV, EPSS und EUVD, VEX-Bewertung und Herstellerhinweise im CSAF-Format.

Die Normtexte sind nicht enthalten, weil Normen urheberrechtlich geschützt sind. Complass erklärt die Anforderungen in eigenen Worten, Auszüge aus Ihrer lizenzierten Ausgabe können Sie selbst hinterlegen.

Häufige Fragen

Brauchen wir ein Zertifikat nach IEC 62443-4-1?

Nicht zwingend. Viele Hersteller beginnen mit einer Selbsterklärung und eigenen Nachweisen. Ein Prozesszertifikat einer unabhängigen Stelle, etwa im IECEE-Schema oder nach dem Programm ISASecure SDLA, schafft bei Kunden zusätzliches Vertrauen.

Welcher Reifegrad ist der richtige?

Das hängt von Kunden und Zertifizierungsprogramm ab. ML 3 setzt voraus, dass der Prozess an mindestens einem Produkt gelebt wurde. Legen Sie das Ziel je Practice fest und begründen Sie es.

Gilt 4-1 auch für reine Software?

Ja. Die Norm betrachtet Produkte für die Industrieautomation, dazu gehören auch Bedien- und Engineering-Software. Der Komponententyp nach 4-2 lautet dann Softwareanwendung.

Reicht ein Prozess nach 4-1 für den CRA?

Er deckt viel ab, aber nicht alles. Meldungen nach Art. 14, die festgelegte Supportzeit und die Konformitätsbewertung kommen aus dem Gesetz. Ein guter 4-1-Prozess liefert dafür die meisten Bausteine.

In einer Demo zeigen wir Ihnen an der Demo-Firma, wie aus verstreuten Vorlagen ein nachvollziehbarer Entwicklungsprozess je Produkt wird.

Demo anfragen 14 Tage testen

Weiterlesen

• Leitfaden „CRA und IEC 62443: was sich überschneidet“
• Leitfaden „CRA: Schwachstellenprozess und CSAF“
• Leitfaden „SBOM nach CRA: Pflichten, Format und Tiefe“
• Leitfaden „Security Level in IEC 62443 einfach erklärt“
• Whitepaper „Secure Development nach CRA und IEC 62443-4-1“
• IEC 62443 für Hersteller in Complass

Keine Rechtsberatung. Dieser Leitfaden gibt einen allgemeinen Überblick und ersetzt nicht die Prüfung im Einzelfall. Maßgeblich sind der Wortlaut der Verordnung (EU) 2024/2847 und Ihre lizenzierte Ausgabe der Norm. Stand der Normung: 10.11.2026.