CRA-Schwachstellenmeldung: Die 24-Stunden-Regel

Die CRA-Schwachstellenmeldung wird am 11. September 2026 verpflichtend. Ab diesem Datum muss jeder Softwarehersteller, der in die EU verkauft, eine aktiv ausgenutzte Schwachstelle innerhalb von 24 Stunden nach Kenntnisnahme melden. Nicht 24 Arbeitsstunden. Vierundzwanzig Stunden.

Dieser Termin liegt Wochen entfernt, nicht Monate, und ob ein Entwicklungsteam das Zeitfenster halten kann, hängt fast vollständig von Arbeit ab, die vor Monaten hätte beginnen müssen. In einem großen Teil der Organisationen hat sie das nicht. Eine OpenSSF-Umfrage von 2026 ergab, dass 72% der nordamerikanischen Organisationen noch wenig oder nichts über ihre rechtliche CRA-Exposition wissen, und das europäische Bild ist zwar besser, aber nicht viel besser.

Im Folgenden legen wir dar, was die CRA-Schwachstellenmeldung im September 2026 verlangt, für wen sie gilt, welche technische Infrastruktur die Einhaltung möglich macht und wo die häufigen Lücken liegen.

Der Cyber Resilience Act und seine gestaffelten Fristen

Der Cyber Resilience Act, formal die Verordnung (EU) 2024/2847, ist die erste EU-weite Verordnung, die verpflichtende Cybersicherheitsanforderungen an digitale Produkte über den gesamten Lebenszyklus stellt, von Konzeption und Entwicklung bis zu Inbetriebnahme und Supportende. Sie trat am 10. Dezember 2024 in Kraft, doch die Pflichten kommen gestaffelt, weshalb die meisten Teams auf das Datum im Dezember 2027 hin geplant haben.

Artikel 14 ist die Ausnahme, denn die Meldepflicht beginnt am 11. September 2026. Alles andere folgt am 11. Dezember 2027: Konformitätsbewertungen, CE-Kennzeichnung, technische Dokumentation und die Anforderung einer Software Bill of Materials. Teams, die den EU-AI-Act-Termin im August 2026 durchgearbeitet haben, werden das Muster erkennen, da Melde- und Transparenzpflichten zuerst greifen und die schwerere Konformitätsmaschinerie später folgt.

Welche Produkte die CRA-Schwachstellenmeldung erfasst

Alle. Die Pflicht gilt für jedes in den Anwendungsbereich fallende Produkt, das bereits auf dem EU-Markt bereitgestellt wurde, nicht nur für Veröffentlichungen nach dem Datum. Ein Produkt, das 2019 ausgeliefert wurde und heute noch verkauft oder unterstützt wird, trägt dieselbe 24-Stunden-Pflicht wie eines, das nächsten Monat erscheint. Weil Altprodukte selten ein aktuelles Abhängigkeitsverzeichnis haben, liegt genau dort der größte Teil der Exposition.

Wer nach dem CRA Hersteller ist

Die meisten Organisationen beantworten das falsch, weil die Definition weiter reicht als der alltägliche Wortsinn. Hersteller ist jede natürliche oder juristische Person, die ein Produkt mit digitalen Elementen entwickelt oder herstellt oder entwickeln oder herstellen lässt und es unter eigenem Namen oder eigener Marke vermarktet.

Händler, die umlabeln Wenn Sie ein Produkt mit digitalen Elementen nehmen und es unter Ihrer Marke in die EU weiterverkaufen, sind Sie der Hersteller. Die Pflicht folgt der Geschäftsbeziehung zum europäischen Markt, nicht der Frage, wer den Code geschrieben hat.

Wer Open Source einbindet Enthält Ihr Produkt Open-Source-Bibliotheken, Frameworks oder Betriebssystemkomponenten, sind diese Teil seiner digitalen Elemente. Die Pflichten gelten für das Produkt als Ganzes, einschließlich der Teile, die Ihr Team nicht geschrieben hat.

Einführer und Bevollmächtigte. Sitzt der Hersteller außerhalb der EU, treffen die Pflichten den Bevollmächtigten oder den Einführer. Der Meldeweg muss daher vertraglich vor einem Vorfall geklärt sein, nicht während eines Vorfalls.

