CRA-Meldepflichten: Was ab dem 11. September 2026 für dich gilt

Falls du zum ersten Mal vom Cyber Resilience Act hörst, hier die Kurzfassung. Der CRA ist eine EU-Verordnung, die erstmals verbindliche Cybersicherheitsanforderungen für vernetzte Produkte festlegt – also für Hardware und Software, die sich mit einem Gerät oder Netzwerk verbinden lässt, von der App über den Router bis zur Maschinensteuerung. Bisher war die Sicherheit solcher Produkte weitgehend Sache des Herstellers, und entsprechend sah sie oft aus: Standard-Kennwörter ab Werk, Schwachstellen, die nie gepatcht werden. Der CRA dreht das um. Hersteller müssen ihre Produkte künftig sicher entwickeln, ohne bekannte ausnutzbare Lücken ausliefern, über den gesamten Lebenszyklus kostenlos mit Sicherheitsupdates versorgen – und Schwachstellen sowie Vorfälle an die Behörden melden. Das gilt unabhängig von der Unternehmensgröße und trifft neben Herstellern auch Importeure und Händler.

Die Pflichten kommen in zwei Wellen: Ab dem 11. September 2026 gelten die Meldepflichten, ab dem 11. Dezember 2027 die vollen Herstellerpflichten für neue Produkte. In diesem Artikel geht es um die erste Welle – die Meldepflichten –, denn sie betrifft anders als die zweite dein gesamtes heutiges Portfolio. Den Gesamtüberblick über das Gesetz, alle Rollen und Pflichten findest du auf unserer CRA-Themenseite.

In Kraft ist der CRA übrigens schon seit dem 10. Dezember 2024 – lange Zeit allerdings ohne spürbare Folgen. Der Wendepunkt ist der 11. September 2026: Ab diesem Tag greift Artikel 14, und mit ihm die ersten echten Pflichten für alle, die vernetzte Produkte in der EU anbieten. Ein Punkt dabei wird gern übersehen: Anders als die großen Herstellerpflichten, die ab Dezember 2027 nur für neu auf den Markt gebrachte Produkte gelten, treffen die Meldepflichten auch deine Bestandsprodukte. Der Drucker, die App, die Maschinensteuerung, die du seit Jahren verkaufst – für all das musst du meldefähig sein. Einen Bestandsschutz gibt es an dieser Stelle nicht.

Konkret verlangt der CRA zwei Dinge von dir: Du musst selbst an die Behörden melden können, wenn etwas passiert. Und du musst Meldungen von außen entgegennehmen können. Beides schauen wir uns jetzt der Reihe nach an.

Bevor du in Panik verfällst: Nicht jede Schwachstelle löst eine Meldung aus. Der CRA kennt genau zwei meldepflichtige Fälle. Der erste ist die aktiv ausgenutzte Schwachstelle, also eine Lücke in deinem Produkt, die tatsächlich angegriffen wird. Eine Schwachstelle, die einfach nur existiert, musst du beheben, aber nicht an die Behörde melden. Der zweite Fall ist der schwerwiegende Sicherheitsvorfall. Der liegt nach der gesetzlichen Definition vor, wenn die Sicherheit des Produkts beeinträchtigt ist, etwa bei Verfügbarkeit, Integrität oder Vertraulichkeit, oder wenn Schadcode im Spiel ist.

Diese Unterscheidung solltest du in deinem Prozess sauber abbilden, denn sie entscheidet später über die Frist für den Abschlussbericht. Und sie hilft dir, das Meldeaufkommen realistisch einzuschätzen: Meldepflichtig ist der Ernstfall, nicht der Alltag deines Schwachstellenmanagements.

Die Fristen des CRA sind knapper als alles, was du aus der DSGVO kennst. Binnen 24 Stunden ab Kenntnis musst du eine Frühmeldung abgeben. Die ist bewusst schlank gehalten: Welches Produkt ist betroffen, besteht der Verdacht auf böswilliges Handeln, in welchen Mitgliedstaaten wird das Produkt vertrieben. Mehr nicht. Binnen 72 Stunden folgt die ausführlichere Meldung mit der Art der Schwachstelle oder des Vorfalls, einer ersten Einschätzung und den ergriffenen Maßnahmen – das kennst du im Prinzip von der Datenschutzpanne. Danach kommt der Abschlussbericht, und hier greift die Unterscheidung von eben: binnen 14 Tagen bei einer ausgenutzten Schwachstelle, binnen eines Monats nach der 72-Stunden-Meldung bei einem Sicherheitsvorfall.

Die Uhr läuft ab Kenntnis. Wochenenden und Feiertage zählen mit. Wer erst am Montagmorgen ins Postfach schaut, hat von seinen 24 Stunden unter Umständen schon 60 verbraucht. Genau deshalb ist die Meldefähigkeit keine Frage eines Formulars, sondern eine Frage der Organisation: Wer hat Kenntnis, wer bewertet, wer meldet, wer vertritt wen im Urlaub?

Gemeldet wird nicht direkt ans BSI, auch wenn das BSI am Ende deine zuständige Behörde ist. Zentrale Anlaufstelle ist die Single Reporting Platform der ENISA, der Cybersicherheitsagentur der EU, kurz SRP. Dort wählst du dein nationales CSIRT aus – für Deutschland das BSI – und deine Meldung geht gleichzeitig an das BSI und an die ENISA, die daraus ein europäisches Lagebild erstellt. Das ist eine echte Erleichterung gegenüber der DSGVO mit ihren 18 Aufsichtsbehörden und 18 Formularen: eine Plattform, ein Prozess, für alle Unternehmen in Europa. Eine Vorab-Registrierung wie bei NIS-2 ist nicht vorgesehen.

