Cyber Resilience Act: Was ab 11. September 2026 gilt

Sie befinden sich: Home > News Archiv > Webmaster > Cyber Resilience Act...

Ab dem 11. September 2026 müssen Hersteller digitaler Produkte aktiv ausgenutzte Schwachstellen binnen 24 Stunden beim BSI und der ENISA melden. Die erste Pflicht des Cyber Resilience Act mit echten Folgen. Sie trifft mehr Webmaster als gedacht.

Ein vernetztes Gerät eines Herstellers taucht plötzlich in einem Botnetz auf. Bisher war das ein Fall fürs Support-Team, vielleicht für die Presseabteilung. Ab dem 11. September 2026 ist es ein Fall mit Frist: Der Hersteller muss die aktiv ausgenutzte Schwachstelle innerhalb von 24 Stunden melden. An das BSI und an die EU-Agentur ENISA.

Das ist der Moment, in dem der Cyber Resilience Act zum ersten Mal wirklich zubeißt. Die Verordnung gilt formal schon seit Dezember 2024, und die volle Wucht mit CE-Kennzeichnung und Konformitätsbewertung kommt erst im Dezember 2027. Dazwischen liegt dieser eine Termin im September, den viele unterschätzen. Eine Meldekette baut man nicht über Nacht auf.

Was der CRA überhaupt regelt

Der Cyber Resilience Act, offiziell die Verordnung (EU) 2024/2847, stellt eine simple Forderung: Wer ein Produkt mit digitalen Elementen auf den EU-Markt bringt, muss es sicher entwickeln, dokumentieren und über die gesamte Supportzeit mit Updates versorgen.

"Produkt mit digitalen Elementen" klingt sperrig, meint aber fast alles, was sich mit einem Netzwerk verbinden kann: Software, Firmware, Apps, Plugins, Router, Kameras, smarte Türschlösser. Auch die Cloud-Komponente zählt dazu, wenn das Produkt ohne sie nicht funktioniert. Ob kostenlos oder bezahlt, spielt keine Rolle. Es zählt, ob etwas im Rahmen einer geschäftlichen Tätigkeit angeboten wird.

Anders als die NIS-2-Richtlinie gilt der CRA direkt in allen Mitgliedstaaten. Deutschland muss ihn nicht erst in nationales Recht gießen. Trotzdem läuft gerade ein nationales Durchführungsgesetz durchs Parlament, das das BSI-Gesetz anpasst und das BSI zur zentralen Behörde macht: Marktaufsicht, Meldestelle und technischer Berater in einem.

Der wichtigste Punkt: Bin ich überhaupt betroffen?

Hier trennen sich zwei Gruppen, und die meisten Missverständnisse entstehen genau an dieser Stelle.

Wer nur eine Website betreibt, ist erstmal raus. Eine normale Unternehmensseite ist kein Produkt, das in Verkehr gebracht wird. Auch reines SaaS, das nur im Browser läuft, fällt nicht unter den CRA, sondern eher unter NIS-2. Der Handwerksbetrieb, der ein Standard-Plugin installiert, wird dadurch nicht zum Hersteller dieses Plugins.

Für diese Gruppe ist der CRA vor allem ein Einkaufsfilter. Die Frage verschiebt sich von "Läuft die Seite?" zu "Wird dieses Plugin gepflegt, kommen Sicherheitsupdates, und reagiert jemand, wenn eine Lücke gemeldet wird?" Verwaiste Erweiterungen waren immer ein Risiko. Künftig sind sie auch ein Geschäftsrisiko.

Die andere Gruppe trifft es direkt: alle, die Software als Produkt anbieten. Ein verkauftes WordPress-Plugin, ein Theme mit Pro-Version, ein Buchungsmodul, eine WooCommerce-Erweiterung, eine App mit angebundenem Backend. Auch eine Agentur, die ein selbst gebautes Plugin an einen EU-Kunden ausliefert, bringt damit ein Produkt auf den Markt.

Und nein, "kostenlos" ist kein Ausweg. Sobald ein Pro-Modell, bezahlter Support, Werbung oder eine Bündelung in einem kostenpflichtigen Angebot dahintersteht, gilt das als geschäftliche Tätigkeit. Die GPL-Lizenz ändert daran nichts.

