Harmonisierte Normen zum CRA: Stand 2026

Was harmonisierte Normen leisten — und was nicht

Der Cyber Resilience Act (EU-Verordnung 2024/2847) legt in Anhang I fest, welche Sicherheitsanforderungen ein Produkt mit digitalen Elementen erfüllen muss. Hersteller müssen nachweisen, dass ihr Produkt diesen Anforderungen entspricht — aber wie dieser Nachweis erbracht wird, lässt die Verordnung offen.

Hier kommen harmonisierte Normen ins Spiel. Wendet ein Hersteller eine Norm an, die im Amtsblatt der Europäischen Union als harmonisierte Norm für den CRA veröffentlicht wurde, gilt die sogenannte Konformitätsvermutung (Art. 27 CRA): Die durch diese Norm abgedeckten Anforderungen gelten als erfüllt. Hersteller müssen das nicht mehr separat für jeden Anhang-I-Punkt beweisen.¹

Das ist ein erheblicher Vorteil — weniger Dokumentationsaufwand, klarerer Prüfpfad, geringeres Risiko bei Marktaufsichtsprüfungen.

Was harmonisierte Normen jedoch nicht leisten:

Sie ersetzen keine interne Risikoanalyse
Sie dokumentieren keine Schwachstellen im eigenen Produkt
Sie ersetzen nicht die Konformitätsbewertung (Self-Assessment oder Notified Body)
Sie schreiben keine CE-Kennzeichnung — das bleibt Hersteller-Aufgabe

Die Norm ist ein Nachweisinstrument, kein Freifahrtschein.

Die wichtigsten Normen für den CRA

EN 18031-Reihe: die primären CRA-Normen

2025 veröffentlichte die Europäische Kommission die EN 18031-Reihe im Amtsblatt der EU — damit ist sie die erste offiziell harmonisierte Normenfamilie für den CRA.²

EN 18031-1 — Sicherheitsanforderungen für internetverbundene Produkte: Allgemeiner Teil

Dieser Teil adressiert die grundlegenden Sicherheitsanforderungen für netzwerkfähige Produkte: sicheres Booten, Update-Mechanismen, Zugangsschutz, Minimierung der Angriffsfläche, Protokollierung sicherheitsrelevanter Ereignisse. Er deckt den Kernbereich der Anhang-I-Teil-I-Anforderungen des CRA ab.

EN 18031-2 — Sicherheitsanforderungen für internetverbundene Produkte: Verarbeitung personenbezogener Daten

Dieser Teil adressiert Anforderungen an Produkte, die personenbezogene Daten verarbeiten — Datenschutz by Design, Datenminimierung, Zugriffsschutz auf personenbezogene Daten. Besonders relevant für Hersteller, die DSGVO und CRA gleichzeitig erfüllen müssen.

EN 18031-3 — Sicherheitsanforderungen für internetverbundene Produkte: Kritische Infrastruktur

Dieser Teil richtet sich an Produkte, die in kritischen Infrastrukturen eingesetzt werden — erhöhte Anforderungen an Redundanz, Ausfallsicherheit und Integritätsschutz.

Praktischer Hinweis zur EN 18031-Reihe: Die Normen adressieren primär internetverbundene Hardware-Produkte und Embedded-Systeme mit Netzwerkanbindung. Für reine Softwareprodukte ohne eigene Hardware-Komponente sind die anwendbaren Teile dieser Normen noch nicht vollständig geklärt — Details dazu weiter unten.

ETSI EN 303 645: IoT-Cybersecurity-Vorgänger

Die ETSI EN 303 645 ist ein älterer europäischer Standard für die Cybersicherheit von Konsumenten-IoT-Geräten. Entwickelt wurde er nicht für den CRA — er deckt aber einen erheblichen Teil der relevanten Anforderungen ab, insbesondere für Consumer-IoT-Produkte wie Smart-Home-Geräte und vernetzte Haushaltsgegenstände.

Das ist der Punkt, den viele übersehen: Stand Mai 2026 ist ETSI EN 303 645 für den CRA nicht als harmonisierte Norm im Amtsblatt veröffentlicht. Als technische Referenz ist sie nutzbar und zeigt die Erwartungshaltung bei IoT-Produkten — eine Konformitätsvermutung löst sie aber nicht aus. Für CRA-Zwecke löst die EN 18031-Reihe sie schrittweise ab.³

