Heute gilt die CRA-Meldepflicht: was ein Plugin-Anbieter jetzt tun muss

Heute ist der 11. September 2026, und damit gilt Artikel 14 des Cyber Resilience Act. Der Artikel heißt amtlich Meldepflichten der Hersteller. Dass er ab genau diesem Datum anzuwenden ist, steht in Artikel 71 der Verordnung (EU) 2024/2847.

Über den CRA ist auf Deutsch inzwischen viel geschrieben worden, fast alles auf derselben Höhe: Es gibt eine Meldepflicht, es gibt Fristen, kümmere dich rechtzeitig. Was fehlt, ist der Teil, der zählt, wenn tatsächlich eine Mail eintrifft, in der jemand eine ausgenutzte Lücke in deinem Plugin beschreibt. Welche Stelle, welche Frist ab welchem Moment, und was du in den nächsten Stunden aufschreibst.

Genau das steht hier. Es ist eine Einordnung auf dem Recherchestand vom 21. August 2026 und keine Rechtsberatung. Wo eine Angabe unsicher war, steht das ausdrücklich dabei.

Wer hier überhaupt gemeint ist

Zwei Definitionen tragen die ganze Sache. Ein Produkt mit digitalen Elementen ist nach Artikel 3 Nummer 1 ein Software- oder Hardwareprodukt samt zugehöriger Datenverarbeitung aus der Ferne, ausdrücklich einschließlich Komponenten, die getrennt in Verkehr gebracht werden. Ein separat vertriebenes Plugin fällt damit unter den Wortlaut. Hersteller ist nach Artikel 3 Nummer 13, wer solche Produkte entwickelt oder entwickeln lässt und sie unter eigenem Namen oder eigener Marke vermarktet, und zwar entgeltlich, gegen Monetarisierung oder kostenlos. Auch ein kostenloses Plugin, das unter deinem Namen im Verzeichnis steht, macht dich nach dem Wortlaut zum Hersteller.

Ehrlich dazu gehört: Diese Einordnung ist aus den Primärdefinitionen gut begründbar, aber es gibt bis heute keine Aussage einer Behörde oder der Kommission, die WordPress-Plugins ausdrücklich benennt.

Drei Stichtage, und nur einer davon ist heute

Der CRA kommt gestaffelt, das ist die häufigste Verwechslung in Gesprächen darüber. Artikel 71 nennt drei Daten:

• 11. Juni 2026: Kapitel IV gilt, also die Vorschriften zu den notifizierten Stellen. Für einen Plugin-Anbieter ohne Konformitätsbewertung ändert das nichts.
• 11. September 2026: Artikel 14 gilt, die Meldepflichten. Das ist heute.
• 11. Dezember 2027: Die Verordnung gilt im Übrigen. Dazu gehören CE-Kennzeichnung, technische Dokumentation, Konformitätsbewertung und die Software-Stückliste aus Anhang I Teil II.

Was heute anfängt, ist also die Pflicht zu melden, wenn etwas passiert. Was 2027 anfängt, ist die Pflicht, dauerhaft nachzuweisen, wie du entwickelst. Wer heute schon SBOM-Werkzeuge kauft, kauft für übernächstes Jahr.

Zwei Meldestränge mit getrennten Fristen

Die Formel 24 Stunden, 72 Stunden, 14 Tage steht in fast jedem Überblicksartikel. Sie beschreibt genau einen der beiden Fälle, die Artikel 14 regelt. Der zweite Fall hat dieselben ersten zwei Stufen und eine andere Endfrist.

Strang 1: aktiv ausgenutzte Schwachstelle

Strang 2: schwerer Sicherheitsvorfall

Zwei Dinge fallen dabei auf, die in der Kurzformel untergehen. Erstens ist der Abschlussbericht beim Vorfall nach einem Monat fällig, nicht nach 14 Tagen. Das BSI nennt diese Ein-Monats-Frist auf seinen eigenen Seiten. Zweitens starten die Fristen nicht alle an derselben Stelle: 24 und 72 Stunden laufen ab dem Moment, in dem du Kenntnis erlangst, die 14 Tage laufen ab dem Moment, in dem eine Abhilfe verfügbar ist, und der Monat läuft ab dem Moment, in dem du die 72-Stunden-Meldung abgegeben hast.

Praktisch heißt das: Der Abschlussbericht im Schwachstellenstrang kann Wochen nach der Frühwarnung fällig werden, und sein Kalendereintrag entsteht erst, wenn der Fix steht.

