Cyber Resilience Act: Neue Anforderungen für Hersteller, Importeure und Händler

Cyber Resilience Act: Neue Anforderungen für Hersteller, Importeure und Händler
  • 21.05.2026
  • Lesezeit 7 Minuten

Die zentralen Pflichten des Cyber Resilience Act (CRA) gelten ab Dezember 2027, die Meldepflichten bereits ab September 2026. Wer jetzt noch nicht damit begonnen hat, die eigene Produkt- und Prozesslandschaft zu analysieren, wird unweigerlich unter Zeitdruck geraten – und Zeitdruck ist bei Compliance-Themen selten ein guter Ratgeber.

Was der CRA regelt und welche Unternehmen betroffen sind 

Der Cyber Resilience Act (CRA) führt erstmals einheitliche Cybersecurity-Anforderungen für Produkte mit digitalen Elementen ein, die auf dem EU-Markt bereitgestellt werden. Erfasst sind sowohl Hardware- als auch Softwareprodukte, die direkt oder indirekt mit einem Gerät oder Netzwerk verbunden werden können. Dazu zählen etwa vernetzte Geräte, IoT-Produkte, industrielle Steuerungskomponenten, Betriebssysteme, Anwendungen, Firmware, Remote-Datenverarbeitungslösungen sowie separat vertriebene digitale Komponenten. 

Im Mittelpunkt stehen Hersteller, die solche Produkte unter eigenem Namen oder eigener Marke in der EU anbieten. Betroffen sind daher nicht nur klassische Hardwarehersteller, sondern auch Softwareanbieter, IoT-Hersteller und Maschinenbauer mit vernetzten Komponenten. Wer ein Produkt unter eigenem Label vermarktet, übernimmt grundsätzlich die Herstellerpflichten – auch dann, wenn die Entwicklung oder Fertigung durch einen OEM erfolgt. 

Auch Importeure und Händler werden durch den CRA in die Pflicht genommen. Sie müssen unter anderem prüfen, ob die Produkte korrekt gekennzeichnet sind und ob der Hersteller die erforderlichen Nachweise und Pflichten erfüllt hat. 
 

Produktkategorien: Nicht alle Produkte sind gleich

Der CRA unterscheidet drei Kategorien, die unterschiedliche Konformitätswege erfordern. Genau hier beginnt eine der ersten praktischen Aufgaben für Hersteller. 

Bei der großen Mehrheit der Produkte, den sogenannten Standardprodukten, kann der Hersteller die Konformität im Rahmen einer Selbstbewertung nachweisen. Eine eigene Risikobewertung und technische Dokumentation reichen aus, sofern harmonisierte Normen eingehalten werden. 

Wichtige Produkte der Klasse I – dazu zählen etwa Passwortmanager, Firewalls oder Netzwerkkonfigurationstools – und Klasse II – etwa industrielle Steuerungssysteme, Betriebssysteme oder Hypervisoren – unterliegen strengeren Anforderungen. Für sie ist in der Regel eine Bewertung durch eine benannte Stelle (Notified Body) erforderlich, sofern nicht vollständig harmonisierte Normen vorliegen. 
 

Was der CRA konkret verlangt

Das Kernziel ist klar: Cybersecurity soll nicht mehr nachträglich in Produkte eingebaut werden. Sie muss von Anfang an mitgedacht werden – in Architektur, Entwicklung, Testing, Auslieferung und Wartung. 

Der CRA fordert von Herstellern:

  • Eine Cybersecurity-Risikobewertung, die das Produkt über seinen gesamten Lebenszyklus begleitet
  • Technische Dokumentation, die Sicherheitseigenschaften, Risiken und Maßnahmen nachvollziehbar macht
  • Sicherheitsupdates über den gesamten erwarteten Nutzungszeitraum – mindestens für fünf Jahre
  • Ein funktionierendes Schwachstellenmanagement mit klaren Prozessen zur Identifikation, Priorisierung, Behebung und Kommunikation
  • Transparente Nutzerinformationen: Wie wird das Produkt sicher konfiguriert? Welche Sicherheitsfunktionen bietet es? Wie werden Updates eingespielt?
  • Eine EU-Konformitätserklärung und CE-Kennzeichnung