Wo SaaS und Cloud-Dienste stehen

Die pauschale Antwort, die in den meisten Compliance-Zusammenfassungen kursiert, ist falsch. Reine Cloud-Dienste als SaaS, PaaS oder IaaS sind keine Produkte mit digitalen Elementen, denn Erwägungsgrund 12 überlässt sie NIS2. Erfasst wird eine Fernverarbeitungslösung: Datenverarbeitung aus der Ferne, die vom Hersteller oder unter seiner Verantwortung entwickelt wurde und ohne die das Produkt eine seiner Funktionen nicht erfüllen könnte. Das Cloud-Backend zur Steuerung eines smarten Geräts fällt darunter. Ein allgemeines SaaS-Werkzeug, das Ihr Produkt lediglich aufruft, nicht.

CRA-Schwachstellenmeldung im September 2026: der genaue Ablauf

Die Pflicht läuft auf einer festen Uhr, und die drei Stufen sind kumulativ, nicht alternativ.

Titel Die Uhr aus Artikel 14 für eine aktiv ausgenutzte Schwachstelle

24 Stunden: Frühwarnung

Meldung, dass eine aktiv ausgenutzte Schwachstelle vorliegt. Keine vollständige technische Analyse erforderlich

›

72 Stunden: Meldung

Beschreibung, betroffene Versionen, erste Folgenabschätzung, getroffene Korrekturmaßnahmen

›

14 Tage: Abschlussbericht

Fällig, sobald eine Korrekturmaßnahme vorliegt: Ursache, Behebung, Nennung der Forschenden

Derselbe 24- und 72-Stunden-Rhythmus gilt für schwerwiegende severe incidentsbei denen der Abschlussbericht binnen eines Monats statt 14 Tagen fällig ist.

Der Ablauf erfasst nicht jede offengelegte CVE. Er erfasst Schwachstellen, die zur Waffe gemacht wurden und in echten Angriffen genutzt werden, eine deutlich engere Menge. Diese Enge schneidet allerdings in beide Richtungen, denn zu wissen, dass eine CVE von offengelegt zu ausgenutzt gewechselt ist, erfordert Threat Intelligence und keine monatliche Abhängigkeitsprüfung. Die Uhr beginnt mit der Kenntnisnahme durch den Hersteller, weshalb eine Überwachungslücke sie nicht anhält.

Die 24-Stunden-Uhr beginnt, wenn Sie Kenntnis erlangen. Sie wartet nicht auf das nächste Sprint-Review.

Wo die CRA-Schwachstellenmeldung eingereicht wird

Meldungen laufen über einen Kanal: die Single Reporting Platform des CRA, die ENISA nach Artikel 16 aufbaut und betreibt. Ein Hersteller reicht einmal ein, und die Einreichung wird gleichzeitig an das als Koordinator benannte CSIRT seiner Hauptniederlassung und an ENISA weitergeleitet. Das ersetzt getrennte Meldungen an jede nationale Behörde.

Daraus folgen zwei praktische Punkte. Erstens war die Plattform Mitte 2026 noch vorbetrieblich, und der Start dürfte über manuelle Eingabe in einem Portal ohne APIs erfolgen, System-zu-System-Meldung ist also am ersten Tag nicht verfügbar. Zweitens ist eine verspätete Plattform kein Grund zu warten, denn das zuständige CSIRT zu bestimmen, festzulegen, wer einreicht, und die Vorlage für die Frühwarnung zu schreiben, ist Arbeit außerhalb der Plattform. Onboarding-Details erscheinen auf der CRA-Meldeseite der Kommission und auf der Seite der Single Reporting Platform von ENISA. CRA reporting page and on ENISA's Single Reporting Platform page.

Abhängigkeiten am Lebensende, von technischer Schuld zur Rechtspflicht

Das ist der Teil, der bei Teams ohne Vorarbeit die unmittelbarste Störung auslösen wird. Viele Unternehmensprodukte liefern Open-Source-Frameworks aus, die ihr Lebensende erreicht haben, was bedeutet: von niemandem kommen mehr Sicherheitspatches.

EOL 31 Dec 2021

AngularJS

Steckt noch in überraschend vielen internen Verwaltungsoberflächen und Kundenportalen, für deren Neuschreibung kein Budget existiert.

