Mit dem Cyber Resilience Act (CRA) führt die Europäische Union verbindliche Anforderungen an die Cybersicherheit von Produkten mit digitalen Elementen ein. Ziel der Verordnung ist es, die Sicherheit digitaler Produkte über ihren gesamten Lebenszyklus hinweg zu verbessern – von der Entwicklung und Herstellung bis zur Nutzung und Wartung.

 

Für Unternehmen bedeutet der CRA mehr als zusätzliche technische Anforderungen. Insbesondere die neuen Meldepflichten bringen organisatorische Veränderungen mit sich. Betroffene Hersteller müssen in der Lage sein, sicherheitsrelevante Schwachstellen und bestimmte Vorfälle innerhalb sehr kurzer Fristen zu bewerten und zu melden.

 

Ein wichtiger Stichtag ist dabei der 11. September 2026. Ab diesem Zeitpunkt gelten die ersten Meldepflichten des CRA. Die vollständige Anwendung weiterer Anforderungen erfolgt zu einem späteren Zeitpunkt.

 

Für Unternehmen ist deshalb jetzt der richtige Zeitpunkt, bestehende Sicherheits- und Meldeprozesse zu überprüfen.

 

 

Welche Unternehmen sind betroffen?

 

Der Cyber Resilience Act richtet sich insbesondere an Hersteller von Produkten mit digitalen Elementen. Dazu gehören nicht nur klassische IT-Produkte. Auch vernetzte Geräte, industrielle Steuerungen, IoT-Produkte, Netzwerkkomponenten oder Software können in den Anwendungsbereich fallen.

 

Für viele Unternehmen ist die Abgrenzung allerdings nicht auf den ersten Blick eindeutig. Ein Maschinenbauunternehmen kann beispielsweise neben der eigentlichen Maschine auch Software oder digitale Steuerungskomponenten entwickeln und vertreiben. Ein Anbieter einer spezialisierten Softwarelösung kann ebenfalls als Hersteller im Sinne des CRA gelten.

 

Darüber hinaus können Unternehmen unter bestimmten Voraussetzungen auch dann in die Rolle des Herstellers gelangen, wenn sie Produkte unter ihrem eigenen Namen oder ihrer eigenen Marke auf den Markt bringen oder bestehende Produkte wesentlich verändern.

 

Deshalb sollte die eigene Rolle innerhalb der Lieferkette frühzeitig geprüft werden. Eine saubere rechtliche und organisatorische Einordnung schafft die Grundlage dafür, die weiteren Anforderungen richtig umzusetzen.

 

 

Neue Meldepflichten ab September 2026

 

Eine der wesentlichen Neuerungen betrifft die Meldung bestimmter Sicherheitsereignisse. Ab dem 11. September 2026 müssen betroffene Hersteller insbesondere aktiv ausgenutzte Schwachstellen sowie schwerwiegende Sicherheitsvorfälle im Zusammenhang mit ihren Produkten melden. Die Anforderungen unterscheiden sich damit von einem klassischen Incident-Management innerhalb des eigenen Unternehmens.

 

Ein Sicherheitsvorfall kann zunächst ein internes IT-Problem sein. Sobald ein betroffenes Produkt unter den CRA fällt und die entsprechenden Voraussetzungen erfüllt sind, können daraus zusätzlich regulatorische Meldepflichten entstehen. Das macht eine schnelle Bewertung erforderlich. Unternehmen müssen nicht nur feststellen können, dass ein Sicherheitsproblem besteht. Sie müssen auch beurteilen können, ob es sich um einen Sachverhalt handelt, der nach den Vorgaben des CRA gemeldet werden muss. Die kurzen Fristen erhöhen den organisatorischen Druck Besonders relevant sind die vorgesehenen Meldefristen.

 

Für bestimmte Meldungen gilt eine erste Frist von 24 Stunden ab Kenntnis der aktiv ausgenutzten Schwachstelle beziehungsweise des entsprechenden Sicherheitsvorfalls. Innerhalb von 72 Stunden ist eine weitergehende Meldung erforderlich. Je nach Art des Vorfalls können anschließend weitere Informationen und ein Abschlussbericht notwendig werden. Diese Fristen sind aus organisatorischer Sicht anspruchsvoll.

 

Bei einem Cybervorfall müssen zunächst technische Informationen gesammelt und bewertet werden. Gleichzeitig muss geklärt werden, welche Systeme oder Produkte betroffen sind und welche Auswirkungen bestehen.

