Cyber Resilience Act: Wer sein Produkt nicht kennt, kann es nicht melden

Im Dezember 2021 saßen IT-Verantwortliche in halb Europa vor derselben Frage. Die kleine, allgegenwärtige Java-Bibliothek zur Protokollierung Log4j enthielt eine Schwachstelle, über die speziell präparierte Eingaben die Ausführung fremden Codes ermöglichen konnten, sie ging als Log4Shell in die Geschichte ein. Bevor Unternehmen sie schließen konnten, mussten viele allerdings erst eine viel banalere Frage beantworten: Steckt Log4j überhaupt irgendwo in unserem Produkt? Log4j saß in Unternehmenssoftware oft tief in transitiven Abhängigkeiten, in fremdem Code, den niemand im eigenen Haus geschrieben hatte, und den entsprechend auch niemand auf dem Schirm hatte. Manche Antworten auf diese Frage dauerten Wochen.

Genau an diesem Punkt setzt der Cyber Resilience Act an, dessen erste Meldepflicht seit dem 11. September 2026 gilt. Wer beim Klang der Verordnung zuerst an Formulare und Fristen denkt, hat recht, aber am Ende geht es um eine einfachere Frage: Weiß ein Unternehmen überhaupt, was in seinem eigenen Produkt steckt?

Auf einen Blick

Der Cyber Resilience Act, offiziell Verordnung (EU) 2024/2847, verpflichtet Hersteller von Produkten mit digitalen Elementen zu grundlegenden Cybersicherheitsstandards, und das für Hardware ebenso wie für Software. Verlangt wird unter anderem secure by design und secure by default, eine maschinenlesbare Software-Stückliste, die mindestens die direkten beziehungsweise Top-Level-Abhängigkeiten abdeckt, sowie ein wirksames Schwachstellenmanagement über den festgelegten Supportzeitraum, grundsätzlich mindestens fünf Jahre (1). Der CRA führt diese Cybersicherheitsanforderungen dabei neu in das europäische CE-Konformitätssystem ein; für die Standardkategorie reicht dafür regelmäßig eine interne Bewertung, extern geprüft wird erst bei bestimmten wichtigen und kritischen Produktklassen.

Vollständig greifen diese Pflichten, SBOM und Konformitätsbewertung eingeschlossen, erst ab dem 11. Dezember 2027, Konformitätsbewertungsstellen können bereits seit dem 11. Juni 2026 notifiziert werden. Zwischen beiden Daten liegt eine einzelne, vorgezogene Pflicht: Ab dem 11. September 2026 muss der Hersteller aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle melden, obschon der Rest der Verordnung noch gar nicht greift.

Genau in dieser Übergangsphase liegt eine Pointe, mit der vorher kaum jemand gerechnet hatte. Die Meldepflicht nach Artikel 14 gilt nämlich nicht nur für Produkte, die ab jetzt auf den Markt kommen, sie erfasst laut Artikel 69 Absatz 3 der Verordnung auch jedes Produkt, das längst ausgeliefert ist (1).

Ein Router aus dem Jahr 2020, eine Steuerungssoftware aus der Pandemie, eine Fachanwendung, die seit Jahren unverändert läuft: Sobald darin eine Schwachstelle aktiv ausgenutzt wird und der Hersteller davon Kenntnis erlangt, beginnt die 24-Stunden-Frist. Die Kommission benennt das damit verbundene Problem selbst recht offen: Werkzeuge zum Scannen alter Software existieren mitunter nicht mehr, Build-Umgebungen sind nicht mehr rekonstruierbar, Abhängigkeiten fehlen oder sind inkompatibel geworden, und die Entwickler, die den Code einmal kannten, haben das Unternehmen häufig längst verlassen (2). Melden muss ein Hersteller trotzdem.

Die übrigen CRA-Pflichten gelten für solche Altprodukte dagegen grundsätzlich nicht rückwirkend, solange sie nach dem 11. Dezember 2027 nicht wesentlich verändert werden. Ausgerechnet die Produkte, für die der CRA womöglich nie eine nachträgliche Software-Stückliste verlangt, müssen also seit dem 11. September 2026 binnen 24 Stunden beurteilt werden können.