EOL 31 Dec 2023

Der Wechsel auf Vue 3 ist ein Breaking Change, weshalb das Upgrade Quartal für Quartal verschoben wird.

EOL 30 Apr 2025

Node.js 18

Eine Laufzeitumgebung ohne Support zieht jede transitive Abhängigkeit mit aus dem Support.

OSS support ended 31 Dec 2024

Spring Framework 5.3

Kommerzieller Support läuft weiter, was eine ungepatchte Installation zur Einkaufsentscheidung statt zur Entwicklungsentscheidung macht.

Das sind Beispiele, keine vollständige Liste. Für jedes Produkt lautet die Frage einfacher: Gibt es im Abhängigkeitsbaum etwas, das von niemandem mehr Sicherheitspatches erhält?

Vor dem 11. September war das Beibehalten dieser Komponenten eine Risikoentscheidung, bei der Teams Migrationskosten gegen Exposition abwogen. Danach wird es eine Compliance-Frage mit definierter Folge. Erscheint eine neue CVE in einer Komponente am Lebensende und wird diese CVE aktiv ausgenutzt, hat der Hersteller 24 Stunden zur Meldung. Ein Patch existiert per Definition nicht, weshalb die Organisation eine Schwachstelle melden muss, die sie nicht beheben kann. Dieses Problem lässt sich nach dem Datum nicht lösen. Entweder die Migration passiert vorher, oder die Exposition wird bewusst in Kauf genommen.

Sorgen wegen Abhängigkeiten am Lebensende in Ihrem Produktstack? Unser Team bewertet Ihre Exposition und erstellt einen Behebungsplan.

Sprechen Sie mit unserem Team

Was die SBOM für die CRA-Schwachstellenmeldung im September 2026 leisten muss

Eine Software Bill of Materials ist ein vollständiges Verzeichnis der Komponenten eines Softwareprodukts. Die formale SBOM-Anforderung gehört zur Frist im Dezember 2027 und nicht zum September, wobei diese Unterscheidung in der Praxis irreführend ist. Das 24-Stunden-Fenster ist nur erreichbar, wenn das Team bereits genau weiß, was im Produkt steckt, bis zu jeder Abhängigkeit und Version. Ohne lebendes Verzeichnis beginnt die Meldung mit manueller Ermittlung, und manuelle Ermittlung ist an einem Tag nicht fertig.

Reicht nicht

SBOM als Compliance-Artefakt

Ein Dokument zu einem Zeitpunkt, das die in dieser Momentaufnahme vorhandenen Komponenten listet. Es erfüllt den Buchstaben der Dokumentationspflicht. Während eines Vorfalls ist es schon veraltet und trägt zur 24-Stunden-Uhr nichts bei.

Was funktioniert

SBOM als operatives

Werkzeug Ein Verzeichnis, das bei jedem Build automatisch neu erzeugt wird, mit CVE-Datenbanken verbunden und an Alarmierung angeschlossen ist, sodass das Sicherheitsteam binnen Minuten erfährt, dass eine Komponente im Produktivbetrieb betroffen ist. Das macht das Fenster erreichbar.

Organisationen, die der Frist voraus sind, haben die zweite Variante. Sie haben außerdem einen definierten Weg von der Warnung zur Meldung, und genau dieser Teil bleibt meist liegen, bis ein Vorfall die Frage stellt.

Die Infrastruktur hinter der CRA-Schwachstellenmeldung im September 2026

Über das Verzeichnis hinaus müssen vier Fähigkeiten vorhanden sein.

Automatisierte Abhängigkeitsüberwachung Kein Sicherheitsteam verfolgt CVE-Datenbanken manuell über jede Abhängigkeit in jedem Produkt. Scanning gehört in die CI/CD-Pipeline, verbunden mit dem NVD, der GitHub Advisory Database und Herstellerfeeds, mit Alarmierung, die auf schwerwiegende Funde in Produktivkomponenten abgestimmt ist.

Intelligence zur aktiven Ausnutzung. Da die Uhr mit der Kenntnis der aktiven Ausnutzung läuft, muss die Überwachung eine offengelegte CVE von einer bestätigt genutzten trennen. Kataloge bekannter ausgenutzter Schwachstellen und kommerzielle Threat Feeds erledigen das.

