Eine konkrete Pflicht, nicht die vollständige Anwendung des CRA

Am 11. September 2026 begann die Meldepflicht des Cyber Resilience Act (CRA) für Hersteller zu gelten. Sie müssen aktiv ausgenutzte Schwachstellen und bestimmte schwerwiegende Vorfälle melden, die die Sicherheit von Produkten mit digitalen Elementen beeinträchtigen. Das Datum ist wichtig, sollte aber genau eingeordnet werden: Es bedeutet weder, dass an diesem Tag sämtliche Pflichten der Verordnung begonnen haben, noch dass jedes Sicherheitsproblem automatisch über diesen Weg zu melden ist. Der unmittelbare Anwendungsbereich ist enger und hängt davon ab, ob die im Gesetz vorgesehenen Voraussetzungen erfüllt sind. Mit diesem Stichtag beginnt eine bestimmte Meldepflicht, nicht ein vollständig anwendbares Regelwerk.

Der CRA ist die Verordnung (EU) 2024/2847 und schafft einen europäischen Rahmen für Cybersicherheitsanforderungen an Produkte mit digitalen Elementen. Die Europäische Kommission unterscheidet zwischen Meldungen, die bereits vorgeschrieben sind, und weiteren Bestimmungen, die erst später gelten. Für Produkt-, Sicherheits- und Compliance-Teams besteht die Aufgabe daher nicht darin, jede künftige Pflicht als bereits aktiv anzusehen. Vielmehr müssen sie die meldepflichtigen Fälle erkennen und ein Verfahren schaffen, mit dem diese festgestellt und eskaliert werden können. Eine klare Trennung der Meldephase vom übrigen Zeitplan hilft, sowohl Versäumnisse als auch die Annahme zu vermeiden, jedes Sicherheitsproblem sei automatisch eine gesetzliche Meldung. Dieser Artikel behandelt die anfängliche Pflicht und ihre praktischen Folgen, nicht die vollständige Anwendung der Verordnung.

Für wen die Pflicht gilt und welche Fälle eine Prüfung auslösen sollten

Die derzeit geltende Pflicht betrifft Hersteller von Produkten mit digitalen Elementen, die in den Anwendungsbereich des CRA fallen. Die Leitlinien der Kommission nennen zwei meldepflichtige Fälle: eine aktiv ausgenutzte Schwachstelle und einen schwerwiegenden Vorfall, der sich auf die Sicherheit des Produkts auswirkt. Die Meldepflicht ist daher nicht mit einer allgemeinen Liste von Fehlern, Warnmeldungen oder möglichen Schwachstellen gleichzusetzen. Ein Unternehmen muss prüfen, ob die Tatsachen in die gesetzlichen Kategorien fallen, und die Grundlage seiner Entscheidung dokumentieren. Ein Hinweis kann eine Untersuchung rechtfertigen, ohne bereits die Meldeschwelle zu erreichen. Umgekehrt darf ein meldepflichtiger Fall nicht übersehen werden, nur weil er zunächst wie ein gewöhnliches technisches Problem behandelt wurde.

Der Begriff Hersteller hat eine regulatorische Bedeutung und ist nicht einfach ein anderes Wort für jeden Entwickler oder jedes Team, das an Software mitwirkt. Die Verordnung ordnet Pflichten nach der Rolle des jeweiligen Wirtschaftsakteurs und enthält auch Bestimmungen für Open-Source-Software-Kuratoren. Die Kommission gibt an, dass deren Meldepflichten am 11. Dezember 2027 beginnen, nicht mit dem Start der aktuellen Herstellerphase. Bei Lieferketten, Komponenten Dritter oder Produkten auf Grundlage von Open-Source-Software sollte geklärt werden, wer nach der Verordnung verantwortlich ist, bevor die Meldeaufgabe zugewiesen wird. Die technische Bezeichnung eines Unternehmens ersetzt nicht die Prüfung seiner rechtlichen Rolle. Dabei kann es nötig sein, die Bereitstellung des Produkts auf dem Markt und die nach dem CRA den verschiedenen Beteiligten zugewiesenen Verantwortlichkeiten zu berücksichtigen. Die technische Mitwirkung allein bestimmt nicht die rechtliche Verantwortung.

