Cyber Resilience Act: Was ab 2027 für Web-Apps und WordPress-Plugins gilt

Seit 11. September 2026 müssen Hersteller, deren Software in der EU angeboten wird, Sicherheitslücken melden, die Angreifer bereits ausnutzen. Ab 11. Dezember 2027 gilt der Cyber Resilience Act dann vollständig. Der Kern ist einfach: Wer Software geschäftlich an andere weitergibt, muss sie über Jahre mit Sicherheitsupdates versorgen. Nicht jede Web-App und nicht jede WordPress-Seite fällt aber darunter. Entscheidend ist, wo die Software läuft und wie sie zu den Menschen kommt, die sie verwenden.

Dieser Beitrag gehört zur Serie Website oder Web-App?. Alle Stichtage auf einen Blick findest du auf der Seite Fristen & Gesetze.

Was der Cyber Resilience Act regelt

Der Cyber Resilience Act (kurz CRA) ist eine EU-Verordnung. Offiziell heißt er Verordnung (EU) 2024/2847. In Kraft ist er seit 10. Dezember 2024, seine Pflichten gelten aber schrittweise. Er legt Mindestregeln für die Sicherheit von Geräten und Software fest, die sich mit einem anderen Gerät oder einem Netzwerk verbinden können. Das Gesetz nennt sie „Produkte mit digitalen Elementen“.

Im CRA gibt es zwei Rollen, die du für diesen Beitrag kennen musst:

• Hersteller: Wer Software entwickelt und sie unter eigenem Namen an andere weitergibt. Er trägt fast alle Pflichten.
• Nutzer oder Betreiber: Wer Software einsetzt, zum Beispiel Plugins auf der eigenen Website. Für ihn sieht der CRA keine eigenen Pflichten vor.

Ein Preis ist nicht nötig, damit jemand als Hersteller gilt. Entscheidend ist, ob die Software Teil eines Geschäfts ist. Es reicht, wenn jemand indirekt damit Geld verdient, etwa über eine kostenpflichtige Zusatzversion.

Die Pflichten kommen in zwei Stufen:

• Seit 11. September 2026: Hersteller müssen Lücken melden, die Angreifer bereits ausnutzen, und schwere Sicherheitsvorfälle.
• Ab 11. Dezember 2027: Alle übrigen Pflichten gelten, von der sicheren Entwicklung bis zur CE-Kennzeichnung.

Als EU-Verordnung gilt der CRA in Deutschland und Österreich direkt, ohne eigenes Landesgesetz. In der Schweiz ist er kein Schweizer Recht. Laut dem deutschen Bundesamt für Sicherheit in der Informationstechnik (BSI) betrifft er aber jeden Hersteller, der Produkte in der EU anbietet, egal wo sein Firmensitz ist.

Die entscheidende Frage: Wo läuft die Software?

Am 27. Juli 2026 hat die EU-Kommission Leitlinien zum Cyber Resilience Act veröffentlicht. Sie sind nicht rechtlich bindend, zeigen aber, wie die Kommission das Gesetz versteht. Die wichtigste Klarstellung für Webentwickler: Software fällt nur dann unter den CRA, wenn sie dem Kunden übergeben wird und auf seinem eigenen Gerät oder Server läuft. Läuft sie auf dem Server des Anbieters und wird nur über den Browser genutzt, fällt sie für sich allein nicht darunter.

Die Kommission nennt dazu ausdrücklich Web-Apps, die nur im Browser genutzt werden. Das gilt auch für Web-Apps, die man als Symbol auf den Startbildschirm des Handys legen kann. Auch eine Website, die nur informiert, fällt nicht darunter. Anders ist es bei Apps aus dem App-Store, Desktop-Programmen und Browser-Erweiterungen. Die werden beim Nutzer installiert und fallen darunter, wenn sie geschäftlich angeboten werden.

Du betreibst eine Website oder hast eine App bauen lassen

Wenn du eine WordPress-Seite betreibst und Plugins nutzt, hast du keine eigenen Pflichten aus dem CRA. Du musst nichts melden und nichts kennzeichnen. Das Gesetz verändert aber den Markt, auf den du angewiesen bist:

• Du siehst, wie lange es Updates gibt. Für neue und wesentlich geänderte Versionen ab Ende 2027 müssen Hersteller angeben, bis wann sie Sicherheitsupdates liefern. Das hilft dir bei der Auswahl von Plugins.
• Manche Anbieter steigen aus. Kleine Plugin-Anbieter könnten den Aufwand scheuen und ihr Plugin aufgeben. Ein verlassenes Plugin bekommt keine Updates mehr und wird zum Risiko.
• Updates einspielen bleibt deine Aufgabe. Laut EU-Kommission ist der Hersteller nicht verantwortlich, wenn ein Update nicht installiert wird.
• Eine Liste deiner Plugins hilft. Wer weiß, welche Plugins und Versionen auf der eigenen Seite laufen, merkt schneller, wenn eines ausläuft.

Hast du dir eine Web-App von einer Agentur bauen lassen, kommt es darauf an, wo sie läuft. Betreibt die Agentur die App und du nutzt sie nur im Browser, fällt sie in der Regel nicht unter den CRA. Hat die Agentur dir den Code geliefert und die App läuft auf deinem Server, ist meist die Agentur der Hersteller. Frag sie in beiden Fällen, wie lange sie Sicherheitsupdates liefert, und lass dir das in den Vertrag schreiben.

Für Unternehmen in bestimmten Branchen gibt es eine eigene EU-Regel zur Cybersicherheit, die NIS2-Richtlinie. Sie betrifft vor allem Bereiche wie Energie, Gesundheit, Transport oder digitale Dienste und meist erst Unternehmen ab 50 Mitarbeitenden oder 10 Millionen Euro Jahresumsatz.

WordPress-Plugins: Wer ist Hersteller?

Ein WordPress-Plugin wird auf dem Server des Website-Betreibers installiert und läuft dort. Es ist damit Software, die beim Nutzer läuft. WordPress nennen die Leitlinien zwar nicht ausdrücklich, die Logik passt aber. Fast alle WordPress-Plugins stehen unter der GPL, einer freien Lizenz: Der Code ist für alle einsehbar und darf verändert werden. Das allein nimmt ein Plugin aber nicht vom CRA aus. Die Kommission schaut darauf, ob das Plugin Teil eines Geschäfts ist.

• Pro-Version oder Kaufplugin: Die bezahlte Version fällt unter den CRA. Der Anbieter ist Hersteller und hat alle Pflichten.
• Gratis-Version einer Firma: Bietet eine Firma eine Gratis-Version an, etwa neben einer Pro-Version, gilt diese Gratis-Version nicht als auf den Markt gebracht. Die Firma hat dafür aber leichtere Pflichten. Das Gesetz nennt sie dann „Verwalter quelloffener Software“. Dazu gehören eine Sicherheitsrichtlinie, die Zusammenarbeit mit den Behörden und die Meldung von Lücken, die Angreifer ausnutzen. Anders ist es, wenn über das Gratis-Plugin selbst Bezahltes verkauft oder freigeschaltet wird, etwa Erweiterungen oder Lizenzen. Dann hat die Firma alle Herstellerpflichten.
• Gratis-Plugin einer Privatperson: Fällt nicht unter den CRA, wenn damit kein Geld verdient wird. Freiwillige Spenden ändern daran in der Regel nichts, solange sie nicht wie ein Kaufpreis wirken.
• Bezahlter Support zu einem Gratis-Plugin: Macht das Plugin laut Kommission nicht automatisch zum Produkt. Entscheidend ist, ob man für die Software selbst oder für ihre Updates zahlen muss.
• Plugin, das nur gegen Daten nutzbar ist: Verlangt ein Gratis-Plugin persönliche Daten als Bedingung, etwa für Werbung oder Auswertungen, zählt das als Geschäft.

