CRA kompakt: Standards und Normen
Dieser Artikel wurde erstmals am 28.05.2025 veröffentlicht und am 03.09.2026 auf Basis des zu diesem Zeitpunkt bekannten Rechts- und Informationsstands aktualisiert.
Dieser Beitrag ordnet ein, welche Standards und Normen für den Cyber Resilience Act (CRA) relevant sind, welchen Reifegrad sie haben und wo ihre rechtlichen Grenzen liegen. Ihr Stand ist inzwischen deutlich konkreter als noch 2025. Eine verfügbare technische Norm, ein Entwurf einer Europäischen Norm (prEN) oder eine veröffentlichte Europäische Norm (EN) erzeugt dennoch nicht automatisch eine rechtliche Konformitätsvermutung. Entscheidend ist, ob ein Produkt einer für die jeweils abgedeckten grundlegenden Anforderungen im Amtsblatt der Europäischen Union zitierten harmonisierten Norm oder ihrem einschlägigen Teil entspricht.
Normungsstand im September 2026
Der Normungsauftrag M/606 umfasst 41 horizontale und vertikale beziehungsweise produktspezifische Standards zur Unterstützung des CRA.
Horizontale Normen behandeln produktübergreifende Themen wie Risikomanagement, Secure Development und Vulnerability Handling. Vertikale Normen konkretisieren Anforderungen für bestimmte Produktkategorien, insbesondere aus Anhang III und IV des CRA. Zusätzlich entwickeln die europäischen Normungsorganisationen unterstützende Dokumente zu gemeinsamen Begriffen, Methoden für sektorale Risikobewertungen und einem gemeinsamen Bedrohungskatalog.
Die DKE (Deutsche Kommission Elektrotechnik Elektronik Informationstechnik) veröffentlicht den laufenden Projektstatus und führt unter anderem die Projekte der Reihe EN 40000-1-x zu Vocabulary, Product Risk Management und Lifecycle, Vulnerability Handling sowie Generic Security Requirements. Der Status einzelner Projekte reicht von der Ausarbeitung über die formale Abstimmung und die Prüfung durch einen Harmonised Standards Consultant (HAS) bis zur späteren Zitierung als harmonisierte Norm.
Eine harmonisierte europäische Norm, kurz hEN, kann eine Konformitätsvermutung auslösen. Ein Arbeitsstand, ein prEN als Entwurf einer Europäischen Norm oder eine veröffentlichte EN als Europäische Norm kann bereits eine wertvolle technische Grundlage sein. Die Konformitätsvermutung nach Artikel 27 CRA gilt nur für ein Produkt, das einer im Amtsblatt zitierten harmonisierten Norm oder ihrem einschlägigen Teil entspricht, und nur für die grundlegenden Anforderungen aus Anhang I, die diese Norm tatsächlich abdeckt.
Bestehende Standards richtig einordnen
Der Report des Joint Research Centre (JRC) und der Agentur der Europäischen Union für Cybersicherheit (ENISA) zum Mapping bestehender Standards bleibt eine gute Grundlage, um vorhandene Prozesse auf CRA-Anforderungen abzubilden. Er ersetzt weder eine anforderungsspezifische Konformitätsbewertung noch den Blick auf den aktuellen Normungsstand.
| Standard oder Richtlinie | Praktischer Nutzen | Rechtliche Grenze |
|---|---|---|
| IEC 62443-4-1 und IEC 62443-4-2 | Secure Development Lifecycle und technische Security-Anforderungen für industrielle Hersteller | Starke Engineering-Grundlage, aber keine automatische CRA-Konformitätsvermutung |
| ISO/IEC 27001, 27002 und 27005 | Risikomanagement und organisatorische Sicherheit | Ergänzen Produktnachweise, ersetzen sie aber nicht |
| ETSI EN 303 645 | Basisschutz für vernetzte Consumer-IoT-Produkte | Anwendbarkeit und Abdeckung müssen pro Produkt geprüft werden |
| ISO/IEC 29147 und ISO/IEC 30111 | Koordinierte Schwachstellenoffenlegung (Coordinated Vulnerability Disclosure, CVD) und Vulnerability Handling | Unterstützen Prozesse, decken die gesetzlichen Meldepflichten aus Artikel 14 nicht allein ab |
| BSI TR-03183-2, Version 2.1.0 | Technische Orientierung für Software Bill of Materials (SBOM) | Nicht verbindlich und keine harmonisierte Norm |
Für die Meldungen nach Artikel 14 gelten eigene Auslöser, Fristen, Inhalte und Empfänger. Hersteller übermitteln sie über die CRA Single Reporting Platform der Agentur der Europäischen Union für Cybersicherheit (ENISA) an das Computer Security Incident Response Team (CSIRT) ihres Mitgliedstaats und gleichzeitig an ENISA.
Für SBOMs ist die BSI TR-03183-2 in Version 2.1.0 die aktuelle BSI-Referenz. Sie ergänzt unter anderem eine Zuordnungsempfehlung zwischen den Datenfeldern der Richtlinie und den SBOM-Formaten SPDX sowie CycloneDX, schafft aber ebenso keine Konformitätsvermutung.
Jetzt belastbar vorbereiten
Auch ohne zitierte harmonisierte Normen kannst du heute bereits konkrete Nachweise aufbauen. Die folgenden Maßnahmen können späteren Umstellungsaufwand reduzieren, wenn sie pro Produkt priorisiert, umgesetzt und dokumentiert werden.
-
Normen-Mapping pro Produkt durchführen. Ordne bestehende Prozesse, Architektur- und Testnachweise den CRA-Anforderungen zu und dokumentiere offene Punkte.
-
IEC 62443 als Engineering-Grundlage nutzen. Gerade für Maschinen- und Gerätehersteller liefert die Normenreihe eine starke Basis für Secure Development Lifecycle und Security Engineering.
-
Vulnerability Handling und CVD aufbauen. Etabliere Zuständigkeiten für Meldungen, Bewertung, Behebung und Kommunikation und ergänze sie um den separaten Prozess für Artikel-14-Meldungen.
-
Normungsstand regelmäßig prüfen. Verfolge DKE, STAN4CR und die Normungsseite der Kommission, damit du neue Entwürfe, Veröffentlichungen und Zitierungen zeitnah bewerten kannst.
Was daraus folgt
Normen machen CRA-Anforderungen technisch greifbarer, aber sie ersetzen keine sorgfältige Konformitätsbewertung. Wer IEC 62443, ISO/IEC 29147 und ISO/IEC 30111 oder die BSI TR-03183 gezielt und produktbezogen einsetzt, kann belastbare Prozesse und Nachweise aufbauen, sofern die Umsetzung dokumentiert und ihre Wirksamkeit überprüft wird. Die rechtliche Konformitätsvermutung gilt erst für ein Produkt, das einer passend abdeckenden, im Amtsblatt zitierten harmonisierten Norm oder ihrem einschlägigen Teil entspricht.
Wie ordnest du bestehende Normen und neue CRA-Entwürfe in deinem Unternehmen ein? Schau gerne bei uns auf LinkedIn vorbei und diskutiere mit.
Autoren

Lars Roith
Lars ist Solution Consultant und berät Unternehmen und Entwicklungsteams ganzheitlich bei der Umsetzung ihrer Softwareentwicklungsprojekte, von den Prozessen über die Anforderungen und Architekturen bis hin zu Umsetzung und Betrieb.