Ein definierter Meldeablauf. Wer reicht ein? Über welches Konto auf der Single Reporting Platform? An welches CSIRT? Was gehört in die Frühwarnung im Unterschied zur 72-Stunden-Meldung? Ein 24-Stunden-Fenster lässt keinen Raum, das während des Laufs zu entscheiden.

Aktuelle Registrierungsdaten. Hersteller müssen sich gegenüber ihrem CSIRT und ENISA identifizieren. Prüfen Sie, ob die Angaben zur juristischen Person stimmen und ob der hinterlegte Sicherheitskontakt nicht jemand ist, der vor zwei Jahren gegangen ist.

CRA-Schwachstellenmeldung und Open Source: was Maintainer schulden

Open Source, die außerhalb einer kommerziellen Tätigkeit entwickelt und bereitgestellt wird, fällt nicht unter die Herstellerpflichten. Die Verordnung erkennt das Ökosystem ausdrücklich an und schafft eine leichtere Kategorie für Open-Source-Software-Verwalter, also Stiftungen und Organisationen, die dauerhafte Unterstützung für Komponenten in kommerziellen Produkten leisten. Verwalter dokumentieren ihre Sicherheitsrichtlinie und Offenlegungspraxis. Konformitätsbewertung und SBOM-Pflicht treffen sie nicht.

Was Maintainer stattdessen spüren werden, ist Nachfragedruck. Sobald die Durchsetzung beginnt, wenden sich Hersteller mit Schwachstellen in nicht gepflegten Komponenten mit dringenden Bitten nach oben, obwohl freiwillige Projekte keine Pflicht zur Antwort haben. Auf einen rechtzeitigen Upstream-Fix zu setzen, ist daher keine Compliance-Strategie. Unsere breitere Sicht auf den Stand europäischer Entwicklungsteams steht in unserem Ausblick zur Cyber-Resilienz 2026..

Eine Bereitschaftscheckliste für die CRA-Schwachstellenmeldung

Fünf Fragen, in der Reihenfolge, in der sie sich lohnen.

Sind wir Hersteller, und für welche Produkte? Listen Sie alles auf, was unter Ihrer Marke in der EU verkauft oder unterstützt wird, einschließlich Altversionen und umgelabelter Fremdprodukte.

Kennen wir unser koordinierendes CSIRT? Es folgt Ihrer Hauptniederlassung in der EU oder Ihrem Bevollmächtigten, wenn das Unternehmen außerhalb ansässig ist.

Haben wir ein lebendes Komponentenverzeichnis? Eines, das sich bei jedem Build neu erzeugt, keine Tabelle vom letzten Audit.

Können wir offengelegt von ausgenutzt binnen Stunden unterscheiden? Hängt die Antwort davon ab, dass jemand am Montagmorgen einen Newsletter liest, ist das Fenster nicht abgedeckt.

Wer schreibt und reicht die Frühwarnung sonntags um 2 Uhr ein? Benennen Sie die Rolle, schreiben Sie die Vorlage und üben Sie einmal, bevor es darauf ankommt.

Was Caixa Mágica dazu beiträgt

Wir entwickeln seit über 20 Jahren Software für den portugiesischen öffentlichen Sektor und für europäische Unternehmenskunden, und zu unseren Sicherheitsnachweisen gehört die Zertifizierung auf der Stufe Secreto durch das portugiesische Nationale Sicherheitsamt. Linux Caixa Mágicaunser Open-Source-Betriebssystem, ist selbst ein Produkt mit digitalen Elementen im Sinne der Verordnung. Die Fragen in diesem Artikel mussten wir für unser eigenes Produkt beantworten, bevor wir andere dazu beraten haben.

Wenn Sie Unterstützung bei der SBOM-Umsetzung, bei der Infrastruktur zur Schwachstellenüberwachung oder bei einer Bereitschaftsbewertung für die CRA-Schwachstellenmeldung über Ihren Produktstack brauchen, können unsere Teams für Softwareentwicklung und küstennah an Ihrer Seite arbeiten.

Häufig gestellte Fragen

CRA-Schwachstellenmeldung: Anwendungsbereich und Fristen

Wer gilt unter dem EU Cyber Resilience Act als Hersteller?