Parallel dazu laufen häufig weitere Prozesse. Die Geschäftsführung muss informiert werden, Kunden oder Geschäftspartner benötigen möglicherweise Informationen und bei bestimmten Vorfällen können zusätzliche gesetzliche Meldepflichten relevant werden. Ein Unternehmen, das erst in dieser Situation beginnt, Zuständigkeiten und Abläufe festzulegen, verliert wertvolle Zeit.

 

 

Incident Response muss regulatorische Anforderungen berücksichtigen

 

Ein professioneller Incident-Response-Prozess sollte deshalb künftig nicht ausschließlich technisch betrachtet werden. Die klassische Frage lautet häufig: Wie erkennen wir einen Angriff und wie bekommen wir unsere Systeme wieder unter Kontrolle? Für betroffene Hersteller kommt eine weitere Ebene hinzu. Es muss frühzeitig bewertet werden, welche regulatorischen Anforderungen mit dem Vorfall verbunden sind.

 

Dazu gehören unter anderem:

• technische Erkennung und Bewertung des Vorfalls
• Bewertung der betroffenen Produkte
• Einschätzung der Schwere und möglichen Auswirkungen
• Prüfung einer möglichen Meldepflicht
• Festlegung der verantwortlichen Personen
• interne Eskalation
• Vorbereitung und Abgabe der erforderlichen Meldungen
• Dokumentation des gesamten Vorgangs
• Nachbereitung und gegebenenfalls Erstellung weiterer Berichte

 

Diese Prozesse sollten nicht voneinander getrennt betrachtet werden. Ein funktionierendes Incident Management verbindet technische, organisatorische und rechtliche Aspekte.

 

 

Besonders wichtig: klare Verantwortlichkeiten

 

In vielen Unternehmen gibt es für technische Sicherheitsvorfälle bereits etablierte Abläufe. Die IT-Abteilung oder ein externer Dienstleister übernimmt die Analyse, isoliert betroffene Systeme und versucht, die Ursache des Vorfalls zu identifizieren. Die regulatorische Bewertung ist dagegen häufig weniger eindeutig geregelt. Genau hier kann es zu Verzögerungen kommen. Die IT verfügt möglicherweise über die technischen Informationen, ist aber nicht für die rechtliche Bewertung zuständig. Die Geschäftsführung trägt die Verantwortung, verfügt im ersten Moment aber nicht über alle notwendigen Details. Datenschutz, Informationssicherheit, Compliance und Rechtsabteilung können wiederum unterschiedliche Aufgaben übernehmen. Deshalb sollte bereits im Vorfeld festgelegt werden, wer welche Rolle übernimmt. Auch Vertretungsregelungen gehören dazu. Ein Meldeprozess, der nur funktioniert, wenn eine bestimmte Person erreichbar ist, ist für zeitkritische Vorfälle nicht ausreichend. Der CRA sollte mit bestehenden Prozessen verbunden werden. Der Cyber Resilience Act steht nicht isoliert neben anderen gesetzlichen Anforderungen. Ein Unternehmen kann gleichzeitig verschiedenen regulatorischen Vorgaben unterliegen.

 

Je nach Unternehmensstruktur und Vorfall können beispielsweise Anforderungen aus der DSGVO oder NIS2 relevant werden. Dadurch entstehen Überschneidungen. Ein Cyberangriff kann beispielsweise personenbezogene Daten betreffen und gleichzeitig Auswirkungen auf ein digitales Produkt haben. In diesem Fall können unterschiedliche Meldepflichten mit unterschiedlichen Fristen und Anforderungen nebeneinander bestehen. Ein zentraler Incident-Response-Prozess schafft hier deutlich mehr Sicherheit als mehrere voneinander getrennte Abläufe. Dabei geht es nicht darum, für jede gesetzliche Vorgabe einen komplett neuen Prozess zu entwickeln. Sinnvoller ist eine gemeinsame Struktur, in der die jeweiligen regulatorischen Anforderungen berücksichtigt werden.

 

 

Was Unternehmen jetzt konkret vorbereiten können

 

Die Vorbereitung muss nicht zwangsläufig mit einem umfangreichen Projekt beginnen. Ein erster Schritt besteht darin, die eigenen Produkte und Dienstleistungen hinsichtlich ihrer möglichen Einordnung unter den CRA zu bewerten. Anschließend sollten die bestehenden Prozesse betrachtet werden. Ein praxisorientierter Check umfasst beispielsweise folgende Punkte:

 

