Mit dem Cyber Resilience Act regelt die EU zum ersten Mal die Sicherheit von Produkten mit digitalen Elementen. Das klingt abstrakt, wird aber schnell konkret. Während NIS2 vorschreibt, wie Unternehmen ihre eigene IT absichern müssen, geht es beim CRA um die Software und die vernetzten Geräte, die man verkauft. Die erste harte Frist steht kurz bevor. Ab dem 11. September 2026 müssen Hersteller aktiv ausgenutzte Schwachstellen in ihren Produkten melden.

Betroffen sind mehr Unternehmen, als man denkt

Der CRA gilt für alle Produkte mit digitalen Elementen, die kommerziell in der EU angeboten werden. Das trifft nicht nur die großen Softwarehäuser. Auch der Maschinenbauer, der seine Anlage mit einer eigenen Steuerungssoftware ausliefert, ist im Sinne der Verordnung ein Hersteller. Genauso das mittelständische Unternehmen, das eine Branchenlösung verkauft, die vor fünfzehn Jahren in Delphi oder C# entstanden ist und seitdem gepflegt wird.

Wichtig ist die Abgrenzung zur Auftragsentwicklung. Wer Software ausschließlich für den internen Gebrauch eines einzelnen Kunden entwickelt, fällt in der Regel nicht unter den CRA. Sobald ein Produkt aber am Markt angeboten wird, greifen die Pflichten. Und zwar auch für Bestandsprodukte, denn bei den Meldepflichten zählt nicht, wann ein Produkt auf den Markt kam, sondern ob es noch verkauft und betrieben wird.

Was ab dem 11. September konkret verlangt wird

Die erste Stufe des CRA dreht sich um das Melden von Sicherheitsvorfällen. Wird eine Schwachstelle in einem Produkt aktiv ausgenutzt, muss der Hersteller innerhalb von 24 Stunden eine Frühwarnung an die europäische Sicherheitsbehörde ENISA und das zuständige nationale CSIRT schicken. Eine Kurzmeldung genügt zunächst. Innerhalb von 72 Stunden folgt dann eine ausführlichere Meldung mit einer Bewertung der Schwachstelle, den betroffenen Produkten und den ergriffenen Gegenmaßnahmen. Nach spätestens 14 Tagen wird ein Abschlussbericht fällig, bei größeren Vorfällen nach einem Monat.

Diese Fristen haben es in sich. Sie setzen nämlich voraus, dass ein Unternehmen überhaupt in der Lage ist, Schwachstellen in den eigenen Produkten zu erkennen und einzuordnen. Genau daran scheitert es in der Praxis am häufigsten. Wer keine Übersicht darüber hat, welche Komponenten und Bibliotheken in den eigenen Produkten stecken, kann unmöglich binnen 24 Stunden reagieren.

Die volle Compliance kommt Ende 2027

Ab Dezember 2027 gelten dann die übrigen Pflichten des CRA. Dazu gehören Security by Design über den gesamten Produktlebenszyklus, regelmäßige Sicherheitsupdates und eine sogenannte Software Bill of Materials, also ein maschinenlesbares Inventar aller verwendeten Komponenten. Hinzu kommen Konformitätsbewertung und CE-Kennzeichnung. Bei Verstößen drohen Bußgelder bis zu 15 Millionen Euro oder 2,5 Prozent des weltweiten Jahresumsatzes.

Besonders kritisch sind veraltete Abhängigkeiten. Wer Bibliotheken oder Frameworks einsetzt, für die es keine Sicherheitsupdates mehr gibt, kann seine Update-Pflicht strukturell nicht erfüllen. Für viele gewachsene Anwendungen ist der CRA damit der konkrete Anlass, das Thema Modernisierung endlich anzugehen. Nicht als Kür, sondern als Voraussetzung, um das Produkt weiter verkaufen zu dürfen.

Wo man sinnvollerweise anfängt

Am Anfang steht die Frage, ob man überhaupt betroffen ist. Verkaufen Sie Software oder vernetzte Produkte in der EU? Falls ja, folgt die Inventur. Welche Bibliotheken, Frameworks und Laufzeitumgebungen stecken in Ihren Produkten, und werden sie noch gepflegt? Danach braucht es einen definierten Meldeprozess. Es muss klar sein, wer im Unternehmen von einer Schwachstelle erfährt, wer sie bewertet und wer die Meldung an die Behörden übernimmt. Und schließlich stellt sich die Frage der Update-Fähigkeit, also ob Sie für alle Produkte am Markt zeitnah Sicherheitsupdates bauen und verteilen können.

Wer diese Fragen heute nicht beantworten kann, hat bis September Handlungsbedarf. Die Grundlagen dafür sind allerdings keine Raketenwissenschaft. Ein Komponenten-Inventar, eine saubere Build-Pipeline und ein funktionierender Update-Mechanismus sind solide Ingenieursarbeit, die sich in überschaubarer Zeit umsetzen lässt. Und sie zahlen sich unabhängig vom CRA aus, weil sie Produktqualität und Wartbarkeit direkt verbessern.