Welche Meldefristen gelten

Nach Angaben der Kommission umfasst das Verfahren eine Frühwarnung innerhalb von 24 Stunden, nachdem der Hersteller von dem Fall Kenntnis erlangt hat, sowie eine vollständige Meldung innerhalb von 72 Stunden. Außerdem ist ein Abschlussbericht erforderlich; dessen Frist hängt vom Fall ab: Bei aktiv ausgenutzten Schwachstellen spätestens 14 Tage, nachdem eine Abhilfemaßnahme verfügbar ist; bei schwerwiegenden Vorfällen innerhalb eines Monats nach der 72-Stunden-Meldung. Dabei handelt es sich um unterschiedliche Meilensteine und nicht um eine einzige Frist, die ab der Entdeckung berechnet wird. Die einzelnen Schritte ermöglichen eine frühzeitige Information der zuständigen Stellen und zugleich eine Ergänzung der Angaben im Verlauf der Bearbeitung.

Der Bezug auf den Zeitpunkt, zu dem der Hersteller Kenntnis erlangt, macht die internen Abläufe zur Erkennung, Validierung und Eskalation von Hinweisen wichtig. Wartet ein internes Verfahren mit der Einbindung zuständiger Funktionen, bis die gesamte Untersuchung abgeschlossen ist, kann es schwierig werden, die Frühwarnfrist einzuhalten. Zugleich entbindet eine erste Meldung nicht davon, die Angaben zu vervollständigen und gegebenenfalls einen Abschlussbericht einzureichen. Für die Auslegung der Fristen im Einzelfall sind die Verordnung und die offiziellen Anweisungen maßgeblich. Eine operative Reaktion sollte Erstbewertung, vollständige Meldung und Abschluss unterscheiden und für jede Phase Verantwortliche und Aufzeichnungen vorsehen. Die Erfassung des Kenntniszeitpunkts und der Bewertung hilft außerdem, die verschiedenen Meldeschritte einheitlich zu steuern.

Die zentrale Plattform und der Weg einer Meldung

Hersteller reichen Meldungen über die CRA Single Reporting Platform (SRP) ein, die ENISA in Zusammenarbeit mit dem CSIRT-Netzwerk eingerichtet hat. Der Meldekanal ist seit dem 11. September 2026 betriebsbereit. Nach Angaben der Kommission übermittelt der Hersteller die Meldung nur einmal: Sie wird an das CSIRT des Mitgliedstaats weitergeleitet, in dem der Hersteller seine Hauptniederlassung hat, und die Informationen werden, außer unter außergewöhnlichen Umständen, gleichzeitig ENISA zur Verfügung gestellt. So gibt es einen festgelegten Zugang zum Meldesystem, ohne dass Hersteller getrennte Erstmeldungen an sämtliche möglichen Empfänger senden müssen.

Das empfangende CSIRT leitet die Meldung unverzüglich an die anderen CSIRTs weiter, in deren Hoheitsgebiet das Produkt auf dem Markt bereitgestellt wurde. Die Kommission weist auch darauf hin, dass die Weitergabe an andere Teams unter außergewöhnlichen Umständen und aus gerechtfertigten Cybersicherheitsgründen verzögert werden kann. Die Plattform ist daher weder als öffentliche Veröffentlichung noch als Verfahren zu verstehen, bei dem ein Unternehmen alle Empfänger einzeln auswählt. Praktisch sollte das interne Verfahren festlegen, wer eine Meldung vorbereiten darf, wer sie genehmigt und wie die übermittelten Informationen dokumentiert werden. ENISA veröffentlicht Leitmaterial zur Nutzung der Plattform. Diese Hinweise unterstützen die Verwendung des Meldekanals, ersetzen aber nicht die rechtliche Prüfung des Anwendungsbereichs. Die zuständigen Personen sollten im Bedarfsfall auf die SRP zugreifen und sie bedienen können.