Und Agenturen? Installiert eine Agentur ein fremdes Open-Source-Plugin für einen Kunden und verändert es nicht wesentlich, wird sie dadurch nicht zum Hersteller. So steht es in den Leitlinien der Kommission. Anders ist es, wenn sie ein eigenes Plugin verkauft oder ein Plugin für einen Kunden programmiert und gegen Bezahlung liefert. Laut BSI gilt der CRA auch für Einzelanfertigungen, egal wie viele Stück es gibt. Wo genau die Grenze bei individuellen Themes und kleinen Code-Anpassungen liegt, ist noch nicht abschließend geklärt.

Für Plugins, die schon vor dem 11. Dezember 2027 auf dem Markt sind, gibt es eine Übergangsregel. Die neuen Anforderungen gelten für sie erst, wenn eine neue Version das Plugin wesentlich verändert. Reine Sicherheitsupdates zählen in der Regel nicht dazu. Bei neuen Funktionen kommt es laut Kommission nicht auf die Größe an, sondern darauf, ob sie neue Risiken bringen. Schon eine kleine Funktion wie „Angemeldet bleiben“ kann reichen. Die Meldepflicht gilt aber schon jetzt auch für Plugins, die vor 2027 auf den Markt kamen, sofern sie unter den CRA fallen.

Laravel-Web-Apps: Betrieben oder geliefert?

Viele eigene Web-Apps sind mit Laravel gebaut. Laravel ist ein Baukasten für Web-Anwendungen. Der Code läuft auf einem Server, genutzt wird die App im Browser. Ob so eine App unter den CRA fällt, hängt davon ab, wo der Code liegt und wer den Server betreibt.

• Der Anbieter betreibt die App, der Kunde nutzt sie nur im Browser: Das fällt laut Kommission in der Regel nicht unter den CRA.
• Der Code wird geliefert und die App läuft auf dem Server des Kunden: Dann gilt das rechtlich als „auf den Markt bringen“, auch wenn es nur einen einzigen Kunden gibt. Die Kommission nennt genau dieses Beispiel: Wer Quellcode an eine Firma für deren interne Plattform liefert, fällt unter den CRA. Das gilt auch, wenn die Firma den Code noch anpassen muss.
• Zur Web-App gehört eine App fürs Handy oder ein Desktop-Programm: Dann fällt diese App unter den CRA. Der Server-Teil, ohne den sie nicht funktioniert, gehört dazu.
• Die App ist nur für die eigene Firma: Software, die nur im eigenen Unternehmen genutzt und nicht weitergegeben wird, kommt nicht auf den Markt. Der CRA greift dann nicht.

Für Maßanfertigungen gibt es eine kleine Ausnahme. Wird eine Software exklusiv für ein bestimmtes Unternehmen gebaut, dürfen beide per Vertrag vereinbaren, dass Sicherheitsupdates etwas kosten. Auch bei den sicheren Voreinstellungen ab Werk dürfen sie abweichen. Das muss ausdrücklich vereinbart sein, und ein Standardprodukt mit kleinen Anpassungen gilt nicht als Maßanfertigung. Lücken beheben und Updates liefern muss der Hersteller trotzdem.

Auch wenn eine Web-App nicht unter den CRA fällt, ist das kein Freibrief. Für Software, die ab 9. Dezember 2026 auf den Markt kommt, gilt die neue Produkthaftung. Mehr dazu im Beitrag Produkthaftung für Software. Und eine App ohne Updates wird mit jeder neu bekannten Lücke angreifbarer. Welche Laravel- und PHP-Versionen wann auslaufen, steht im Beitrag Wartung einer Web-App.

Was Hersteller ab 11. Dezember 2027 tun müssen

Wer Hersteller ist, hat ab Dezember 2027 eine Reihe von Pflichten. Die wichtigsten in einfachen Worten:

