CRA 2026: Pflichten nach dem Cyber Resilience Act

Ab dem 11. September 2026 kann ein solcher Hinweis die 24-Stunden-Frist des Art. 14 CRA auslösen. Sobald nach einer unverzüglichen Erstbewertung ein hinreichender Grad an Gewissheit besteht, dass eine im Produkt enthaltene Schwachstelle aktiv ausgenutzt wird, muss der Hersteller unverzüglich und spätestens innerhalb von 24 Stunden eine Frühwarnung abgeben. Die Meldung erfolgt über die einheitliche Meldeplattform über den elektronischen Endpunkt des zuständigen koordinierenden CSIRT und ist gleichzeitig für ENISA zugänglich.

Der Cyber Resilience Act betrifft zahlreich Unternehmen, die Produkte vertreiben, angefangen beim Babyfon über den Passwortmanager bis zur Industriesteuerung. Schätzungen gehen von Hunderten Millionen betroffener Geräte im EU-Binnenmarkt aus. Welche Pflichten wann greifen und was bereits im September 2026 durchsetzbar wird, zeigt der folgende Überblick.

 Begriff und Bedeutung

Der Cyber Resilience Act – Verordnung (EU) 2024/2847, amtlich Cyberresilienz-Verordnung – ist das erste horizontale EU-Regelwerk für die Cybersicherheit von Produkten mit digitalen Elementen. Er trat am 10. Dezember 2024 in Kraft und gilt unmittelbar in allen Mitgliedstaaten.

Der Ansatz ist der des Produktsicherheitsrechts. Wie bei Maschinen oder elektrischen Geräten gilt, wer ein Produkt auf dem Binnenmarkt bereitstellt, muss wesentliche Anforderungen erfüllen, eine Konformitätsbewertung durchführen, eine EU-Konformitätserklärung ausstellen und das Produkt mit der CE-Kennzeichnung versehen.

Neu ist, dass der CRA Cybersicherheit über wesentliche Phasen des Produktlebenszyklus adressiert – von Konzeption und Entwicklung über das Inverkehrbringen bis zur Schwachstellenbehandlung während des festgelegten Unterstützungszeitraums.

Der Hintergrund ist ein regulatorischer Blindfleck. Vor dem CRA gab es keinen einheitlichen europäischen Rahmen für die Cybersicherheit vernetzter Produkte, sondern ein Nebeneinander aus freiwilligen Standards und sektorspezifischen Regeln. Produkte konnten mit bekannten Schwachstellen, ohne Sicherheitsupdates und ohne Transparenz auf den Markt gebracht werden.

In der Folgenabschätzung zum Verordnungsvorschlag schätzte die Kommission, dass die Initiative die jährlichen Kosten von Cybervorfällen für Unternehmen in der EU um rund 180 bis 290 Milliarden Euro reduzieren könnte. Dem stellte sie aggregierte Compliance-Kosten von bis zu rund 29 Milliarden Euro gegenüber.

Anders als die NIS-2-Regulierung ist der CRA primär produkt- und rollenbezogen. Entscheidend ist insbesondere, ob ein Produkt mit digitalen Elementen im Anwendungsbereich bereitgestellt wird und welche Rolle das Unternehmen als Hersteller, Einführer, Händler oder sonstiger Wirtschaftsakteur einnimmt. Allgemeine Unternehmensgrößenschwellen bestimmen den CRA-Anwendungsbereich dagegen grundsätzlich nicht.

Anwendungsbereich

Erfasst sind auf dem Markt bereitgestellte Hardware- und Softwareprodukte, deren Zweckbestimmung oder vernünftigerweise vorhersehbare Verwendung eine direkte oder indirekte logische oder physische Datenverbindung mit einem Gerät oder Netz einschließt. Hinzu kommen Fernverarbeitungslösungen, die für eine Kernfunktion des Produkts erforderlich sind.

In der Praxis betrifft das unter anderem:

• vernetzte Konsumgeräte, Smart-Home-Produkte, Wearables und vernetztes Kinderspielzeug
• Betriebssysteme, Browser, mobile Anwendungen und lokal installierte Software
• Passwortmanager, VPN-Lösungen, Firewalls und Identitätsmanagement
• Netzwerktechnik, Router, Mikroprozessoren und Mikrocontroller
• industrielle Steuerungssysteme und Betriebstechnik
• Smart-Meter-Gateways und Chipkarten

