Am 11. September 2026 wird Artikel 14 des EU Cyber Resilience Act (EU CRA) verbindlich. Ab diesem Tag müssen Hersteller von Produkten mit digitalen Elementen aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle melden: innerhalb von 24 Stunden, mit Folgeberichten nach 72 Stunden und einem Abschlussbericht. Das gilt auch für Produkte, die schon heute auf dem Markt sind.
Die komplette Meldekette auf einer Seite. Ein Klick auf die Grafik öffnet die druckfähige PDF-Version.
Wer die Meldepflicht verletzt, riskiert Bußgelder von bis zu 15 Millionen Euro oder 2,5 Prozent des weltweiten Jahresumsatzes, je nachdem, welcher Betrag höher ist. Verstöße gegen Artikel 14 liegen damit in der höchsten Sanktionsstufe des EU CRA.
Die gute Nachricht: Die Vorbereitung ist überschaubar, wenn man weiß, was genau verlangt wird. Dieser Artikel geht Artikel 14 Absatz für Absatz durch und ordnet jeder Pflicht eine Maßnahme zu, die sich mit vorhandenen Mitteln umsetzen lässt. Danach wissen Sie, was bis zum Stichtag zu tun ist.
Die kurze Antwort: Was bis zum 11. September 2026 stehen muss
Wenn Sie nur eine Liste mitnehmen, dann diese fünf Punkte:
- Zuständigkeit klären. Meldeverantwortlicher plus Vertretung benannt, zuständiges CSIRT dokumentiert.
- Produktdaten bereitstellen. Je Produkt: Versionsstände, Liste der EU-Vertriebsländer, und aktuelle Kontaktdaten Ihrer Kunden verfügbar halten, damit Sie Betroffene im Ernstfall direkt benachrichtigen können.
- Meldevorlagen bauen. Je eine Vorlage für 24-Stunden-Frühwarnung, 72-Stunden-Meldung, Abschlussbericht und Nutzerbenachrichtigung, damit im Ernstfall keine wertvolle Zeit mit Formulieren verloren geht.
- Erstprüfung organisieren. Eine definierte Stelle, bei der alle Hinweise ankommen, plus eine kurze Checkliste, mit der Ihr Team sofort entscheidet: meldepflichtig oder nicht.
- Einmal durchspielen. Ein Probelauf mit einer fiktiven Schwachstelle, bevor es ernst wird.
Der Rest dieses Artikels leitet diese fünf Punkte aus dem Rechtstext ab: was Artikel 14 verlangt, was er ausdrücklich nicht verlangt, welche Fristen gelten und wie der Prozess im Ernstfall abläuft.
Was Artikel 14 verlangt: zwei Auslöser, zwei Meldeketten
Artikel 14 kennt zwei meldepflichtige Ereignisse:
1. Aktiv ausgenutzte Schwachstellen (Absätze 1 und 2). Gemeint sind Fälle, in denen Sie feststellen, dass eine Schwachstelle in Ihrem Produkt von Angreifern tatsächlich ausgenutzt wird. Eine veröffentlichte CVE allein löst die Frist noch nicht aus. Erst Ihre Kenntnis von der aktiven Ausnutzung startet die Uhr.
2. Schwerwiegende Sicherheitsvorfälle (Absätze 3 bis 5). Ein Vorfall gilt als schwerwiegend, wenn er die Fähigkeit des Produkts beeinträchtigt oder beeinträchtigen kann, die Verfügbarkeit, Authentizität, Integrität oder Vertraulichkeit sensibler oder wichtiger Daten und Funktionen zu schützen. Ebenso, wenn er zur Einführung oder Ausführung von bösartigem Code im Produkt oder im System eines Nutzers geführt hat oder führen kann.
Beide Ereignisse melden Sie gleichzeitig an das als Koordinator benannte CSIRT Ihres Mitgliedstaats und an die ENISA. Der Weg dafür ist die einheitliche Meldeplattform nach Artikel 16, die zum Stichtag bereitsteht.
Was Artikel 14 nicht verlangt
Genauso wichtig wie die Pflicht ist ihre Grenze. Viele Hersteller überschätzen den Umfang der Meldepflicht deutlich. Nicht meldepflichtig nach Artikel 14 sind:
- Funde aus Vulnerability-Scannern. Wenn Ihr Scanner eine CVE in einer Dependency findet, ist das ein Fall für Ihr Schwachstellenmanagement, aber keine Meldung an CSIRT und ENISA. Es fehlt die aktive Ausnutzung.
- Veröffentlichte CVEs ohne Ausnutzung Ihres Produkts. Auch eine kritische CVE mit CVSS 9.8 löst keine Frist aus, solange Sie keine Kenntnis haben, dass sie in Ihrem Produkt aktiv ausgenutzt wird.
- Hinweise von Sicherheitsforschern. Eine verantwortungsvoll gemeldete Schwachstelle aus einer Coordinated Disclosure ist zu behandeln und zu beheben. Meldepflichtig wird sie erst, wenn eine aktive Ausnutzung festgestellt ist. Aufgepasst bei einem Sonderfall: Belegt der Hinweis, dass bereits etwas passiert ist, etwa eingeschleuster Schadcode in Ihrem Produkt oder eine kompromittierte Build-Pipeline, dann ist das keine bloße Schwachstelle mehr, sondern ein Sicherheitsvorfall nach Absatz 5 Buchstabe b. Der ist meldepflichtig, auch ohne festgestellte aktive Ausnutzung. Prüfen Sie eingehende Forscher-Meldungen deshalb immer gegen beide Auslöser.
- Ergebnisse aus Pentests und internen Audits. Selbst gefundene Schwachstellen bleiben ein interner Vorgang, solange niemand sie aktiv ausnutzt.
- Vorfälle unterhalb der Schwelle aus Absatz 5. Ein Vorfall ohne Auswirkung auf die Sicherheit des Produkts, etwa ein reiner Verfügbarkeitsausfall Ihrer Website, fällt nicht unter Artikel 14.
Zwei Einschränkungen gehören dazu: Erstens gibt es neben der Meldepflicht auch eine Behandlungspflicht. Nach Artikel 13 und Anhang I müssen Hersteller Schwachstellen behandeln und Sicherheitsupdates bereitstellen. Diese Pflicht gilt aber erst ab dem 11. Dezember 2027 (mehr zu beiden Stichtagen in der CRA-Roadmap 2026/2027). Bis dahin können Sie sie aus reiner Compliance-Sicht ignorieren, ohne ein Bußgeld zu riskieren. Ob Sie aus Business-Perspektive trotzdem handeln sollten, etwa wegen Kundenverträgen, Reputationsrisiken oder anstehender Audits, müssen Sie individuell bewerten. Die Meldepflicht aus Artikel 14 dagegen greift schon am 11. September 2026, also 15 Monate früher. Zweitens können Sie Schwachstellen und Vorfälle nach Artikel 15 jederzeit freiwillig melden, wenn Sie das für sinnvoll halten.
Für die Praxis heißt das: Ihr Prozess braucht einen sauberen Verifizierungsschritt. Erst wenn aus einem Scanner-Fund, einem Forscher-Hinweis oder einem Verdacht eine festgestellte aktive Ausnutzung oder ein schwerwiegender Vorfall wird, beginnt die 24-Stunden-Frist.
Die Meldefristen im Überblick
| Stufe | Aktiv ausgenutzte Schwachstelle | Schwerwiegender Vorfall |
|---|---|---|
| Frühwarnung | innerhalb von 24 Stunden nach Kenntnis | innerhalb von 24 Stunden nach Kenntnis |
| Detailmeldung | innerhalb von 72 Stunden nach Kenntnis | innerhalb von 72 Stunden nach Kenntnis |
| Abschlussbericht | spätestens 14 Tage nachdem eine Korrektur- oder Risikominderungsmaßnahme verfügbar ist | innerhalb eines Monats nach der 72-Stunden-Meldung |
Die 24 und 72 Stunden sind Kalenderstunden. Sie laufen am Wochenende und an Feiertagen weiter. Wer Freitagabend verifiziert, meldet spätestens Samstagabend. Planen Sie Ihre Vertretungsregelung entsprechend.
Alle Fristen beginnen mit Ihrer Kenntnisnahme. Wichtig dabei: Kenntnisnahme ist nicht der Moment, in dem ein Hinweis in Ihrem Posteingang landet. Nach der Guidance der EU-Kommission gilt ein Hersteller erst dann als kenntnisnehmend, wenn er nach einer Erstprüfung mit hinreichender Sicherheit davon ausgehen kann, dass eine aktive Ausnutzung vorliegt oder ein schwerwiegender Vorfall die Sicherheit des Produkts beeinträchtigt hat.
Diese Erstprüfung dürfen Sie allerdings nicht aufschieben. Die Guidance verlangt, dass Sie jeden verdächtigen Hinweis unverzüglich bewerten, egal ob er von einem Kunden, einem Sicherheitsforscher, einer Behörde oder aus den Medien kommt. Wer die Verifizierung verschleppt, verschiebt die Frist nicht, sondern riskiert den Vorwurf, zu spät Kenntnis genommen zu haben. Dokumentieren Sie deshalb die Zeit zwischen Eingang und Verifizierung lückenlos: Wann kam der Hinweis, wann begann die Prüfung, wann stand das Ergebnis fest. Nur so können Sie im Zweifel belegen, dass Ihre 24-Stunden-Frist erst mit der Verifizierung begonnen hat und die Prüfung trotzdem prompt lief. Genau deshalb entscheidet Ihre interne Erkennungs- und Eskalationskette darüber, ob 24 Stunden viel oder wenig Zeit sind.
Jede Pflicht aus Artikel 14, gemappt auf eine konkrete Maßnahme
Die folgende Tabelle führt alle Anforderungen aus Artikel 14 auf und zeigt jeweils die Maßnahme, mit der Sie die Anforderung erfüllen. Keine davon erfordert ein Großprojekt.
| Pflicht (Artikel 14) | Was verlangt wird | Ihre Maßnahme |
|---|---|---|
| Abs. 1: Meldung aktiv ausgenutzter Schwachstellen | Jede aktiv ausgenutzte Schwachstelle, von der Sie Kenntnis erlangen, gleichzeitig an das koordinierende CSIRT und die ENISA melden, über die einheitliche Meldeplattform. | Benennen Sie einen Meldeverantwortlichen samt Vertretung. Definieren Sie schriftlich, was bei Ihnen als „Kenntnisnahme" gilt und wer die Meldung auslöst. Richten Sie einen internen Meldekanal ein, über den Support, Entwicklung und externe Melder Hinweise an diese Person eskalieren. |
| Abs. 2a: Frühwarnung binnen 24 Stunden | Frühwarnung mit Angabe der Mitgliedstaaten, in denen das Produkt bereitgestellt wurde. | Bereiten Sie eine ausgefüllte Vorlage je Produkt vor: Produktname, Version, Ansprechpartner, Vertriebsländer. Pflegen Sie die Liste der Mitgliedstaaten je Produkt aktuell, dann ist die 24-Stunden-Meldung ein Ausfüllvorgang von Minuten. Welche Felder Sie in jeder Meldestufe ausfüllen müssen, listet das ENISA-FAQ zur Single Reporting Platform mit einer vollständigen Feldtabelle auf. |
| Abs. 2b: Schwachstellenmeldung binnen 72 Stunden | Allgemeine Informationen zum Produkt, zur Art der Ausnutzung und der Schwachstelle, zu ergriffenen Korrektur- oder Risikominderungsmaßnahmen und zu Maßnahmen, die Nutzer ergreifen können. Dazu die Einstufung der Sensibilität, sofern Sie eine vorgenommen haben. | Erstellen Sie ein 72-Stunden-Template mit genau diesen Feldern. Empfehlenswert ist eine aktuelle SBOM je Produkt: Sie ist für die Meldung selbst nicht vorgeschrieben, macht es aber deutlich leichter, betroffene Komponenten innerhalb der Frist zu identifizieren. Legen Sie ein kurzes Playbook fest: Wer analysiert, wer formuliert Workarounds für Nutzer, wer gibt frei. |
| Abs. 2c: Abschlussbericht spätestens 14 Tage nach verfügbarer Korrekturmaßnahme | Beschreibung der Schwachstelle inkl. Schweregrad und Auswirkungen, Informationen zu ausnutzenden Akteuren (falls verfügbar), Informationen zum bereitgestellten Sicherheitsupdate. Wichtig: Die 14 Tage laufen nicht ab Kenntnisnahme. Die Frist beginnt erst, wenn Sie einen Patch oder eine Risikominderungsmaßnahme fertiggestellt haben. Wie lange die Entwicklung des Fixes dauert, gibt Artikel 14 nicht vor. | Standardisieren Sie Ihre Schweregradbewertung (z. B. CVSS) und dokumentieren Sie jeden Fix in einem Security Advisory. Halten Sie den Zeitpunkt, ab dem die Maßnahme verfügbar ist, sauber fest, denn er startet die Frist. Wenn Patch-Notes und Advisory ohnehin zum Release-Prozess gehören, ist der Abschlussbericht fast fertig, bevor die Frist beginnt. |
| Abs. 3: Meldung schwerwiegender Vorfälle | Jeden schwerwiegenden Sicherheitsvorfall mit Auswirkung auf die Produktsicherheit gleichzeitig an CSIRT und ENISA melden, über die Meldeplattform. | Nutzen Sie dieselbe Meldekette wie für Schwachstellen. Ergänzen Sie Ihr Incident-Response-Playbook um den Schritt „CRA-Meldepflicht prüfen" mit Verweis auf die Kriterien aus Absatz 5. |
| Abs. 4a: Frühwarnung binnen 24 Stunden (Vorfall) | Angabe, ob der Verdacht auf rechtswidrige oder böswillige Handlungen besteht, plus betroffene Mitgliedstaaten. | Nehmen Sie die Frage „böswillige Handlung: ja / nein / unklar" als Pflichtfeld in Ihre Erstbewertungs-Checkliste auf. Die Länderliste haben Sie aus der Maßnahme zu Absatz 2a bereits. |
| Abs. 4b: Vorfallmeldung binnen 72 Stunden | Art des Vorfalls, erste Bewertung, ergriffene Maßnahmen und Maßnahmen für Nutzer. Laut ENISA-Meldetemplate sind bei dieser Stufe zusätzlich Datum und Uhrzeit der Erkennung sowie des Auftretens des Vorfalls Pflichtfelder. | Verwenden Sie das gleiche Template-Prinzip wie bei Absatz 2b, nur mit Vorfall-Feldern. Erfassen Sie Erkennungs- und Auftretenszeitpunkt von Anfang an in Ihrer Vorfallakte. Ein gemeinsames Formular für beide Meldearten reduziert Fehler unter Zeitdruck. |
| Abs. 4c: Abschlussbericht binnen eines Monats | Ausführliche Beschreibung inkl. Schweregrad und Auswirkungen, Art der Bedrohung bzw. Ursache, getroffene und laufende Abhilfemaßnahmen. | Machen Sie das Post-Incident-Review zum festen Prozessschritt mit Termin im Kalender. Wer den Vorfall sauber in einer Timeline dokumentiert hat, schreibt den Abschlussbericht in einer Stunde. |
| Abs. 5: Schwellenwert „schwerwiegend" | Definition, wann ein Vorfall meldepflichtig ist (Schutzziele beeinträchtigt oder bösartiger Code eingeführt/ausgeführt). | Übersetzen Sie die beiden Kriterien in eine interne Klassifizierungsmatrix mit Beispielen aus Ihrer Produktwelt. So entscheidet das Team im Ernstfall in Minuten statt in Meetings. |
| Abs. 6: Zwischenbericht auf Anfrage des CSIRT | Das CSIRT kann Statusaktualisierungen anfordern. | Pflegen Sie ab der ersten Meldung eine laufende Fall-Timeline (Ticket oder Vorfallakte). Ein Zwischenbericht ist dann ein Export, keine Rekonstruktion. |
| Abs. 7: Zuständiges CSIRT bestimmen | Gemeldet wird an das CSIRT des Mitgliedstaats der Hauptniederlassung. Das ist der Staat, in dem die Cybersicherheitsentscheidungen überwiegend getroffen werden. Für Hersteller ohne EU-Niederlassung gilt eine Kaskade über Bevollmächtigten, Einführer, Händler und Nutzer. | Bestimmen und dokumentieren Sie einmalig Ihr zuständiges CSIRT und hinterlegen Sie den Zugang zur Meldeplattform. Diese Entscheidung will niemand um 2 Uhr nachts während eines Vorfalls treffen. |
| Abs. 8: Nutzer informieren | Betroffene Nutzer (ggf. alle Nutzer) über Schwachstelle oder Vorfall und mögliche Gegenmaßnahmen informieren, gegebenenfalls in strukturiertem, maschinenlesbarem Format. Sonst kann das CSIRT die Information selbst veröffentlichen. Die Kommissions-Guidance präzisiert: Kunden, zu denen eine direkte Beziehung besteht, sind direkt zu informieren. Eine allgemeine Bekanntmachung genügt nur für den breiteren Nutzerkreis, und Details dürfen risikobasiert auf die Betroffenen beschränkt bleiben. | Fahren Sie zweigleisig. Halten Sie erreichbare Kundenkontakte je Produkt vor und bereiten Sie eine Benachrichtigungsvorlage für die direkte Ansprache Betroffener vor. Für die breitere, maschinenlesbare Information hat sich CSAF als Standard für Security Advisories etabliert. Ein CSAF-Feed allein ersetzt die direkte Benachrichtigung bekannter betroffener Kunden nicht. |
| Abs. 9 und 10: Delegierte Rechtsakte und Durchführungsrechtsakte | Die Kommission präzisiert Meldeformate und -verfahren. Diese Pflichten richten sich an die Kommission, wirken sich aber auf Ihre Templates aus. | Beobachten Sie die Durchführungsrechtsakte zu Format und Verfahren, damit Ihre Vorlagen zum Stichtag zum offiziellen Format passen. Ein Fachnewsletter oder ein Quartalstermin zur Prüfung reicht dafür aus. |
Häufig als Pflicht geframt, tatsächlich eine Empfehlung: Der öffentliche Single Point of Contact, über den Nutzer und Sicherheitsforscher Schwachstellen melden können, wird oft so dargestellt, als verlange ihn Artikel 14 ab September 2026. Das stimmt nicht. Die Pflicht dazu kommt aus Artikel 13 Absatz 17 (zentrale Anlaufstelle für Nutzer) und der Coordinated-Disclosure-Policy nach Anhang I Teil II, und beides gilt erst ab dem 11. Dezember 2027. Sie müssen zum 11. September 2026 also keinen öffentlichen Meldekanal einrichten.
Faktisch werden Sie ohne ihn aber kaum meldefähig sein. Die unverzügliche Erstprüfung jedes Hinweises setzt voraus, dass Hinweise überhaupt bei der richtigen Stelle ankommen. Ohne definierten Eingang landen sie verstreut in Support-Postfächern, werden zu spät erkannt oder falsch priorisiert, und genau dort entsteht das Risiko, eine aktive Ausnutzung zu spät zu verifizieren. Deshalb unsere klare Empfehlung: Richten Sie den Meldekanal zum 11. September 2026 ein, auch wenn die formale Pflicht erst 15 Monate später greift.
Die Prozess-Landkarte: vom Hinweis zur abgeschlossenen Meldung
So sieht der komplette Ablauf im Ernstfall aus. Wenn Ihr Team diese sechs Phasen kennt und die Vorbereitung aus dem nächsten Abschnitt erledigt ist, gibt es keinen Moment mehr, in dem unklar ist, was als Nächstes zu tun ist.
Zum Ausdrucken und Weitergeben: Die komplette Prozess-Landkarte mit allen sechs Phasen, Uhr-Status und Fristen gibt es als PDF auf einer Seite.
Phase 1: Eingang. Die Uhr läuft noch nicht. Ein Hinweis trifft ein, egal ob von einem Sicherheitsforscher, einem Kunden, dem eigenen Team, einer Behörde oder aus den Medien. Er landet in Ihrem definierten Meldekanal. Dokumentieren Sie den Eingang mit Zeitstempel.
Phase 2: Erstprüfung, unverzüglich. Die Uhr läuft noch nicht, aber Sie stehen unter Prüfpflicht. Bewerten Sie den Hinweis sofort gegen beide Auslöser:
- Weder aktive Ausnutzung noch schwerwiegender Vorfall nach Absatz 5: keine Meldepflicht. Behandeln Sie den Fund als normale Schwachstelle, dokumentieren Sie die Entscheidung. Eine freiwillige Meldung nach Artikel 15 steht Ihnen offen.
- Aktive Ausnutzung mit hinreichender Sicherheit verifiziert: Meldekette Schwachstelle (Phase 3 bis 6).
- Schwerwiegender Vorfall nach Absatz 5 verifiziert, etwa eingeschleuster Schadcode: Meldekette Vorfall (Phase 3 bis 6, mit Vorfall-Fristen).
Der Zeitpunkt der Verifizierung ist Ihre Kenntnisnahme. Halten Sie ihn mit Zeitstempel fest, jetzt startet die Uhr.
Phase 3: Stunde 0 bis 24. Frühwarnung. Melden Sie über die Single Reporting Platform an Ihr CSIRT und die ENISA: betroffenes Produkt, Titel, bei Schwachstellen die Vertriebsländer, bei Vorfällen der Verdacht auf böswillige Handlung. Ihre vorbereitete Vorlage macht das zum Ausfüllvorgang. Parallel laufen Ihre technischen Sofortmaßnahmen.
Phase 4: Stunde 24 bis 72. Detailmeldung. Reichen Sie die Analyse nach: Art der Schwachstelle oder des Vorfalls, erste Bewertung, ergriffene Maßnahmen, Workarounds für Nutzer. Ab jetzt gilt auch Absatz 8: Informieren Sie bekannte betroffene Kunden direkt und den breiteren Nutzerkreis über ein Advisory, sobald das ohne zusätzliches Risiko möglich ist.
Phase 5: Fix entwickeln. Ohne gesetzliche Frist, aber dokumentiert. Entwickeln Sie den Patch oder die Risikominderungsmaßnahme. Artikel 14 gibt dafür keine Frist vor. Halten Sie den Zeitpunkt fest, ab dem die Maßnahme verfügbar ist, denn er startet die letzte Frist.
Phase 6: Abschlussbericht. Bei Schwachstellen spätestens 14 Tage nach Verfügbarkeit der Maßnahme, bei Vorfällen innerhalb eines Monats nach der 72-Stunden-Meldung. Ihre Fall-Timeline und das Security Advisory liefern den Inhalt. Veröffentlichen Sie das Advisory, bei Bedarf maschinenlesbar als CSAF.
Durchgehend, von Phase 1 bis 6: Dokumentieren. Jeder Schritt mit Zeitstempel in der Fall-Timeline. Damit beantworten Sie Zwischenbericht-Anfragen des CSIRT per Export und können jederzeit belegen, wann Sie was wussten und getan haben.
So sieht das im Ernstfall aus: ein durchgespieltes Beispiel
Ein fiktiver, aber realistischer Fall bei einem Hersteller von IoT-Gateways:
Dienstag, 14:32 Uhr. Ein Sicherheitsforscher meldet über Ihren Meldekanal eine Schwachstelle im Fernwartungsmodul Ihres Gateways. Er liefert Logs eines Kunden mit, die auf laufende Ausnutzung hindeuten. Der Eingang wird mit Zeitstempel erfasst, der Meldeverantwortliche ist informiert.
Dienstag, 15:10 Uhr. Die Erstprüfung beginnt. Ihr Team reproduziert die Schwachstelle und prüft die Logs. Prüfbeginn dokumentiert.
Mittwoch, 09:40 Uhr. Die Analyse bestätigt: Die Schwachstelle wird aktiv ausgenutzt. Das ist Ihre Kenntnisnahme, dokumentiert mit Zeitstempel. Die Uhr läuft, die Frühwarnung ist bis Donnerstag, 09:40 Uhr fällig.
Mittwoch, 16:05 Uhr. Die Frühwarnung geht über die Single Reporting Platform an Ihr CSIRT und die ENISA, mit Produkt, Titel und Vertriebsländern aus Ihrer vorbereiteten Vorlage. Rund 17 Stunden Puffer bleiben ungenutzt, weil die Vorlage fertig war.
Freitag, 08:30 Uhr. Die Detailmeldung geht raus, gut innerhalb der 72-Stunden-Frist: Art der Schwachstelle, erste Bewertung, ein Workaround (Fernwartungsmodul deaktivieren). Parallel informieren Sie die bekannten betroffenen Kunden direkt.
Neun Tage später. Der Patch ist getestet und verfügbar. Der Zeitpunkt wird dokumentiert, ab jetzt läuft die 14-Tage-Frist für den Abschlussbericht.
Drei Tage danach. Abschlussbericht eingereicht, Security Advisory als CSAF veröffentlicht. Der Fall ist geschlossen, die komplette Timeline liegt mit Zeitstempeln vor.
Das Entscheidende an diesem Beispiel: Zwischen dem Eingang am Dienstag und dem Fristbeginn am Mittwoch liegen 19 Stunden Prüfzeit, sauber dokumentiert. Ohne diese Dokumentation sähe es im Nachhinein so aus, als hätte die Frist schon Dienstag begonnen und als wäre die Frühwarnung anderthalb Stunden zu spät gewesen.
Die Vorbereitung in fünf Schritten
Wenn Sie die Tabelle abarbeiten, ergibt sich fast von selbst dieser Fahrplan bis zum 11. September 2026:
- Zuständigkeit klären. Meldeverantwortlicher plus Vertretung, zuständiges CSIRT dokumentiert. Den Zugang zur Meldeplattform richten Sie spätestens am 11. September 2026 ein, wenn die Plattform live geht. Die Registrierungs-Anleitung dafür veröffentlicht die ENISA vorab.
- Produktdaten bereitstellen. Je Produkt: Versionsstände, Liste der Mitgliedstaaten, Kundenkontakte. Dazu eine aktuelle SBOM: Für Artikel 14 ist sie nicht vorgeschrieben (Pflicht wird sie erst ab Dezember 2027 über Anhang I), aber ohne sie werden Sie bei einer Komponenten-Schwachstelle kaum innerhalb der Fristen klären, welche Produkte betroffen sind. Wie Sie eine SBOM aufbauen, zeigt der SBOM-Leitfaden.
- Templates bauen. Je eine Vorlage für 24-Stunden-Frühwarnung, 72-Stunden-Meldung, Abschlussbericht und Nutzerbenachrichtigung.
- Erstprüfung organisieren. Ein definierter Eingangskanal für Hinweise und die Klassifizierungsmatrix nach Absatz 5, damit jeder verdächtige Hinweis unverzüglich bewertet werden kann. Ein aktives Schwachstellen-Monitoring verlangt Artikel 14 nicht; es ist eine sinnvolle Ergänzung und wird ab Dezember 2027 ohnehin Teil der Schwachstellenbehandlung nach Anhang I.
- Einmal durchspielen. Ein Tabletop-Durchlauf mit fiktiver Schwachstelle zeigt, wo die Kette hakt, solange es noch nichts kostet.
Der Aufwand dafür liegt bei den meisten Herstellern im Bereich weniger Personentage. Die 24-Stunden-Frist wird erst dann zum Problem, wenn Produktdaten, Zuständigkeiten und Vorlagen im Ernstfall zusammengesucht werden müssen.
Was Kunnus davon übernimmt
Alles oben Beschriebene können Sie selbst aufbauen. Die eigentliche Arbeit liegt aber nicht im Aufbau, sondern im Betrieb: Templates aktuell halten, jeden Fall sauber dokumentieren, Fristen im Blick behalten, und das ab dem 11. September 2026 dauerhaft und im Zweifel um 2 Uhr nachts. Genau diese Arbeit nimmt Kunnus Ihnen ab, an den Punkten, an denen die 24-Stunden-Kette in der Praxis reißt: Eine öffentliche URL dient als Single Point of Contact für eingehende Hinweise. Ein geführter Prozess trennt den Verdacht von der Verifizierung, und erst mit der Verifizierung startet das SLA-Tracking der Meldestufen. Jede Bewertung, Statusänderung und Meldung wird mit Zeitstempel geloggt und ist im Nachgang beweisbar. Die Nutzerinformation läuft über Security Advisories als CSAF-Stream.
So bildet Kunnus die Pflichten aus der Tabelle oben ab:
| Pflicht (Artikel 14) | So löst es Kunnus |
|---|---|
| Abs. 1: Meldung aktiv ausgenutzter Schwachstellen | Die öffentliche Kunnus-URL ist Ihr Single Point of Contact. Eingehende Hinweise landen direkt im geführten Prozess und beim Meldeverantwortlichen statt in einem Support-Postfach. Damit decken Sie zugleich die zentrale Anlaufstelle ab, die Artikel 13 Absatz 17 ab Dezember 2027 verlangt. |
| Abs. 2a: Frühwarnung binnen 24 Stunden | Kunnus fragt in einem Template genau die Angaben ab, die Sie melden müssen, und füllt vor, was aus bestehenden Daten im System bekannt ist. Die Frühwarnung wird damit so leicht wie möglich. |
| Abs. 2b: Schwachstellenmeldung binnen 72 Stunden | Analyse, ergriffene Maßnahmen und Workarounds werden im Fall dokumentiert. Die Inhalte der 72-Stunden-Meldung liegen damit gesammelt an einem Ort vor. |
| Abs. 2c: Abschlussbericht (Schwachstelle) | Der Zeitpunkt, ab dem ein Fix verfügbar ist, wird im Fall festgehalten und startet das 14-Tage-SLA. Das Security Advisory zum Fix liefert den Inhalt des Abschlussberichts. |
| Abs. 3: Meldung schwerwiegender Vorfälle | Vorfälle laufen durch dieselbe geführte Meldekette wie Schwachstellen, mit eigenen Feldern je Meldestufe. |
| Abs. 4a: Frühwarnung binnen 24 Stunden (Vorfall) | Die Erstbewertung im geführten Prozess fragt die Pflichtangaben ab, inklusive des Verdachts auf böswillige Handlung. |
| Abs. 4b: Vorfallmeldung binnen 72 Stunden | Erkennungs- und Auftretenszeitpunkt werden ab Fallanlage mit Zeitstempel erfasst und stehen für die 72-Stunden-Meldung bereit. |
| Abs. 4c: Abschlussbericht (Vorfall) | Die dokumentierte Fall-Timeline ist die Basis des Abschlussberichts, und die Monatsfrist wird als SLA getrackt. |
| Abs. 5: Schwellenwert „schwerwiegend" | Die Verifizierung ist ein eigener Prozessschritt. Erst wenn Sie den Fall als aktiv ausgenutzt oder schwerwiegend einstufen, startet die SLA-Uhr der Meldestufen. |
| Abs. 6: Zwischenbericht auf Anfrage | Jede Bewertung, Statusänderung und Meldung wird mit Zeitstempel geloggt. Der Zwischenbericht ist ein Export der Timeline. |
| Abs. 7: Zuständiges CSIRT | Zuständiges CSIRT und Plattform-Zugang werden einmalig bei der Einrichtung von Kunnus dokumentiert, je Legal Entity. Im Ernstfall liegt die Information dort, wo der Fall bearbeitet wird. |
| Abs. 8: Nutzer informieren | Advisories veröffentlichen Sie aus Kunnus als CSAF-Stream. Für die direkte Ansprache betroffener Kunden liefern dieselben Advisories den fertigen Inhalt. |
| Abs. 9 und 10: Formate und Verfahren | Das Kunnus-Team verfolgt die Rechtsakte und hält Kunnus auf dem aktuellsten Stand, von den Meldetemplates bis zur CRA-Wissensdatenbank. Über Änderungen informiert der Kunnus-Newsletter. |
Die Prozessschritte aus der Tabelle oben bleiben Ihre Entscheidung. Kunnus sorgt dafür, dass Eingang, Verifizierung, Fristen und Dokumentation dahinter jederzeit stimmen.
Sehen Sie sich den Workflow live an: Demo anfordern. Oder verschaffen Sie sich zuerst einen Überblick, wo Ihr Unternehmen steht, mit der kostenlosen CRA-Reifegradanalyse (15 bis 20 Minuten).
Häufige Fragen zur Meldepflicht
Was genau muss ich bis zum 11. September 2026 tun? Fünf Dinge: Zuständigkeit klären (Meldeverantwortlicher, Vertretung, zuständiges CSIRT), Produktdaten bereitstellen (Versionen, Vertriebsländer, Kundenkontakte), Meldevorlagen für alle drei Meldestufen bauen, einen Eingangskanal mit Erstprüfungsprozess einrichten und den Ablauf einmal proben. Details in der Vorbereitung in fünf Schritten oben.
Muss ich jede CVE aus dem Scanner melden? Nein. Meldepflichtig sind nur aktiv ausgenutzte Schwachstellen und schwerwiegende Vorfälle nach Absatz 5. Scanner-Funde, veröffentlichte CVEs ohne Ausnutzung, Forscher-Hinweise und Pentest-Ergebnisse gehören ins interne Schwachstellenmanagement, nicht an CSIRT und ENISA.
Wann startet die 24-Stunden-Frist? Mit der verifizierten Kenntnisnahme, nicht mit dem Eingang eines Hinweises. Die Erstprüfung muss aber unverzüglich beginnen und lückenlos dokumentiert sein, sonst riskieren Sie den Vorwurf verspäteter Kenntnisnahme.
An wen melde ich? Gleichzeitig an das koordinierende CSIRT des Mitgliedstaats Ihrer Hauptniederlassung und an die ENISA, über die Single Reporting Platform nach Artikel 16.
Der vollständige Rechtstext von Artikel 14 mit FAQ und Querverweisen steht in der Kunnus CRA-Wissensdatenbank. Rechtsverbindlich ist allein der im Amtsblatt der EU veröffentlichte Wortlaut der Verordnung (EU) 2024/2847. Dieser Artikel stellt keine Rechtsberatung dar.