Cyber Resilience Act: Meldepflichten und Schwachstellenprozess

Kurzantwort: Was seit September 2026 gilt

Stand 23. September 2026 müssen Hersteller von Produkten mit digitalen Elementen eine aktiv ausgenutzte Schwachstelle oder einen schwerwiegenden Sicherheitsvorfall unter den Voraussetzungen des Artikels 14 der Verordnung (EU) 2024/2847 melden. Die Pflichten gelten seit 11. September 2026. Die meisten übrigen Anforderungen des Cyber Resilience Acts, darunter die umfassenden Produkt- und Konformitätspflichten, werden dagegen erst ab 11. Dezember 2027 anwendbar.

Die Meldung läuft über die von ENISA betriebene zentrale Meldeplattform. Nach Kenntnisnahme ist eine Frühwarnung unverzüglich, spätestens binnen 24 Stunden, und eine vollständige Meldung spätestens binnen 72 Stunden abzugeben. Danach folgt je nach Fall ein Abschlussbericht nach Bereitstellung einer Korrektur- oder Eindämmungsmaßnahme beziehungsweise binnen eines Monats nach der vollständigen Vorfallmeldung.

Dieser Beitrag ordnet den betrieblichen und technischen Ablauf ein und ersetzt keine Rechtsberatung. Ob ein Produkt, eine Rolle oder ein konkretes Ereignis erfasst ist, sollte mit den zuständigen Fach- und Rechtsstellen geprüft werden.

Zuerst Produkt, Herstellerrolle und Marktbezug klären

Der Cyber Resilience Act erfasst Hardware- und Softwareprodukte mit digitalen Elementen, die auf dem Unionsmarkt bereitgestellt werden und deren vorgesehene oder vernünftigerweise vorhersehbare Verwendung eine direkte oder indirekte Datenverbindung zu einem Gerät oder Netzwerk einschließt. Auch separat in Verkehr gebrachte Softwarekomponenten können darunter fallen. Entscheidend ist deshalb nicht, ob ein Unternehmen sich selbst als IT-Anbieter bezeichnet, sondern welche digitalen Produkte es unter eigener Verantwortung bereitstellt.

Der Meldeprozess beginnt mit der Rollenklärung: Wer bringt das betroffene Produkt unter eigenem Namen oder eigener Marke in Verkehr, wer trifft die wesentlichen Sicherheitsentscheidungen und welches Unternehmen ist rechtlich Hersteller? Ein intern genutzter Standarddienst macht das nutzende Unternehmen nicht automatisch zum Hersteller. Wer ein Produkt wesentlich verändert oder unter eigenem Namen weitergibt, benötigt dagegen eine gesonderte Prüfung.

Nach den ENISA-FAQ können die seit September 2026 geltenden Meldepflichten auch Produkte betreffen, die schon vor dem allgemeinen Anwendungsbeginn im Dezember 2027 auf den Markt gebracht wurden. Maßgeblich ist unter anderem, wann der Hersteller von der aktiven Ausnutzung oder dem Vorfall Kenntnis erhält. Diese Übergangsfrage gehört deshalb ausdrücklich in die Ereignisprüfung.

• Produktname, Produktfamilie, Version und unterstützte Betriebsvarianten eindeutig führen
• Herstellerrolle, verantwortliche Gesellschaft und Hauptniederlassung dokumentieren
• Marktbereitstellung in der EU und mögliche Ausnahmen fachkundig prüfen
• verantwortliche Produkt-, Sicherheits-, Rechts- und Kommunikationsrollen benennen

Aktiv ausgenutzte Schwachstelle und schwerwiegenden Vorfall unterscheiden

Eine Schwachstelle ist nicht allein deshalb meldepflichtig, weil ein Scanner sie findet oder eine Bibliothek eine Sicherheitswarnung veröffentlicht. Für die erste Fallgruppe verlangt die Verordnung verlässliche Hinweise darauf, dass ein böswilliger Akteur die Schwachstelle ohne Erlaubnis des Systemeigentümers ausgenutzt hat. Das Team muss daher Quelle, Vertrauensniveau, betroffene Produktversion und Hinweise auf tatsächliche Ausnutzung getrennt erfassen.

Die zweite Fallgruppe betrifft schwerwiegende Vorfälle, die sich auf die Sicherheit eines Produkts mit digitalen Elementen auswirken. Artikel 14 nennt Auswirkungen auf Verfügbarkeit, Authentizität, Integrität oder Vertraulichkeit. Reine Störungen ohne ausreichenden Produkt- und Sicherheitsbezug sind nicht automatisch CRA-meldepflichtig; zugleich darf ein potenziell relevanter Fall nicht in einer allgemeinen IT-Störungswarteschlange liegen bleiben.

