Zum Hauptinhalt springen

CRA-Checkliste für Hersteller

Diese Punkte sollten Sie jetzt prüfen

Der Cyber Resilience Act (CRA) richtet sich in erster Linie an Hersteller von Produkten mit digitalen Elementen. Für viele Unternehmen stellt sich deshalb nicht mehr die Frage, ob sie sich mit dem CRA beschäftigen müssen, sondern wie sie die Anforderungen strukturiert in die Umsetzung bringen. Genau dafür ist eine saubere Checkliste wichtig: nicht als juristische Theorieliste, sondern als praktischer Arbeitsrahmen für Produktmanagement, Entwicklung, Security, Qualität und Geschäftsführung. Der CRA ist seit dem 10. Dezember 2024 in Kraft. Voll anwendbar ist er ab dem 11. Dezember 2027; die Meldepflichten nach Artikel 14 gelten bereits ab dem 11. September 2026.

Warum eine CRA-Checkliste für Hersteller so wichtig ist

Der CRA ist ein horizontaler EU-Rechtsrahmen für Hardware- und Softwareprodukte mit digitalen Elementen, die auf dem Unionsmarkt bereitgestellt werden. Er erfasst sowohl Endprodukte als auch Komponenten, die separat auf dem Markt bereitgestellt werden. Hersteller müssen dabei nicht nur punktuelle Sicherheitsmaßnahmen umsetzen, sondern nachweisen, dass ihre Produkte die wesentlichen Cybersecurity-Anforderungen erfüllen – von Planung und Entwicklung bis Wartung und Schwachstellenbehandlung.

Gerade deshalb ist der CRA kein Thema, das allein in Legal oder IT-Security aufgehoben ist. Wer die Anforderungen erfüllen will, braucht klare Zuständigkeiten und einen strukturierten Blick auf Produkte, Prozesse, Dokumentation und Supportmodelle. Die folgende Checkliste hilft dabei, den Umsetzungsstand realistisch einzuordnen und operative Lücken früh sichtbar zu machen. Diese Struktur folgt den Herstellerpflichten, wie sie die EU-Kommission in ihrer CRA-Zusammenfassung beschreibt.

1. Prüfen Sie zuerst, ob Ihr Produkt in den CRA fällt

Der CRA gilt für Produkte mit digitalen Elementen, wenn sie auf dem Markt bereitgestellt werden und ihre beabsichtigte oder vernünftigerweise vorhersehbare Nutzung eine direkte oder indirekte logische oder physische Datenverbindung zu einem Gerät oder Netzwerk umfasst. Nicht vom CRA erfasst sind Produkte, die nicht im Rahmen einer kommerziellen Tätigkeit auf dem Markt bereitgestellt werden. Außerdem gibt es bestimmte Ausnahmen, wenn andere EU-Rechtsakte die Cybersecurity-Aspekte bereits speziell regeln.

Checklistenfrage: Haben wir Produkte, Software oder Komponenten im Portfolio, die digital vernetzt sind oder mit Netzwerken bzw. Geräten verbunden werden können und auf dem EU-Markt bereitgestellt werden?

2. Klären Sie Ihre (Markt-) Rolle 

Im CRA ist der Hersteller die natürliche oder juristische Person, die ein Produkt mit digitalen Elementen entwickelt oder herstellen lässt und es unter eigenem Namen oder eigener Marke vermarktet – unabhängig davon, ob es verkauft, monetarisiert oder kostenlos bereitgestellt wird. Zusätzlich kennt der CRA weitere Rollen wie Importeur, Distributor und Bevollmächtigten. Für die Umsetzung ist es entscheidend, dass intern klar ist, wer tatsächlich Hersteller im regulatorischen Sinn ist.

Checklistenfrage: Ist eindeutig festgelegt, welche Gesellschaft oder Organisationseinheit bei jedem Produkt als Hersteller im CRA-Sinn auftritt?

3. Führen Sie eine Cybersecurity-Risikobewertung durch