Lass dich von der Plattform aber nicht in falscher Sicherheit wiegen: Die SRP ist nur der letzte Schritt in der Kette. Die internen Zuständigkeiten, die Bewertungslogik und die Fristenüberwachung davor musst du selbst aufbauen – und genau das ist der Teil, der Zeit kostet.

Melden können ist die eine Hälfte. Die andere: Du musst selbst erreichbar sein. Der CRA verlangt eine sogenannte CVD-Kontaktstelle, eine Anlaufstelle für Coordinated Vulnerability Disclosure – und zwar ebenfalls ab dem 11. September 2026 und auch für Bestandsprodukte. Dahinter steckt ein einfacher Gedanke. Wenn ein Sicherheitsforscher eine Lücke in deinem Produkt findet, soll er sie dir melden können, statt sie zu veröffentlichen oder zu verkaufen. Dafür brauchst du eine veröffentlichte Kontaktadresse, sinnvollerweise auf deiner Webseite, und einen Prozess dahinter: Meldung annehmen, bewerten, im Zweifel beheben und koordiniert veröffentlichen – also die Beschreibung der Schwachstelle erst dann publik machen, wenn der Patch bereitsteht. Steckt die Lücke in einer Fremdkomponente, die du einsetzt, gibst du die Information an deren Hersteller weiter.

Wichtig ist der Zusammenhang zwischen beiden Pflichten: Eine eingehende CVD-Meldung kann deine eigene Meldepflicht auslösen. Stellt sich heraus, dass die gemeldete Lücke bereits aktiv ausgenutzt wird, tickt ab diesem Moment deine 24-Stunden-Uhr. Der Meldekanal muss deshalb laufend überwacht werden, nicht einmal die Woche.

Ein Punkt noch, bevor es an den Fahrplan geht. Der CRA fügt sich in eine Meldelandschaft ein, die ohnehin schon voll ist. Der CRA schützt das Produkt, NIS-2 die Organisation, die DSGVO die Daten – und ein einziger Vorfall kann alle drei betreffen. Aus der ausgenutzten Schwachstelle im Produkt wird ein IT-Sicherheitsvorfall in deiner Organisation, und wenn dabei personenbezogene Daten abfließen, auch noch eine Datenschutzpanne. Einen integrierten Meldeprozess gibt es bislang nicht. Im ungünstigsten Fall meldest du denselben Sachverhalt dreimal, an unterschiedliche Stellen, binnen unterschiedlicher Fristen. Bau deinen CRA-Meldeprozess deshalb nicht als weiteres Silo, sondern häng ihn an dein bestehendes Incident-Response- und Notfallmanagement an: ein Vorfall, eine Erfassung, danach die Prüfung aller Meldewege.

Was für die Meldefähigkeit zu tun ist, passt auf eine Seite, verlangt aber Entscheidungen. Kläre zuerst deine Betroffenheit: Welche Produkte haben digitale, vernetzte Elemente, und bist du dabei Hersteller, Importeur oder Händler? Richte dann die CVD-Kontaktstelle ein und veröffentliche sie. Definiere den Meldeprozess zur Behörde mit klaren Zuständigkeiten und Vertretungsregeln, und teste ihn einmal trocken durch: Ein fiktiver Fall, von der Kenntnis bis zur 24-Stunden-Meldung. Erstelle, wenn du schon dabei bist, eine CVD-Richtlinie, die den Umgang mit gemeldeten Schwachstellen schriftlich regelt – verpflichtend wird sie erst 2027, aber sie gibt deinem Prozess jetzt die Struktur. Und sensibilisiere deine Mitarbeitenden, denn die 24-Stunden-Frist beginnt mit der Kenntnis irgendeines Mitarbeiters, nicht erst mit der Kenntnis der Geschäftsführung.

Die erste CRA-Welle ist inhaltlich überschaubar: eine Kontaktstelle, ein Meldeprozess, dreieinhalb Fristen. Gefährlich ist sie trotzdem, aus zwei Gründen. Sie gilt ab dem 11. September 2026 auch für Bestandsprodukte, betrifft also nicht erst deine nächste Produktgeneration, sondern dein heutiges Portfolio. Und die 24-Stunden-Frist ab Kenntnis lässt sich nicht improvisieren – sie funktioniert nur mit geklärten Zuständigkeiten, einem überwachten Meldekanal und Mitarbeitenden, die wissen, was im Ernstfall zu tun ist. Der Aufbau kostet Wochen, kein Wochenende. Wer erst im Ernstfall damit beginnt, meldet im Blindflug.

Einen Gesamtüberblick über den CRA mit allen Pflichten, Rollen und Fristen findest du auf unserer CRA-Themenseite. Dort gibt es auch die CRA-Checkliste und eine Vorlage für die CVD-Richtlinie zum Download. Wenn du bei der Betroffenheitsprüfung oder beim Aufbau deines Meldeprozesses Unterstützung brauchst, melde dich gern – und für die Sensibilisierung deiner Mitarbeitenden findest du in der NOVICADEMY passende IT-Sicherheitsschulungen.