Die Meldepflicht folgt einem gestaffelten Fahrplan: eine Frühwarnung innerhalb von 24 Stunden nach Kenntnisnahme, eine detaillierte Meldung nach 72 Stunden, ein Abschlussbericht spätestens 14 Tage nach Verfügbarkeit einer Korrektur- oder Risikominderungsmaßnahme bei einer aktiv ausgenutzten Schwachstelle, bei einem schwerwiegenden Sicherheitsvorfall innerhalb eines Monats nach der 72-Stunden-Meldung.

Die 24 Stunden beginnen dabei nicht mit jedem Schwachstellenverdacht: Meldepflichtig wird eine Schwachstelle, sobald dem Hersteller verlässliche Nachweise dafür vorliegen, dass sie tatsächlich von einem böswilligen Akteur ausgenutzt wurde, ein bloßer Bug-Bounty-Fund ohne solche Hinweise genügt noch nicht. Parallel dazu muss der Hersteller auch die betroffenen, im Zweifel alle Nutzer ohne unnötige Verzögerung informieren, mit ausreichend Angaben, um selbst Schutzmaßnahmen zu ergreifen.

Gemeldet wird einmalig über die von ENISA betriebene Single Reporting Platform. Die Meldung geht an das zuständige koordinierende CSIRT, in Deutschland das CERT-Bund beim BSI, und gleichzeitig an ENISA; das empfangende CSIRT übernimmt bei Bedarf die weitere Verteilung an andere betroffene nationale CSIRTs (3). Wer die Fristen versäumt, riskiert Bußgelder von bis zu 15 Millionen Euro oder 2,5 Prozent des weltweiten Jahresumsatzes, wobei Kleinst- und Kleinunternehmen von Bußgeldern gerade für die 24-Stunden-Frühwarnung ausgenommen sind (1).

Für das BSI bedeutet der CRA einen geplanten Rollenwechsel: Der Regierungsentwurf zur Durchführung der Verordnung sieht das Amt als zentrale Marktüberwachungsbehörde für vernetzte Produkte vor, mit 95 neuen Stellen allein für 2026, ansteigend auf 141 bis 2029, und rund zehn Millionen Euro für Meldesysteme und ein sogenanntes Reallabor (4). Das Gesetzgebungsverfahren dazu läuft noch, nach erster Lesung im Bundestag und Überweisung an die Ausschüsse; die Rolle des CERT-Bund als koordinierende Stelle für eingehende CRA-Meldungen steht davon unabhängig bereits fest.

Wer bereits mit NIS2 zu tun hatte, kennt Meldefristen dieser Art bereits, nur dass beide Verordnungen unterschiedliche Adressaten haben. NIS2 verpflichtet, je nach BSIG-Einstufung, besonders wichtige und wichtige Einrichtungen zu Risikomanagement, Betreiber kritischer Anlagen sind darunter nur eine Teilgruppe, und die Geschäftsleitung haftet der eigenen Einrichtung, wenn sie diese Pflichten schuldhaft versäumt.

NIS2 knüpft an die Organisation und ihre Tätigkeit an, der CRA primär an das Produkt und dessen Bereitstellung auf dem Markt: Meldepflichtig nach Artikel 14 ist grundsätzlich der Hersteller. Importeure und Vertreiber müssen bekannt gewordene Schwachstellen unverzüglich an ihn weitergeben und bei erheblichen Cybersicherheitsrisiken zusätzlich die Marktüberwachung informieren; vertreiben sie ein Produkt unter eigenem Namen oder verändern sie es wesentlich, können sie selbst als Hersteller gelten. Ein Anbieter von Gebäudetechnik etwa kann von NIS2 komplett unberührt bleiben und trotzdem, sobald er einen Sensor oder eine Steuerungssoftware unter eigenem Namen vertreibt, als Hersteller mitten im CRA stehen.

Die Fristen selbst sind knapp, aber lernbar. Schwerer wiegt, was ihnen vorausgehen muss: die Erkennung, ob eine Schwachstelle tatsächlich aktiv ausgenutzt wird, und die Klärung, wer diese Einschätzung intern treffen darf. Eine Analyse des Sicherheitsunternehmens Cycode beobachtet aus der Praxis genau diese Eskalationswege als eine der größten Lücken, neben lückenhaften Produktinventaren (5).