Adressat ist in erster Linie der Hersteller, unabhängig davon, ob er seinen Sitz in der EU hat. Wer Produkte aus einem Drittland in den Binnenmarkt bringt, unterliegt der Verordnung ebenso. Eigene, abgestufte Pflichten treffen Einführer und Händler. Bei Auftragsfertigung ist derjenige Hersteller im Sinne des CRA, der das Produkt unter eigenem Namen oder eigener Marke vermarktet.

Nicht erfasst sind insbesondere:

Ausgenommen sind insbesondere die in Art. 2 CRA ausdrücklich genannten Produktbereiche, darunter Medizinprodukte und In-vitro-Diagnostika sowie bestimmte Kraftfahrzeug-, Luftfahrt- und Schiffsausrüstungen. Für weitere Produkte kann der CRA unter den Voraussetzungen des Art. 2 Abs. 5 durch delegierte Rechtsakte eingeschränkt oder ausgeschlossen werden, wenn sektorspezifisches Unionsrecht ein mindestens gleichwertiges Schutzniveau gewährleistet.

Zudem ebenso Produkte ausschließlich für Zwecke der nationalen Sicherheit oder Verteidigung sowie zur Verarbeitung von Verschlusssachen, wobei Dual-Use-Produkte dagegen erfasst bleiben sowie freie und quelloffene Software, die außerhalb einer Geschäftstätigkeit bereitgestellt wird. Für sogenannte Verwalter quelloffener Software enthält der CRA jedoch ein eigenes, abgestuftes Pflichtenregime.

Reine Cloud- oder SaaS-Dienste fallen nicht schon aufgrund ihrer entfernten Bereitstellung in den CRA. Eine entfernte Softwarekomponente kann jedoch als Datenfernverarbeitungslösung Teil eines Produkts mit digitalen Elementen sein, wenn sie vom Hersteller oder unter seiner Verantwortung konzipiert und entwickelt wurde und das Produkt ohne diese Verarbeitung eine seiner Funktionen nicht erfüllen könnte. Für Grenzfälle sind zusätzlich die am 27. Juli 2026 veröffentlichten, nicht bindenden Kommissionsleitlinien heranzuziehen.

Rechtsgrundlagen im Überblick

Produktkategorien

Der Umfang der Nachweispflichten hängt von der Kritikalität des Produkts ab. Die Einordnung entscheidet darüber, ob eine interne Selbstbewertung genügt oder eine notifizierte Stelle einzubinden ist.

Wesentliche Anforderungen

Anhang I Teil I betrifft die Eigenschaften des Produkts. Produkte mit digitalen Elementen müssen so konzipiert, entwickelt und hergestellt werden, dass sie angesichts der bestehenden Risiken ein angemessenes Cybersicherheitsniveau gewährleisten. Auf Grundlage der Cybersicherheitsrisikobewertung müssen sie – soweit die jeweilige Anforderung zutrifft – unter anderem ohne bekannte ausnutzbare Schwachstellen und mit sicherer Standardkonfiguration auf dem Markt bereitgestellt werden.

Anhang I Teil II betrifft den Umgang mit Schwachstellen über die Zeit. Dazu gehören insbesondere:

• Identifikation und Dokumentation von Schwachstellen und Komponenten, einschließlich einer Software-Stückliste (SBOM) für zumindest die obersten Abhängigkeiten
• unverzügliche Behebung von Schwachstellen, insbesondere durch Sicherheitsupdates
• regelmäßige Tests und Überprüfungen der Sicherheit
• Veröffentlichung von Informationen zu behobenen Schwachstellen nach Bereitstellung eines Updates
• eine Richtlinie zur koordinierten Offenlegung von Schwachstellen und eine Kontaktadresse für Meldungen
• Sicherheitsupdates müssen grundsätzlich zeitnah und unentgeltlich bereitgestellt werden.
• Sicherheitsrelevante Aktualisierungen sollen zudem so gestaltet und bereitgestellt werden, dass Nutzer ihren Zweck nachvollziehen und sie zuverlässig installieren können.