Was die Meldepflicht auslöst, und was nicht

Eine aktiv ausgenutzte Schwachstelle setzt belastbare Hinweise darauf voraus, dass ein Angreifer sie tatsächlich ausnutzt. Ein schwerer Sicherheitsvorfall ist ein Ereignis, das die Fähigkeit des Produkts beeinträchtigt oder beeinträchtigen kann, Verfügbarkeit, Authentizität, Integrität oder Vertraulichkeit von Daten zu schützen.

Ein gewöhnlicher Fehler löst keine Meldung aus, ein Routine-Update ebenso wenig. Auch eine Lücke, die dir ein Sicherheitsforscher meldet und die niemand ausnutzt, gehört in den normalen Behebungsweg. Wer dagegen Hinweise auf eine laufende Ausnutzung erhält und drei Tage nachdenkt, hat die erste Frist verpasst. Diese Unterscheidung ist die Frage, die du im Ernstfall zuerst beantwortest.

Die zweite Pflicht, die oft untergeht

Artikel 14 Absatz 8 verpflichtet den Hersteller, die Nutzer des Produkts über die Schwachstelle oder den Vorfall zu informieren und gegebenenfalls über Maßnahmen, die die Nutzer selbst ergreifen können, erforderlichenfalls in maschinenlesbarem Format.

Das ist eine eigenständige Pflicht neben der Meldung an die Behörden, und für einen Plugin-Anbieter der sichtbarste Teil der Verordnung, weil ihn jeder Kunde mitbekommt. Ohne Vorbereitung scheitert genau dieser Teil am ehesten: Wenn du dein Plugin kostenlos über wordpress.org verteilst, kennst du deine Nutzer nicht. Du hast den Update-Kanal, die Release-Notes und die readme. Wer Updates ohnehin liegen lässt, bekommt die Information auch dann nicht, wenn du sie sauber verschickst, dazu steht mehr unter WordPress-Plugins aktualisieren.

Wohin die Meldung geht, und warum das heute noch hakt

Gemeldet wird gleichzeitig an das koordinierende CSIRT und an die ENISA, über die zentrale Meldeplattform nach Artikel 16, die Single Reporting Platform. Das empfangende CSIRT verteilt die Meldung an die CSIRTs der übrigen Mitgliedstaaten, in denen dein Produkt vertrieben wird.

So weit die Verordnung. Der Stand der Wirklichkeit am 21. August 2026 sah so aus:

• Die Plattform war nicht öffentlich erreichbar. Die ENISA formulierte es im Futur: Ab dem 11. September 2026 werde sie von CSIRTs und Herstellern für die Pflichtmeldungen genutzt.
• Es gab keinen öffentlichen Registrierungslink. Die produktive Adresse der Plattform war noch nicht veröffentlicht.
• Es gab Anleitungsdokumente der ENISA für Registrierung und Meldungsabgabe, zuletzt aktualisiert im Juli und August 2026, und eine Helpdesk-Adresse: cra-srp-helpdesk@enisa.europa.eu.
• Nach diesen Anleitungen läuft die Anmeldung über EU Login. Beim ersten Zugriff werden Rolle, zuständiges CSIRT, Rechtsvereinbarung und Herstellerdaten erfasst.

Ein ENISA-Update vom 3. August 2026 nimmt etwas Druck heraus. Die Validierung deines Kontos durch das koordinierende CSIRT ist keine Voraussetzung dafür, dass deine Meldepflicht erfüllt ist; sie läuft parallel, ein noch nicht freigeschaltetes Konto führt also nicht automatisch zum Pflichtverstoß. Die Weitergabe an CSIRTs weiterer Mitgliedstaaten erfolgt manuell. Und die ENISA empfiehlt, das EU-Login-Konto vorab anzulegen, die Registrierung auf der Plattform aber erst dann, wenn eine konkrete Meldung ansteht. Diese Punkte stammen aus einer Sekundärquelle, die ENISA-Anleitungsdokumente selbst waren nicht frei abrufbar.

Deutschland: BSI und CERT-Bund

Gemeldet wird an das CSIRT des Mitgliedstaats deiner Hauptniederlassung. Für Deutschland ist das das BSI mit CERT-Bund. Das BSI bestätigt auf seinen eigenen Seiten die Fristenstaffel einschließlich der Ein-Monats-Frist und verweist für die Plattform auf die ENISA.