Die Anforderung zur Bereitstellung von Sicherheitsupdates für mindestens fünf Jahre ist besonders relevant. Sie betrifft nicht nur die Entwicklungsabteilung, sondern auch Lizenzmodelle, Supportverträge, End-of-Life-Planung und die Frage, wie lange Drittbibliotheken und Komponenten von ihren Maintainern gepflegt werden. Wer heute ein Produkt auf den Markt bringt, verpflichtet sich damit zu einer Supportlaufzeit, die im Produktgeschäft nicht immer eingepreist ist.
 

CRA-Meldepflicht ab 2026:  Fristen und Anforderungen im Überblick

Ab dem 11. September 2026 müssen Hersteller aktiv ausgenutzte Schwachstellen und schwere Sicherheitsvorfälle melden. Die Fristen sind eng:

  • Innerhalb von 24 Stunden: Frühwarnung an ENISA und die zuständigen nationalen Behörden
  • Innerhalb von 72 Stunden: Detailliertere Meldung mit weiteren Informationen
  • Anschließend: Abschlussbericht

In der Praxis bedeutet das: Meldeprozesse müssen vorab technisch und organisatorisch vorbereitet sein – mit klaren Zuständigkeiten, vorbereiteten Meldewegen und einer funktionierenden Verbindung zwischen Product Security, Incident Response, Legal und Kundenkommunikation. Gerade dieser Bereich wird von vielen Herstellern aktuell noch unterschätzt, weil er nicht primär als technisches Thema wahrgenommen wird. 
 

Die technischen Herausforderungen in der Praxis

Security by Design: Sicherheitsanforderungen werden oft als nachgelagerte Prüfinstanz behandelt, nicht als integraler Bestandteil von Architekturentscheidungen und Entwicklungsprozessen. Der CRA zwingt dazu, das zu ändern – und zwar dauerhaft, nicht als einmaliges Projekt.

Drittanbieterkomponenten: Die meisten Softwareprodukte basieren auf einem Mix aus Open-Source-Bibliotheken, kommerziellen Komponenten, APIs und Cloud-Diensten. Der CRA verlangt, dass Hersteller wissen, was in ihrem Produkt steckt und welche Schwachstellen darin vorliegen. In der Praxis erfordert das eine Software Bill of Materials (SBOM), kontinuierliches Dependency Scanning, sichere Build- und Release-Pipelines sowie eine klare Policy für den Umgang mit End-of-Life-Komponenten.  

Bestandsprodukte: Wer ein Produkt anbietet, das nach Dezember 2027 weiter auf dem EU-Markt vertrieben werden soll, ist ebenfalls zur Konformität verpflichtet – es sei denn, es wird nicht wesentlich modifiziert und ist vor dem Stichtag bereits auf dem Markt. Die Frage, was eine „wesentliche Modifikation" ist, die eine erneute Konformitätsbewertung auslöst, ist noch nicht abschließend geklärt. Das wird in der Praxis zu Auslegungsdiskussionen führen.  Unternehmen, die ihre Produktstrategie frühzeitig darauf ausrichten, werden einen klaren Vorteil haben. 

Governance und Verantwortlichkeiten: Der größte Aufwand liegt häufig nicht in der technischen Implementierung, sondern in den organisatorischen Fragen. Wer ist verantwortlich? Wie werden Anforderungen in Entwicklungs- und Qualitätsprozesse integriert? Wie werden Lieferantenanforderungen formuliert und geprüft? Der CRA ist kein reines IT-Security-Thema. Er betrifft Produktmanagement, Entwicklung, Einkauf, Qualitätsmanagement, Lieferantenmanagement, Vertrieb und After-Sales gleichermaßen.
 

Einordnung: CRA, NIS2 und andere Regulierungen

Der CRA steht nicht allein, sondern ist im Kontext eines wachsenden Regelwerks zu betrachten. 