Hersteller müssen einen Zeitraum festlegen, in dem Schwachstellen wirksam behandelt werden. Er soll der erwarteten Nutzungsdauer entsprechen und beträgt im Regelfall mindestens fünf Jahre. Nur bei einer kürzeren erwarteten Nutzungsdauer darf er kürzer ausfallen. Der Unterstützungszeitraum ist den Nutzern klar und verständlich vor dem Kauf mitzuteilen. Für viele Hersteller ist das die wirtschaftlich folgenreichste Vorgabe, weil sie Produktkalkulation, Ersatzteilstrategie und Entwicklungsressourcen über Jahre bindet.

Meldepflichten ab dem 11. September 2026

Die Meldepflicht gilt auch für Produkte, die bereits vor dem 11. September 2026 in Verkehr gebracht wurden, solange sie auf dem Markt und im Unterstützungszeitraum sind.

Erfasst sind zwei Auslöser:

• aktiv ausgenutzte Schwachstellen
• und schwerwiegende Sicherheitsvorfälle mit Auswirkungen auf die Sicherheit des Produkts.

Die Meldungen werden über die von ENISA eingerichtete einheitliche Meldeplattform über den elektronischen Endpunkt des zuständigen koordinierenden CSIRT übermittelt und sind gleichzeitig für ENISA zugänglich. Die weitere Verteilung an betroffene koordinierende CSIRTs erfolgt nach den Vorgaben des Art. 16 CRA. Unternehmen sollten Registrierung, Zugriffsrechte und interne Zuständigkeiten deshalb vor dem 11. September 2026 vorbereiten.

Für Hersteller mit großen Produktportfolios kann das zu einem Engpass werden und gehört in die Notfall- und Rufbereitschaftsplanung.

Hinzu kommen zwei flankierende Pflichten. Nach Kenntniserlangung muss der Hersteller die betroffenen Nutzer und gegebenenfalls alle Nutzer über die Schwachstelle oder den schwerwiegenden Sicherheitsvorfall sowie erforderliche Risiko- und Korrekturmaßnahmen informieren. Erfolgt dies nicht rechtzeitig, kann das koordinierende CSIRT die Nutzer unter den Voraussetzungen des Art. 14 Abs. 8 selbst informieren. Wird eine Schwachstelle in einer fremden Komponente entdeckt, ist zusätzlich der Hersteller oder Betreuer dieser Komponente zu informieren.

Wann beginnt die Frist?

Nach den nicht bindenden Leitlinien der Kommission liegt Kenntnis vor, wenn ein hinreichender Grad an Gewissheit besteht, dass eine Schwachstelle aktiv ausgenutzt wird oder ein schwerwiegender Vorfall die Sicherheit des Produkts beeinträchtigt hat. Eine kurze Ersteinschätzung darf abgewartet werden. Eine noch laufende forensische Untersuchung mit dem Ziel vollständiger Gewissheit rechtfertigt eine Fristüberschreitung dagegen grundsätzlich nicht.

Erleichterung für kleine Unternehmen:

Kleinstunternehmen und kleine Unternehmen werden nach Artikel 64 CRA nicht mit einer Geldbuße belegt, wenn sie die Frist für die 24-Stunden-Frühwarnung versäumen. Die Meldepflicht selbst entfällt dadurch nicht.

Altprodukte:

Die Meldepflichten des Art. 14 CRA gelten nach Art. 69 Abs. 3 auch für Produkte mit digitalen Elementen, die bereits vor dem 11. Dezember 2027 in Verkehr gebracht wurden. Nach Art. 69 Abs. 3 CRA gelten die Meldepflichten des Art. 14 auch für Produkte mit digitalen Elementen, die bereits vor dem 11. Dezember 2027 in Verkehr gebracht wurden. Der Wortlaut der Übergangsregelung macht dies nicht davon abhängig, dass sich das Produkt noch innerhalb seines Unterstützungszeitraums befindet.

 Zeitschiene

Für Produkte, die ab dem 11. Dezember 2027 neu in Verkehr gebracht werden, müssen die einschlägigen CRA-Anforderungen erfüllt sein. Für bereits zuvor in Verkehr gebrachte Produkte enthält Art. 69 CRA Übergangsregelungen. Die Meldepflichten des Art. 14 gelten jedoch unabhängig davon. Regulierte Kunden verlangen bereits heute vertragliche Zusicherungen zur CRA-Konformität, unter anderem weil sie selbst NIS-2-Anforderungen an die Lieferkette erfüllen müssen.