Das deutsche Durchführungsgesetz war am 21. August 2026 noch nicht in Kraft. Das Gesetz zur Durchführung der Cyberresilienz-Verordnung liegt als Bundestagsdrucksache 21/6134 vom 26. Mai 2026 vor, erste Lesung am 11. Juni 2026, danach Überweisung in den Innenausschuss, der Bundesrat hatte keine Einwendungen. Es schafft keine neuen Pflichten. Es benennt Zuständigkeiten: Das BSI wird nationale Marktüberwachungsbehörde und notifizierende Behörde und ab dem 11. September 2026 CSIRT als Meldestelle. Ein Verfahrensstand nach Juni 2026 war zum Recherchezeitpunkt nicht auffindbar.

Der Vergleich mit dem AI Act ist aufschlussreich. Dort ist das deutsche Durchführungsgesetz seit dem 29. Juli 2026 in Kraft. Beim CRA steckt es im Verfahren, während die Verordnung heute unmittelbar gilt. Eine Verordnung wartet nicht auf das nationale Begleitgesetz.

Was die versäumte Meldung kostet

Artikel 64 Absatz 2 nennt für Verstöße gegen die grundlegenden Anforderungen aus Anhang I sowie gegen die Pflichten aus Artikel 13 und Artikel 14 Geldbußen von bis zu 15.000.000 Euro oder, bei Unternehmen, bis zu 2,5 Prozent des gesamten weltweiten Jahresumsatzes des vorangegangenen Geschäftsjahres, je nachdem, welcher Betrag höher ist. Diese letzte Formulierung wird oft weggelassen und dreht die Aussage um: Es ist keine Wahlmöglichkeit nach unten.

Zur Einordnung: Artikel 64 Absatz 3 sieht für andere Pflichten bis zu 10.000.000 Euro oder 2 Prozent vor, Absatz 4 für falsche, unvollständige oder irreführende Auskünfte an notifizierte Stellen und Marktüberwachungsbehörden bis zu 5.000.000 Euro oder 1 Prozent.

Und dann steht in Artikel 64 Absatz 10 eine Ausnahme, die kaum jemand kennt. Geldbußen gelten nicht für Hersteller, die Kleinstunternehmen oder kleine Unternehmen sind, soweit es um die Versäumung der Frist aus Artikel 14 Absatz 2 Buchstabe a oder Artikel 14 Absatz 4 Buchstabe a geht. Das sind die beiden 24-Stunden-Frühwarnungen. Ebenfalls von Geldbußen nach dieser Vorschrift ausgenommen sind Open-Source-Software-Stewards.

Diese Ausnahme ist eng, und sie wird regelmäßig zu weit gelesen. Sie betrifft die Frist der Frühwarnung. Sie befreit nicht von der Meldepflicht selbst, sie erfasst nicht die 72-Stunden-Meldung und sie erfasst nicht den Abschlussbericht. Ein kleiner Anbieter, der überhaupt nicht meldet, steht damit genauso im Bußgeldrahmen wie ein großer.

Die ersten 24 Stunden, praktisch

Der folgende Ablauf ist eine Arbeitsvorlage, keine Wiedergabe gesetzlicher Formularvorgaben. Die Verordnung nennt Fristen und Adressaten; welche Felder das Meldeformular der Plattform tatsächlich verlangt, war am 21. August 2026 nicht öffentlich einsehbar. Was hier steht, ist das, was du für eine Meldung ohnehin zusammentragen musst.

Stunde 0. Die Meldung trifft ein, per Mail an deine Sicherheitsadresse, über das Support-Forum oder über eine Disclosure-Plattform. Halte Datum und Uhrzeit minutengenau fest. Das ist der Beginn der Frist und die eine Angabe, die du später nicht mehr rekonstruieren kannst.

Erste Stunde. Eine Person entscheidet, welcher Strang. Gibt es Hinweise auf tatsächliche Ausnutzung, etwa Logeinträge, kompromittierte Installationen, ein öffentliches Exploit? Dann Strang 1. Ist etwas passiert, das die Schutzwirkung des Produkts beeinträchtigt, etwa ein untergeschobenes Update oder ein Einbruch in deine Build-Infrastruktur? Dann Strang 2. Beides zugleich ist möglich, im Zweifel gilt der schärfere Strang. Die Entscheidung wird schriftlich festgehalten.

Bis Stunde vier. Umfang bestimmen: welches Produkt, welche Versionen, seit wann, welche Konstellation überhaupt betroffen ist, ob es eine Gegenmaßnahme ohne Update gibt. Parallel den Kontakt zum Melder halten, damit er nicht in der Zwischenzeit veröffentlicht.

