IEC 62443-4-1: Warum sichere Softwareentwicklung jetzt zur Pflicht für die Fertigung wird

Den größten Teil des letzten Jahrzehnts kannte man IEC 62443-4-1 vor allem von den großen Automatisierungsanbietern - denen mit Zertifikat auf der Website und eigenem Product-Security-Team. Für einen Maschinenbauer, der seine eigene HMI schreibt, oder einen Hersteller mit hauseigener Software, die mit einer SPS kommuniziert, stand die Norm bequem in der Spalte „schön zu haben, vielleicht später“.

Diese Spalte schließt sich gerade. Drei EU-Rechtsakte laufen auf dieselbe Frage hinaus - können Sie nachweisen, dass die Software in Ihrem Produkt sicher entwickelt wurde und dass Sie sie auch weiterhin sicher halten? - und IEC 62443-4-1 ist in der industriellen Welt die am breitesten anerkannte Antwort darauf.

1. Was IEC 62443-4-1 eigentlich ist

IEC 62443 ist eine Normenreihe zur Security von industriellen Automatisierungs- und Steuerungssystemen. Der Großteil beschreibt, wie ein Betreiber eine Anlage absichert oder welche technischen Fähigkeiten eine Komponente haben muss. Teil 4-1 ist anders: Er beschreibt nicht das Produkt, sondern den Prozess, mit dem ein Hersteller es entwickelt und pflegt - einen Secure Development Lifecycle (SDL).

Er ist in acht Praktiken gegliedert:

• Security Management - wer für Produktsicherheit verantwortlich ist, wie das Team geschult wird, wie der Prozess selbst gesteuert wird
• Spezifikation von Security-Anforderungen - ein Bedrohungsmodell und Sicherheitsanforderungen, die existieren, bevor der Code existiert
• Secure by Design - Defense in Depth, minimale Angriffsfläche, sicherheitsgeprüfte Architektur
• Sichere Implementierung - Coding-Standards, statische Analyse, Review jeder Änderung
• Security-Verifikation und -Validierung - Testen der Anforderungen, Fuzzing, Schwachstellenscans, Penetrationstests
• Management sicherheitsrelevanter Probleme - Annahme, Bewertung und Behebung von Schwachstellenmeldungen, auch von außen
• Management von Security-Updates - zeitnahe, dokumentierte und signierte Patches
• Security-Leitfäden - Dokumentation, die Integratoren und Betreibern erklärt, wie das Produkt sicher eingesetzt und betrieben wird

Jede Praxis wird anhand eines Reifegrads von 1 (ad hoc) bis 4 (kontinuierliche Verbesserung) bewertet. Die Norm ist also etwas, in das man hineinwächst, kein Bestanden/Nicht-bestanden-Häkchen.

2. Der Cyber Resilience Act macht aus „schön zu haben“ Gesetz

Der EU Cyber Resilience Act (CRA) gilt für praktisch jedes Produkt mit digitalen Elementen auf dem EU-Markt - einschließlich Industriesteuerungen, Maschinensoftware, HMIs, Gateways und der PC-Anwendungen, die sie ansteuern. Die ersten Pflichten gelten bereits: Seit dem 11. September 2026 müssen Hersteller aktiv ausgenutzte Schwachstellen und schwerwiegende Vorfälle an ENISA und das nationale CSIRT melden, mit einer Frühwarnung innerhalb von 24 Stunden. Die vollständigen Anforderungen gelten ab dem 11. Dezember 2027.

Legt man Anhang I des CRA neben IEC 62443-4-1, ist die Überschneidung kaum zu übersehen: Sicherheit auf Basis einer Risikobewertung, sichere Standardkonfiguration, eine Software-Stückliste (SBOM), unverzügliche Behandlung von Schwachstellen, eine Policy zur koordinierten Offenlegung, Sicherheitsupdates getrennt von Funktionsupdates und Dokumentation für den Nutzer. Das sind dieselben Themen wie die acht Praktiken oben - der CRA legt fest, was gelten muss, 62443-4-1 beschreibt, wie man ein Team organisiert, damit es dauerhaft gilt.

Deshalb stützt sich die europäische Normungsarbeit zum CRA bei Industrieprodukten so stark auf IEC 62443. Wie die harmonisierten Normen am Ende auch heißen - ein Team, das bereits nach 62443-4-1 arbeitet, ordnet vorhandene Nachweise zu, statt bei null anzufangen. Die Kosten eines Fehlers sind auch nicht theoretisch: Verstöße gegen die grundlegenden Anforderungen des CRA können Bußgelder von bis zu 15 Mio. € oder 2,5 % des weltweiten Umsatzes nach sich ziehen - und, schmerzhafter, Produkte, die in der EU nicht mehr legal verkauft werden dürfen.

3. Die Maschinenverordnung bringt den Safety-Aspekt hinzu