Die Entscheidung sollte anhand eines dokumentierten Kriterienbaums erfolgen. Er hält Tatsachen, Unsicherheiten, Quellen und Verantwortliche fest. Auch eine begründete Nichtmeldung benötigt einen nachvollziehbaren Stand, weil neue Erkenntnisse die Bewertung ändern können.

• Was ist betroffen: Produkt, Version, Komponente, Dienst oder interne IT?
• Welche verlässlichen Hinweise belegen eine tatsächliche böswillige Ausnutzung?
• Welche Sicherheitswirkung trat ein und wie groß ist ihr Umfang?
• Wann erreichte die Information eine zuständige Herstellerfunktion?
• Welche Annahmen sind noch offen und bis wann werden sie überprüft?

24 Stunden, 72 Stunden und Abschlussbericht als eine Fristenkette steuern

Die Fristen beginnen mit der Kenntnisnahme des Herstellers, nicht erst mit einer vollständig abgeschlossenen technischen Analyse. Deshalb muss der Prozess einen belastbaren Awareness-Zeitpunkt festhalten und die Entscheidung sofort an die zuständigen Rollen eskalieren. Fehlende Details werden in der Frühwarnung als vorläufiger Stand behandelt und später ergänzt; sie dürfen nicht zum unkontrollierten Abwarten führen.

Die Frühwarnung muss unverzüglich, spätestens binnen 24 Stunden, übermittelt werden. Spätestens binnen 72 Stunden folgt die vollständige Meldung mit den dann verfügbaren Informationen, einer Bewertung und bereits ergriffenen Korrektur- oder Eindämmungsmaßnahmen. Bei einer aktiv ausgenutzten Schwachstelle ist der Abschlussbericht spätestens 14 Tage nach Verfügbarkeit einer Korrektur- oder Eindämmungsmaßnahme fällig; bei einem schwerwiegenden Vorfall spätestens einen Monat nach der vollständigen 72-Stunden-Meldung.

Interne Zielzeiten sollten vor den gesetzlichen Maximalfristen liegen. Beispielsweise kann ein Triage-Slot unmittelbar nach Eingang, eine Meldeentscheidung innerhalb weniger Stunden und eine zweite fachliche Prüfung vor Abgabe vorgesehen werden. Maßgeblich bleiben die gesetzlichen Fristen und der konkrete Fall.

• T0: Awareness-Zeitpunkt, Quelle und verantwortliche Person unveränderbar protokollieren
• bis 24 Stunden: Frühwarnung mit bekanntem Mindeststand einreichen
• bis 72 Stunden: vollständige Meldung mit Bewertung und Maßnahmen aktualisieren
• danach: Abhilfe, Kommunikation und Abschlussbericht fristgerecht nachführen

ENISA-Plattform, CSIRT und vertretungsberechtigte Konten vorbereiten

Die Meldung erfolgt über die CRA Single Reporting Platform von ENISA. Dort wählt der Hersteller ein benanntes koordinierendes Computer Security Incident Response Team aus. Nach der ENISA-Einordnung richtet sich die Zuordnung grundsätzlich nach der Hauptniederlassung, an der überwiegend die produktbezogenen Cybersicherheitsentscheidungen getroffen werden. Ein Ereignis wird über die Plattform nur einmal gemeldet, auch wenn mehrere Niederlassungen oder Märkte betroffen sind.

Für die Registrierung ist ein persönliches EU-Login mit Mehrfaktor-Authentifizierung erforderlich. Eine Organisation kann eine primäre und weitere sekundäre autorisierte Vertretungen hinterlegen. Entwürfe sind laut ENISA-FAQ nur für das jeweils angemeldete Konto sichtbar. Deshalb darf ein kritischer Meldungsentwurf nicht ausschließlich im persönlichen Browserkonto einer einzelnen Person existieren; intern braucht es einen gemeinsam kontrollierten Fallstand und Vertretungsregeln.

Zum Start stellt die Plattform keine Programmierschnittstelle bereit. Automatisiert werden können interne Signalerfassung, Produktzuordnung, Fristen, Freigaben und die Vorbereitung konsistenter Angaben. Die eigentliche Übermittlung wird als menschlich kontrollierter Schritt in der Weboberfläche geplant. Bei einer Plattformstörung bleibt der Fall intern fristfest dokumentiert; ENISA beschreibt für dringende Kommunikation zusätzliche Kontaktmöglichkeiten zum zuständigen CSIRT, die spätere Plattformmeldung aber nicht ersetzen.

