CRA und IEC 62443-4-1
IEC 62443-4-1 und Cyber Resilience Act: vom Secure Development Lifecycle zum CRA-Nachweis
Sie entwickeln bereits nach IEC 62443-4-1 oder planen einen Secure Development Lifecycle? Wir ordnen Anhang I des Cyber Resilience Act den Praktiken Ihres Prozesses zu und bewerten nur, was für den CRA noch fehlt. Ohne 62443-Prozess bauen wir mit Ihnen die Bausteine auf, die der CRA verlangt.
Was IEC 62443-4-1 abdeckt und was der CRA zusätzlich verlangt
IEC 62443-4-1 stellt Anforderungen an den Entwicklungsprozess für Produkte der industriellen Automatisierung: Sicherheitsanforderungen, Design, Implementierung, Test, Umgang mit Schwachstellen und Updates, Sicherheitshinweise für Anwender. Die Norm ordnet das acht Praktiken zu, von Security Management (SM) bis Security Guidelines (SG).
Der Cyber Resilience Act setzt am einzelnen Produkt an: Der Hersteller bewertet dessen Cybersicherheitsrisiken, berücksichtigt das Ergebnis von der Planung bis zur Wartung und nimmt die Bewertung in die technische Dokumentation auf (Art. 13 Abs. 2 bis 4). Ein zertifizierter 62443-4-1-Prozess belegt eine Methode und verlangt mit SR-2 ein Bedrohungsmodell je Produkt. Die Bewertung in der Form, die Art. 13 Abs. 3 und 4 und Anhang VII Nr. 3 verlangen, entsteht daraus nicht von selbst: je Anforderung aus Anhang I Teil I Nr. 2, ob sie anwendbar ist, wie sie umgesetzt wird, und bei Nichtanwendbarkeit die Begründung. Dazu kommen Pflichten, die eine Norm von 2018 nicht kennen kann, etwa die Meldungen nach Art. 14 über die einheitliche Meldeplattform, die seit dem 11. September 2026 gelten.
Leistungsbausteine
Sie beauftragen, was fehlt. Vorhandene Prozesse, Vorlagen und Werkzeuge nutzen wir weiter.
Delta-Bewertung gegen Ihren 62443-4-1-Prozess
Wir ordnen Anhang I Teil I und Teil II den Praktiken Ihres bestehenden Prozesses zu und bewerten nur, was der Prozess für den CRA noch nicht hervorbringt. Was funktioniert, bauen wir nicht neu.
Mehr zur Gap-AnalyseRisikobewertung je Produkt
Aus Quellcode, Deployment-Konfiguration und Dokumentation leiten wir Architektur, Datenflüsse und Vertrauensgrenzen ab und halten das Bedrohungsmodell als Code in Ihrem Repository. Daraus erarbeiten wir mit Ihren Entwicklern die Risikobewertung für die technische Dokumentation; das Modell lässt sich bei einem geänderten Release erneut ausführen.
Zum Threat ModelingCRA-Bausteine ohne 62443-Prozess
Ohne 62443-Prozess beginnen wir mit den Bausteinen, die der CRA je Produkt verlangt: die Risikobewertung je Produkt, eine SBOM-Kette aus der Build-Pipeline, ein Ablauf für die Behandlung von Schwachstellen und der Meldeprozess nach Art. 14.
Fachartikel Security by DesignWas Sie in der Hand haben
Ergebnisse, die in die technische Dokumentation eingehen und Ihr Team weiterführt.
01
Zuordnung Anhang I zu IEC 62443-4-1
Je Anforderung: welche Praktik sie abdeckt, welcher Nachweis vorliegt, was fehlt.
02
Lückenbericht je Produkt
Bewertete Befunde und ein priorisierter Maßnahmenplan.
03
Risikobewertung je Produkt
Für Anhang VII Nr. 3, mit einem Modell, das sich bei einem geänderten Release erneut ausführen lässt.
04
Beschreibung der angewandten Spezifikationen
Textbausteine für Anhang VII Nr. 5, solange keine harmonisierte Norm angewandt wird.
Beispielauszug: Anhang I und die Praktiken von IEC 62443-4-1
So sieht die Zuordnung in der Delta-Bewertung aus. Sie ist unsere eigene, vereinfachte Lesart: Weder der CRA noch IEC 62443-4-1 enthalten eine amtliche Zuordnung. Im Auftrag entsteht sie je Produkt aus Ihrem Prozess.
| CRA-Anforderung | Praktik in IEC 62443-4-1 | Was wir für den CRA prüfen |
|---|---|---|
| Risikobewertung je Produkt (Art. 13 Abs. 3 und 4, Anhang VII Nr. 3) | SR (u. a. SR-2 Bedrohungsmodell) | Dokument je Produkt, mit Begründung nicht anwendbarer Anforderungen. |
| Sicherheitsupdates, sichere Verbreitung (Anhang I Teil I Nr. 2 Buchst. c, Teil II Nr. 2, 7, 8) | SUM | Getrennte Sicherheitsupdates, soweit machbar; gegebenenfalls automatisch mit Opt-out. |
| Software-Stückliste (Anhang I Teil II Nr. 1) | SM (Komponenten Dritter) | SBOM je Release, maschinenlesbar, mindestens oberste Abhängigkeiten. |
| Schwachstellen behandeln und offenlegen (Anhang I Teil II Nr. 2, 4 bis 6) | DM | CVD-Strategie, Kontaktadresse, Veröffentlichung behobener Schwachstellen. |
| Nutzerinformationen (Anhang II) | SG | Kontaktstelle für Schwachstellen, Enddatum des Unterstützungszeitraums. |
Eigene Zuordnung von Blackfort Technology. Anforderungen nach VO (EU) 2024/2847; Praktiken und Kürzel nach dem Inhaltsverzeichnis von IEC 62443-4-1:2018.
Vorgehen
Vom vorhandenen Prozess zum Nachweis je Produkt.
1
Kostenloses Erstgespräch
Produkte, Entwicklungsprozess, vorhandene Zertifikate und Vorgaben Ihrer Abnehmer. Danach ein Angebot mit klar abgegrenztem Umfang.
2
Delta-Bewertung
Zuordnung Anhang I zu den Praktiken Ihres Prozesses, Prüfung der Nachweise, Lückenbericht je Produkt.
3
Lücken schließen
Risikobewertung je Produkt, SBOM-Kette, Meldeprozess, je nach Befund.
4
Dokumentation
Unterlagen für die technische Dokumentation und die Nutzerinformationen nach Anhang II.
Ist IEC 62443 eine harmonisierte Norm zum CRA?
Aus einer Norm entsteht eine Konformitätsvermutung nur, wenn es eine harmonisierte Norm ist, deren Fundstelle im Amtsblatt der EU veröffentlicht ist, und nur für die Anforderungen, die sie abdeckt (Art. 27 Abs. 1). Daneben können gemeinsame Spezifikationen und europäische Cybersicherheitszertifizierungen eine Vermutung begründen (Art. 27 Abs. 5 und 8). Die Kommission hat CEN, CENELEC und ETSI am 3. Februar 2025 mit dem Normungsauftrag M/606 (Durchführungsbeschluss C(2025) 618) beauftragt, europäische Normen zum CRA auszuarbeiten. Bei unserer Prüfung am 9. Oktober 2026 war im Amtsblatt noch keine solche Fundstelle zum CRA veröffentlicht. IEC 62443-4-1 begründet heute also keine Konformitätsvermutung nach dem CRA.
Nutzlos ist die Norm deshalb nicht: Ohne harmonisierte Normen beschreibt die technische Dokumentation die gewählten Lösungen und listet die sonstigen angewandten technischen Spezifikationen auf (Anhang VII Nr. 5). Dort gehört ein gelebter 62443-4-1-Prozess hin. Bei wichtigen Produkten der Klasse I ist dann allerdings eine notifizierte Stelle einzubeziehen, sofern nicht gemeinsame Spezifikationen oder ein europäisches Schema für die Cybersicherheitszertifizierung mindestens der Vertrauenswürdigkeitsstufe „mittel“ vollständig angewandt werden (Art. 32 Abs. 2).
Abgrenzung
Damit die Erwartungen stimmen:
- Wir sind keine Zertifizierungsstelle und keine notifizierte Stelle. Zertifikate nach IEC 62443 und Bescheinigungen im Konformitätsbewertungsverfahren stellen wir nicht aus.
- Penetrationstests gehören nicht zu unserem Angebot, auch nicht für die Praktik SVV.
- Keine Rechtsdienstleistung: Wir schätzen Rolle und Produktklasse technisch ein und markieren rechtlich zu entscheidende Fragen zur Prüfung durch Ihre Rechtsabteilung oder Kanzlei.
Die Pflichten aus dem CRA bleiben bei Ihrem Unternehmen. Wir unterstützen Sie dabei, sie zu erfüllen und nachzuweisen.
Häufige Fragen
Reicht eine Zertifizierung nach IEC 62443-4-1 für den Cyber Resilience Act?+
Nein. Sie belegt einen Entwicklungsprozess mit Methode. Der CRA verlangt zusätzlich je Produkt Risikobewertung, technische Dokumentation, Nutzerinformationen und Konformitätsbewertung sowie die Meldewege nach Art. 14. Die Delta-Bewertung zeigt, was Ihr Prozess davon schon liefert. Zertifikate nach IEC 62443-4-1 stellen akkreditierte Zertifizierungsstellen aus; Blackfort Technology zertifiziert nicht.
Ist IEC 62443-4-1 eine harmonisierte Norm unter dem CRA?+
Bei unserer Prüfung am 9. Oktober 2026 war im Amtsblatt keine Fundstelle einer harmonisierten Norm zum CRA veröffentlicht. Eine Konformitätsvermutung aus einer harmonisierten Norm (Art. 27 Abs. 1) entsteht erst mit dieser Veröffentlichung.
Welche Praktiken umfasst IEC 62443-4-1?+
Acht: Security Management (SM), Specification of Security Requirements (SR), Secure by Design (SD), Secure Implementation (SI), Security Verification and Validation Testing (SVV), Management of Security-related Issues (DM), Security Update Management (SUM) und Security Guidelines (SG).
Wir haben keinen Secure Development Lifecycle. Wo fangen wir an?+
Mit der Risikobewertung je Produkt, denn nach Art. 13 bestimmt sie, wie Sie Anhang I umsetzen. Danach folgen SBOM-Kette, Schwachstellenbehandlung und Meldeprozess.
Zum Weiterlesen
- Security by Design im CRA umsetzen
- Risikobewertung und Threat Modeling
- Technische Dokumentation und Konformität
- SBOM-Beratung
- Meldeprozess und PSIRT aufbauen
- CRA-Workshop für Ihr Team
Diese Inhalte dienen der allgemeinen technischen und organisatorischen Information zum Cyber Resilience Act (Verordnung (EU) 2024/2847) und stellen keine Rechtsberatung dar (keine Rechtsdienstleistung i.S.d. RDG).
Stand: 2026-10-09
Kontakt aufnehmen
Delta-Bewertung anfragen
Nennen Sie uns Ihre Produkte und den Stand Ihres Entwicklungsprozesses. Das Erstgespräch ist kostenlos und unverbindlich; wir melden uns in der Regel innerhalb von ein bis zwei Werktagen.