Cyber Resilience Act Schritt für Schritt: Bereitschaft für Hersteller

Ein praktischer CRA-Bereitschaftspfad für Hersteller: Bestätigen Sie Geltungsbereich und Klassifizierung, schließen Sie Lücken in Anhang I, führen Sie Schwachstellenbehandlung und Meldung durch, und planen Sie Konformitätsbewertung und CE-Kennzeichnung vor Dezember 2027.

Dieser Leitfaden richtet sich an Hersteller von vernetzter Hardware und Software sowie an die Teams für Produktsicherheit, Engineering und Compliance, die den Cyber Resilience Act (CRA) umsetzen müssen. Die Rollen von Importeuren, Distributoren und Open-Source-Verwaltern werden ebenfalls behandelt. Am Ende verfügen Sie über einen bestätigten Geltungsbereich und eine Rolle pro Produkt, eine Klassifizierungsentscheidung, eine Anhang-I-Lückenanalyse, einen funktionierenden Prozess für Schwachstellenbehandlung und -meldung sowie einen Plan für Dokumentation, Konformitätsbewertung und CE-Kennzeichnung.

Bevor Sie beginnen

Der CRA ist eine Produktgesetzgebung in der CE-Kennzeichnungstradition, keine Organisationsnorm wie ISO/IEC 27001. Die Konformität wird pro Produkt bewertet. Sie benötigen eine Produktliste, die reine Softwareprodukte, Firmware, Begleit-Apps und Cloud-Back-Ends umfasst; einen benannten Produktsicherheitsverantwortlichen (in der Regel ein PSIRT-Leiter) mit Einfluss auf Freigabeentscheidungen; und Zugriff auf Architekturdiagramme, Build-Pipelines und Abhängigkeitsmanifeste. Der Rechtstext ist auf EUR-Lex^[1] verfügbar, und die Kommission veröffentlicht Leitlinien und häufig gestellte Fragen auf ihrer Implementierungsseite^[3]. Eine Übersicht finden Sie auf unserer Cyber Resilience Act-Seite.

Schritt 1: Bestätigen Sie den Geltungsbereich und Ihre Rolle pro Produkt

Der Cyber Resilience Act gilt für Produkte mit digitalen Elementen, deren beabsichtigte oder vernünftigerweise vorhersehbare Verwendung eine Datenverbindung zu einem Gerät oder Netzwerk umfasst, einschließlich der Fernverarbeitung von Daten, die ein Produkt zur Erfüllung seiner Funktionen benötigt. Produkte, die unter spezifische Branchenregeln fallen, wie Medizinprodukte, Kraftfahrzeuge und Zivilluftfahrt, sind ausgenommen. Eigenständige SaaS fällt in der Regel unter NIS2 statt unter den Cyber Resilience Act.

• Dokumentieren Sie pro Produkt, ob es in den Geltungsbereich fällt, und welche Ausnahme Sie ggf. in Anspruch nehmen.
• Bestimmen Sie Ihre Rolle. Ein Hersteller entwickelt das Produkt oder lässt es entwickeln und vermarktet es unter seinem eigenen Namen. Ein Importeur bringt das Produkt eines Herstellers außerhalb der EU auf den EU-Markt. Ein Distributor macht es weiter unten in der Lieferkette verfügbar. Ein Open-Source-Software-Verwalter ist eine juristische Person, die systematisch freie und quelloffene Software unterstützt, die für kommerzielle Tätigkeiten bestimmt ist.
• Achten Sie auf Rollenwechsel: Ein Importeur oder Distributor, der ein Produkt umbenennt oder wesentlich verändert, übernimmt Herstellerpflichten.
• Erfassen Sie Produkte, die bereits auf dem Markt sind. Sie unterliegen den vollständigen Anforderungen nur, wenn sie nach dem 11. Dezember 2027 wesentlich verändert werden, aber die Meldepflicht nach Artikel 14 gilt für sie.

Schritt 2: Klassifizieren Sie jedes Produkt

Die meisten Produkte fallen in die Standardkategorie. Anhang III listet wichtige Produkte auf. Klasse I umfasst Betriebssysteme, Browser, Passwort-Manager, VPNs, Router, SIEM-Systeme und Smart-Home-Sicherheitsprodukte wie Türschlösser und Kameras. Klasse II umfasst Hypervisoren und Container-Runtimes, Firewalls und Systeme zur Eindringlingserkennung oder -abwehr sowie manipulationssichere Mikroprozessoren und Mikrocontroller. Anhang IV listet kritische Produkte auf: Hardware-Geräte mit Sicherheitsmodulen, Smart-Meter-Gateways sowie Smartcards und sichere Elemente.

Die Durchführungsverordnung (EU) 2025/2392 vom 28. November 2025 enthält die technische Beschreibung jeder Kategorie und ist am 21. Dezember 2025 in Kraft getreten^[2]. Maßgeblich ist die Kernfunktionalität des Produkts. Ein Produkt, das lediglich eine aufgelistete Komponente integriert, wird deshalb allein nicht zum wichtigen Produkt.