• Sicher entwickeln: Die Risiken bewerten und die Software so bauen, dass sie keine bekannten ausnutzbaren Lücken hat.
• Bausteine kennen: Eine Stückliste der verwendeten Software-Bausteine führen, mindestens aller direkt eingebundenen, in einem Format, das Programme lesen können. Fachleute nennen das SBOM, „Software Bill of Materials“.
• Meldungen annehmen: Eine Kontaktstelle anbieten, an die andere Sicherheitslücken melden können.
• Updates liefern: Gefundene Lücken schnell beheben und die Sicherheitsupdates kostenlos ausliefern, wo technisch möglich getrennt von neuen Funktionen.
• Supportzeitraum festlegen: Er muss mindestens fünf Jahre dauern, außer das Produkt wird erwartbar kürzer genutzt. Wird es länger genutzt, muss der Zeitraum länger sein.
• Supportende angeben: Beim Kauf muss klar stehen, bis wann es Sicherheitsupdates gibt, mindestens mit Monat und Jahr.
• Updates verfügbar halten: Jedes Sicherheitsupdate muss mindestens zehn Jahre lang abrufbar bleiben, oder bis zum Ende des Supportzeitraums, wenn das länger ist.
• Dokumentieren und kennzeichnen: Eine technische Dokumentation führen und schriftlich bestätigen, dass die Software die Regeln erfüllt. Fachleute nennen das Konformitätserklärung. Dazu kommt das CE-Zeichen, wie man es von Elektrogeräten kennt. Bei den meisten Plugins und Apps darf der Hersteller das selbst prüfen. Strengere Regeln gelten für Produkte, deren Hauptzweck zum Beispiel Passwortverwaltung, Zugangsverwaltung oder ein VPN ist. Ein Login-Formular allein reicht dafür nicht.

Bei Verstößen gegen die wesentlichen Anforderungen und die Herstellerpflichten sieht der CRA Bußgelder von bis zu 15 Millionen Euro oder 2,5 Prozent des weltweiten Jahresumsatzes vor, je nachdem, was höher ist. Für Verwalter quelloffener Software gibt es laut EU-Kommission keine Bußgelder.

Die Meldepflicht seit September 2026

Seit 11. September 2026 müssen Hersteller zwei Dinge melden: Lücken, die Angreifer bereits ausnutzen, und schwere Sicherheitsvorfälle, die ihr Produkt betreffen. Gemeldet wird über die zentrale Meldeplattform der EU-Agentur für Cybersicherheit (ENISA). Die Fristen laut BSI:

• 24 Stunden: Frühwarnung, sobald der Hersteller davon erfährt.
• 72 Stunden: Meldung mit weiteren Informationen.
• 14 Tage: Abschlussbericht zur Lücke, nachdem ein Update oder eine Gegenmaßnahme verfügbar ist.
• Ein Monat nach der 72-Stunden-Meldung: Abschlussbericht zu einem schweren Vorfall.

Die Meldepflicht gilt auch für Produkte, die schon vor 2027 auf dem Markt waren, sofern sie unter den CRA fallen. Kleinst- und Kleinunternehmen, also Firmen mit weniger als 50 Mitarbeitenden und höchstens 10 Millionen Euro Jahresumsatz, bekommen laut EU-Kommission kein Bußgeld, wenn sie die 24-Stunden-Frist versäumen. Melden müssen sie trotzdem, und für die 72-Stunden-Meldung gilt diese Ausnahme nicht. Mehr dazu im Beitrag Cyber Resilience Act: Meldepflicht für Sicherheitslücken.

# Lücken in den Composer-Paketen prüfen
composer audit

# Stückliste (SBOM) im CycloneDX-Format erzeugen
composer require --dev cyclonedx/cyclonedx-php-composer
composer CycloneDX:make-sbom --output-format=JSON --output-file=sbom.json

Checkliste: Betrifft es dich?

Hake ab, was auf dich zutrifft. Dein Stand bleibt in diesem Browser gespeichert.

1. Ich gebe Software an andere weiter. Zum Beispiel ein Plugin, ein Theme, eine App oder Quellcode für den Server eines Kunden.
2. Die Software ist Teil meines Geschäfts. Direkt über einen Preis oder eine Pro-Version, oder indirekt über Dienste, die nur mit der Software funktionieren.

Hast du beide Punkte abgehakt, bist du sehr wahrscheinlich Hersteller im Sinne des CRA. Dann zeigt dir der zweite Teil, was zu tun ist. Lücken melden musst du schon jetzt können, den Rest bis spätestens Dezember 2027.

