EPNWDer Cyber Resilience Act
Als 2014 Heartbleed bekannt wurde, war das eine Nachricht, über die in der Tech-Welt monatelang gesprochen wurde. Danach dauerte es eine Weile, bis es die nächste große Lücke in die Schlagzeilen schaffte. Inzwischen werden fast täglich neue Bugs, die von Hackern ausgenutzt werden können, bekannt, zuletzt PHP2Shell, das im Oktober 2026 sogar Behörden, Kliniken und Städte dazu brachte, ihre Webseiten vom Netz zu nehmen. Ein wichtiger Grund dafür ist KI: Sie hilft dabei, Schwachstellen schneller zu finden und auszunutzen. Neben klassischen Bugs sind auch Supply Chains ein immer häufigeres Ziel für Angriffe: Das gezielte Einschleusen von Backdoors in Open-Source-Projekte, die millionenfach die Basis für viele der wichtigsten großen kommerziellen Produkte bilden, ist so einfach wie nie, da sich die oft freiwilligen Open-Source-Maintainer mit einer Flut an vor allem KI-generierten Softwarebeiträgen (Pull-Requests) konfrontiert sehen und es auf ehrenamtlicher Basis nicht mehr möglich ist, jede Code-Zeile genauestens zu überprüfen.
Die Tech-Welt wird unsicherer, und das müssen wir akzeptieren. Die Lösung ist nicht, wettrüstungsartig Code mit Code zu bekämpfen, sondern Pläne zu schaffen für den unausweichlichen, nächsten Cyberangriffsfall.
Sicherheit per Gesetz
Genau hier setzt der Cyber Resilience Act (CRA) der EU an. Die Verordnung (EU) 2024/2847 ist im Dezember 2024 in Kraft getreten und verfolgt einen einfachen Gedanken: Wer Produkte mit digitalen Elementen in der EU verkauft, muss dafür sorgen, dass sie über den Verkaufstag hinweg, in ihrem gesamten Lebenszyklus, sicher sind. Dazu zählen Router und Smart-Home-Geräte ebenso wie Software, Apps und vernetzte Maschinen. Bislang konnten Hersteller Sicherheit als nettes Extra behandeln. Mit dem CRA wird sie zur Voraussetzung für das CE-Kennzeichen, ohne das ein Produkt nicht auf den Markt darf.
Was der CRA verlangt
Die Pflichten treffen in erster Linie die Hersteller, aber auch Importeure und Händler müssen im Rahmen ihrer Sorgfaltspflichten prüfen, ob die Produkte, die sie verkaufen, die Anforderungen erfüllen. Konkret bedeutet das:
Sicherheit muss von Anfang an mitgedacht werden („Security by Design”). Produkte dürfen keine bekannten ausnutzbaren Schwachstellen enthalten, wenn sie ausgeliefert werden. Die Standardkonfiguration ausgelieferter Software muss sicher sein („Security by Default”), also keine Standardpasswörter wie „admin/admin” und keine unnötig offenen Schnittstellen. Außerdem müssen Daten angemessen geschützt und die Angriffsfläche klein gehalten werden.
Die Sicherheitspflicht des Herstellers endet nicht mit dem Verkauf. Stattdessen müssen Hersteller kostenlose Sicherheitsupdates für einen vor Verkauf transparent kommunizierten Zeitraum bereitstellen, in der Regel mindestens fünf Jahre oder, bei kürzerer Nutzungsdauer, entsprechend der erwarteten Lebensdauer des Produkts.
Hersteller müssen zudem wissen, was in ihrem Produkt steckt. Dafür verlangt der CRA eine technische Dokumentation und eine Software-Stückliste (SBOM), die alle verwendeten Komponenten auflistet. Wird in einer Bibliothek eine Lücke bekannt, lässt sich so schnell feststellen, welche Produkte betroffen sind. Wer Drittkomponenten einsetzt, trägt die Verantwortung dafür und muss sie mit der gebotenen Sorgfalt auswählen und aktuell halten. Die SBOM-Liste muss in den meisten Fällen zwar nicht veröffentlicht werden, das Anlegen ist jedoch stets Pflicht.
Sicherheitsklassen
Nicht jedes Produkt wird dabei gleich streng geprüft. Für die große Mehrheit der Produkte genügt eine Selbstbewertung durch den Hersteller. Für Produkte mit erhöhtem Risiko sieht der CRA jedoch zwei Stufen „wichtiger Produkte” vor. In Klasse 1 fallen etwa Passwortmanager, VPN-Software, Browser, Router für den Heimgebrauch oder smarte Türschlösser. Hier darf der Hersteller nur dann selbst bewerten, wenn er harmonisierte Normen vollständig anwendet, andernfalls ist eine Prüfung durch eine externe Stelle nötig. In Klasse 2 landen Produkte, deren Kompromittierung besonders weitreichende Folgen hätte, darunter Firewalls, Einbruchserkennungssysteme, Hypervisoren und Container-Laufzeitumgebungen sowie manipulationssichere Mikrocontroller. Sie müssen zwingend von einer externen, benannten Stelle geprüft werden. Als „kritische Produkte” gelten schließlich Geräte wie Smart-Meter-Gateways oder Smartcards und Sicherheitsmodule. Für sie kann die EU künftig eine europäische Cybersicherheitszertifizierung vorschreiben.
Meldepflichten
Der vielleicht wichtigste Punkt ist der Umgang mit dem „nächsten Cyberangriffsfall”. Hersteller müssen ein Verfahren für den Umgang mit Schwachstellen etablieren, inklusive einer Anlaufstelle für Sicherheitsforscher und koordinierter Offenlegung („Coordinated Vulnerability Disclosure”). Wird eine Schwachstelle bereits aktiv ausgenutzt oder kommt es zu einem schwerwiegenden Sicherheitsvorfall, der das Produkt betrifft, gilt ein enger Zeitplan, der innerhalb von 24 Stunden eine Frühwarnung an die zuständige nationale Stelle (CSIRT) und die EU-Agentur ENISA vorsieht. Nach 72 Stunden folgt eine genauere Meldung, und spätestens 14 Tage nach Verfügbarkeit eines Fixes ein Abschlussbericht. Diese Meldepflichten gelten bereits seit dem 11. September 2026. Der Großteil der übrigen Pflichten greift ab dem 11. Dezember 2027.
Und Open Source?
Naheliegend ist die Sorge, der CRA könnte ehrenamtliche Maintainer überfordern. Der Gesetzgeber hat das erkannt und nachgebessert: Rein nichtkommerzielle Open-Source-Projekte fallen nicht unter die Verordnung. Wer Open Source jedoch im Rahmen einer Geschäftstätigkeit anbietet, ist Hersteller und voll verantwortlich. Für Organisationen, die Open-Source-Projekte dauerhaft unterstützen, etwa Stiftungen, gibt es mit dem „Open-Source-Software-Steward” eine eigene Rolle mit leichteren Pflichten, vor allem einer Sicherheitsrichtlinie und der Zusammenarbeit mit den Behörden. Die eigentliche Konsequenz dabei ist, dass Unternehmen, die Open Source in ihre Produkte einbauen, in der Pflicht sind, die Sicherheit ihrer Lieferkette zu verantworten, und im Zweifel Maintainer finanziell oder personell unterstützen müssen.
Was das konkret bedeutet
Für Hersteller heißt das: Sicherheitsprozesse, Update-Infrastruktur, SBOM-Erstellung und ein funktionierendes Incident-Management sind Marktzugangsvoraussetzungen. Wer jetzt noch nicht damit begonnen hat, hat bis Ende 2027 nicht viel Zeit. Bei Verstößen drohen Bußgelder von bis zu 15 Millionen Euro oder 2,5 Prozent des weltweiten Jahresumsatzes, je nachdem, welcher Betrag höher ist.
Für Anwender, ob Privatpersonen oder Unternehmen, bedeutet der CRA vor allem mehr Transparenz und Verlässlichkeit: Sie erfahren, wie lange ein Gerät Updates erhält, und können sich darauf verlassen, dass Hersteller Schwachstellen nicht mehr unter den Teppich kehren dürfen.
Der CRA wird die nächste Lücke nicht verhindern. Das wäre unrealistisch. Aber er sorgt dafür, dass Hersteller vorbereitet sind, wenn sie kommt: Sie wissen, was in ihren Produkten steckt, können schnell reagieren, informieren die richtigen Stellen und liefern Patches aus.