Eine Software-Stückliste beantwortet dabei aber nur die halbe Frage. Sie zeigt, welche Komponente irgendwo steckt, noch nicht, ob sich die konkrete Schwachstelle unter den tatsächlichen Betriebsbedingungen des eigenen Produkts überhaupt ausnutzen lässt. Eine betroffene Bibliothek kann also Bestandteil eines Produkts sein, ohne dass sich die Schwachstelle darin tatsächlich ausnutzen lässt, etwa weil der betroffene Code gar nicht aufgerufen wird oder kompensierende Schutzmaßnahmen greifen; eine verpflichtende Meldung entsteht dann nicht (2). Zu wissen, dass Log4j irgendwo steckt, reicht deshalb nicht. Produktwissen heißt am Ende: Komponente, Version, Abhängigkeit, ausgelieferte Produktversion und tatsächliche Ausnutzbarkeit, dazu die interne Klarheit, wer diese Informationen im Ernstfall zusammenträgt.

Diese Wissenslücke trifft künftig nicht nur historisch gewachsene Produkte. Wer mit einem KI-Codeassistenten Software erzeugt, ohne selbst über nennenswerte Programmierkenntnisse zu verfügen, ist im eigenen Produkt von Anfang an nicht Herr im eigenen Haus. Vor dem produktiven Einsatz eines auf diese Weise entstandenen Codes lohnt sich deshalb der Blick einer erfahrenen Entwicklung, die Abhängigkeiten, Schwachstellen und Meldewege von vornherein mitdenkt.

Betroffene Hersteller kommen an vier Fragen nicht vorbei, unabhängig von Branche und Größe: Wer entscheidet innerhalb weniger Stunden, ob vorliegende Hinweise bereits als belastbarer Beleg für eine aktive Ausnutzung gelten, und wer setzt danach die Meldung in Gang? Existiert eine aktuelle Software-Stückliste für jedes ausgelieferte Produkt, oder wird sie im Ernstfall erst zusammengesucht?

Lässt sich nachvollziehen, welche ausgelieferten Produktversionen bei welchen Kunden betroffen sind, und wer diese Nutzer kurzfristig informieren kann? Und sind Zuständigkeit, Zugang und Meldeweg über die Single Reporting Platform bereits eingerichtet, oder wird das alles erst in der ersten Stunde eines echten Vorfalls geklärt? Wer diese Fragen heute beantworten kann, hat zumindest die Voraussetzung geschaffen, unter Zeitdruck handlungsfähig zu bleiben. Die 24 Stunden beginnen dann nicht mit einer Inventur.

Nicht jedes Unternehmen, das Software einsetzt, fällt unter diese Meldepflicht, gemeint ist ausdrücklich der Hersteller im funktionalen Sinn des CRA: wer ein Produkt unter eigenem Namen oder eigener Marke im Rahmen einer gewerblichen Tätigkeit bereitstellt. Reine Anwenderunternehmen bleiben außen vor, auch wenn NIS2 sie über eine andere Tür erreichen kann. Eine Ausnahme betrifft freie Software: Wer Software außerhalb einer gewerblichen Tätigkeit frei verfügbar macht, fällt grundsätzlich nicht unter den CRA. Für Verwalter größerer Open-Source-Ökosysteme, sogenannte Open-Source-Stewards, gelten reduzierte Pflichten ohne CE-Kennzeichnung; ihre eigene Meldepflicht beginnt allerdings erst am 11. Dezember 2027, nicht bereits jetzt. Umfangreiche Leitlinien mit 67 Praxisbeispielen hat die EU-Kommission dazu am 27. Juli 2026 veröffentlicht, unter anderem zur Abgrenzung von Anwendungsbereich, wesentlichen Änderungen und Open-Source-Software (6).

Am Ende bleibt von alledem ein einziger Satz übrig, der wichtiger ist als jede Frist: Ein Produkt zu melden setzt voraus, es zu kennen.