Die Meldepflicht ab September im Detail

Gemeldet werden müssen zwei Dinge: aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle. Nicht jede theoretische Lücke, sondern die, die gerade angegriffen wird.

Die Kette ist dreistufig:

• Innerhalb von 24 Stunden eine Frühwarnung. Nur das Nötigste: betroffenes Produkt, in welchen Ländern es vertrieben wird, eine erste Einschätzung. Technische Details, mit denen sich ein Exploit bauen ließe, gehören hier ausdrücklich nicht rein.
• Innerhalb von 72 Stunden die Hauptmeldung mit Art der Schwachstelle, Auswirkung und geplanten Gegenmaßnahmen.
• Spätestens 14 Tage nach Verfügbarkeit eines Patches der Abschlussbericht. Bei Sicherheitsvorfällen ist es ein Monat nach der ersten Meldung.

Die Meldung läuft über die CRA Single Reporting Platform, die die ENISA aufbaut. Formal adressiert man sie an das CSIRT im Land des Hauptsitzes, in Deutschland also an das BSI beziehungsweise CERT-Bund. Die ENISA bekommt sie automatisch parallel.

Ein Punkt, den man leicht falsch versteht: Diese Frühwarnung ist keine Pressemitteilung. Sie ist vertraulich zwischen Hersteller und Behörde. Das BSI rechnet mit rund 2.000 solcher Meldungen pro Jahr.

Die Pflicht gilt für alle Produkte, die auf dem Markt sind, auch für solche, die vor 2027 ausgeliefert wurden. Eine alte Codebasis schützt nicht davor.

Open Source und die Steward-Regel

Hier hat Brüssel nachgebessert, nachdem die Open-Source-Welt Alarm geschlagen hatte. Freie Software, die ohne geschäftliche Absicht entwickelt und verteilt wird, fällt nicht unter den CRA. Wer privat ein Projekt auf GitHub pflegt und kein Geld damit verdient, ist außen vor.

Für Stiftungen und Organisationen, die solche Projekte dauerhaft tragen, gibt es eine eigene, leichtere Kategorie: den Open-Source-Software-Steward nach Artikel 24. Diese müssen eine Sicherheitsrichtlinie haben und ausgenutzte Schwachstellen melden, zahlen aber keine Bußgelder. Ein einzelner Entwickler, der nur Code zu einem fremden Projekt beisteuert, trägt ebenfalls keine Herstellerpflichten.

Was bei Verstößen droht

Die Zahlen sind unangenehm: bis zu 15 Millionen Euro oder 2,5 Prozent des weltweiten Jahresumsatzes, je nachdem, was höher ist. Das gilt für Verstöße gegen die grundlegenden Sicherheitsanforderungen.

Für Plugin-Entwickler ist eine andere Folge oft greifbarer als das Bußgeld: Das BSI kann ein Produkt vom Markt nehmen. Übersetzt heißt das, eine Erweiterung kann aus dem WordPress-Verzeichnis oder von CodeCanyon fliegen, wenn sie die Anforderungen nicht erfüllt.

CRA, NIS-2 und DSGVO sind nicht dasselbe

Drei Kürzel, drei verschiedene Baustellen. Der CRA betrifft das Produkt und seine Sicherheit. NIS-2 betrifft die Organisation und richtet sich an bestimmte Sektoren und Betreiber. Die DSGVO schützt personenbezogene Daten. Alle drei können gleichzeitig gelten.

Wer für NIS-2 oder Datenschutz schon Prozesse aufgebaut hat, kann vieles wiederverwenden. Ein Inventar der Komponenten, klare Zuständigkeiten, eine Eskalationskette. Ein ISMS nach ISO 27001 deckt grob zwei Drittel der organisatorischen Anforderungen ab. Die produktspezifischen Pflichten fehlen trotzdem.

Was jetzt zu tun ist

Für reine Website-Betreiber:

• Verschaffen Sie sich einen Überblick, welche Plugins und Themes laufen und wer sie pflegt.
• Sortieren Sie aus, was verwaist ist oder seit Monaten kein Update bekommen hat.
• Achten Sie bei neuen Erweiterungen darauf, ob der Anbieter eine Sicherheitskontaktstelle und einen klaren Update-Rhythmus hat.