Bis Stunde 24. Frühwarnung abgeben. Sie heißt Frühwarnung, nicht Analyse, und darf offene Punkte enthalten.

Was du für die Frühwarnung brauchst

• Produktname, betroffene Versionen, Anbieterdaten.
• Zeitpunkt und Quelle deiner Kenntnis.
• Kurze Beschreibung dessen, was passiert ist, und woraus du auf Ausnutzung schließt.
• Erste Einschätzung der Auswirkung und der betroffenen Verbreitung.
• Die Mitgliedstaaten, in denen das Produkt verfügbar ist. Bei einem Plugin im offenen Verzeichnis ist das die ganze Union.
• Was bereits läuft, und wann du mit einer Abhilfe rechnest.

Was in dein eigenes Protokoll gehört

Das Protokoll ist die unspektakulärste und nützlichste Hälfte der Arbeit. Es beantwortet später die Frage, ob du die Fristen gehalten hast. Ein Textfile im Repository reicht, solange es geführt wird.

• Zeitpunkt und Quelle der Kenntnis.
• Die Entscheidung, welcher Strang, mit Begründung in zwei Sätzen.
• Zeitpunkt der Frühwarnung, der 72-Stunden-Meldung und des Abschlussberichts, jeweils mit Empfänger.
• Zeitpunkt, ab dem eine Abhilfe verfügbar war. Von diesem Punkt aus rechnest du die 14 Tage im Schwachstellenstrang.
• Die Fassung der Kundeninformation, so wie sie hinausgegangen ist, und wann.
• Betroffene Versionen und die Version, die den Fix enthält.

Wie die Kundeninformation aussieht

Kurz, sachlich, ohne Beschwichtigung. Betroffene Versionen nennen, sagen, was ein Nutzer jetzt tun soll, sagen, ab welcher Version das Problem behoben ist. Wenn es eine Zwischenmaßnahme gibt, steht sie ganz oben. Bei einem WordPress-Plugin ist der Ort dafür die readme mit dem Changelog-Eintrag und dem Update selbst, dazu die Sicherheitsseite und, wenn du eine Kundenliste hast, eine Mail. Der maschinenlesbare Teil aus Artikel 14 Absatz 8 ist bei einem Plugin praktisch die Versionsangabe im Update-Kanal.

Was vorher stehen muss, damit du im Ernstfall nicht suchst

• Ein veröffentlichter Sicherheitskontakt, am besten ein eigenes Postfach und nicht das Support-Forum.
• Eine /.well-known/security.txt nach RFC 9116, damit Melder den Weg finden, ohne zu raten.
• Eine Richtlinie zur koordinierten Offenlegung: was du zusagst, was du erbittest, welcher Geltungsbereich.
• Ein Weg, alle betroffenen Nutzer zu erreichen. Für kostenlose Verzeichnis-Plugins ist das der Update-Kanal samt readme, für verkaufte Produkte die Kundenliste.
• Ein fester Ort für das Protokoll, angelegt, bevor du ihn brauchst.

Ein Wochenende dauert das nicht. Mitten in einem Vorfall dauert es zu lange. Welche Werkzeuge dabei helfen, deine Installationen im Blick zu behalten, steht im Vergleich der Sicherheits-Plugins.

Wo wir selbst stehen

Weil ein Ratgeber, der nur fordert, wenig wert ist: Bei uns gibt es eine Sicherheitsseite mit veröffentlichtem Sicherheitskontakt, zugesagten Antwortzeiten, Geltungsbereich und der Richtlinie zur koordinierten Offenlegung, dazu eine /.well-known/security.txt nach RFC 9116, die auf diese Seite verweist. Für die Selbstauskunft dahinter gibt es ein kostenloses Werkzeug: Die CRA-Selbstauskunft erzeugt aus deinen Angaben eine security.txt, einen readme-Abschnitt für wordpress.org und öffentliche Sicherheitsangaben für deine Website. Sie läuft im Browser, erhebt keine E-Mail-Adresse und speichert nichts.

Was bei uns noch nicht steht, gehört genauso hierher. Für unsere kostenlosen Plugins im WordPress-Verzeichnis, etwa Wellenbrecher, kennen wir die Installationen nicht; unser Weg zu diesen Nutzern ist der Update-Kanal und die readme, sonst nichts. Eine Registrierung auf der Meldeplattform ist bislang nicht möglich, vorbereiten lässt sich nur das EU-Login-Konto. Und unser Vorfallprotokoll liegt intern, es ist keine öffentliche Seite.

Häufige Fragen