NIS2 adressiert insbesondere wesentliche und wichtige Einrichtungen, darunter auch Betreiber kritischer Infrastrukturen, und stellt Anforderungen an Cybersecurity-Maßnahmen bei Unternehmen. Der CRA hingegen setzt bei den Produkten selbst an. Für viele Unternehmen – etwa Hersteller industrieller Steuerungssysteme – gelten beide Regelwerke parallel. Hinzu kommen je nach Produkt und Branche sektorspezifische Anforderungen wie die Radio Equipment Directive (RED), die Machinery Regulation, der EU AI Act oder die Medical Device Regulation (MDR). 

Wer den CRA isoliert betrachtet, läuft Gefahr, doppelten Aufwand zu erzeugen oder Synergien zu verpassen. Eine kohärente Compliance-Architektur, die Überschneidungen identifiziert und Anforderungen aus mehreren Regelwerken gemeinsam adressiert, ist langfristig effizienter – auch wenn sie initial mehr Analyse erfordert. 
 

Was bei Nichtkonformität droht

Die Sanktionen sind erheblich. Bei Verstößen gegen wesentliche Cybersecurity-Anforderungen sowie zentrale Hersteller- und Meldepflichten drohen Bußgelder von bis zu 15 Millionen Euro oder 2,5 Prozent des weltweiten Jahresumsatzes, je nachdem, welcher Betrag höher ist. Für weitere Verstöße sind bis zu 10 Millionen Euro oder 2 Prozent, für falsche oder irreführende Informationen gegenüber Behörden bis zu 5 Millionen Euro oder 1 Prozent des Jahresumsatzes möglich. Zusätzlich können Behörden Korrekturmaßnahmen verlangen, Produkte vom Markt nehmen oder deren Bereitstellung untersagen. 

Das Bußgeld ist aber oft nicht das eigentliche Risiko. Ein nicht konformes Produkt, das bei einem Sicherheitsvorfall in der Lieferkette eines Kunden auftaucht, kann zu Haftungsansprüchen, Vertragsstrafen und Reputationsschäden führen, die die Bußgeldrisiken noch übersteigen. Gerade im B2B-Bereich wird Cybersecurity zunehmend zum Bestandteil von Lieferantenbewertungen und Vertragsverhandlungen.  Wer darauf nicht vorbereitet ist, kann Geschäft verlieren. 
 

Was Unternehmen jetzt tun sollten

Die erste Frage ist oft: Bin ich überhaupt betroffen? In vielen Fällen lautet die Antwort: Ja – insbesondere dann, wenn ein Produkt digitale Elemente enthält und direkt oder indirekt mit einem Gerät oder Netzwerk verbunden ist. 

Danach geht es um Priorisierung: Welche Produkte fallen in welche Kategorie? Welche Anforderungen gelten konkret? Wo bestehen Lücken – in Prozessen, Dokumentation, technischen Kontrollen, Zuliefererverträgen? Diese Analyse ist der notwendige Ausgangspunkt, bevor Maßnahmen sinnvoll geplant werden können. 

Der CRA bietet dabei nicht nur Compliance-Risiken, sondern auch eine echte Chance: Wer Cybersecurity konsequent in Produktentwicklung und -wartung verankert, baut Vertrauen bei Kunden, Partnern und Behörden auf – und setzt sich in einem Markt ab, in dem Sicherheit zunehmend zum Kaufkriterium wird. 
 

Wie wir Sie bei der CRA-Umsetzung unterstützen

Baker Tilly unterstützt Unternehmen in allen Phasen der CRA-Umsetzung – von der ersten Betroffenheitsanalyse über die Einordnung der konkreten Anforderungen bis hin zur Begleitung auf dem Weg zur CE-Konformität. Dabei helfen wir insbesondere, die regulatorischen Vorgaben in technische und organisatorische Anforderungen zu übersetzen und deren Auswirkungen auf den gesamten Produktlebenszyklus zu verstehen. 

Sprechen Sie uns an – gemeinsam definieren wir einen pragmatischen Umsetzungsweg, der regulatorische Anforderungen, technische Machbarkeit und Ihre bestehenden Produkt- und Entwicklungsprozesse zusammenbringt.