IEC 62443: Industrial Security

Die IEC 62443 ist eine international anerkannte Normenfamilie für die Sicherheit industrieller Steuerungssysteme und Automatisierungstechnik. Eingesetzt wird sie häufig im Kontext von Operational Technology (OT), SCADA-Systemen und industriellen Produkten.

Für den CRA ist IEC 62443 teilweise relevant:

IEC 62443-4-1 (Entwicklungsprozesse) und 62443-4-2 (Produktanforderungen) decken einen Teil der CRA-Anhang-I-Anforderungen ab
Sie sind jedoch ebenfalls nicht als harmonisierte CRA-Normen im Amtsblatt veröffentlicht
Für Hersteller industrieller Steuerungsprodukte (typischerweise Important Class I oder II) bieten sie eine nützliche technische Grundlage — ersetzen aber den CRA-spezifischen Nachweis nicht vollständig

In der Praxis erleben wir: Wer IEC 62443 bereits umsetzt, hat einen Vorsprung bei der CRA-Konformität — insbesondere bei Anforderungen an sichere Entwicklungsprozesse (SDL) und Produktsicherheitsanforderungen. Aber es bleibt eine Lücke. SBOM, CE-Kennzeichnung und Meldepflicht sind nicht Teil der IEC 62443.⁴

Ein Hersteller von industriellen MQTT-Gateways — klassisches Industrie-4.0-Produkt, Important Class I — kann mit IEC 62443-4-1 seinen Entwicklungsprozess solide dokumentieren. Für den vollständigen CRA-Nachweis reicht das trotzdem nicht.

ISO/IEC 27001: ISMS-Standard

ISO/IEC 27001 ist der weltweit verbreitetste Standard für Informationssicherheits-Managementsysteme (ISMS). Er beschreibt, wie ein Unternehmen seine internen Sicherheitsprozesse organisiert und verbessert.

Für den CRA ist ISO/IEC 27001 relevant, aber unzureichend:

CRA-Anforderung	ISO/IEC 27001	Abdeckung
Sicherheitsprozesse im Unternehmen	Ja	Hoch
Schwachstellen-Management	Teilweise (Annex A.12.6)	Mittel
SBOM-Pflicht (Anhang I)	Nein	Keine
CE-Kennzeichnung	Nein	Keine
Meldepflicht nach Art. 14	Nein	Keine
Produktspezifische Sicherheitsanforderungen	Nein	Keine

ISO/IEC 27001 adressiert die organisatorische Sicherheit. Der CRA stellt zusätzlich produktspezifische Anforderungen. Ein zertifiziertes ISMS ist ein guter Ausgangspunkt — kein Endpunkt.⁵

Was viele CRA-Berater nicht sagen: Hersteller, die ISO/IEC 27001 als alleinigen CRA-Nachweis planen, werden bei der Marktaufsichtsprüfung scheitern. Die Norm ist kein Substitut. Konkret bedeutet das: Prüft die Marktaufsichtsbehörde ein IoT-Startup mit ISMS-Zertifikat, aber ohne SBOM und produktspezifische Sicherheitsdokumentation, gibt es nichts zu diskutieren.

Die kritische Lücke: reine Software

Das klingt nach einem Randproblem. Ist es nicht.

Stand Mai 2026 gibt es keine vollständig harmonisierte CRA-Norm für Softwareprodukte ohne eigene Hardware-Komponente. Betroffen sind unter anderem:

Desktop-Anwendungen (Windows, macOS, Linux)
Server-Software (Web-Server, Datenbanken, Middleware)
Mobile Apps, die eigenständig als Produkt vertrieben werden (nicht als Dienstleistung)
Embedded-Softwarekomponenten, die in Drittgeräte integriert werden
Entwickler-Tools mit Netzwerkfunktionen