Für alle, die Software, Plugins oder Geräte anbieten:

• Richten Sie einen Meldeweg für Schwachstellen ein. Das BSI empfiehlt in seiner Richtlinie TR-03183-3 unter anderem eine security.txt im Stammverzeichnis.
• Erstellen Sie eine SBOM, also eine Stückliste Ihrer Software-Abhängigkeiten, und gleichen Sie diese automatisiert gegen CVE-Datenbanken ab. Werkzeuge wie Trivy oder OWASP Dependency-Track helfen dabei.
• Bereiten Sie Melde-Vorlagen vor und legen Sie eine Eskalationskette fest, die auch nachts und am Wochenende erreichbar ist. Die 24-Stunden-Frist kennt keine Bürozeiten.
• Registrieren Sie sich auf der ENISA-Plattform, sobald sie verfügbar ist.
• Planen Sie für 2027 die Konformitätsunterlagen ein: technische Dokumentation, Konformitätserklärung und CE-Kennzeichnung.

Der Termin ist näher, als das Datum aussagt

September 2026 klingt nach viel Zeit. Aber eine belastbare Meldekette, eine gepflegte SBOM und ein eingespielter Prozess brauchen erfahrungsgemäß zwölf bis zwanzig Monate. Rechnet man rückwärts, war der ehrliche Startzeitpunkt eher gestern.

Der eigentliche Bruch steckt woanders. Jahrelang galt: Eine Lücke patcht man still, und niemand erfährt davon. Der CRA dreht das um. Eine Schwachstelle ist kein internes Problem mehr, sondern ein meldepflichtiges Ereignis mit Stoppuhr. Für gut organisierte Anbieter ist das lästig, aber machbar. Für alle, die Sicherheit bisher als optionales Extra behandelt haben, wird es der Moment der Wahrheit.

Wer es genau wissen will: Das BSI führt eine eigene CRA-Themenseite mit den technischen Richtlinien, und die Verordnung steht im Volltext bei EUR-Lex.

enisa resilience ausgenutzte cyber melden gilt

Webung: Hier bekommen Sie PHP fähigen Webspace der mit Ökostrom betrieben wird ab bereits 2 Euro/ Monat für ihre Homepage. Zusätzlich ist eine eigene Internetadresse mit enthalten.

Neusten News in der Kategorie "Webmaster"

• GEO: So wird Ihre Website in KI-Antworten zitiert Wer bei Google ganz oben steht, taucht in ChatGPT oder Perplexity oft ...

• Google Spam Update Juni 2026: Das sollten Sie tun Am 24. Juni hat Google das June 2026 Spam Update ausgerollt. Ohne Blog...

• Token-Explosion: So ruinieren MCP-Server Ihren Coding-Workfl... MCP-Server wirken wie clevere Helfer, doch sie können Ihren KI-Co...

• Neue Hürden für Entwickler: So meistern Sie den raueren Arbe... Die Suche nach Programmierjobs wird zur Herausforderung. Automatisieru...

• FAIR ersetzt WordPress.org-API mehr Kontrolle für Entwickle... Die Linux Foundation startet mit FAIR einen neuen, dezentralen Paketma...

• GitHub-Sicherheitslücke: Private und gelöschte Repos bleiben... GitHub hat ein erhebliches Sicherheitsproblem: Gelöschte und private R...

• Barrierefreiheitsstärkungsgesetz: Website-Sperrung für Firme... Unternehmen in Deutschland stehen unter enormem Druck: Bis Juni 2025 m...

• Supply-Chain-Attacke: Polyfill.io verteilt Schadcode über CD... Mehrere Sicherheitsforscher warnen vor einer aktiven Bedrohung durch d...

• Kritische PHP-Schwachstelle unter Windows entdeckt PHP-Entwickler haben ein neues Sicherheitsupdate veröffentlicht, ...

• Ab Juli: Google indexiert nur noch mobilfähige Websites Eigentlich schien Googles Mobile-First-Offensive abgeschlossen. Aber d...