Checkliste: Bist du bereit?

1. Ich weiß, welche Bausteine meine Software nutzt. Es gibt eine aktuelle Liste aller Pakete und Bibliotheken.
2. Ich habe eine Kontaktstelle für Sicherheitsmeldungen. Sie ist öffentlich auffindbar.
3. Ich kann eine ausgenutzte Lücke innerhalb von 24 Stunden melden. Ich weiß, wer das macht und wie die Meldeplattform funktioniert.
4. Ich habe einen Supportzeitraum festgelegt. Er dauert mindestens fünf Jahre oder so lange, wie die Software erwartbar genutzt wird.
5. Ich kann Sicherheitsupdates schnell und kostenlos ausliefern. Wo technisch möglich, getrennt von neuen Funktionen. Das verlangt der CRA.

Was noch offen ist

Viele Grenzfälle sind noch nicht geklärt. Die Leitlinien der Kommission sind nicht bindend, und Gerichte haben noch nicht entschieden. Dieser Beitrag ist keine Rechtsberatung. Wenn du unsicher bist, ob deine Software darunter fällt, lass das von einer Anwältin oder einem Anwalt mit Erfahrung im IT-Recht prüfen.

Häufige Fragen

Gilt der Cyber Resilience Act für WordPress-Plugins?

Ja, wenn das Plugin Teil eines Geschäfts ist. Das ist bei Kaufplugins und Pro-Versionen der Fall. Für die Gratis-Version einer Firma gelten leichtere Pflichten. Ein Gratis-Plugin einer Privatperson, mit dem kein Geld verdient wird, fällt nicht darunter.

Fällt meine Laravel-Web-App unter den CRA?

Wenn sie nur im Browser genutzt wird und auf dem Server des Anbieters läuft, in der Regel nicht. Wenn der Code an einen Kunden geliefert wird und auf dessen Server läuft, oder wenn eine App zum Installieren dazugehört, dann schon.

Ich habe mir eine App bauen lassen. Muss ich etwas tun?

Eigene Pflichten aus dem CRA hast du als Auftraggeber in der Regel nicht. Läuft die App auf deinem Server, ist meist die Agentur Hersteller. Lass dir im Vertrag festhalten, wie lange sie Sicherheitsupdates liefert und was sie kosten.

Wie lange muss ein Hersteller Sicherheitsupdates liefern?

Mindestens fünf Jahre, außer die Software wird erwartbar kürzer genutzt. Wird sie länger genutzt, muss der Supportzeitraum länger sein. Das Ende muss beim Kauf angegeben werden, mindestens mit Monat und Jahr.

Muss ich als Website-Betreiber etwas melden?

Nicht nach dem CRA. Die Meldepflicht trifft die Hersteller der Software, nicht die Betreiber von Websites. Bei einer Datenpanne kann aber die DSGVO eine Meldung an die Datenschutzbehörde innerhalb von 72 Stunden verlangen.

Gilt der CRA auch für Anbieter aus der Schweiz?

Ja, wenn sie Software in der EU anbieten. Laut BSI gilt der CRA unabhängig davon, wo der Hersteller seinen Sitz hat.

Du willst wissen, ob deine Software oder deine Web-App betroffen ist? Schreib mir über die Kontaktseite. Ich schaue mir an, wie deine Software zu den Nutzern kommt und was bis Dezember 2027 zu tun ist. Wie ich Websites und eigene Programme laufend betreue, steht auf den Seiten WordPress-Wartung und Laravel-Wartung.

Quellen

• EU-Kommission: Leitlinien zur Anwendung des Cyber Resilience Act, C(2026) 5252, 27.07.2026 (PDF, englisch)
• EU-Kommission: Cyber Resilience Act – Zusammenfassung
• EU-Kommission: CRA Implementation FAQ
• BSI: Cyber Resilience Act
• EUR-Lex: Verordnung (EU) 2024/2847 (Cyber Resilience Act)
• Patchstack: Managed CRA Article 14 reporting for open source maintainers
• CycloneDX: cyclonedx-php-composer