Die Kommission stellt klar, dass Hersteller eine Cybersecurity-Risikobewertung durchführen müssen. Diese Risikobewertung ist nicht nur ein Dokument für die Akte, sondern die Grundlage dafür, wie die wesentlichen Cybersecurity-Anforderungen umgesetzt werden. Sie muss bei Planung, Design, Entwicklung, Produktion, Lieferung und Wartung berücksichtigt werden.

Checklistenfrage: Gibt es für jedes betroffene Produkt eine belastbare Risikobewertung, die tatsächlich in Architektur, Entwicklung, Produktion, Auslieferung und Wartung einfließt?

4. Setzen Sie die wesentlichen Sicherheitsanforderungen systematisch um

Nach dem CRA müssen Hersteller sicherstellen, dass ihre Produkte beim Design, bei der Entwicklung und Produktion die wesentlichen Cybersecurity-Anforderungen erfüllen. Die Kommission verweist dafür auf Annex I. Für Unternehmen heißt das in der Praxis: Security darf nicht nur in einzelnen Tests oder nachgelagerten Freigaben auftauchen, sondern muss strukturell im Produktlebenszyklus verankert sein.

Checklistenfrage: Sind Security-by-Design und Security-by-Default im Entwicklungsprozess tatsächlich verankert – oder beruhen wesentliche Sicherheitsmaßnahmen noch auf Einzelinitiativen?

5. Prüfen Sie Drittkomponenten und Abhängigkeiten

Wenn Hersteller Drittkomponenten integrieren, müssen sie laut CRA mit der erforderlichen Sorgfalt handeln, damit diese Komponenten die Cybersecurity des eigenen Produkts nicht beeinträchtigen. Für viele Unternehmen ist das einer der kritischsten Punkte, weil hier Bibliotheken, Embedded-Komponenten, Firmware-Bestandteile oder Fremdsoftware ins Spiel kommen.

Checklistenfrage: Haben wir Transparenz über Drittkomponenten, deren Sicherheitsrelevanz und den Prozess, wie Schwachstellen in diesen Komponenten bewertet und behandelt werden, Stichwort SBOM?

6. Bauen Sie die technische Dokumentation frühzeitig auf

Die Cybersecurity-Risikobewertung und die Mittel zur Umsetzung der wesentlichen Anforderungen müssen in die technische Dokumentation aufgenommen werden. Diese Dokumentation muss Marktüberwachungsbehörden auf Anfrage zur Verfügung gestellt werden können. In der Praxis ist das einer der Punkte, die Unternehmen am häufigsten unterschätzen: Nicht die einzelne Maßnahme fehlt, sondern der belastbare Nachweis.

Checklistenfrage: Ist unsere technische Dokumentation so aufgebaut, dass Risikobewertung, Sicherheitsmaßnahmen, gewählte Standards und Nachweise strukturiert und prüffähig vorliegen?

7. Planen Sie die Konformitätsbewertung rechtzeitig ein

Bevor ein Produkt mit digitalen Elementen auf den Markt gebracht wird, muss der Hersteller das gewählte Konformitätsbewertungsverfahren durchführen. Wenn dieses erfolgreich ist, sind anschließend die EU-Konformitätserklärung zu erstellen und die CE-Kennzeichnung anzubringen. Gerade für Hersteller mit mehreren Produktlinien ist das keine Formalität, sondern ein echter Organisations- und Dokumentationsprozess.

Checklistenfrage: Ist geklärt, welches Konformitätsbewertungsverfahren je Produkt greift, wer es verantwortet und wie Erklärung sowie CE-Kennzeichnung organisatorisch abgesichert werden?

8. Stellen Sie Pflichtinformationen für Nutzer bereit

Zusammen mit dem Produkt müssen Hersteller bestimmte Informationen bereitstellen, darunter Identifikationsmerkmale, Name und Kontaktdaten sowie die in Annex II beschriebenen Informationen und Anweisungen für Nutzer. Dazu gehört ausdrücklich auch das Enddatum des Support-Zeitraums, das zum Zeitpunkt des Kaufs klar und verständlich angegeben werden muss.