Vom Sicherheitssignal bis zum Abschluss: neun kontrollierte Stationen

Ein belastbarer CRA-Ablauf verbindet technische Analyse und regulatorische Meldung, ohne sie zu vermischen. Das Sicherheitsteam bewertet die Evidenz, die Produktverantwortung stellt Produkt- und Versionsbezug her, die Rechts- beziehungsweise Compliance-Funktion prüft Rolle und Meldekriterium, und ein autorisierter Vertreter übermittelt den abgestimmten Stand. Jede Station erhält einen Besitzer, eine Frist und ein prüfbares Ergebnis.

Der Vorgang bleibt über eine eindeutige Fall-ID verbunden. Meldungsstände, technische Artefakte, Entscheidungen, Nutzerinformationen und Korrekturversionen werden verknüpft, aber nach Schutzbedarf getrennt. Besonders sensible Exploitdetails gehören nicht ungefiltert in allgemeine Ticketkommentare oder breit verteilte Benachrichtigungen.

• 1. Signal aus Support, Forschung, Lieferkette, Monitoring oder Behörde sicher annehmen
• 2. Fall-ID, Awareness-Zeitpunkt, Quelle und erste Evidenz festhalten
• 3. Produkt, Version, Komponente, Herstellerrolle und betroffene Märkte zuordnen
• 4. aktive Ausnutzung oder schweren Sicherheitsvorfall anhand belegter Kriterien bewerten
• 5. Meldeentscheidung und koordinierendes CSIRT freigeben
• 6. Frühwarnung spätestens binnen 24 Stunden übermitteln und Nachweis sichern
• 7. Analyse, Umfang und Maßnahmen für die 72-Stunden-Meldung vervollständigen
• 8. Patch, Konfigurationshilfe, Eindämmung und Nutzerkommunikation kontrolliert ausrollen
• 9. Abschlussbericht abgeben, Wirksamkeit prüfen und den Fall nachvollziehbar schließen

Ein Produktinventar macht aus einem Signal einen bearbeitbaren Fall

Ohne Produktinventar bleibt ein Hinweis auf eine Bibliothek oder Version technisch interessant, aber betrieblich unvollständig. Das Inventar verbindet Produktfamilien mit unterstützten Versionen, eingebetteten Komponenten, Veröffentlichungswegen, verantwortlichen Teams und erreichbaren Kundengruppen. Eine Software Bill of Materials kann die Komponentenbeziehung unterstützen, ist aber kein Ersatz für Produktverantwortung und Wirkungsanalyse.

Für die Meldung zählt nicht nur, dass eine Komponente vorhanden ist. Das Team muss feststellen, ob der verwundbare Codepfad erreichbar ist, welche ausgelieferten Versionen betroffen sind und ob eine Abhilfe verfügbar ist. Produkt- und Komponentenstände sollten deshalb mit Release-, Support- und Deploymentinformationen verbunden sein. Die breiteren CRA-Anforderungen ab Dezember 2027 werden damit vorbereitet, ohne sie fälschlich als bereits vollständig geltende September-Pflicht darzustellen.

• Produktfamilie, Version, Auslieferungsdatum und Supportstatus
• Komponenten- und Abhängigkeitsbezug mit Herkunft und Version
• Produktverantwortung, Sicherheitskontakt und Eskalationsvertretung
• betroffene Installationsmodelle, Märkte und erreichbare Nutzergruppen
• Patch-, Workaround-, Rücknahme- und Kommunikationsfähigkeit

Drittkomponenten vom Lieferantenhinweis bis zum eigenen Produkt verfolgen

Ein Hinweis eines Open-Source-Projekts oder Lieferanten beantwortet noch nicht, ob das eigene Produkt betroffen und der eigene Herstellerprozess ausgelöst ist. Der Eingang wird zunächst einer konkreten Komponente und Version zugeordnet. Danach folgen Erreichbarkeitsanalyse, Produktbezug, aktive Ausnutzung und mögliche Sicherheitswirkung. Das Ergebnis wird pro ausgelieferter Produktversion festgehalten.

Verantwortlichkeiten dürfen nicht zwischen Einkauf, Entwicklung und Produktsicherheit verloren gehen. Die Lieferkette liefert Evidenz und Korrekturstände; der Hersteller bewertet das eigene Produkt und seine Pflichten. Umgekehrt sollten relevante Erkenntnisse kontrolliert an Lieferanten, Koordinatoren oder Open-Source-Projekte zurückfließen, ohne vertrauliche Meldungsinhalte unnötig offenzulegen.