Welche Schlussfolgerungen diese Phase nicht zulässt

Dass die Meldepflicht gilt, bedeutet nicht, dass bereits alle materiellen Bestimmungen des CRA anwendbar sind. Als allgemeiner Anwendungsbeginn für den größten Teil der Verordnung ist der 11. Dezember 2027 vorgesehen; die Meldepflicht begann früher. Dieser gestaffelte Zeitplan erklärt, warum ein Unternehmen schon jetzt Meldungen vorbereiten und einreichen muss, während es zugleich an anderen Pflichten arbeitet, deren Anwendungsdatum noch nicht erreicht ist. Die getrennte Betrachtung der Termine ermöglicht eine verlässliche Planung, ohne die laufende Meldearbeit aufzuschieben oder spätere Anforderungen fälschlich als bereits anwendbar darzustellen.

Aus dieser Beschreibung folgt auch nicht, dass jede Organisation, die Code schreibt oder vertreibt, ein Hersteller ist oder dass jeder in der Cloud gehostete Dienst unter den CRA fällt. Die Verordnung bestimmt ihren Anwendungsbereich anhand von Produkten mit digitalen Elementen und bestimmten Funktionen. Außerdem enthält sie besondere Bedingungen für mit einem Produkt verbundene Fernverarbeitungslösungen. Dieser Artikel fasst die anfängliche Meldepflicht zusammen, entscheidet aber keine Einzelfragen der Einstufung, Ausnahmen oder des Zusammenspiels mit anderen EU-Vorschriften. Liegt ein Produkt oder Geschäftsmodell an der Grenze des rechtlichen Anwendungsbereichs, müssen der Verordnungstext und die einschlägigen offiziellen Klarstellungen geprüft werden. Allgemeine Orientierung kann die Prüfung unterstützen, ersetzt aber nicht die Analyse des konkreten Falls.

Was Unternehmen jetzt vorbereiten sollten

Eine sinnvolle Vorbereitung kann mit einer Übersicht der Produkte beginnen, die auf dem EU-Markt bereitgestellt werden, der dafür verantwortlichen Hersteller und der Kanäle, über die Schwachstellen- und Vorfallmeldungen eingehen. Anschließend kann das Unternehmen Eskalationskriterien festlegen, anhand derer sich rasch prüfen lässt, ob ein Fall möglicherweise eine aktive Ausnutzung oder einen schwerwiegenden Vorfall mit Auswirkungen auf die Produktsicherheit betrifft. Diese Arbeit setzt nicht voraus, dass jeder Hinweis gemeldet werden muss. Sie soll sicherstellen, dass die Entscheidung rechtzeitig die richtigen Personen erreicht und relevante Informationen beim Übergang zwischen Technik, Sicherheit, Recht und Compliance nicht verloren gehen.

Sinnvoll ist außerdem, Zuständigkeiten für die Bewertung des Falls, die Zusammenstellung technischer Informationen, die Prüfung des Meldeinhalts und die Einreichung über die SRP festzulegen. Der Zeitpunkt der Kenntniserlangung und die getroffenen Entscheidungen sollten dokumentiert werden, denn die offiziellen Fristen laufen ab dieser Kenntnis und Meldungen umfassen mehrere Schritte. Schließlich sollte der Compliance-Kalender den bereits geltenden Stichtag 11. September 2026 von den Pflichten unterscheiden, die am 11. Dezember 2027 beginnen. Ein praktischer Ausgangspunkt ist, den Anwendungsbereich zu prüfen, den Entscheidungsablauf zu erproben und die offiziellen ENISA-Anweisungen zur Plattform heranzuziehen. Unternehmen sollten weder von einer allgemeinen Meldepflicht für jeden Fall ausgehen noch bis zum letzten Moment warten, um Verantwortliche zu bestimmen.