Was der Cyber Resilience Act jetzt von Herstellern verlangt
Seit dem 11. September 2026 müssen Hersteller aktiv ausgenutzte Schwachstellen innerhalb von 24 Stunden melden. Das klingt nach einer Formalie. In der Praxis setzt es etwas voraus, das vielen Unternehmen noch fehlt: die Fähigkeit, Angriffe auf die eigenen Produkte überhaupt zu erkennen. Wie es dazu kam, beginnt in einer Werkhalle vor einigen Jahrzehnten.
Lange zählte nur, dass die Maschine läuft
Ende der 1990er-Jahre, irgendwo in einer mittelständischen Werkhalle. Eine neue Fertigungsanlage wird angeliefert, aufgebaut und in Betrieb genommen. Der Techniker des Herstellers prüft die Drehzahlen, stellt die ersten Aufträge ein und zeigt dem Schichtleiter, wo er die Stückzahlen ablesen kann. Am Ende des Tages läuft die Maschine. Mehr wollte niemand.
Ob die Steuerung ihre Daten verschlüsselt überträgt, fragt in diesem Moment keiner. Die Anlage hängt an keinem Netz, das nach draußen reicht. Die größte Gefahr für die Produktion ist ein Lagerschaden und kein Angreifer. Ein Sicherheitskonzept im heutigen Sinn steht in keinem Lastenheft, weil es dafür schlicht keinen Anlass gibt.
Die Jahre vergehen, die Maschine läuft weiter. Irgendwann wird sie ans Firmennetz angeschlossen, damit die Produktionsdaten direkt in die Planung fließen. Später kommt ein Fernwartungszugang dazu, damit der Hersteller nicht mehr für jede Störung anreisen muss. Die Anlage ist jetzt vernetzt. Gebaut ist sie aber immer noch wie damals: Protokolle, die jeder im Netzwerk mitlesen kann, Software, die seit der Inbetriebnahme kein Update gesehen hat.
Und wer kümmert sich darum? Der Hersteller sieht nicht, was beim Kunden mit seinem Gerät passiert. Der Kunde darf oft gar nicht ran: keine Administratorrechte, keine Einsicht, manchmal sogar die ausdrückliche Ansage, nichts zu verändern, weil sonst die Gewährleistung erlischt. Die Verantwortung für die Sicherheit liegt irgendwo dazwischen, also bei niemandem.
Wie teuer diese Lücke werden kann, zeigte sich 2016. Das Botnetz Mirai durchsuchte das Internet nach Routern, Kameras und anderen vernetzten Geräten, die noch mit Werks- oder Standardpasswörtern liefen, und übernahm sie massenhaft. Mit dieser geliehenen Rechenleistung legten die Angreifer per DDoS-Angriff unter anderem den DNS-Dienstleister Dyn lahm, und zahlreiche bekannte Websites waren zeitweise nicht erreichbar. Das Einfallstor war kein raffinierter Exploit, sondern ein Passwort, das ab Werk gesetzt und nie geändert worden war.
Heute gehört Sicherheit zum Produkt
Zurück in die Gegenwart. Die Werkhallen von heute sind durchgängig vernetzt, Produkte mit digitalen Elementen stecken in nahezu jedem Unternehmen, und Angreifer suchen gezielt nach genau den Schwachstellen, die über Jahre niemand behoben hat. Für die Sicherheit von Unternehmensnetzen gibt es mit NIS2 inzwischen klare Vorgaben. Für die Sicherheit der Produkte, die in diesen Netzen laufen, gab es lange fast nichts.
Genau hier setzt der Cyber Resilience Act an. Die EU-Kommission hat ihn 2022 vorgelegt, seit dem 10. Dezember 2024 ist er in Kraft. Seine Botschaft ist unmissverständlich: Wer ein Produkt baut, ist auch für dessen Sicherheit verantwortlich, und zwar nicht nur am Tag der Auslieferung, sondern über den gesamten Lebenszyklus.
Der CRA verteilt die Verantwortung neu
Der Cyber Resilience Act (Verordnung (EU) 2024/2847) gilt für Produkte mit digitalen Elementen, also für Hardware und Software, und richtet sich in erster Linie an die Hersteller. Importeure und Händler haben ebenfalls Pflichten, wenn auch geringere.
Damit unterscheidet sich der CRA grundlegend von NIS2. NIS2 verpflichtet Unternehmen, ihre eigene Organisation abzusichern. Der CRA setzt früher an: bei den Produkten, die diese Unternehmen einsetzen. Sicherheit wird zur Produkteigenschaft, die vor dem Inverkehrbringen nachgewiesen werden muss.
Konkret heißt das unter anderem:
Security by Design und by Default: Produkte dürfen keine bekannten ausnutzbaren Schwachstellen haben und müssen mit einer sicheren Standardkonfiguration ausgeliefert werden.
Schwachstellenmanagement: Hersteller müssen Sicherheitsupdates über den gesamten Unterstützungszeitraum bereitstellen. Er beträgt in der Regel mindestens fünf Jahre.
SBOM: Hersteller müssen eine Software Bill of Materials erstellen, also ein Verzeichnis der verwendeten Softwarekomponenten. Veröffentlichen müssen sie sie nicht.
Wer Angriffe nicht erkennt, kann sie auch nicht melden
Seit dem 11. September 2026 gilt die erste konkrete Pflicht. Hersteller müssen aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle melden, und zwar in festen Stufen:
nach 24 Stunden eine Frühwarnung,
nach 72 Stunden weitere Informationen,
spätestens 14 Tage nach einem Sicherheitsupdate oder Workaround einen Abschlussbericht bei Schwachstellen; bei Sicherheitsvorfällen einen Monat nach der ersten Meldung.
Die Meldungen laufen über die Single Reporting Platform der ENISA. Sie gehen an die ENISA und an das zuständige koordinierende CSIRT, in Deutschland an das CERT-Bund im BSI.
Die Uhr läuft ab dem Moment, in dem der Hersteller von der Schwachstelle erfährt. Genau hier liegt das Problem. Viele Hersteller, gerade im Mittelstand, haben noch keine Mechanismen, um Angriffe auf ihre Produkte zu erkennen. Und in der Regel entdeckt nicht der Hersteller selbst die Schwachstelle, sondern ein Pentester, ein Sicherheitsforscher oder im schlechtesten Fall ein Angreifer.
Wer keinen funktionierenden Prozess hat, um solche Hinweise entgegenzunehmen, zu bewerten und weiterzugeben, hat mit der 24-Stunden-Frist ein strukturelles Problem.
Totschweigen ist keine Strategie mehr
Bisher war es durchaus üblich, Schwachstellen still zu patchen und nicht an die große Glocke zu hängen. Der CRA dreht diese Logik um. Transparenz wird zur Pflicht.
Das wirft eine unbequeme Frage auf: Ist ein Hersteller, der nie etwas meldet, besonders sicher, oder erkennt er einfach nichts?
Das ist keine Absolution. Tests, Code-Reviews und sichere Entwicklungsprozesse bleiben Aufgabe der Hersteller. Aber wer Schwachstellen schnell erkennt, transparent meldet und zügig behebt, zeigt Reife und keine Schwäche.
Eine Excel-Tabelle ersetzt keine SBOM
Auch die SBOM klingt auf dem Papier überschaubar. In der Praxis enthalten moderne Produkte zahlreiche Bibliotheken und Module in unterschiedlichen Versionen, die sich mit jedem Release ändern können. Wer das manuell dokumentieren will, verliert in agilen Entwicklungszyklen schnell den Überblick.
Realistisch funktioniert das nur automatisiert, direkt eingebunden in die Build- und Release-Prozesse. Diese Automatisierung muss aber erst aufgebaut, getestet und integriert werden. Für bestehende Produkte bedeutet das erheblichen Nacharbeitungsaufwand.
Der Zeitplan ist knapp
Vollständig gilt der CRA ab dem 11. Dezember 2027. Ab dann dürfen nur noch konforme Produkte in der EU in Verkehr gebracht werden, und auch die Sanktionen greifen: bis zu 15 Millionen Euro oder 2,5 Prozent des weltweiten Jahresumsatzes.
Das klingt nach viel Zeit, ist es aber nicht. Produktlebenszyklen dauern Jahre. Was 2027 auf den Markt kommt, wurde oft zu einer Zeit konzipiert, als Cybersecurity im Lastenheft kaum eine Rolle spielte.
Wie zäh die Umsetzung von Regulierung verlaufen kann, zeigt NIS2. Laut BSI haben sich bis Ende September 2026 rund 20.000 Einrichtungen registriert. Erwartet wurden etwa 29.500. Viele Unternehmen wissen schlicht nicht, dass sie betroffen sind, oder sie warten ab.
Der eigentliche Effekt zeigt sich in einigen Jahren
Der CRA wird nicht von heute auf morgen alle Produkte sicher machen. Seine erste Wirkung ist eine andere: Er verändert die Erwartungen. Schon heute fragen Kunden in Ausschreibungen genauer nach, wie Software arbeitet und ob unsichere Protokolle im Einsatz sind.
Für Hersteller wird CRA-Konformität damit zur Voraussetzung für den Marktzugang, ähnlich wie es eine ISO 27001 in vielen Ausschreibungen bereits ist. Wer früh anfängt, hat einen Vorsprung. Wer abwartet, arbeitet später unter Zeitdruck nach.
Mehr dazu im Podcast
In der aktuellen Folge von Cybersecurity Basement sprechen Michael und Andreas ausführlich über den Cyber Resilience Act. Es geht darum, warum die Meldefristen ambitioniert sind, warum viele Unternehmen bei NIS2 noch nicht wissen, ob sie betroffen sind, und wie Geschäftsführer zwischen Investitionen in Cybersecurity und dem Risiko von Sanktionen abwägen.