Open-Source-Software-Verwalter haben nach der Verordnung eigene, zeitlich anders einsetzende Pflichten. Diese Rollenfrage ändert nicht, dass ein Hersteller die in seinem kommerziell bereitgestellten Produkt verwendeten Komponenten kennen und einen eingehenden Hinweis für das eigene Produkt bewerten muss.

Beispielprozess: ausgenutzte Bibliothek in einer Unternehmenssoftware

Ein Hersteller erhält über seinen Sicherheitskontakt einen belastbaren Hinweis, dass eine Schwachstelle in einer eingebetteten Bibliothek aktiv ausgenutzt wird. Der Eingang erzeugt sofort eine Fall-ID und einen Awareness-Zeitpunkt. Das Komponentenregister zeigt, dass zwei unterstützte Produktversionen die Bibliothek enthalten; eine dritte Version enthält den verwundbaren Codepfad nicht.

Produktsicherheit bestätigt die Evidenz, Produktmanagement ordnet betroffene Versionen und Auslieferungsmodelle zu, und die zuständige Funktion prüft Herstellerrolle sowie Meldekriterium. Die autorisierte Vertretung gibt innerhalb der 24-Stunden-Frist die Frühwarnung ab. Parallel wird ein Workaround getestet, während Entwicklung einen Patch vorbereitet. Bis zur 72-Stunden-Meldung werden Reichweite, Bewertung und Maßnahmen ergänzt.

Support erhält eine freigegebene, zielgruppengerechte Information und kann betroffene Nutzer anhand der Produktstände erreichen. Nach Bereitstellung der Korrektur wird deren Wirksamkeit überwacht. Meldungsreferenz, Patchversion, Kommunikation und Abschlussbericht werden unter derselben Fall-ID verbunden. Dieses Anwendungsszenario zeigt den Ablauf; es ist keine reale Kundenreferenz.

CRA-Meldung, NIS2-Vorfall und interne Störung getrennt koordinieren

Ein Ereignis kann mehrere Melde- oder Informationswege berühren. Der Cyber Resilience Act betrachtet die Sicherheit eines Produkts mit digitalen Elementen aus der Herstellerperspektive. NIS2-bezogene Vorgaben und nationale Umsetzungen können dagegen erhebliche Sicherheitsvorfälle bei erfassten Einrichtungen adressieren. Datenschutzverletzungen folgen wiederum einer eigenen Prüfung. Gleichlautende Fristen oder Empfänger dürfen nicht unterstellt werden.

Der zentrale Fall kann gemeinsame Tatsachen wie Zeit, Systeme, Wirkung und Maßnahmen halten. Darauf greifen getrennte Entscheidungsspuren mit eigenen Kriterien, Empfängern und Freigaben zu. So werden Fakten nicht widersprüchlich mehrfach erfasst, rechtliche Rollen aber auch nicht in einer universellen Meldemaske vermischt.

In 30 Tagen einen arbeitsfähigen Meldeprozess aufsetzen

Der erste Schritt ist kein neues Sicherheitswerkzeug, sondern eine belastbare Verbindung vorhandener Stellen: Sicherheitskontakt, Produktverantwortung, Incident Response, Entwicklung, Support, Recht beziehungsweise Compliance und autorisierte Plattformkonten. Gemeinsam werden ein Kriterienbaum, die erreichbaren Produktdaten und die Fristenkette an realistischen Fällen getestet.

Ein Tabletop-Test sollte auch ungünstige Bedingungen abbilden: Eingang außerhalb der Kernzeit, unklare aktive Ausnutzung, mehrere Produktversionen, fehlende Komponenteninformation, eine nicht erreichbare Schlüsselperson und eine vorübergehend nicht verfügbare Plattform. Der Test gilt erst als bestanden, wenn Frühwarnung, 72-Stunden-Stand, Korrektur und Abschluss mit eindeutigen Besitzern durchlaufen werden können.

• Woche 1: Produkte, Herstellerrollen, Kontakte und vorhandene Incident-Wege abgrenzen
• Woche 2: Kriterienbaum, Awareness-Zeitpunkt, Fristen und Freigaben definieren
• Woche 3: EU-Login, autorisierte Vertretungen, CSIRT-Zuordnung und Vertretung prüfen
• Woche 4: Tabletop-Test durchführen, Lücken schließen und Nachweisablage abnehmen
• danach: Prozess mit Produktinventar, Komponentenbezug und Release-Steuerung weiter vertiefen