Nehmen wir ein konkretes Beispiel: Ein Maschinenbau-Zulieferer entwickelt embedded Software für Heizungssteuerungen — kein eigenes Gehäuse, kein eigener Chip, aber ein eigenständiges Softwareprodukt mit Netzwerkfunktion. Für genau diesen Fall fehlt heute eine harmonisierte Norm. Die Konformitätsvermutung über harmonisierte Normen können diese Hersteller aktuell nicht vollständig nutzen. Was das konkret bedeutet:

Mehr Dokumentationsaufwand: Jede CRA-Anforderung muss einzeln nachgewiesen werden, ohne den Abkürzungsweg über die Norm.
Unsicherheit bei der Konformitätsbewertung: Ohne Norm fehlt ein klarer Prüfkatalog — Notified Bodies und Hersteller müssen den Bewertungsrahmen eigenständig definieren.
Warten auf Normen ist riskant: Wer jetzt wartet, bis die fehlenden Normen kommen, bevor er mit der Dokumentation beginnt, riskiert den Dezember-2027-Stichtag zu verpassen.

Die Europäische Kommission hat entsprechende Aufträge an die Normungsorganisationen CEN/CENELEC und ETSI erteilt. Weitere harmonisierte Normen für Softwareprodukte werden erwartet — der Zeitplan ist jedoch nicht verbindlich, und eine Veröffentlichung im Amtsblatt bis Ende 2026 ist ungewiss.

Die Lücke bei harmonisierten Normen für reine Software ist ein erhebliches Problem — und ein Argument, jetzt mit der Dokumentation zu beginnen statt auf Normen zu warten.

Was Hersteller ohne passende Norm tun können

Wer heute keine vollständig anwendbare harmonisierte Norm hat, muss auf alternative Konformitätsnachweise zurückgreifen. Der CRA erlaubt das ausdrücklich — harmonisierte Normen sind nur eine Erleichterung, keine Pflicht.

Praktische Alternativen:

Mapping gegen CRA Anhang I: Dokumentieren Sie systematisch, wie jede Anforderung aus Anhang I Teil I und Teil II in Ihrem Produkt umgesetzt ist. Das ist mehr Arbeit als eine Norm-Checkliste, aber es funktioniert.
Kombination mehrerer Normen: ISO/IEC 27001 für Prozesse + IEC 62443-4-1 für SDL + eigene Dokumentation für produktspezifische Anforderungen. Keine dieser Normen liefert die Konformitätsvermutung, aber gemeinsam decken sie viele Anforderungen dokumentiert ab.
Technical Guidance der ENISA: Die ENISA hat Leitlinien zur Umsetzung der CRA-Anforderungen für verschiedene Produktkategorien veröffentlicht. Diese ersetzen keine Norm, sind aber eine anerkannte Interpretationshilfe.
Früher Kontakt zum Notified Body: Für Produkte der höheren Klassen empfiehlt sich ein frühes Gespräch mit dem zuständigen NB — um zu klären, welchen Prüfrahmen er bei fehlenden harmonisierten Normen anlegt. Das schafft Planungssicherheit.

Was viele unterschätzen: Auch das Self-Assessment für Default-Produkte muss dokumentiert und schlüssig sein. Für einen Hersteller von embedded Software für Heizungssteuerungen reicht das Self-Assessment zwar aus — aber “reicht aus” bedeutet nicht “formlos”. Mehr dazu unter CRA Self-Assessment: Wer es braucht und wie es geht.

Eine vollständige Übersicht der Produktanforderungen aus CRA Anhang I finden Sie unter CRA Anhang I: Sicherheitsanforderungen im Detail.

Quellen

EU-Verordnung 2024/2847 des Europäischen Parlaments und des Rates vom 23. Oktober 2024 (Cyber Resilience Act), Artikel 27: https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=OJ:L_202402847
Europäische Kommission — Harmonisierte Normen für den Cyber Resilience Act (EN 18031): https://digital-strategy.ec.europa.eu/de/policies/cyber-resilience-act
ETSI — EN 303 645 v2.1.1, Cyber Security for Consumer Internet of Things: https://www.etsi.org/deliver/etsi_en/303600_303699/303645/02.01.01_60/en_303645v020101p.pdf
IEC — IEC 62443 Series, Security for Industrial Automation and Control Systems: https://www.iec.ch/iec62443
ISO — ISO/IEC 27001:2022, Information security management systems: https://www.iso.org/standard/27001