Produktportfolio prüfen:
Welche Produkte enthalten digitale Komponenten oder Software? Welche davon werden unter eigener Marke angeboten?

 

Verantwortlichkeiten definieren:
Welche Personen übernehmen die technische Analyse, die regulatorische Bewertung und die Kommunikation?

 

Meldewege festlegen:
Welche interne Stelle entscheidet über eine mögliche CRA-Meldung und wer ist zur Abgabe berechtigt?

 

Erreichbarkeit sicherstellen:
Sind die zuständigen Personen auch außerhalb der üblichen Geschäftszeiten erreichbar?

 

Informationen vorbereiten:
Welche technischen Informationen werden bei einem Vorfall benötigt und wie können diese innerhalb kurzer Zeit zusammengestellt werden?

 

Schnittstellen zu anderen Pflichten prüfen:
Bestehen Überschneidungen mit DSGVO, NIS2 oder anderen regulatorischen Anforderungen?

 

Prozess testen:
Ein Tabletop-Exercise oder ein simuliertes Szenario kann Schwachstellen im Ablauf sichtbar machen, bevor ein echter Vorfall eintritt.

 

Gerade der letzte Punkt wird in der Praxis häufig unterschätzt.

 

Ein Prozess kann auf dem Papier vollständig aussehen und trotzdem im Ernstfall nicht funktionieren. Erst eine realistische Simulation zeigt, ob Informationen tatsächlich schnell verfügbar sind, ob die richtigen Personen eingebunden werden und ob Entscheidungen innerhalb der erforderlichen Zeit getroffen werden können.

 

 

Cybersecurity wird zunehmend zur Managementaufgabe

 

Der Cyber Resilience Act steht für eine Entwicklung, die sich bereits seit einigen Jahren beobachten lässt. Cybersicherheit wird zunehmend nicht mehr ausschließlich als technisches Thema betrachtet. Gesetzgeber und Behörden erwarten von Unternehmen strukturierte Prozesse, klare Verantwortlichkeiten und einen nachvollziehbaren Umgang mit Sicherheitsrisiken. Für die Geschäftsführung bedeutet das auch, Cybersecurity stärker als Bestandteil des Risikomanagements zu verstehen. Besonders bei Unternehmen, die eigene digitale Produkte entwickeln oder vertreiben, reicht es langfristig nicht aus, lediglich die interne IT-Infrastruktur abzusichern. Auch die Sicherheit der Produkte selbst, das Schwachstellenmanagement, die Kommunikation mit Kunden und die Reaktion auf Sicherheitsvorfälle gehören zunehmend zum Verantwortungsbereich des Unternehmens.

 

Der September sollte nicht der Beginn der Vorbereitung sein Der 11. September 2026 ist deshalb mehr als ein weiterer Termin im Kalender. Für betroffene Unternehmen sollte dieser Stichtag der Anlass sein, bestehende Prozesse auf ihre Praxistauglichkeit zu überprüfen. Dabei muss nicht jede Einzelheit von Anfang an perfekt umgesetzt sein. Entscheidend ist zunächst, dass die grundlegenden Strukturen vorhanden sind. Dazu gehören insbesondere klare Zuständigkeiten, definierte Eskalationswege, eine belastbare technische Erkennung von Sicherheitsvorfällen und eine Verbindung zwischen IT, Informationssicherheit, Management und den zuständigen Compliance- oder Rechtsfunktionen. Die Erfahrung aus der Praxis zeigt: Im Ernstfall ist nicht die fehlende Information das größte Problem, sondern häufig die fehlende Abstimmung. Wenn mehrere Abteilungen zunächst klären müssen, wer verantwortlich ist, welche Informationen benötigt werden und welche Schritte einzuleiten sind, verstreicht schnell wertvolle Zeit.

 

 

Fazit

 

Der Cyber Resilience Act bringt neue Anforderungen an Hersteller digitaler Produkte. Besonders die ab September 2026 geltenden Meldepflichten verlangen eine gute Vorbereitung. Die technischen Sicherheitsmaßnahmen bleiben dabei eine wichtige Grundlage. Entscheidend wird jedoch zunehmend die Verbindung zwischen Technik, Organisation und Management.

 

Unternehmen sollten deshalb ihre bestehenden Incident-Response-Prozesse jetzt überprüfen und um die Anforderungen des CRA ergänzen. Ein belastbarer Prozess schafft im Ernstfall nicht nur rechtliche Sicherheit. Er sorgt vor allem dafür, dass ein Unternehmen auch unter hohem Zeitdruck handlungsfähig bleibt.