Der Cyber Resilience Act rückt für viele Website-Teams näher an den Alltag heran, als es auf den ersten Blick wirkt. Die EU-Verordnung richtet sich zwar nicht an jede normale Unternehmenswebsite. Sie betrifft aber sehr wohl Unternehmen, die Software, Apps, Plugins, Themes, vernetzte Geräte oder digitale Produkte auf dem EU-Markt anbieten. Genau dort wird es für WordPress-Agenturen, Plugin-Anbieter, SaaS-Teams und Betreiber größerer Webprojekte spannend.
Für klassische Website-Betreiber ist der Cyber Resilience Act vor allem ein Beschaffungs- und Qualitätsfilter: Welche Plugins werden gepflegt? Gibt es klare Sicherheitsupdates? Wer reagiert bei Schwachstellen? Wer hingegen selbst ein WordPress-Plugin verkauft, individuelle Software als Produkt anbietet oder digitale Komponenten in Kundenlösungen bereitstellt, sollte die eigene Rolle genauer prüfen. Dieser Beitrag gibt eine praktische Einordnung für Deutschland und die EU, ersetzt aber keine individuelle Rechtsberatung.
Was der Cyber Resilience Act regelt
Der Cyber Resilience Act, kurz CRA, ist die EU-Verordnung für Cybersicherheit bei Produkten mit digitalen Elementen. Gemeint sind vereinfacht gesagt Hardware- und Softwareprodukte, die direkt oder indirekt mit einem Gerät oder Netzwerk verbunden sind. Die EU-Kommission beschreibt den CRA als horizontales Regelwerk für solche digitalen Produkte. Er soll Sicherheitsanforderungen über den gesamten Produktlebenszyklus verbindlicher machen: von der Entwicklung über Updates bis zum Umgang mit Schwachstellen.
Die wichtigsten Daten sind bereits gesetzt. Die Verordnung ist am 10. Dezember 2024 in Kraft getreten. Die Hauptpflichten gelten nach Angaben der EU-Kommission ab dem 11. Dezember 2027. Eine wichtige Vorstufe beginnt früher: Ab dem 11. September 2026 müssen Hersteller aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle melden, wenn sie Produkte mit digitalen Elementen betreffen.
Warum WordPress-Teams das Thema nicht ignorieren sollten
WordPress selbst ist Open Source und lebt von einem riesigen Ökosystem aus Themes, Plugins, Page-Buildern, Shopsystemen, Formularlösungen, Tracking-Erweiterungen und Schnittstellen. Viele Website-Betreiber installieren diese Bausteine wie normale Werkzeuge. Aus Sicht des CRA kommt es aber darauf an, ob ein Produkt mit digitalen Elementen auf dem EU-Markt bereitgestellt wird und welche Rolle ein Unternehmen in der Lieferkette hat.
Ein lokaler Handwerksbetrieb, der ein Standard-Plugin nutzt, wird dadurch nicht automatisch zum Hersteller dieses Plugins. Trotzdem sollte er wissen, dass unsichere oder verwaiste Erweiterungen ein Geschäftsrisiko bleiben. Für Plugin-Anbieter, SaaS-Betreiber, Agenturen mit eigenen wiederverwendbaren Modulen und Unternehmen mit verkauften Softwarekomponenten sieht die Lage anders aus. Dort kann der CRA Prozesse verlangen, die bisher oft nur aus größerer Softwareentwicklung bekannt waren.
Wer im WordPress-Umfeld besonders prüfen sollte
Besonders relevant ist eine CRA-Prüfung für Unternehmen, die eigene Plugins, Themes oder digitale Erweiterungen gegen Entgelt anbieten. Dazu können auch spezialisierte Branchenlösungen gehören, etwa Buchungs-Plugins, Mitgliederbereiche, WooCommerce-Erweiterungen, Automatisierungsmodule, Schnittstellen zu ERP- oder CRM-Systemen und Apps, die mit einer Website verbunden sind.
Auch Agenturen sollten genauer hinsehen, wenn sie nicht nur einmalige Auftragsentwicklung leisten, sondern wiederverwendbare Softwarepakete an mehrere Kunden ausrollen. Entscheidend ist nicht allein, ob etwas „WordPress“ heißt, sondern ob ein digitales Produkt bereitgestellt wird, wer als Hersteller auftritt, wie Updates zugesagt werden und ob ein wirtschaftlicher Vertrieb oder eine vergleichbare Bereitstellung vorliegt.
Für reine Website-Betreiber ist die praktische Frage meist eine andere: Nutze ich Komponenten, die auch in zwei oder drei Jahren noch Sicherheitsupdates erhalten? Kann mein Dienstleister bei kritischen Schwachstellen schnell reagieren? Sind Verantwortlichkeiten in Wartungs-, Hosting- und Agenturverträgen eindeutig geregelt?
Die 2026-Frist: Meldeprozesse brauchen Vorlauf
Die Reporting-Pflichten sind der erste harte Meilenstein. Die EU-Kommission und ENISA beschreiben, dass Hersteller ab dem 11. September 2026 aktiv ausgenutzte Schwachstellen und schwerwiegende Vorfälle über eine Single Reporting Platform melden müssen. Nach der EU-Darstellung sind eine frühe Warnung innerhalb von 24 Stunden und eine vollständige Meldung innerhalb von 72 Stunden vorgesehen. Abschlussberichte folgen je nach Fall später.
Das klingt nach einem reinen Compliance-Thema. In der Praxis braucht es aber technische Vorarbeit. Wer nicht weiß, welche Komponenten in der eigenen Software stecken, kann eine ausgenutzte Schwachstelle kaum schnell bewerten. Wer keinen Prozess für Sicherheitsmeldungen hat, verliert bei einem Vorfall Zeit. Wer keine klare Update- und Supportstrategie dokumentiert hat, kann Kunden nicht sauber informieren.
Was Website-Betreiber jetzt von Plugin- und Softwareanbietern erwarten sollten
Auch wenn viele Website-Betreiber nicht selbst in den direkten Herstellerpflichten stehen, können sie ihre Lieferkette besser steuern. Bei neuen Plugins, Themes und Integrationen lohnt sich eine einfache Sicherheitsabfrage: Gibt es regelmäßige Updates? Wie lange wird die aktuelle Version unterstützt? Wo können Schwachstellen gemeldet werden? Gibt es eine verantwortliche Kontaktadresse? Werden sicherheitskritische Änderungen nachvollziehbar dokumentiert?
Für WordPress-Websites mit Kundenkonten, Formularen, Zahlungsfunktionen oder Tracking-Anbindungen ist diese Prüfung besonders wichtig. Dort überschneiden sich technische Sicherheit, Datenschutz und Nutzervertrauen. Wer personenbezogene Daten verarbeitet, sollte neben dem CRA auch die Grundlagen aus der DSGVO im Blick behalten. Einen praktischen Einstieg bietet unser Beitrag zum DSGVO-Website-Check.
CRA, NIS-2 und DSGVO: drei unterschiedliche Blickwinkel
Der Cyber Resilience Act ersetzt weder NIS-2 noch die DSGVO. Er setzt an einem anderen Punkt an: beim Produkt und seiner Cybersicherheit. NIS-2 betrifft vor allem bestimmte Einrichtungen und Sektoren mit Anforderungen an das Sicherheitsmanagement. Die DSGVO schützt personenbezogene Daten und verlangt angemessene technische und organisatorische Maßnahmen. Der CRA soll dafür sorgen, dass digitale Produkte selbst sicherer entwickelt, gepflegt und aktualisiert werden.
Für Unternehmen in Deutschland entsteht daraus ein gemeinsames Bild: Website-Sicherheit ist nicht mehr nur ein IT-Thema nach dem Launch. Sie gehört in Einkauf, Produktentwicklung, Verträge, Dokumentation und laufende Wartung. Wer bereits für NIS-2, Datenschutz oder Cookie-Consent Prozesse aufgebaut hat, kann viele Bausteine wiederverwenden: Inventar, Verantwortlichkeiten, Vorfallbewertung, Eskalation und Dokumentation.
Eine praktische Checkliste für WordPress-Projekte
Der erste Schritt ist ein Software-Inventar. Erfassen Sie alle Plugins, Themes, eigenen Module, Schnittstellen, externen Skripte und Automatisierungen. Notieren Sie Hersteller, Version, Zweck, Datenbezug, Updatequelle und Supportstatus. Das ist nicht nur für den CRA hilfreich, sondern auch für Datenschutzprüfungen, Consent-Management und technische Wartung.
Der zweite Schritt ist Rollenklärung. Sind Sie nur Anwender, Agentur, Reseller, Integrator oder Anbieter eines eigenen digitalen Produkts? Bei Mischmodellen sollte genau dokumentiert werden, wer für Entwicklung, Sicherheitsupdates, Hosting, Betrieb und Kundensupport zuständig ist. Diese Klarheit verhindert Lücken, wenn später eine kritische Schwachstelle auftaucht.
Der dritte Schritt ist ein einfacher Vulnerability-Workflow. Legen Sie fest, wo Sicherheitsmeldungen eingehen, wer sie bewertet, wie schnell reagiert wird und wie Kunden informiert werden. Für Anbieter eigener Software gehört dazu auch eine Strategie für Security Updates, Changelogs, Supportzeiträume und Abhängigkeiten von Drittkomponenten.
Der vierte Schritt betrifft externe Dienste. Viele Websites nutzen Analyse-Tools, Cookie-Banner, Newsletterdienste, Zahlungsanbieter oder KI-Automatisierungen. Prüfen Sie, welche Komponenten wirklich nötig sind und ob sie sauber dokumentiert werden. Für Datenschutzthemen helfen der AdSimple Datenschutz Generator und unser Überblick zur Einwilligungsverwaltung nach TDDDG.
Was Plugin-Anbieter bis 2026 vorbereiten sollten
Plugin- und Softwareanbieter sollten den CRA nicht erst kurz vor 2027 anfassen. Die Meldepflichten ab September 2026 setzen voraus, dass ein Team Schwachstellen erkennen, priorisieren, melden und beheben kann. Dafür braucht es mindestens eine gepflegte Komponentenliste, klare Zuständigkeiten, einen Kommunikationsweg für Sicherheitsmeldungen und einen Prozess für schnelle Patches.
Hinzu kommt die Produktdokumentation. Kunden müssen verstehen, welche Version unterstützt wird, welche Systemvoraussetzungen gelten und wie Sicherheitsupdates eingespielt werden. Für viele kleine Anbieter ist das eine Umstellung, aber auch ein Wettbewerbsvorteil: Wer transparent erklärt, wie Sicherheit gepflegt wird, wirkt vertrauenswürdiger als ein Plugin ohne erkennbare Wartung.
Was normale Website-Betreiber sofort tun können
Für Betreiber einer Unternehmenswebsite ist der beste Einstieg pragmatisch. Löschen Sie ungenutzte Plugins. Aktualisieren Sie WordPress, Themes und Erweiterungen regelmäßig. Prüfen Sie, ob kritische Funktionen wie Formulare, Shops, Loginbereiche und Analyse-Skripte noch benötigt und sauber abgesichert sind. Dokumentieren Sie, wer Updates durchführt und wer bei Sicherheitsmeldungen erreichbar ist.
Bei neuen Projekten sollten Sicherheitsfragen in Angebote und Wartungsverträge. Das muss nicht kompliziert sein: Update-Rhythmus, Backup-Prüfung, Reaktionszeiten, Verantwortlichkeiten und Umgang mit Drittkomponenten reichen oft als Grundlage. Rechtliche Basispflichten wie Impressum, Datenschutzerklärung und Consent bleiben daneben wichtig. Für die Pflichtangaben kann der AdSimple Impressum Generator unterstützen.
Fazit: CRA-Vorbereitung beginnt bei Transparenz
Der Cyber Resilience Act wird nicht jede WordPress-Website direkt in ein neues Produkt-Compliance-Projekt verwandeln. Er verändert aber die Erwartungen an Softwareanbieter und damit auch an die Auswahl von Plugins, Themes und digitalen Dienstleistern. Wer heute weiß, welche Komponenten auf der Website laufen, wer sie pflegt und wie Sicherheitsvorfälle behandelt werden, ist deutlich besser vorbereitet.
Für Website-Betreiber heißt das: Lieferkette sichtbar machen, Wartung ernst nehmen und Sicherheitsfragen nicht auf später verschieben. Für Plugin-, SaaS- und Softwareanbieter heißt es: Rollen prüfen, Schwachstellenmanagement aufbauen und die September-2026-Meldepflichten rechtzeitig einplanen. So wird der CRA nicht nur zur Pflicht, sondern zu einem Anlass, WordPress-Projekte stabiler und vertrauenswürdiger zu machen.