Ein Hersteller ist jede Organisation, die ein Produkt mit digitalen Elementen entwickelt oder entwickelt hat und dieses unter eigenem Namen oder Markenzeichen in der EU vermarktet. Dazu gehören Wiederverkäufer, die Produkte unter neuem Markennamen anbieten, Organisationen, die Open-Source-Komponenten zu kommerziellen Produkten bündeln, und im Fall eines Herstellers außerhalb der EU der Bevollmächtigte oder Importeur. Sie müssen den Code nicht selbst geschrieben haben.

Was ist die Berichterstattungspflicht der CRA vom September 2026?

Ab dem 11. September 2026 müssen Hersteller innerhalb von 24 Stunden nach Bekanntwerden einer aktiv ausgenutzten Schwachstelle eine Frühwarnung an ihr koordinierendes nationales CSIRT und die ENISA übermitteln, innerhalb von 72 Stunden eine vollständigere Benachrichtigung und innerhalb von 14 Tagen nach Bereitstellung einer Korrekturmaßnahme einen Abschlussbericht. Bei schwerwiegenden Vorfällen gilt derselbe Rhythmus von 24 und 72 Stunden mit einem Abschlussbericht innerhalb eines Monats. Die Berichte werden über die Single Reporting Platform der ENISA einmalig eingereicht, und die Pflicht gilt für Produkte, die bereits auf dem EU-Markt sind.

Gilt das CRA für SaaS-Produkte?

Standardmäßig nicht. Cloud-Dienste, die rein als SaaS, PaaS oder IaaS angeboten werden, fallen unter die NIS2-Richtlinie und nicht unter die CRA. Eine Cloud-Komponente ist nur als Datenverarbeitungslösung aus der Ferne betroffen, d. h. sie wird vom Hersteller entworfen oder liegt in dessen Verantwortung, und das Produkt würde eine seiner Funktionen ohne sie nicht erfüllen können.

SBOM, Abhängigkeiten und Open Source

Was ist ein SBOM und warum ist es für die Einhaltung der CRA-Vorschriften wichtig?

Eine Software-Stückliste (SBOM) ist ein vollständiges Inventar der Komponenten in einem Softwareprodukt. Die formale Anforderung gilt ab Dezember 2027, aber eine operative SBOM, die bei jedem Build neu generiert und mit CVE-Datenbanken verknüpft wird, ermöglicht ab September 2026 eine 24-Stunden-Berichterstattung. Ohne eine solche beginnt die Benachrichtigung mit manueller Ermittlung, die in der verfügbaren Zeit nicht abgeschlossen werden kann.

Sind Open-Source-Abhängigkeiten am Ende ihrer Lebensdauer eine Haftung für CRA?

Ja. Wenn Ihr Produkt Komponenten versendet, die keine Sicherheitspatches mehr erhalten, begründet jede neue, aktiv ausgenutzte CVE in diesen Komponenten eine Meldepflicht, die Sie nicht durch einen Patch schließen können. Dies rückt End-of-Life-Abhängigkeiten aus der Spalte "technische Schulden" in die Spalte "regulatorische Compliance".

Sind Open-Source-Maintainer CRA-Verpflichtungen ausgesetzt?

Nicht direkt, für Projekte, die außerhalb einer kommerziellen Tätigkeit entwickelt und geliefert werden. Open-Source-Softwareverwalter haben geringere Pflichten in Bezug auf Sicherheitspolitik und Offenlegungsdokumentation. Das praktische Risiko für die Maintainer besteht darin, dass Hersteller, die nach Beginn der Durchsetzung dringende Korrekturen suchen, unter Druck geraten.

Caixa Mágica Team

Caixa Mágica Software ist ein portugiesisches Softwareunternehmen mit über 20 Jahren Erfahrung in der Bereitstellung von kundenspezifischer Software, KI-Lösungen und Nearshore-Entwicklungsteams für europäische Unternehmen.

Software Development · Caixa Mágica Software

Machen Sie Ihre Software-Lieferkette vor dem 11. September

Operative SBOMs. Schwachstellenüberwachung in Ihrer Pipeline. Migrationspläne für Abhängigkeiten am Lebensende. Von einem Team, das seit über 20 Jahren sichere Software für den öffentlichen Sektor und für Unternehmen ausliefert.

So entwickeln wir Gespräch beginnen