Der Cyber Resilience Act wird häufig vor allem mit dem Jahr 2027 verbunden. Das ist grundsätzlich nachvollziehbar, denn die meisten Anforderungen der EU-Verordnung gelten ab dem 11. Dezember 2027. Wer daraus ableitet, dass bis dahin noch ausreichend Zeit bleibt, übersieht jedoch einen entscheidenden Punkt: Die CRA-Meldepflichten für bestimmte Schwachstellen und Sicherheitsvorfälle gelten bereits seit dem 11. September 2026. Für betroffene Hersteller bedeutet das, dass sie schon heute in der Lage sein müssen, innerhalb kurzer Fristen eine belastbare Bewertung vorzunehmen und die erforderlichen Informationen zu melden.
Dabei geht es nicht nur um die Nutzung eines Meldeportals. Unternehmen benötigen klare Zuständigkeiten, ein wirksames Schwachstellenmanagement und eine funktionierende Incident Response. Denn die erste Frist beträgt höchstens 24 Stunden ab dem Zeitpunkt, an dem der Hersteller von einem meldepflichtigen Sachverhalt Kenntnis erlangt. Wer erst dann klärt, welche Produkte betroffen sind, wer entscheiden darf und wo die relevanten Informationen liegen, verliert wertvolle Zeit.
Der Cyber Resilience Act gilt nicht erst ab 2027
Der Cyber Resilience Act, die Verordnung (EU) 2024/2847, schafft europaweit verbindliche Cybersicherheitsanforderungen für Produkte mit digitalen Elementen. Erfasst werden grundsätzlich viele Hard- und Softwareprodukte, die direkt oder indirekt mit einem Gerät oder Netzwerk verbunden sind. Dazu können beispielsweise vernetzte Maschinen, IoT-Geräte, Router, Sicherheitskameras, mobile Anwendungen oder eigenständige Softwarelösungen gehören. Ob ein konkretes Produkt tatsächlich in den Anwendungsbereich fällt, muss anhand der Verordnung und der jeweiligen Bereitstellung auf dem EU-Markt geprüft werden.
Die zeitliche Staffelung ist dabei wichtig. Die Verordnung trat bereits im Dezember 2024 in Kraft. Bestimmungen zu den notifizierenden Behörden gelten seit Juni 2026. Die umfassenden Produktanforderungen werden überwiegend ab dem 11. Dezember 2027 anwendbar. Artikel 14 und damit die CRA-Meldepflichten gelten für Hersteller jedoch schon seit dem 11. September 2026.
Diese Pflichten beschränken sich nicht automatisch auf Produkte, die erst ab Ende 2027 neu auf den Markt kommen. Nach den aktuellen Hinweisen der Europäischen Kommission und der ENISA können auch Produkte mit digitalen Elementen betroffen sein, die bereits vorher auf dem Markt bereitgestellt wurden, sofern sie in den Anwendungsbereich der Verordnung fallen. Hersteller sollten ihre Produktportfolios deshalb nicht nur mit Blick auf zukünftige Entwicklungen bewerten.
Welche Ereignisse müssen gemeldet werden?
Nicht jede entdeckte Schwachstelle und nicht jede technische Störung löst automatisch eine Meldung aus. Artikel 14 unterscheidet zwei zentrale Kategorien: aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle mit Auswirkungen auf die Sicherheit eines Produkts mit digitalen Elementen.
Eine aktiv ausgenutzte Schwachstelle liegt vor, wenn verlässliche Anhaltspunkte dafür bestehen, dass ein böswilliger Akteur die Schwachstelle ohne Zustimmung des Systeminhabers tatsächlich ausgenutzt hat. Die bloße theoretische Möglichkeit eines Angriffs oder die Veröffentlichung eines Proof of Concept genügt daher nicht zwangsläufig. Trotzdem muss ein wirksames Schwachstellenmanagement Hinweise aus unterschiedlichen Quellen schnell zusammenführen und bewerten können. Informationen können beispielsweise aus der eigenen Sicherheitsüberwachung, von Kunden, Sicherheitsforschenden, Dienstleistern oder aus öffentlich verfügbaren Warnmeldungen stammen.
Ein schwerwiegender Sicherheitsvorfall betrifft die Sicherheit des Produkts und kann insbesondere dessen Verfügbarkeit, Authentizität, Integrität oder Vertraulichkeit beeinträchtigen. Ob ein Vorfall die gesetzlichen Kriterien erfüllt, muss im Einzelfall anhand seiner Auswirkungen bewertet werden. Genau an dieser Stelle greifen technische Analyse, rechtliche Einordnung und Incident Response ineinander. Ein Unternehmen benötigt ausreichend Informationen, um schnell entscheiden zu können, darf die Bewertung aber auch nicht so lange hinauszögern, bis jedes technische Detail abschließend geklärt ist.
Ein Beispiel aus der Praxis
Ein Hersteller vernetzter Sensoren erhält von einem Kunden Protokolldaten, die auf eine erfolgreiche Ausnutzung einer Schwachstelle in der Geräte-Firmware hindeuten. Zunächst ist unklar, welche Produktversionen betroffen sind und ob weitere Kunden angegriffen wurden. Trotzdem beginnt die Frist nicht erst mit Abschluss der forensischen Untersuchung. Entscheidend ist der Zeitpunkt, zu dem der Hersteller von der aktiv ausgenutzten Schwachstelle Kenntnis erlangt.
In einer solchen Situation muss das Schwachstellenmanagement die Meldung aufnehmen, die betroffenen Produktstände identifizieren und vorhandene Erkenntnisse dokumentieren. Parallel bewertet das Team für Incident Response die technischen Auswirkungen, mögliche Gegenmaßnahmen und die weitere Eskalation. Die verantwortliche Stelle muss anschließend entscheiden, ob die Voraussetzungen der Meldung erfüllt sind und die fristgerechte Übermittlung veranlassen.
24 Stunden, 72 Stunden und der Abschlussbericht
Die CRA-Meldepflichten sehen ein gestuftes Verfahren vor. Die erste Frühwarnung muss ohne unangemessene Verzögerung und spätestens innerhalb von 24 Stunden nach Kenntniserlangung erfolgen. Sie soll zunächst auf das Ereignis aufmerksam machen und enthält nur die zu diesem Zeitpunkt erforderlichen beziehungsweise verfügbaren Angaben.
Innerhalb von höchstens 72 Stunden muss eine weiterführende Meldung folgen. Bei einer aktiv ausgenutzten Schwachstelle sind unter anderem allgemeine Informationen zum betroffenen Produkt, zur Art der Schwachstelle und zur Ausnutzung sowie zu bereits ergriffenen oder möglichen Gegenmaßnahmen relevant. Bei einem schwerwiegenden Sicherheitsvorfall werden zusätzliche Informationen und eine erste Bewertung des Vorfalls benötigt.
Danach ist ein Abschlussbericht vorgesehen. Bei aktiv ausgenutzten Schwachstellen muss dieser spätestens 14 Tage nach Verfügbarkeit einer Korrektur- oder Abhilfemaßnahme eingereicht werden. Bei schwerwiegenden Sicherheitsvorfällen gilt grundsätzlich eine Frist von einem Monat nach der 72-Stunden-Meldung. Diese gestufte Vorgehensweise berücksichtigt, dass innerhalb der ersten 24 Stunden häufig noch kein vollständiges Lagebild vorliegt. Sie entbindet Hersteller jedoch nicht davon, bereits zu Beginn strukturiert und nachvollziehbar zu handeln.
Die Meldungen erfolgen über die von ENISA betriebene Single Reporting Platform. Dort wählen Hersteller das zuständige koordinierende Computer Security Incident Response Team aus. Welches CSIRT zuständig ist, richtet sich grundsätzlich nach der Hauptniederlassung in der EU und danach, wo überwiegend die Entscheidungen zur Cybersicherheit der Produkte getroffen werden. Die organisatorische Vorbereitung umfasst deshalb auch die Klärung, wer im Unternehmen die Meldung technisch abgeben darf und wer bei Abwesenheiten übernimmt.
Warum eine Kontaktliste allein nicht ausreicht
Die 24-Stunden-Frist macht deutlich, dass Meldebereitschaft ein Prozess und kein einzelnes Dokument ist. Eine Kontaktliste kann hilfreich sein, ersetzt aber weder ein belastbares Schwachstellenmanagement noch eine geübte Incident Response. Mehrere Unternehmensbereiche müssen in kurzer Zeit zusammenarbeiten: Produktentwicklung kennt Versionen und Komponenten, IT-Sicherheit analysiert technische Hinweise, Legal oder Compliance bewertet die regulatorischen Anforderungen und die Unternehmenskommunikation bereitet bei Bedarf Informationen für Kunden und Partner vor.
Besonders kritisch sind unklare Übergabepunkte. Erkennt ein Support-Team einen möglichen Angriff, muss festgelegt sein, wann und an wen es den Hinweis eskaliert. Meldet ein externer Sicherheitsforscher eine Schwachstelle, braucht das Unternehmen einen überwachten Eingang und einen definierten Bewertungsprozess. Wird eine Komponente eines Drittanbieters betroffen, muss schnell nachvollziehbar sein, in welchen eigenen Produkten und Versionen sie eingesetzt wird.
Ein belastbares Produktinventar bildet dafür die Grundlage. Es sollte nicht nur Produktnamen enthalten, sondern auch Versionen, Softwarekomponenten, Verantwortliche, Supportzeiträume und relevante Abhängigkeiten abbilden. Eine Software Bill of Materials kann die Analyse unterstützen, weil sie die Zuordnung betroffener Drittkomponenten zu konkreten Produkten erleichtert. Sie ersetzt jedoch nicht die fachliche Bewertung, ob im jeweiligen Fall tatsächlich eine Meldepflicht besteht.
So entsteht echte Meldebereitschaft
Ein praxistauglicher Prozess beginnt mit eindeutig benannten Rollen. Unternehmen sollten festlegen, wer Hinweise entgegennimmt, wer die technische Bewertung verantwortet, wer die rechtliche Entscheidung trifft und wer die Meldung übermittelt. Für jede dieser Rollen werden Vertretungen benötigt. Darüber hinaus sollte dokumentiert sein, welche Informationen in den verschiedenen Meldephasen erforderlich sind und aus welchen Systemen sie beschafft werden können.
Das Schwachstellenmanagement sollte mit dem Produktinventar, der Kundenkommunikation und den Entwicklungsprozessen verbunden sein. Nur so können Verantwortliche erkennen, welche Versionen betroffen sind, welche Abhilfemaßnahmen zur Verfügung stehen und wie Nutzer informiert werden können. Gleichzeitig muss die Incident Response um produktspezifische Szenarien ergänzt werden. Ein klassischer IT-Notfallplan, der ausschließlich die interne Infrastruktur betrachtet, reicht nicht aus, wenn ein Vorfall die Sicherheit ausgelieferter Produkte betrifft.
Regelmäßige Übungen zeigen, ob die festgelegten Abläufe auch unter Zeitdruck funktionieren. Ein geeignetes Szenario könnte mit einer Kundenmeldung über eine mutmaßlich aktiv ausgenutzte Schwachstelle beginnen. Das Team müsste die Plausibilität bewerten, betroffene Produkte identifizieren, den Zeitpunkt der Kenntniserlangung dokumentieren und innerhalb eines simulierten Zeitfensters eine Entscheidung vorbereiten. Dabei werden häufig Lücken sichtbar: fehlende Ansprechpartner, unvollständige Produktdaten, nicht erreichbare Entscheider oder Unsicherheit über den Meldeweg.
Die Ergebnisse solcher Übungen sollten in konkrete Verbesserungsmaßnahmen überführt werden. Der Cyber Resilience Act verlangt zwar keine perfekte Kenntnis aller Einzelheiten innerhalb von 24 Stunden. Er setzt aber voraus, dass Hersteller ohne unangemessene Verzögerung handeln und die jeweils verfügbaren Informationen strukturiert weitergeben können.
Fazit: Die Uhr läuft bereits
Der Cyber Resilience Act ist kein reines Zukunftsthema für Ende 2027. Die ersten operativ besonders anspruchsvollen Pflichten sind bereits wirksam. Seit dem 11. September 2026 müssen betroffene Hersteller aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle innerhalb enger Fristen über die europäische Meldeplattform übermitteln.
Die CRA-Meldepflichten können nur eingehalten werden, wenn Produktinformationen, Zuständigkeiten und Eskalationswege vor einem Ernstfall geklärt sind. Unternehmen sollten deshalb prüfen, ob relevante Hinweise zuverlässig erkannt werden, wer die Meldepflicht bewertet, wie der Zeitpunkt der Kenntniserlangung dokumentiert wird und wer eine Meldung fristgerecht einreichen kann.
Syngenity® GmbH unterstützt Organisationen dabei, die Anforderungen der europäischen Verordnung strukturiert in bestehende Sicherheits- und Compliance-Prozesse zu integrieren. Dazu gehören die Bewertung der Betroffenheit, die Gestaltung klarer Rollen und Eskalationswege sowie die Weiterentwicklung von Vulnerability- und Incident-Management-Prozessen.
Denn Meldebereitschaft entsteht nicht erst dann, wenn die 24-Stunden-Frist bereits läuft. Die entscheidende Frage lautet daher: Wäre Ihr Unternehmen heute in der Lage, innerhalb von 24 Stunden die richtige Entscheidung zu treffen und die notwendigen Schritte einzuleiten?
