CRA kompakt: Standards und Normen

4 MinutenLars Roith
Dieser Artikel gibt einen Überblick über Standards und Normen, die für den Cyber Resilience Act eine Rolle spielen.

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 RichtliniePraktischer NutzenRechtliche Grenze
IEC 62443-4-1 und IEC 62443-4-2Secure Development Lifecycle und technische Security-Anforderungen für industrielle HerstellerStarke Engineering-Grundlage, aber keine automatische CRA-Konformitätsvermutung
ISO/IEC 27001, 27002 und 27005Risikomanagement und organisatorische SicherheitErgänzen Produktnachweise, ersetzen sie aber nicht
ETSI EN 303 645Basisschutz für vernetzte Consumer-IoT-ProdukteAnwendbarkeit und Abdeckung müssen pro Produkt geprüft werden
ISO/IEC 29147 und ISO/IEC 30111Koordinierte Schwachstellenoffenlegung (Coordinated Vulnerability Disclosure, CVD) und Vulnerability HandlingUnterstützen Prozesse, decken die gesetzlichen Meldepflichten aus Artikel 14 nicht allein ab
BSI TR-03183-2, Version 2.1.0Technische 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.

  1. Normen-Mapping pro Produkt durchführen. Ordne bestehende Prozesse, Architektur- und Testnachweise den CRA-Anforderungen zu und dokumentiere offene Punkte.

  2. 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.

  3. 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.

  4. 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 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.