CRA-Meldepflicht für Shopware-Plugins: Wann Hersteller handeln müssen
7 Min. Lesezeit
von Marcel, Senior-Softwareentwickler
Ein Kunde meldet verdächtige Zugriffe auf seinen Shop. In einem von dir veröffentlichten Shopware-Plugin steckt möglicherweise die Ursache. Musst du das jetzt nach dem Cyber Resilience Act (CRA) melden – und wenn ja, bis wann? Für Anbieter kommerzieller Erweiterungen ist diese Frage seit dem 11. September 2026 akut. An diesem Tag begann die Meldepflicht für Hersteller digitaler Produkte; die meisten übrigen CRA-Produktanforderungen gelten erst ab 11. Dezember 2027. Die EU-Verordnung gilt unmittelbar, ohne dass Deutschland diese Fristen erst in ein eigenes Gesetz übertragen müsste. EU-Kommission zum Zeitplan
Dieser Leitfaden zeigt, wie du eine Meldung technisch vorbereitest. Er ist keine verbindliche Einstufung deiner Erweiterung oder eines konkreten Vorfalls. Stand: 25. September 2026.
Das Wichtigste in Kürze
Wer? Wer eine kommerziell angebotene Software-Erweiterung unter eigenem Namen auf den EU-Markt bringt, sollte prüfen, ob er als Hersteller eines Produkts mit digitalen Elementen unter den CRA fällt. Der bloße Betrieb eines Shopware-Shops macht dich nicht zum Hersteller seiner Plugins.
Was? Zu melden sind aktiv ausgenutzte Schwachstellen im eigenen Produkt und schwerwiegende Vorfälle, die dessen Sicherheit betreffen. Ein CVE-Eintrag oder ein theoretischer Fehler allein löst diese Pflicht nicht automatisch aus.
Wann? Frühwarnung binnen 24 Stunden und weitere Meldung binnen 72 Stunden, jeweils ab Kenntnis des meldepflichtigen Sachverhalts und ohne unnötige Verzögerung. Der Abschlussbericht hat je nach Vorfall einen anderen Startpunkt.
Wie? Die Meldung erfolgt über die
einheitliche ENISA-Meldeplattform
. Eine Schnittstelle für automatisches Einreichen bietet sie derzeit nicht.
Fällt ein Shopware-Plugin überhaupt unter den CRA?
Der CRA erfasst Hard- und Softwareprodukte, die auf dem EU-Markt bereitgestellt werden; dazu können auch separat angebotene Software-Komponenten gehören. Hersteller ist grundsätzlich, wer ein solches Produkt unter eigenem Namen oder eigener Marke in Verkehr bringt. Aus dieser Regel folgt: Ein kommerziell angebotenes Shopware-Plugin kann erfasst sein. Die EU-Kommission hat aber keine pauschale Sonderregel „jedes Shopware-Plugin ist betroffen“ veröffentlicht. Vertriebsweg, tatsächliches Produkt, Rolle und mögliche Ausnahmen gehören in die konkrete Prüfung. Verordnung (EU) 2024/2847, Zusammenfassung der Kommission
Tabelle seitlich wischen →
| Deine Rolle | Was sich daraus für diese Meldung ergibt |
|---|---|
| Du veröffentlichst eine kommerzielle Shopware-Erweiterung unter eigenem Namen. | Prüfe die Herstellerrolle und richte bei Betroffenheit einen Meldeprozess für dein Produkt ein. |
| Du betreibst einen Shop und nutzt Erweiterungen anderer Anbieter. | Der bloße Einsatz macht dich nicht zum Hersteller dieser Erweiterungen. Melde Sicherheitsprobleme an den jeweiligen Anbieter und sichere deinen Shop. Andere Pflichten, etwa aus Datenschutz- oder Sicherheitsrecht, können unabhängig davon bestehen. |
| Du entwickelst nur im Auftrag oder pflegst fremde Plugins. | Kläre vertraglich und fachlich, wer das Produkt unter eigenem Namen bereitstellt und wer Meldungen für diesen Hersteller bearbeitet. Der Code-Autor und der rechtliche Hersteller müssen nicht dieselbe Person sein. |
Für nichtkommerziell bereitgestellte freie Software und sogenannte Open-Source-Software-Verwalter gelten besondere Regeln. Deren CRA-Meldepflicht nach Artikel 24 Absatz 3 startet erst am 11. Dezember 2027. Ein kostenloser Download allein entscheidet jedoch nicht, ob eine Bereitstellung im Rahmen einer kommerziellen Tätigkeit erfolgt. EU-Kommission, ENISA-FAQ
Welche Sicherheitsmeldung löst die 24 Stunden aus?
Artikel 14 der CRA-Verordnung nennt zwei Fälle:
- Aktiv ausgenutzte Schwachstelle: Es gibt verlässliche Hinweise, dass ein böswilliger Akteur die Schwachstelle ohne Erlaubnis in einem System ausgenutzt hat.
- Schwerwiegender Sicherheitsvorfall im Produkt: Der Vorfall beeinträchtigt oder gefährdet beispielsweise den Schutz wichtiger Daten oder Funktionen; Artikel 14 Absatz 5 nennt die Kriterien.
Ein automatischer Dependency-Scan meldet eine anfällige Bibliothek? Das ist ein Anlass zur sofortigen Analyse, aber noch kein Beleg, dass gerade dein Plugin aktiv ausgenutzt wird. Umgekehrt darfst du einen glaubhaften Hinweis aus einem Kundenshop nicht bis zum fertigen Patch liegen lassen. Prüfe, welche deiner veröffentlichten Versionen die Funktion enthalten, ob der anfällige Code im konkreten Produkt erreichbar ist, was die Logs belegen und ob weitere Kunden betroffen sein können. Bei einer Schwachstelle in einer eingebundenen Fremdkomponente ist die eigene Produktbetroffenheit gesondert zu bewerten; die ENISA-FAQ verweist dafür ausdrücklich auf die Kommissionsleitlinien.
Ein fiktives Beispiel: Ein Plugin für den Datenexport erlaubt in Version 1.8 unberechtigten Zugriff auf Exportdateien. Ein Kunde liefert Log-Auszüge, die einen tatsächlichen Abruf durch Dritte nahelegen. Der Hersteller hält Zeitpunkt und Herkunft des Hinweises fest, prüft die betroffene Version und bewertet mit Sicherheitsverantwortlichen, ob verlässliche Hinweise auf aktive Ausnutzung vorliegen. Der Fix, die Information der betroffenen Kunden und die CRA-Meldung laufen dann parallel. Ohne diesen Nachweis wäre der Fehler trotzdem zu beheben; die Pflichtmeldung wegen aktiver Ausnutzung lässt sich allein aus der Existenz des Fehlers nicht ableiten.
Der Meldeablauf: 24 Stunden, 72 Stunden, Abschlussbericht
Der Ausgangspunkt für die ersten beiden Fristen ist die Kenntnis des Herstellers vom meldepflichtigen Sachverhalt – nicht das Datum, an dem ein Ticket angelegt, ein Patch fertig oder eine CVE-Nummer vergeben wurde. Die EU-Kommission und ENISA unterscheiden diese Stufen:
Tabelle seitlich wischen →
| Stufe | Frist | Was du vorbereitest |
|---|---|---|
| Frühwarnung | Ohne unnötige Verzögerung, spätestens 24 Stunden ab Kenntnis | Produkt und Vorfallart, Zeitpunkt der Kenntnis, erreichbare Fakten und gegebenenfalls betroffene EU-Staaten. Fehlende Erkenntnisse als offen kennzeichnen. |
| Weitere Meldung | Ohne unnötige Verzögerung, spätestens 72 Stunden ab Kenntnis | Allgemeine Angaben zu Produkt, Ausnutzung oder Vorfall, erste Bewertung, bereits ergriffene Gegenmaßnahmen und mögliche Schritte der Nutzer. |
| Abschlussbericht: aktiv ausgenutzte Schwachstelle | Spätestens 14 Tage nachdem eine Korrektur- oder Risikominderungsmaßnahme verfügbar ist | Auswirkung und Schwere, soweit verfügbar Informationen zur Ausnutzung, Patch oder andere Gegenmaßnahme. |
| Abschlussbericht: schwerwiegender Vorfall | Innerhalb eines Monats nach der 72-Stunden-Meldung | Aktualisierte Vorfallsbeschreibung, Ursache soweit bekannt und ergriffene Maßnahmen. |
Praktisches Detail: Der 72-Stunden-Zähler in der aktuellen ENISA-Plattform rechnet laut ENISA-FAQ, Frage 26 derzeit 48 Stunden ab Einreichen der Frühwarnung. Dadurch kann die Oberfläche eine Meldung als überfällig markieren, obwohl seit Kenntnis des Vorfalls noch keine 72 Stunden vergangen sind. Dokumentiere den tatsächlichen Kenntniszeitpunkt und berechne die gesetzliche Frist selbst. Reiche Meldungen trotzdem ohne unnötige Verzögerung ein; der Zählerfehler ist kein Grund zum Warten.
So bereitest du deinen Plugin-Betrieb vor
Du brauchst dafür kein neues Compliance-System. Du brauchst einen Weg, der auch an einem Freitagabend funktioniert:
- Eingang festlegen: Eine auffindbare Sicherheitsadresse oder ein Meldeformular, dazu eine Vertretung und ein Alarmweg für dringende Hinweise.
- Versionen zuordnen: Eine Liste der veröffentlichten Plugin-Versionen, enthaltenen Abhängigkeiten, unterstützten Shopware-Versionen und zugehörigen Kunden oder Installationen, soweit dir diese Daten rechtmäßig vorliegen.
- Fakten sichern: Eingang und Kenntniszeitpunkt, betroffene Version, technische Hinweise, Log-Belege, erste Bewertung und getroffene Maßnahmen in einem Vorgang dokumentieren. Sicherheitsbelege nur berechtigten Personen zugänglich machen.
- Meldeweg einrichten: Die zuständige Person sollte den ENISA-Zugang mit EU Login und Mehrfaktor-Authentifizierung kennen. Die Meldung geht über die Plattform an den für die Hauptniederlassung zuständigen koordinierenden CSIRT und an ENISA.
- Kunden erreichen: Plane, wie du betroffene Betreiber über ein Update oder eine vorläufige Risikominderung informierst, auch wenn noch nicht alle technischen Details geklärt sind.
Die ENISA-Plattform unterstützt derzeit keine API für die automatische Einreichung. Ein internes Tool kann Versionsdaten, Belege und Fristen bündeln oder Felder vorbereiten; die Meldung erfolgt aktuell in der Plattformoberfläche. Die Entscheidung, ob ein Vorfall die gesetzlichen Kriterien erfüllt, verlangt weiterhin eine fachliche Prüfung. ENISA-FAQ, Frage 15
Auch bei einem Ausfall der Plattform verschwindet die Aufgabe nicht: ENISA empfiehlt, die Meldung nach Wiederverfügbarkeit dort einzureichen; bei dringendem Kommunikationsbedarf kann der zuständige CSIRT vorher direkt kontaktiert werden. Den Plattformbericht ersetzt dieser Kontakt nicht.
Quellen und nächster Schritt
- Verordnung (EU) 2024/2847, insbesondere Artikel 3, 14, 16 und 71
- EU-Kommission: CRA-Meldepflichten und Fristen
- EU-Kommission: Anwendungsbereich und zeitliche Staffelung
- ENISA: aktuelle FAQ zur Meldeplattform
Du veröffentlichst eine Shopware-Erweiterung und weißt nicht, ob dein Sicherheitsprozess im Ernstfall trägt? Schick uns über das Kontaktformular den Vertriebsweg, die Zahl deiner aktiven Plugin-Versionen und den bisherigen Weg für Sicherheitsmeldungen. Wir prüfen mit dir, wie Hinweise, Versionen, Updates und Kundenkommunikation technisch zusammenlaufen können. Die rechtliche Einstufung von Produkt und Meldepflicht lässt du anschließend fachkundig abnehmen. Wie wir Erweiterungen entwickeln und pflegen, steht auf unserer Seite zu Shopware-Plugins.