• Vergleichen Sie die Kernfunktionalität jedes Produkts mit den Beschreibungen in der Durchführungsverordnung, nicht nur mit den Kurzbeschreibungen in den Anhängen.
• Verfassen Sie pro Produkt eine kurze Begründung, besonders bei Grenzfällen.

Schritt 3: Bewerten Sie das Risiko und ordnen Sie die Lücken Anhang I zu

Artikel 13 verlangt eine Cybersicherheits-Risikobewertung, die Planung, Entwurf, Entwicklung, Herstellung, Lieferung und Wartung informiert und bestimmt, wie jede Anforderung aus Anhang I anwendbar ist. Anhang I Teil I fordert zusammengefasst Produkte ohne bekannte ausnutzbare Schwachstellen, mit sicherer Standardkonfiguration, mit Sicherheitsupdates (wo angemessen standardmäßig automatisch), Zugriffskontrolle, Vertraulichkeit und Integritätsschutz, Datensparsamkeit, Verfügbarkeit, eine begrenzte Angriffsfläche, Verringerung der Auswirkungen von Vorfällen, Sicherheitsprotokollierung und sichere Datenlöschung.

• Erstellen Sie ein Bedrohungsmodell für jedes Produkt oder jede Produktfamilie über Hardware, Firmware, Software und Backend.
• Dokumentieren Sie für jede Anforderung aus Anhang I die Anwendbarkeit, wie sie erfüllt wird, Nachweise und verbleibende Lücken. Begründen Sie alles, was als nicht anwendbar gekennzeichnet ist.

Die begleitende Vorlage enthält eine Checkliste für Anhang I mit allen Anforderungen aus Teil I und Teil II, ein Klassifizierungsarbeitsblatt und einen Zeitplan.

Schritt 4: Schwachstellenbehandlung einrichten, einschließlich einer SBOM

Anlage I Teil II gilt für den gesamten Supportzeitraum. Hersteller müssen Komponenten dokumentieren, einschließlich einer Software-Stückliste (SBOM) in einem gängigen maschinenlesbaren Format, das mindestens Abhängigkeiten auf oberster Ebene abdeckt; Schwachstellen ohne Verzögerung beheben; regelmäßig testen; behobene Schwachstellen offenlegen; eine Richtlinie zur koordinierten Offenlegung von Schwachstellen (CVD) und einen Meldekontakt pflegen; Updates sicher verteilen; und Sicherheitsupdates kostenlos mit Sicherheitshinweisen bereitstellen.

• Generieren Sie SBOMs pro Build (SPDX oder CycloneDX) und speichern Sie sie pro Release. Sie müssen sie nicht veröffentlichen.
• Legen Sie den Supportzeitraum fest: mindestens fünf Jahre, es sei denn, das Produkt wird voraussichtlich kürzer verwendet, und sichtbar für Käufer.
• Veröffentlichen Sie eine CVD-Richtlinie und einen Sicherheitskontakt, beispielsweise über security.txt, und führen Sie eine PSIRT-Aufnahme mit Triage-Zielen durch.
• Melden Sie Schwachstellen, die Sie in integrierten Komponenten, einschließlich Open-Source-Code, finden, deren Verwaltern.

Schritt 5: Meldung jetzt funktionsfähig machen

Seit dem 11. September 2026 müssen Hersteller jede aktiv ausgenutzte Schwachstelle und jeden schwerwiegenden Vorfall, der die Produktsicherheit betrifft, über die Single Reporting Platform von ENISA^[4] melden. Der Bericht erreicht das koordinierende CSIRT des Mitgliedstaats der Hauptniederlassung und ENISA gleichzeitig.

Phase	Aktiv ausgenutzte Schwachstelle	Schwerwiegender Vorfall
Frühwarnung	24 Stunden nach Bekanntwerden	24 Stunden nach Bekanntwerden
Benachrichtigung	72 Stunden nach Bekanntwerden	72 Stunden nach Bekanntwerden
Abschlussbericht	14 Tage nach Verfügbarkeit einer Korrekturmaßnahme	Ein Monat nach der Meldung

• Definieren Sie, wer entscheidet, dass eine Schwachstelle aktiv ausgenutzt wird, und wann die Frist beginnt.
• Registrieren Sie sich auf der Plattform und üben Sie eine Einreichung.
• Bereiten Sie Berichtsvorlagen und einen Prozess vor, um betroffene Nutzer zu informieren. Unser Handlungsleitfaden zur Vorfallmeldung stimmt die CRA-Meldung mit NIS2, DORA und DSGVO ab.

Schritt 6: Konformitätsbewertungsweg wählen

Nach Artikel 32 können Standardprodukte die interne Kontrolle (Modul A) nutzen. Wichtige Produkte der Klasse I dürfen Modul A nur verwenden, wenn harmonisierte Normen, gemeinsame Spezifikationen oder ein Zertifizierungsschema auf der Stufe „erheblich" vollständig angewendet wurden; andernfalls benötigen sie die Module B und C oder Modul H mit einer benannten Stelle. Produkte der Klasse II benötigen stets eine dritte Partei. Kritische Produkte müssen ein europäisches Cybersicherheits-Zertifizierungsschema verwenden, wenn ein delegierter Rechtsakt dies verlangt, andernfalls gelten die Wege der Klasse II. Wichtige freie und quelloffene Produkte dürfen Modul A verwenden, wenn ihre technische Dokumentation öffentlich ist.

