CRA-Meldepflichten ab September 2026
Ab September läuft die Uhr: Was Softwarehersteller jetzt über den Cyber Resilience Act wissen müssen
TL;DR: Ab 11. September 2026 müssen betroffene Hersteller aktiv ausgenutzte Schwachstellen und schwere Sicherheitsvorfälle innerhalb enger Fristen melden – dafür brauchen sie nicht nur sichere Software, sondern belastbare Prozesse.
Am 11. September 2026 beginnt die erste operative Phase des europäischen Cyber Resilience Act, kurz CRA. Hersteller von Produkten mit digitalen Elementen müssen dann aktiv ausgenutzte Schwachstellen und schwere Sicherheitsvorfälle über eine zentrale europäische Plattform melden.
Die umfassenden Produktpflichten gelten zwar überwiegend erst ab Dezember 2027. Die Meldepflichten greifen jedoch früher – und betreffen unter bestimmten Voraussetzungen auch Produkte, die bereits auf dem europäischen Markt sind.
Softwaresicherheit wird zur Herstelleraufgabe
Der CRA ist 2024 in Kraft getreten. Er führt verbindliche Cybersicherheitsanforderungen für Hardware und Software ein, die in der Europäischen Union bereitgestellt werden und direkt oder indirekt mit einem Gerät oder Netzwerk verbunden sind.
Im Mittelpunkt steht der Hersteller: also die natürliche oder juristische Person, die ein Produkt unter ihrem eigenen Namen oder ihrer eigenen Marke auf den Markt bringt. Je nach Geschäftsmodell können darunter klassische Softwareanbieter, App-Hersteller, Geräteproduzenten und Anbieter eingebetteter Systeme fallen.
Die genaue Abgrenzung ist nicht immer trivial. Reine Dienstleistungen und bestimmte Software-as-a-Service-Angebote sind anders zu bewerten als installierbare Softwareprodukte; zugleich kann notwendige entfernte Datenverarbeitung Bestandteil eines Produkts mit digitalen Elementen sein. Unternehmen sollten ihren Anwendungsfall daher fachlich und bei Bedarf rechtlich prüfen, statt sich allein auf die Bezeichnung „SaaS“ oder „Individualsoftware“ zu verlassen.
Grundsätzlich verlangt der CRA, Cybersicherheit über den gesamten Produktlebenszyklus zu berücksichtigen: von Planung und Entwicklung über Veröffentlichung und Betrieb bis zum Ende des ausgewiesenen Unterstützungszeitraums. Die EU-Kommission fasst den Anwendungsbereich und die Herstellerpflichten ausführlich zusammen.
Nicht jede Sicherheitslücke muss gemeldet werden
Ab September muss nicht jede gewöhnliche Schwachstelle sofort an Behörden gemeldet werden. Die Pflicht konzentriert sich auf zwei Kategorien.
Die erste ist eine aktiv ausgenutzte Schwachstelle. Damit ist eine Sicherheitslücke gemeint, für die belastbare Hinweise vorliegen, dass ein Angreifer sie tatsächlich in einem System eingesetzt hat. Ein theoretischer Fehler oder ein neu veröffentlichter CVE-Eintrag reicht dafür nicht automatisch aus.
Die zweite Kategorie umfasst schwere Sicherheitsvorfälle, die sich auf ein Produkt mit digitalen Elementen auswirken. Dabei geht es nicht nur darum, ob ein einzelner Server des Herstellers ausgefallen ist, sondern ob Sicherheit, Verfügbarkeit, Vertraulichkeit oder Integrität des Produkts erheblich betroffen sind.
Diese Differenzierung ist wichtig. Unternehmen brauchen einen Prozess, der Meldungen und technische Erkenntnisse zunächst bewertet: Ist die eigene Software betroffen? Existiert ein realistischer Angriffsweg? Gibt es Hinweise auf eine aktive Ausnutzung? Handelt es sich um einen meldepflichtigen Vorfall?
Ohne klar definierte Kriterien drohen zwei Fehler. Entweder wird zu spät gemeldet, weil niemand die Tragweite erkennt, oder jedes Sicherheitsproblem löst unnötig einen regulatorischen Alarm aus.
24 Stunden für die erste Warnung
Wird ein Unternehmen auf eine meldepflichtige Schwachstelle oder einen schweren Vorfall aufmerksam, beginnen enge Fristen.
Innerhalb von 24 Stunden muss eine erste Warnung abgegeben werden. Nach spätestens 72 Stunden folgt eine ausführlichere Meldung mit den zu diesem Zeitpunkt verfügbaren Informationen zum betroffenen Produkt, zum Problem und zu bereits ergriffenen oder empfohlenen Maßnahmen.
Bei einer aktiv ausgenutzten Schwachstelle ist spätestens 14 Tage nach Bereitstellung einer Korrektur oder Risikominderung ein Abschlussbericht fällig. Für schwere Sicherheitsvorfälle gilt grundsätzlich eine Frist von einem Monat nach der ausführlicheren Meldung.
Die EU-Kommission erläutert den vollständigen Meldeablauf. Die Meldung erfolgt einmalig über die CRA Single Reporting Platform. Sie wird an das zuständige nationale Computer Security Incident Response Team, kurz CSIRT, und an die EU-Cybersicherheitsagentur ENISA weitergeleitet.
ENISA soll die Plattform rechtzeitig zum 11. September 2026 in Betrieb nehmen. Laut der aktuellen ENISA-Dokumentation wird sie als zentraler Einstiegspunkt für Hersteller und teilweise auch für Open-Source-Stewards dienen.
Der schwierigste Zeitpunkt heißt „Kenntnis“
Die Frist beginnt nicht erst, wenn Geschäftsführung oder Rechtsabteilung einen Bericht freigegeben haben. Maßgeblich ist, wann der Hersteller Kenntnis von der aktiv ausgenutzten Schwachstelle oder dem schweren Vorfall erhält.
Damit wird ein organisatorisches Detail entscheidend: Wann gilt eine Information im Unternehmen als bekannt? Genügt ein Support-Ticket? Muss ein Entwickler einen Verdacht bestätigt haben? Was passiert, wenn ein externer Sicherheitsforscher eine unvollständige Meldung sendet?
Unternehmen sollten diese Fragen nicht erst im Ernstfall diskutieren. Sie benötigen einen nachvollziehbaren Eingangskanal, dokumentierte Bewertungsstufen und klare Eskalationswege. Der Zeitpunkt des Eingangs, die technischen Erkenntnisse und jede Entscheidung sollten festgehalten werden.
Ein überfülltes gemeinsames E-Mail-Postfach ist dafür kein belastbarer Prozess. Ebenso wenig reicht es, Schwachstellen ausschließlich über automatische Abhängigkeitsscanner zu verwalten. Automatisierung kann Hinweise liefern, aber die regulatorische Bewertung benötigt Kontext.
Was Unternehmen jetzt vorbereiten sollten
Der CRA macht Vulnerability Management zu einer funktionsübergreifenden Aufgabe. Entwicklung, Betrieb, IT-Sicherheit, Support, Produktmanagement, Kommunikation und Geschäftsführung müssen wissen, welche Rolle sie im Ernstfall übernehmen.
Am Anfang steht ein vollständiger Produkt- und Komponentenüberblick. Ein Unternehmen sollte wissen, welche Versionen im Einsatz sind, welche Open-Source-Abhängigkeiten enthalten sind und für welche Produkte es selbst als Hersteller auftritt. Eine Software Bill of Materials, kurz SBOM, kann dabei helfen, ersetzt aber nicht die Bewertung der tatsächlichen Auswirkungen.
Danach braucht es einen etablierten Kanal für Schwachstellenmeldungen. Externe Sicherheitsforscher, Kunden und interne Teams müssen erkennen können, wohin sie sich wenden sollen. Eingehende Hinweise müssen priorisiert, technisch geprüft und einem verantwortlichen Produkt zugeordnet werden.
Ebenso wichtig ist ein CRA-tauglicher Incident-Response-Ablauf. Er sollte festlegen, wer die 24-Stunden-Warnung auslöst, wer die 72-Stunden-Meldung vorbereitet und wer mit Kunden, Partnern und Behörden kommuniziert. Vertretungen gehören ausdrücklich dazu: Ein meldepflichtiger Vorfall richtet sich nicht nach Urlaub oder Wochenende.
Ein interner Probelauf ist sinnvoll. Ein realistisches Szenario zeigt schnell, ob Produktversionen, Ansprechpartner, Logs und technische Informationen innerhalb weniger Stunden zusammengetragen werden können.
Die größeren Pflichten folgen 2027
Die Meldepflicht ist nur der erste sichtbare Teil des CRA. Ab 11. Dezember 2027 greifen die umfassenden Anforderungen an Entwicklung, Konformität und Schwachstellenbehandlung.
Hersteller müssen eine Cybersicherheits-Risikobewertung durchführen und deren Ergebnisse in Planung, Entwicklung, Produktion, Auslieferung und Wartung berücksichtigen. Produkte sollen sicher konfiguriert ausgeliefert werden. Sicherheitsupdates müssen während des Unterstützungszeitraums bereitgestellt werden.
Dieser Unterstützungszeitraum beträgt grundsätzlich mindestens fünf Jahre. Ist die erwartete Nutzungsdauer eines Produkts kürzer, kann auch der Supportzeitraum entsprechend kürzer ausfallen. Bei langlebiger Software können dagegen längere Verpflichtungen angemessen sein. Die Verordnung nennt Betriebssysteme ausdrücklich als Beispiel für Produkte mit längerer erwartbarer Nutzungsdauer.
Damit wird auch das Produktversprechen präziser: Hersteller müssen nicht nur eine erste Version ausliefern, sondern erklären können, wie lange sie Sicherheitsprobleme beheben.
Open Source bleibt ein Sonderfall
Nicht kommerziell bereitgestellte freie und quelloffene Software fällt nicht automatisch unter dieselben Herstellerpflichten. Wird Open Source jedoch im Rahmen einer kommerziellen Tätigkeit auf dem Markt bereitgestellt, kann die Bewertung anders ausfallen.
Der CRA kennt außerdem die Rolle des Open-Source-Software-Stewards. Gemeint sind Organisationen, die freie Software systematisch und dauerhaft unterstützen, ohne sie selbst als Hersteller eines kommerziellen Produkts bereitzustellen.
Für Softwareunternehmen bleibt entscheidend: Die Verwendung einer Open-Source-Komponente verlagert die Verantwortung für das eigene Produkt nicht auf deren Maintainer. Hersteller müssen Schwachstellen ihrer integrierten Komponenten beobachten und in ihrem Produkt behandeln.
Kontext
Mit dem CRA verschiebt die EU Cybersicherheit vom freiwilligen Qualitätsversprechen in Richtung überprüfbarer Produkthaftung und Marktaufsicht. Die Verordnung ergänzt bestehende Regelwerke wie NIS2 und DORA, verfolgt aber einen anderen Schwerpunkt: Nicht primär der Betreiber einer kritischen Organisation, sondern das digitale Produkt und sein Hersteller stehen im Mittelpunkt.
Was bis September passieren muss
Unternehmen sollten zunächst klären, welche ihrer Produkte in den Anwendungsbereich fallen. Danach müssen Produktinventar, Meldungseingang, technische Bewertung, Eskalation und Behördenkommunikation als zusammenhängender Prozess getestet werden.
Die 24-Stunden-Frist lässt keine langwierige Zuständigkeitsklärung zu. Wer erst nach einem Vorfall über Verantwortliche, Produktversionen und Meldewege diskutiert, hat wertvolle Zeit bereits verloren.
Der CRA verlangt nicht, dass Software fehlerfrei wird. Er verlangt, dass Hersteller Sicherheitsrisiken systematisch behandeln, wirksame Korrekturen bereitstellen und bei ernsthaften Fällen schnell sowie nachvollziehbar handeln.
Dieser Beitrag bietet eine technische und organisatorische Einordnung und ersetzt keine Rechtsberatung.