Nationale Durchführung in Deutschland

Als unmittelbar geltende Verordnung bedarf der CRA keiner Umsetzung, wohl aber flankierender nationaler Regelungen zu Zuständigkeiten, Verfahren und Sanktionen.

Die Bundesregierung beschloss den Entwurf des CRA-Durchführungsgesetzes am 29. April 2026. Der Bundestag beriet ihn am 11. Juni 2026 in erster Lesung und überwies ihn anschließend an die Ausschüsse. Nach dem Regierungsentwurf soll das BSI grundsätzlich als Marktüberwachungsbehörde und notifizierende Behörde fungieren. Für Unternehmen bedeutet das eine zusätzliche Berührungsfläche mit derselben Behörde, die bereits die NIS-2-Aufsicht führt.

Sanktionen

Neben Bußgeldern stehen den Marktüberwachungsbehörden die üblichen Instrumente des Produktrechts zur Verfügung: Anordnung von Abhilfemaßnahmen, Beschränkung oder Untersagung der Bereitstellung sowie Rücknahme und Rückruf. Hinzu kommt das zivilrechtliche Haftungsrisiko, wenn ein unzureichend abgesichertes oder nicht mehr unterstütztes Produkt zum Einfallstor wird.

Typische Risiken

Unerkannte Betroffenheit und falsche Rolle

Viele Unternehmen sehen sich nicht als Hersteller. Wer Software unter eigenem Namen vertreibt, ein zugekauftes Gerät mit eigener Marke versieht oder ein Produkt wesentlich verändert, ist es im Sinne des CRA jedoch. Die Abgrenzung zwischen lokal bereitgestellter Software, Datenfernverarbeitung und reinem SaaS ist für den CRA-Anwendungsbereich zentral. Unabhängig davon ist gesondert zu prüfen, ob der Anbieter oder Kunde als Einrichtung unter das NIS-2-Regime beziehungsweise das BSIG fällt. Beide Regelwerke können parallel einschlägig sein.

Fehlende Sichtbarkeit über Komponenten

Ohne aktuelle Software-Stückliste lässt sich weder feststellen, ob eine gemeldete Schwachstelle das eigene Produkt betrifft, noch der zuständige Komponentenhersteller informieren. Der Aufbau eines belastbaren SBOM-Prozesses ist die Voraussetzung dafür, die 24-Stunden-Frist überhaupt einhalten zu können.

Der 24-Stunden-Prozess

Die Frist läuft ab Kenntnis, nicht ab dem nächsten Werktag. Erforderlich sind eine kontinuierliche Beobachtung von Schwachstellendatenbanken und Bedrohungsinformationen, eine funktionierende Meldestelle für externe Hinweisgeber, klare Eskalationswege und eine benannte Person mit Entscheidungsbefugnis für die Meldung.

Vertraulichkeit und Wettbewerbsinteressen

Meldungen enthalten Angaben zu Architektur, betroffenen Komponenten, Reichweite und geplanten Abhilfemaßnahmen. Die Meldung führt nicht automatisch zu einer öffentlichen Bekanntmachung. Für Meldedaten gelten Vertraulichkeits-, Sicherheits- und Need-to-know-Vorgaben. Je nach Fall sieht der CRA jedoch eine Weitergabe an weitere zuständige Stellen vor; bei schwerwiegenden Sicherheitsvorfällen kann unter den Voraussetzungen des Art. 17 Abs. 2 auch eine Information der Öffentlichkeit erfolgen. Dennoch sollte vorab geklärt sein, welche Informationen in welcher Detailtiefe übermittelt werden.

Lieferkette in beide Richtungen

Der CRA verpflichtet den Hersteller, dieser ist aber auf Informationen seiner Zulieferer angewiesen. Ohne vertragliche Meldepflichten der Komponentenlieferanten fehlt die Grundlage für eine fristgerechte eigene Meldung. Umgekehrt geben regulierte Kunden ihre Anforderungen weiter.

Parallele Meldepflichten

