Am 11. September 2026 treten die ersten Pflichten des Cyber Resilience Act in Kraft, der Verordnung (EU) 2024/2847. In den meisten Redaktionen und Marketingabteilungen löst dieser Satz nichts aus, weil er nach einem Thema für Softwarehäuser klingt. Das ist er auch, aber nicht nur. Wer eine Website betreibt, betreibt fremde Software, und deren Hersteller bekommen ab September Pflichten, deren Erfüllung oder Nichterfüllung direkt auf der eigenen Seite landet.
Was am 11. September tatsächlich beginnt
Der Cyber Resilience Act gilt für Produkte mit digitalen Elementen, die in der EU auf den Markt gebracht werden. Er ist bereits in Kraft, seine Pflichten greifen aber gestaffelt. Der 11. September 2026 ist der Termin für die Meldepflichten nach Artikel 14: Wird eine Schwachstelle in einem Produkt aktiv ausgenutzt, muss der Hersteller innerhalb von 24 Stunden eine Frühwarnung abgeben, innerhalb von 72 Stunden eine Meldung nachreichen und binnen 14 Tagen einen Abschlussbericht liefern. Adressat ist die europäische Agentur für Cybersicherheit ENISA, zusammen mit der jeweils zuständigen nationalen Stelle.
Der zweite Termin, der 11. Dezember 2027, ist der größere. Dann gelten die vollen Herstellerpflichten, von der CE-Kennzeichnung über die Stückliste der verwendeten Komponenten bis zur Pflicht, Sicherheitsupdates über einen definierten Zeitraum bereitzustellen. Artikel 13 Absatz 8 nennt dafür mindestens fünf Jahre oder die kürzere erwartete Nutzungsdauer des Produkts.
Warum das auch Betreiber angeht, die keine Software herstellen
Eine typische WordPress-Installation besteht aus einem Kern, einem Theme und je nach Haus zwischen zehn und vierzig Erweiterungen. Jede einzelne davon hat einen Hersteller, und jeder dieser Hersteller steht ab September vor der Frage, ob er die Meldepflichten erfüllen kann und will. Für Sie als Betreiber ist die interessante Zahl deshalb nicht die Frist, sondern die Antwort auf eine einfachere Frage: Wissen Sie, wer hinter den Erweiterungen steht, die auf Ihrer Seite laufen, und wie Sie diese Person im Ernstfall erreichen?
In der Praxis fällt die Antwort ernüchternd aus. Ein erheblicher Teil der verbreiteten Erweiterungen wird von Einzelpersonen gepflegt, oft ohne veröffentlichten Sicherheitskontakt. Manche Anbieter werden die neuen Pflichten zum Anlass nehmen, Produkte einzustellen oder aus dem europäischen Markt zu nehmen. Das ist kein Untergangsszenario, sondern eine absehbare Marktbereinigung. Sie trifft aber zuerst diejenigen, die nicht wissen, was bei ihnen läuft.
Die Frage, die niemand sauber beantwortet
Offen ist, wer im Sinne der Verordnung als Hersteller gilt, wenn mehrere Beteiligte an einer Website arbeiten. Eine Agentur, die ein Theme anpasst, ein Dienstleister, der eine Erweiterung nach Kundenwunsch erweitert, ein Betreiber, der eine Open-Source-Komponente selbst modifiziert: Für diese Mischfälle gibt es bislang keine belastbare, allgemein akzeptierte Einordnung. Wer Ihnen dazu heute eine eindeutige Auskunft gibt, sollte gefragt werden, worauf er sie stützt.
Für die Praxis heißt das, die Frage nicht als Erstes zu stellen. Sie ist wichtig, aber sie blockiert, und die Dinge, die ohnehin sinnvoll sind, hängen nicht an ihrer Beantwortung.
Was sich ohne Rechtsgutachten heute tun lässt
Der erste Schritt ist eine Bestandsaufnahme, die keine zwei Stunden braucht: eine Liste aller eingesetzten Erweiterungen, dazu je Eintrag der Hersteller, das Datum der letzten Aktualisierung und ein Weg, ihn im Sicherheitsfall zu erreichen. Wo diese Spalte leer bleibt, haben Sie ein Ergebnis, und zwar unabhängig davon, wie die Zuständigkeitsfrage am Ende ausgeht.
Der zweite Schritt betrifft die eigene Erreichbarkeit. Eine security.txt nach RFC 9116 unter /.well-known/ ist eine Textdatei mit fünf Zeilen, die Sicherheitsforschern sagt, an wen sie einen Fund melden sollen. Sie kostet nichts und sorgt dafür, dass ein Hinweis bei Ihnen ankommt und nicht im allgemeinen Kontaktformular versandet. Wer selbst Software anbietet, sei es ein Plugin, ein Theme oder ein internes Werkzeug, braucht zusätzlich eine öffentliche Angabe zum Supportzeitraum. Ein kostenloses Werkzeug dafür haben wir unter hafenstudios.com/tools/cra-selbstauskunft.html bereitgestellt. Es erzeugt aus wenigen Angaben eine security.txt, einen readme-Abschnitt und einen öffentlichen Textbaustein, läuft vollständig im Browser und verlangt kein Konto. Es beantwortet ausdrücklich nicht, ob der Cyber Resilience Act auf Ihr Produkt anwendbar ist, und es bewertet auch keine Konformität. Diese Grenze ist bewusst gezogen, denn beides wäre eine Rechtsfrage.
Der Ton, in dem das Thema gerade verkauft wird
Rund um die Frist wächst ein Markt für Angst. Es kursieren Bußgeldzahlen, teils mit falschen Bezugsnormen, und es werden Zertifikate angeboten, die es in dieser Form nicht gibt: Eine Konformitätsbewertung nach der Verordnung ist bis zur vollen Anwendung im Dezember 2027 gar nicht möglich, und für den Großteil der Produkte ist ohnehin eine Selbstbewertung vorgesehen, nicht die Prüfung durch eine externe Stelle. Wer Ihnen heute eine CRA-Zertifizierung verkauft, verkauft ein Etikett. Die nüchterne Bestandsaufnahme ist langweiliger und bringt mehr.
In eigener Sache
Dieser Beitrag stammt von hafenstudios, dem WordPress-Studio von Horst Wenzel in Hamburg, und hinter hafenstudios und Charming Media steht derselbe Betreiber. Wir sind vom Cyber Resilience Act selbst betroffen, weil wir Erweiterungen anbieten, und das genannte Werkzeug ist aus unserer eigenen Vorbereitung entstanden. Es ist kostenlos und bleibt es, Anmeldung gibt es keine. Wir kennzeichnen die Herkunft dieses Textes lieber deutlich, als sie zu verschweigen.