Ab dem 20. Januar 2027 ersetzt die neue EU-Maschinenverordnung die Maschinenrichtlinie. Erstmals umfassen ihre grundlegenden Sicherheits- und Gesundheitsschutzanforderungen ausdrücklich den Schutz gegen Korrumpierung - einschließlich böswilliger Versuche von außen - und verlangen, dass sicherheitsrelevante Steuerungen beabsichtigter und unbeabsichtigter Manipulation standhalten, wobei Softwareänderungen aufgezeichnet und nachvollziehbar sein müssen.

Mit anderen Worten: Eine Cybersecurity-Schwäche in Maschinensoftware ist jetzt eine potenzielle Safety-Nichtkonformität und landet bei der CE-Kennzeichnung. Für einen Maschinenbauer wird „wir haben es vor der Auslieferung getestet“ keine überzeugende Antwort auf diese Anforderung sein. Ein dokumentierter, wiederholbarer Entwicklungsprozess schon.

4. NIS2 reicht es die Lieferkette hinunter

Selbst Hersteller, die keine Software verkaufen, sind betroffen. NIS2 Artikel 21 verpflichtet betroffene Einrichtungen, die Sicherheit der Lieferkette zu steuern und Sicherheit bei Erwerb, Entwicklung und Wartung ihrer Systeme sicherzustellen, einschließlich Schwachstellenbehandlung und -offenlegung. In der Praxis wird daraus eine Einkaufsfrage: Welche Nachweise hat Ihr Lieferant, dass die Software auf Ihrer Linie sicher entwickelt und gepflegt wird?

Wir sehen bereits, dass die Ausrichtung an IEC 62443-4-1 - oder ein darauf basierendes ISASecure-SDLA- bzw. IECEE-Zertifikat - in Anfragen und Lieferantenfragebögen auftaucht. Ein Lieferant, der mit einer Prozessbeschreibung, einer SBOM und einer Policy zur Schwachstellenbehandlung antworten kann, gewinnt dieses Gespräch. Einer, der nur einen Pentest-Bericht vom letzten Jahr vorweisen kann, meistens nicht.

5. Warum ein Pentest nicht mehr reicht

Ein einmaliges Security-Assessment ist wertvoll - oft erfährt man erst so, wo man tatsächlich steht. Aber es beschreibt eine Version der Software an einem Tag. Den oben genannten Regelwerken geht es um den Lebenszyklus: was mit dem nächsten Release passiert, dem nächsten Abhängigkeits-Upgrade, der nächsten CVE in einer Bibliothek, von der man nicht wusste, dass man sie mitliefert.

Genau das formalisiert IEC 62443-4-1. Bei unseren eigenen Security-Assessments von Industriesoftware sind die Befunde selbst nur die Hälfte des Ergebnisses. Die andere Hälfte ist, statische Analyse, Abhängigkeitsscans, native Codeanalyse und SBOM-Erzeugung in jeden Pull Request einzubauen, damit das nächste Release automatisch geprüft wird, statt auf das nächste Audit zu warten.

Wo man anfängt

Niemand erreicht Reifegrad 3 in einem Quartal, und niemand muss mit einem Zertifizierungsaudit beginnen. Der praktische Weg für einen Hersteller oder Maschinenbauer sieht so aus:

1. Erfassen Sie Ihre Produkte mit digitalen Elementen - einschließlich der „kleinen“ internen Tools, die mit einer SPS sprechen. Die sind meist am schlechtesten geschützt.
2. Führen Sie eine Gap-Analyse gegen die acht Praktiken durch, ehrlich bewertet nach Reifegraden. Die meisten Teams stellen fest, dass sichere Implementierung und Verifikation teilweise vorhanden sind, während Sicherheitsanforderungen, Problemmanagement und Nutzerdokumentation fehlen.
3. Automatisieren Sie zuerst, was sich automatisieren lässt - SAST, Abhängigkeitsscans und SBOM-Erzeugung in der CI sind günstig, schnell eingeführt und liefern direkt die Nachweise, die der CRA verlangt.
4. Richten Sie die Schwachstellenbehandlung jetzt ein, nicht 2027: einen Kontakt für Meldungen, einen Triage-Prozess und jemanden, der eine 24-Stunden-Meldung abgeben kann. Unter dem CRA gilt dieser Teil bereits.
5. Schreiben Sie auf, was Sie tun - Bedrohungsmodelle, Sicherheitsanforderungen, Review-Protokolle, Release Notes. In 62443-4-1 wird ein undokumentierter Prozess so behandelt wie ein fehlender.

Das Fenster zwischen „empfohlen“ und „verpflichtend“ ist kurz, und es schließt sich bereits. Teams, die jetzt mit dem Aufbau ihres sicheren Entwicklungsprozesses beginnen, erreichen die Fristen 2027 mit Nachweisen, die sie seit einem Jahr erzeugen. Alle anderen werden versuchen, sie unter Druck zu rekonstruieren - genau die Art von Arbeit, die wir Herstellern lieber ersparen.