Checklistenfrage: Sind Nutzerinformationen, Kontaktangaben, Identifikationsmerkmale und das Support-Enddatum sauber definiert und konsistent über Vertrieb, Produktdokumentation und Support hinweg kommuniziert?

9. Definieren Sie den Support-Zeitraum und das Vulnerability Handling

Der Hersteller muss einen Support-Zeitraum bestimmen, in dem Schwachstellen des Produkts wirksam behandelt werden. Das ist operativ besonders wichtig, weil damit nicht nur Security, sondern auch Service, Ersatzteilstrategie, Produktmanagement und Kundenkommunikation betroffen sind. Der CRA verlangt also nicht nur ein sicheres Produkt beim Markteintritt, sondern auch einen funktionierenden Umgang mit Schwachstellen während der vorgesehenen Nutzungszeit.

Checklistenfrage: Haben wir je Produkt einen realistischen Support-Zeitraum festgelegt und einen belastbaren Prozess, um Schwachstellen in diesem Zeitraum wirksam zu behandeln?

10. Bereiten Sie die Meldepflichten vor

Sobald ein Produkt auf dem Markt ist, muss der Hersteller aktiv ausgenutzte Schwachstellen und schwere Sicherheitsvorfälle, die die Sicherheit des Produkts betreffen, melden. Die Fristen sind anspruchsvoll: 24 Stunden für die Frühwarnung, 72 Stunden für die Hauptmeldung, ein Abschlussbericht spätestens 14 Tage nach Verfügbarkeit einer Korrektur- oder Abhilfemaßnahme bei aktiv ausgenutzten Schwachstellen und ein Abschlussbericht innerhalb eines Monats nach der 72-Stunden-Meldung bei schweren Sicherheitsvorfällen. Die Meldung erfolgt über die von ENISA betriebene CRA Single Reporting Platform.

Checklistenfrage: Gibt es bereits einen internen Melde- und Eskalationsprozess, mit dem aktiv ausgenutzte Schwachstellen und schwere Sicherheitsvorfälle CRA-konform erkannt, bewertet und fristgerecht gemeldet werden können?

11. Denken Sie CRA als Querschnittsthema, nicht als Einzelprojekt

Der CRA verteilt seine Anforderungen faktisch über mehrere Funktionen: Produktmanagement, Entwicklung, Qualität, Service, Support, Legal, Security und Geschäftsführung. Genau deshalb scheitern viele Unternehmen nicht am Verständnis einzelner Vorschriften, sondern an fehlenden Zuständigkeiten, Prozessbrüchen und unklarer Governance. Diese Schlussfolgerung ergibt sich direkt aus dem Umstand, dass der CRA Anforderungen an Entwicklung, Dokumentation, Support, Konformitätsbewertung und Meldewesen gleichzeitig stellt.

Checklistenfrage: Gibt es eine klare CRA-Governance mit Verantwortlichkeiten, Eskalationswegen und Entscheidungskompetenzen über alle betroffenen Bereiche hinweg?

Fazit

Eine gute CRA-Checkliste für Hersteller ist kein Papier für die Ablage, sondern ein Instrument zur Priorisierung. Der eigentliche Mehrwert liegt darin, früh zu erkennen, wo Produkte, Prozesse und Zuständigkeiten noch nicht CRA-ready sind. Genau dort entsteht später der größte Zeitdruck: bei technischer Dokumentation, Supportmodellen, Third-Party-Komponenten, Meldelogik und Konformitätsbewertung. Wer diese Punkte jetzt strukturiert angeht, schafft nicht nur regulatorische Sicherheit, sondern verbessert auch Produktqualität, Transparenz und Cyber-Resilienz.

Sie möchten schnell und belastbar einschätzen, ob Ihre Produkte unter den CRA fallen?Wir unterstützen Sie mit einem pragmatischen CRA-Betroffenheitscheck: Portfolio-Sichtung, regulatorische Einordnung, erste Risikoeinschätzung und klare Prioritäten für die nächsten Schritte.

d.works

Jens Langguth
Leiter Consulting

[email protected]


Unsere neuesten Beiträge