• Harmonisierte Normen verfolgen. Zum Zeitpunkt der Erstellung plant die Kommission die ersten Ergebnisse für 2026 und weitere für 2027.^[3].
• Wenn Sie eine benannte Stelle benötigen, buchen Sie frühzeitig. Deren Regeln gelten ab dem 11. Juni 2026, und die Kapazitäten werden gegen Dezember 2027 knapp.

Schritt 7: Technische Dokumentation zusammenstellen

Artikel 31 und Anhang VII erfordern eine Dokumentation, die das Produkt und seinen Verwendungszweck, die Konstruktion und Herstellung, das Verfahren zur Behandlung von Schwachstellen, die SBOM, die Risikobewertung, die Begründung des Unterstützungszeitraums, angewendete Normen, Testberichte und die Konformitätserklärung abdeckt. Diese ist zehn Jahre nach dem Inverkehrbringen aufzubewahren, oder für den Unterstützungszeitraum, falls dieser länger ist. Anhang II legt die Benutzerinformationen fest, einschließlich der Kontaktstelle für Schwachstellen und des Endes des Unterstützungszeitraums.

In Secrato wird dieser Schritt dem Modul Richtlinien und Nachweise zugeordnet, wobei jedes Kontrollergebnis aus Anhang I und der zugehörige Nachweis mit dem Dokumentationssatz des Produkts verknüpft sind.

Schritt 8: Konformität erklären, CE-Kennzeichnung anbringen und Wartung durchführen

Nach der Bewertung stellen Sie die EU-Konformitätserklärung auf (Artikel 28, Anlage V) und bringen die CE-Kennzeichnung an (Artikel 30). Bei Software kann diese auf der Erklärung oder auf der begleitenden Website angebracht werden. Die Konformität bleibt während des Unterstützungszeitraums bestehen: Schwachstellen weiterhin behandeln, jedes Sicherheitsupdate mindestens zehn Jahre oder den verbleibenden Unterstützungszeitraum lang verfügbar halten, falls dieser länger ist, und bewerten, ob Änderungen wesentliche Änderungen darstellen, die eine neue Bewertung erfordern.

• Importeure und Vertriebspartner darauf hinweisen, was sie vor dem Verkauf überprüfen müssen.
• Überprüfen Sie die Risikobewertung und die Matrix in Anhang I bei jeder größeren Version und führen Sie eine jährliche Managementbewertung durch.

Wie dies mit anderen Rahmenwerken verbunden ist

Die CRA regelt das Produkt; NIS2, ISO/IEC 27001 und CyFun regeln die Organisation. Sichere Entwicklung, Schwachstellenmanagement, Lieferantenmanagement und Incident Response gemäß ISO/IEC 27001 Anhang A oder NIS2 Artikel 21 liefern weiterhin einen großen Teil der Prozessnachweise, die die CRA erwartet. Bis harmonisierte CRA-Standards vorliegen, sind IEC 62443-4-1 und 4-2 (Industrie) und ETSI EN 303 645 (Consumer IoT) nützliche Referenzen.

Häufig gestellte Fragen

Gilt die CRA für Produkte, die wir bereits verkaufen?

Produkte, die vor dem 11. Dezember 2027 in den Verkehr gebracht werden, müssen die vollständigen Anforderungen nur erfüllen, wenn sie danach wesentlich verändert werden. Artikel-14-Meldungen gelten für sie ab dem 11. September 2026.

Müssen wir unsere SBOM veröffentlichen?

Nein. Sie ist Teil der technischen Dokumentation und muss den Marktüberwachungsbehörden auf Anfrage zur Verfügung gestellt werden.

Wir entwickeln nur Open-Source-Software. Sind wir ein Hersteller?

Nicht unbedingt. Open-Source-Software, die außerhalb einer kommerziellen Tätigkeit bereitgestellt wird, fällt nicht in den Geltungsbereich. Eine Stiftung, die sie systematisch für die kommerzielle Nutzung unterstützt, kann ein Steward sein, unterliegt dann einem leichteren Regime und ist von Bußgeldern befreit. Wenn Sie das Produkt selbst monetarisieren, sind Sie wahrscheinlich ein Hersteller.

Fällt SaaS in den Geltungsbereich?

Eigenständige SaaS fällt grundsätzlich nicht darunter. Ein Cloud-Backend, das ein Gerät zur Erfüllung seiner Funktionen benötigt, ist Teil dieses Produkts.

Welche Tools helfen Softwareherstellern, sich auf die CRA vorzubereiten?

Beginnen Sie mit unserer kostenlosen CRA-Bereitschafts-Checkliste, um zu sehen, wo jedes Produkt steht. Eine GRC-Plattform wie Secrato ordnet dann die CRA-Anforderungen Kontrollen, Verantwortlichen und Nachweisen zu und ermöglicht es Ihnen, bereits für ISO/IEC 27001 oder NIS2 geleistete Arbeit wiederzuverwenden.