CRA-Meldepflicht seit 11. September 2026: Was Hersteller jetzt technisch aufbauen müssen
Das Wichtigste in Kürze · Stand 3. Oktober 2026
Die Meldepflicht gilt. Die Erkennung fehlt bei den meisten Herstellern.
- Seit 11. September 2026 müssen Hersteller aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle melden — Frühwarnung binnen 24 Stunden (Art. 14 Cyber Resilience Act).
- Auch für Produkte im Feld: Die Meldepflicht gilt für alle Produkte mit digitalen Elementen, die vor dem 11. Dezember 2027 in Verkehr gebracht wurden (Art. 69 Abs. 3).
- Das eigentliche Problem ist technisch: Melden kann nur, wer erkennt. Ohne Software-Stückliste, laufenden Schwachstellenabgleich und einen Meldekanal erfahren Sie von einer ausgenutzten Lücke zu spät — oder gar nicht.
- Die übrigen Pflichten folgen am 11. Dezember 2027. Wer jetzt die Erkennung aufbaut, erfüllt damit bereits den größten Teil von Anhang I Teil II.
Was seit dem 11. September 2026 gilt
Der Cyber Resilience Act (Verordnung (EU) 2024/2847) wird in Stufen wirksam. Die meisten Anforderungen — sichere Produktgestaltung, Schwachstellenbehandlung, technische Dokumentation, CE-Kennzeichnung — gelten ab dem 11. Dezember 2027. Art. 14, die Meldepflicht, gilt bereits seit dem 11. September 2026 (Art. 71 Abs. 2). Das ist die unbequeme Reihenfolge des CRA: Die Pflicht zu melden kommt vor der Pflicht, systematisch nach Lücken zu suchen.
Gemeldet werden zwei Arten von Ereignissen. Erstens aktiv ausgenutzte Schwachstellen — Lücken, für die es verlässliche Belege gibt, dass ein Angreifer sie ohne Erlaubnis in einem System ausgenutzt hat (Art. 3 Nr. 42). Zweitens schwerwiegende Vorfälle, die die Sicherheit des Produkts betreffen: wenn sensible oder wichtige Daten oder Funktionen in ihrer Verfügbarkeit, Authentizität, Integrität oder Vertraulichkeit beeinträchtigt sind oder werden können, oder wenn Schadcode in das Produkt oder die Systeme der Nutzer gelangt ist oder gelangen kann (Art. 14 Abs. 5).
Die Fristen für aktiv ausgenutzte Schwachstellen
innerhalb von 24 Stunden
Frühwarnung
Ab Kenntnis der aktiv ausgenutzten Schwachstelle — mit Angabe der Mitgliedstaaten, in denen das Produkt bereitgestellt wurde (Art. 14 Abs. 2 lit. a).
innerhalb von 72 Stunden
Schwachstellenmeldung
Betroffenes Produkt, Art der Schwachstelle und des Exploits, ergriffene Gegenmaßnahmen und was Nutzer selbst tun können (Art. 14 Abs. 2 lit. b).
spätestens 14 Tage nach dem Fix
Abschlussbericht
Beschreibung inkl. Schweregrad und Auswirkung, Angaben zum Angreifer (soweit bekannt), Details zum Sicherheitsupdate (Art. 14 Abs. 2 lit. c).
Für schwerwiegende Vorfälle gelten dieselben 24 und 72 Stunden; der Abschlussbericht ist dort aber einen Monat nach der 72-Stunden-Meldung fällig, nicht nach dem Fix (Art. 14 Abs. 4). Das CSIRT kann zwischendurch einen Zwischenbericht anfordern.
Gemeldet wird gleichzeitig an das koordinierende CSIRT und an die ENISA, über die zentrale Meldeplattform (Single Reporting Platform), die laut ENISA seit dem 11. September 2026 in Betrieb ist. In Deutschland nennt das BSI CERT-Bund als koordinierendes CSIRT. Zusätzlich müssen Sie die betroffenen Nutzer über die Schwachstelle und mögliche Gegenmaßnahmen informieren (Art. 14 Abs. 8) — tun Sie es nicht rechtzeitig, kann das CSIRT es übernehmen.
Wen es trifft — und wen nicht
Betroffen ist, wer ein Produkt mit digitalen Elementen auf den EU-Markt bringt: Software oder Hardware mit einer direkten oder indirekten Datenverbindung — vernetzte Maschinen und Steuerungen, IoT-Geräte, Router, Desktop- und Mobile-Software, Firmware, verkaufte Softwarekomponenten. Dazu gehören auch die Fernverarbeitungslösungen des Herstellers, ohne die das Produkt eine Funktion nicht erfüllen kann: die Cloud des Geräts, das Backend der App (Art. 3 Nr. 1 und 2).
Ausgenommen sind unter anderem Medizinprodukte, Kraftfahrzeuge und Luftfahrt, für die eigene Regelwerke gelten (Art. 2). Reines Software-as-a-Service fällt nach Erwägungsgrund 12 unter NIS2, nicht unter den CRA. Für Betreiber gilt also häufig NIS2, für Hersteller der CRA — und wer beides ist, hat beide Meldewege.
Für Produkte der Standardkategorie genügt ab Dezember 2027 eine Selbstbewertung der Konformität (Modul A, Art. 32 Abs. 1). Wichtige Produkte der Klasse I und II (Anhang III) — etwa Betriebssysteme, Router, Passwortmanager, VPN, Firewalls oder Hypervisoren — brauchen strengere Verfahren. Die Meldepflicht gilt für alle Kategorien gleich.
Das eigentliche Problem: Melden kann nur, wer erkennt
Die 24-Stunden-Uhr beginnt, sobald Sie Kenntnis haben. Die juristische Frage ist, wann das ist. Die technische Frage ist wichtiger: Wie erfahren Sie überhaupt davon? In den meisten mittelständischen Herstellern gibt es darauf keine gute Antwort. Ein Kunde ruft im Support an, ein Forscher schreibt an die allgemeine Info-Adresse, ein Händler leitet eine Mail weiter — oder die Lücke steht zuerst in einem Fachartikel.
Der häufigste Fall wird ein anderer sein: Eine Schwachstelle in einer verbreiteten Bibliothek wird weltweit ausgenutzt, und die Frage ist, ob Ihr Produkt sie enthält. Wer seine Komponenten nicht kennt, braucht Tage, um das herauszufinden. Wer eine aktuelle Software-Stückliste hat, braucht Minuten.
Genau deshalb hängen Meldepflicht und Schwachstellenbehandlung zusammen. Was Anhang I Teil II ab Dezember 2027 vorschreibt, ist das Fundament, das Sie für die Meldepflicht schon heute brauchen.
Die acht Anforderungen an die Schwachstellenbehandlung
Anhang I Teil II CRA — ab 11. Dezember 2027 verbindlich, für eine funktionierende Meldekette schon heute die Grundlage.
Komponenten kennen — SBOM
Schwachstellen und Komponenten identifizieren und dokumentieren, mit einer Software-Stückliste (SBOM) in einem gängigen, maschinenlesbaren Format — mindestens für die direkten Abhängigkeiten.
Ohne Verzögerung beheben
Schwachstellen unverzüglich beheben, Sicherheitsupdates wo technisch möglich getrennt von Funktionsupdates ausliefern.
Regelmäßig testen
Wirksame und regelmäßige Tests und Überprüfungen der Sicherheit des Produkts.
Behobene Lücken offenlegen
Nach Verfügbarkeit eines Updates öffentlich informieren: Beschreibung, betroffene Produkte, Auswirkung, Schweregrad, Hilfe zur Behebung.
CVD-Richtlinie
Eine Richtlinie zur koordinierten Offenlegung von Schwachstellen (Coordinated Vulnerability Disclosure) einführen und durchsetzen.
Meldeadresse
Informationsaustausch erleichtern — inklusive einer Kontaktadresse, über die Dritte Schwachstellen melden können.
Sichere Update-Verteilung
Mechanismen, die Updates sicher verteilen — wo sinnvoll automatisch.
Updates kostenlos und erklärt
Sicherheitsupdates unverzüglich und kostenlos bereitstellen, begleitet von Hinweisen, was Nutzer tun sollen.
Dazu kommen die Herstellerpflichten aus Art. 13: Sorgfalt beim Einbinden fremder Komponenten einschließlich Open Source, Meldung gefundener Lücken an den jeweiligen Maintainer, ein Supportzeitraum von in der Regel mindestens fünf Jahren und die Verfügbarkeit jedes Sicherheitsupdates für mindestens zehn Jahre oder den Rest des Supportzeitraums.
Was Sie in den nächsten Wochen technisch aufbauen sollten
Acht Schritte, sortiert nach Wirkung. Die ersten drei entscheiden, ob Sie eine ausgenutzte Lücke überhaupt rechtzeitig bemerken.
- 1
Produkte und Supportzeiträume inventarisieren
Welche Produkte mit digitalen Elementen haben Sie im Markt — auch ältere Versionen? Die Meldepflicht gilt für alle, die vor dem 11.12.2027 in Verkehr gebracht wurden (Art. 69 Abs. 3). Notieren Sie pro Produkt den Supportzeitraum und wer intern zuständig ist.
- 2
Eine SBOM pro Produkt erzeugen — automatisch
Eine einmalig von Hand gepflegte Liste veraltet mit dem nächsten Release. Erzeugen Sie die SBOM in der Build-Pipeline (z. B. CycloneDX oder SPDX), versionieren Sie sie mit dem Release und archivieren Sie sie für jede ausgelieferte Version.
- 3
Komponenten gegen Schwachstellendaten abgleichen — laufend
Die SBOM nützt nur, wenn sie täglich gegen neue CVEs und Exploit-Meldungen geprüft wird. Achten Sie besonders auf Kennzeichnungen für „bekannt ausgenutzt“ (etwa den KEV-Katalog der CISA): Genau dort beginnt Ihre 24-Stunden-Uhr am wahrscheinlichsten.
- 4
Eine Meldeadresse veröffentlichen
security.txt nach RFC 9116 und eine Seite mit Ihrer Offenlegungsrichtlinie. Wer eine Lücke in Ihrem Produkt findet, muss wissen, wohin damit — sonst erfahren Sie davon aus der Presse.
- 5
Den Meldeweg einmal durchspielen
Wer entscheidet, ob „aktiv ausgenutzt“ zutrifft? Wer meldet bei der ENISA-Plattform, mit welchem Zugang? Die ENISA empfiehlt, den EU-Login mit MFA erst bei Bedarf anzulegen — klären Sie trotzdem vorab, wer ihn anlegt. Ein Wochenende ist kein Grund für Verzug.
- 6
Updates sicher ausliefern können
Signierte Updates, ein dokumentierter Verteilweg, ein Plan für Geräte ohne automatische Updates. Ohne Update gibt es keinen Abschlussbericht — die 14-Tage-Frist läuft ab Verfügbarkeit der Behebung.
- 7
Nutzer informieren können
Art. 14 Abs. 8 verlangt, betroffene Nutzer über die Schwachstelle und Gegenmaßnahmen zu informieren. Haben Sie eine Kundenliste pro Produkt und Version — oder nur Händleradressen?
- 8
Das Produkt testen lassen, bevor es ein Angreifer tut
Regelmäßige Sicherheitstests verlangt Anhang I Teil II Nr. 3 ohnehin. Ein Penetrationstest von Firmware, App, API und Backend findet die Lücken, die sonst irgendwann auf der ENISA-Plattform landen.
Ein Beispiel für Schritt 4 finden Sie bei uns selbst: Wir veröffentlichen eine Richtlinie zur Meldung von Schwachstellen und eine security.txt — beides kostet einen Nachmittag und ist der einfachste Schritt der Liste.
Bußgelder — und warum sie nicht das größte Risiko sind
Verstöße gegen die grundlegenden Anforderungen und gegen Art. 13 und 14 können mit bis zu 15 Millionen Euro oder 2,5 % des weltweiten Jahresumsatzes geahndet werden, je nachdem, welcher Betrag höher ist (Art. 64 Abs. 2). Kleinst- und Kleinunternehmen werden für eine verpasste 24-Stunden-Frühwarnung nicht mit Geldbußen belegt — die Pflicht selbst gilt für sie trotzdem.
Das größere Risiko im Alltag ist ein anderes: Ihre Kunden lesen dieselben Fristen. Wer Maschinen, Geräte oder Software an Unternehmen liefert, die selbst unter NIS2 fallen, wird nach seinem Schwachstellenprozess gefragt — im Einkauf, im Lieferantenaudit, im nächsten Rahmenvertrag. Eine belastbare Antwort ist ab jetzt ein Verkaufsargument.
Häufige Fragen zur CRA-Meldepflicht
Gilt die CRA-Meldepflicht auch für Produkte, die wir vor Jahren ausgeliefert haben?
Ja. Art. 69 Abs. 3 der Verordnung (EU) 2024/2847 stellt klar, dass die Meldepflichten aus Art. 14 für alle Produkte mit digitalen Elementen gelten, die vor dem 11. Dezember 2027 in Verkehr gebracht wurden — also auch für Bestandsprodukte im Feld. Die übrigen Anforderungen gelten für solche Altprodukte nur, wenn sie nach diesem Datum wesentlich geändert werden.
Was ist eine „aktiv ausgenutzte Schwachstelle“?
Eine Schwachstelle, für die es verlässliche Belege gibt, dass ein böswilliger Akteur sie ohne Erlaubnis des Systembetreibers in einem System ausgenutzt hat (Art. 3 Nr. 42 CRA). Eine bloß theoretisch ausnutzbare Lücke oder ein Fund aus einem beauftragten Penetrationstest löst die Meldepflicht nicht aus.
An wen geht die Meldung?
Gleichzeitig an das als Koordinator benannte CSIRT und an die ENISA — über die zentrale Meldeplattform (Single Reporting Platform), die laut ENISA seit dem 11. September 2026 in Betrieb ist. Zuständig ist das CSIRT des Mitgliedstaats Ihrer Hauptniederlassung; für Deutschland nennt das BSI CERT-Bund als koordinierendes CSIRT.
Fällt unsere SaaS-Anwendung unter den CRA?
Reines Software-as-a-Service fällt in der Regel unter NIS2, nicht unter den CRA (Erwägungsgrund 12). Anders sieht es bei einer Fernverarbeitungslösung aus, ohne die ein Produkt mit digitalen Elementen eine seiner Funktionen nicht erfüllen kann — etwa das Backend einer App oder die Cloud eines vernetzten Geräts (Art. 3 Nr. 2). Die Einordnung im Einzelfall gehört zu Ihrer Rechtsberatung.
Welche Bußgelder drohen?
Für Verstöße gegen die grundlegenden Anforderungen sowie gegen Art. 13 und 14 bis zu 15 Millionen Euro oder 2,5 % des weltweiten Jahresumsatzes, je nachdem, welcher Betrag höher ist (Art. 64 Abs. 2). Kleinst- und Kleinunternehmen werden für das Versäumen der 24-Stunden-Frühwarnung nicht mit Geldbußen belegt (Art. 64 Abs. 10) — die Pflicht selbst gilt für sie trotzdem.
Brauchen wir für die Meldepflicht schon eine SBOM?
Die SBOM-Pflicht aus Anhang I Teil II ist ab dem 11. Dezember 2027 verbindlich. Praktisch brauchen Sie sie schon heute: Ohne aktuelle Stückliste können Sie nicht schnell genug feststellen, ob eine aktiv ausgenutzte Lücke in einer Bibliothek Ihr Produkt betrifft — und damit auch nicht innerhalb von 24 Stunden melden.
Wenn Sie Unterstützung wollen
Die Schritte oben können Sie selbst gehen. Wenn Sie dabei Hilfe wollen, übernehmen wir die technische Seite — mit einem deutschen Security-Lead, der jeden Bericht verantwortet, und Entwicklern, die beim Beheben mit anpacken.
CRA-Readiness-Check
Zwei Tage, €2.900, für ein Produkt: SBOM-Reife, Update-Mechanismus, Meldewege, Testpraxis und offene Angriffsfläche — mit priorisiertem Maßnahmenplan.
CRA-Leistungen ansehenProdukt-Penetrationstest
Ab €3.500: Firmware, Gerät, App, API und Backend — die regelmäßigen Sicherheitstests, die Anhang I Teil II verlangt, mit Re-Test nach der Behebung.
Penetrationstest ansehenSecure-SDLC-Review
Vier Tage, €4.900: Build-Pipeline, SBOM-Erzeugung, Abhängigkeiten und Secrets — damit die Stückliste automatisch entsteht und aktuell bleibt.
Security Audit ansehenWas wir bewusst nicht anbieten
Wir sind keine Kanzlei und keine benannte Stelle: Die rechtliche Einordnung Ihres Produkts und die Konformitätsbewertung gehören zu Ihrer Rechtsberatung. Wir übernehmen auch keine 24/7-Bereitschaft für Ihre Meldefristen. Was wir liefern, ist die technische Grundlage, damit Sie rechtzeitig wissen, was Sie melden müssen. Dieser Artikel ist eine technische Einordnung, keine Rechtsberatung.
Quellen
- Verordnung (EU) 2024/2847 (Cyber Resilience Act) — Amtsblatt der EU, insbesondere Art. 3, 13, 14, 64, 69, 71 und Anhang I
- ENISA: Single Reporting Platform (SRP) — Frequently Asked Questions
- BSI: Single Reporting Platform und Meldungen nach dem Cyber Resilience Act
- CISA: Known Exploited Vulnerabilities Catalog
- RFC 9116: A File Format to Aid in Security Vulnerability Disclosure (security.txt)
Bauen Sie die Erkennung, bevor Sie die Meldung brauchen
In einem 30-minütigen Erstgespräch schauen wir uns ein Produkt an und sagen Ihnen, welche technischen Lücken zwischen Ihrem heutigen Stand und einer funktionierenden Meldekette liegen.
Lieber erst sehen, was von außen erreichbar ist? Kostenlosen Attack-Surface-Check anfordern