Ein Vorfall kann – abhängig vom jeweiligen Anwendungsbereich und den gesetzlichen Meldeschwellen – mehrere Regime gleichzeitig auslösen: etwa die CRA-Frühwarnung innerhalb von 24 Stunden, die frühe Erstmeldung nach § 32 BSIG innerhalb von 24 Stunden an die gemeinsame Meldestelle von BSI und BBK sowie bei einer meldepflichtigen Verletzung personenbezogener Daten die 72-Stunden-Frist nach Art. 33 DSGVO. Ein Vorfallprozess, der alle drei Bewertungen abbildet, verhindert, dass eine Frist über der anderen vergessen wird.

Risiken im Überblick

• Nicht geprüfte Produktbetroffenheit und falsche Rolleneinordnung
• Fehlende oder unvollständige Software-Stückliste
• Kein geübter Meldeprozess für die 24-Stunden-Frist
• Unklare oder zu kurz kalkulierte Unterstützungszeiträume
• Produkte, die mit bekannten ausnutzbaren Schwachstellen ausgeliefert werden
• Fehlende Richtlinie zur koordinierten Offenlegung von Schwachstellen
• Zulieferverträge ohne Melde- und Informationspflichten
• Falsche Einschätzung der Produktkategorie und damit des Konformitätsbewertungsverfahrens
• Kapazitätsengpässe bei notifizierten Stellen kurz vor Dezember 2027
• Bußgelder, Rückrufe und Vertriebsverbote
• Verlust von Aufträgen, wenn Kunden CRA-Zusicherungen verlangen
• Zivilrechtliche Haftung nach Vorfällen mit unzureichend abgesicherten Produkten

Verhältnis zu anderen Regelwerken

Der CRA reguliert das Produkt, NIS-2 die Organisation, die es einsetzt oder betreibt. Beide greifen ineinander. Wer als besonders wichtige oder wichtige Einrichtung die Sicherheit seiner Lieferkette nachweisen muss, verlangt von Herstellern CRA-Konformität. Umgekehrt kann ein Softwareanbieter zugleich Hersteller im Sinne des CRA und wichtige Einrichtung im Sinne des BSIG sein.

Zwischen CRA und KI-Verordnung besteht eine ausdrückliche Konformitätsbrücke. Art. 12 CRA sieht bereits vor, dass ein erfasstes Hochrisiko-KI-System bei Erfüllung bestimmter CRA-Cybersicherheitsanforderungen als mit den entsprechenden Anforderungen des Art. 15 KI-VO konform gilt. Der Digital Omnibus hat die Verknüpfung durch den neuen Art. 42 Abs. 3 KI-VO ausdrücklich gespiegelt. Die Regelung ist jedoch Teil des Hochrisiko-Regimes der KI-Verordnung und wird entsprechend den verschobenen Anwendungsfristen grundsätzlich erst ab dem 2. Dezember 2027 beziehungsweise 2. August 2028 relevant.

Zur DSGVO besteht kein Vorrangverhältnis. Sicherheit der Verarbeitung nach Art. 32 DSGVO und Datenschutz durch Technikgestaltung nach Art. 25 DSGVO bleiben eigenständig zu erfüllen; der CRA setzt lediglich einen produktbezogenen Mindeststandard, auf den sich Verantwortliche bei der Auswahl von Produkten stützen können.

SBS LEGAL – Kanzlei für IT-Recht

SBS LEGAL berät Unternehmen im IT-Recht und bei rechtlichen Fragen rund um den Cyber Resilience Act und die europäische Cybersicherheitsregulierung. Dazu gehört insbesondere die rechtliche Einordnung von CRA-Pflichten, Meldeprozessen, Vertragsstrukturen und Schnittstellen zu NIS-2, BSIG und Datenschutzrecht.

Rechtliche Unterstützung bei CRA-Compliance und Cybersicherheit

Wir unterstützen Hersteller, Softwareanbieter, Einführer, Händler und weitere Wirtschaftsakteure dabei, ihren Anwendungsbereich und ihre Rolle nach dem CRA rechtlich einzuordnen, Verantwortlichkeiten in der Lieferkette vertraglich abzubilden und regulatorische Anforderungen in bestehende Compliance-Prozesse zu integrieren. Dabei berücksichtigen wir insbesondere die Meldepflichten nach Art. 14 CRA, Fragen zu Software und Open Source sowie die Überschneidungen mit NIS-2, Datenschutzrecht und KI-Regulierung.

Der Erstkontakt zu SBS LEGAL ist kostenlos.