Cyber Resilience Act: Die fünf wichtigsten Erkenntnisse aus den Leitlinien der EU-Kommission

Der Cyber Resilience Act (CRA) stellt Hersteller von Software, vernetzten Geräten und anderen Produkten mit digitalen Elementen vor umfangreiche neue Anforderungen an die Cybersicherheit. Während die meisten Vorgaben ab dem 11. Dezember 2027 gelten, müssen Hersteller bereits ab dem 11. September 2026 aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle melden.

Bei der Vorbereitung auf den CRA stellen sich zahlreiche praktische Fragen: Wann gilt eine neue Softwareversion als neues Produkt? Welche Folgen hat ein wesentliches Update? Wie lange müssen Sicherheitsupdates bereitgestellt werden? Und müssen bereits entwickelte Produkte für den CRA neu konstruiert werden?

Die EU-Kommission hat nun Leitlinien zur Anwendung des CRA veröffentlicht. Darin erläutert die EU-Kommission anhand praxisnaher Beispiele, wie zentrale Begriffe und Pflichten des CRA nach ihrer Auffassung zu verstehen sind. Die Leitlinien sind zwar rechtlich nicht bindend, bieten Unternehmen und voraussichtlich auch den zuständigen Behörden aber wichtige Orientierung für die laufende Umsetzung.

Nachfolgend haben wir Aspekte der Leitlinien mit besonders hoher Praxisrelevanz zusammengefasst: 

1. Die 24-Stunden-Meldefrist beginnt nicht beim ersten Verdacht

Ab dem 11. September 2026 müssen Hersteller aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle melden. Die Leitlinien erläutern, ab welchem Zeitpunkt die kurzen Meldefristen laufen.

Ein unbestätigter Hinweis allein löst die Frist noch nicht aus. Der Hersteller muss ihn jedoch unverzüglich prüfen. Die Meldefrist beginnt, sobald nach dieser ersten Prüfung mit hinreichender Sicherheit feststeht, dass:

• eine im Produkt enthaltene Schwachstelle aktiv ausgenutzt wird oder
• ein schwerwiegender Sicherheitsvorfall aufgetreten ist und die Sicherheit des Produkts beeinträchtigt hat.

Ab diesem Zeitpunkt ist grundsätzlich innerhalb von 24 Stunden eine erste Warnmeldung abzugeben. Innerhalb von 72 Stunden folgt eine ergänzende Meldung. Bei einer aktiv ausgenutzten Schwachstelle ist der vollständige Bericht grundsätzlich innerhalb von 14 Tagen nach Verfügbarkeit einer Korrektur- oder Minderungsmaßnahme einzureichen. Bei einem schwerwiegenden Sicherheitsvorfall beträgt die Frist einen Monat nach der 72-Stunden-Meldung.

Unternehmen benötigen daher neben einem technischen Meldeweg auch klare Zuständigkeiten für die erste Bewertung und Eskalation. Der Prozess sollte sowohl externe Hinweise als auch Erkenntnisse aus eigenen Sicherheitstests erfassen. Die Leitlinien betonen, dass die erste Prüfung unverzüglich erfolgen muss – insbesondere, wenn die mögliche Schwachstelle ein erhebliches Risiko darstellt. Entsprechende Abläufe sollten vor dem 11. September 2026 praktisch erprobt werden.

2. Eine Softwareversion wird grundsätzlich nur einmal in Verkehr gebracht

Software, die als eigenes Produkt angeboten wird, wird nach Auffassung der EU-Kommission zu dem Zeitpunkt in Verkehr gebracht, zu dem die fertiggestellte Version erstmals auf dem EU-Markt angeboten wird. Dies gilt unabhängig davon, wann einzelne Kunden die Software erwerben oder herunterladen.

Die Leitlinien verdeutlichen dies anhand eines Beispiels: Wird die Softwareversion 1.0.0 am 1. Januar 2028 erstmals zum Download angeboten, gilt sie an diesem Tag als in Verkehr gebracht – auch wenn einzelne Kunden sie erst später herunterladen. Eine später bereitgestellte Version 1.0.1 gilt nicht als neu in Verkehr gebracht, sofern die Änderungen nicht wesentlich sind. Für sie bleibt daher das ursprüngliche Datum maßgeblich.

Anders kann es bei verschiedenen Varianten derselben Software sein, etwa bei Builds für unterschiedliche Betriebssysteme oder bei Paketen mit abweichenden Funktionen. Solche Varianten können als eigenständige Produkte gelten. Eine neue Softwareversion wird zudem erneut in Verkehr gebracht, wenn sie wesentlich geändert wurde.

Diese Abgrenzung ist vor allem für die Übergangsregeln des CRA wichtig. Hersteller sollten dokumentieren, wann einzelne Versionen erstmals angeboten wurden, welche Varianten sie als eigene Produkte behandeln und welche Änderungen später vorgenommen wurden.

3. Bereits entwickelte Produkte müssen nicht automatisch neu konstruiert werden

Viele Produkte, die erst nach dem 11. Dezember 2027 auf den Markt kommen, befinden sich bereits heute in der Entwicklung oder sind schon fertig entwickelt. Nach den Leitlinien verlangt der CRA in solchen Fällen nicht automatisch eine Neukonstruktion.

Hersteller müssen allerdings die Cybersicherheitsrisiken des Produkts bewerten. Anhand der technischen Dokumentation müssen sie nachweisen können, dass das Produkt ein angemessenes Sicherheitsniveau erreicht und die Anforderungen des CRA erfüllt. Auch die vorgeschriebene Konformitätsbewertung, die EU-Konformitätserklärung und die CE-Kennzeichnung bleiben erforderlich.

Die Kommission verlangt jedoch nicht zwingend, sämtliche Nachweise und Tests aus früheren Entwicklungsphasen nachträglich zu erstellen. Lässt sich nicht mehr belegen, wie die Cybersicherheitsrisiken während der ursprünglichen Entwicklung berücksichtigt wurden, kann der Hersteller eine aktuelle Risikobewertung vornehmen und darlegen, wie das bestehende Produktdesign und die vorhandenen Sicherheitsmaßnahmen die festgestellten Risiken begrenzen.

Diese Klarstellung ist insbesondere für Industrieprodukte mit langen Entwicklungszyklen relevant. Unternehmen sollten prüfen, welche Nachweise für laufende Produktentwicklungen bereits vorhanden sind und wo noch Dokumentationslücken geschlossen werden müssen.

4. Bei Softwareupdates entscheidet das Sicherheitsrisiko, nicht der Umfang

Nicht jedes größere Update ist eine „wesentliche Änderung“ im Sinne des CRA. Umgekehrt kann auch eine kleine Anpassung wesentlich sein. Entscheidend ist, ob sich der vorgesehene Einsatz des Produkts verändert oder neue beziehungsweise höhere Cybersicherheitsrisiken entstehen, die bisher nicht berücksichtigt wurden.

Als Beispiel nennt die Kommission ein System, das zunächst nur Betriebsdaten von Maschinen anzeigt. Erhält es später die Möglichkeit, diese Maschinen zu steuern, verändert sich sein vorgesehener Einsatz. Das Update ist daher als wesentliche Änderung einzustufen.

Die Leitlinien nennen zudem nicht abschließende Prüfkriterien. Zu untersuchen ist insbesondere, ob ein Update:

• zusätzliche Schnittstellen, Kommunikationskanäle, Ausführungsumgebungen oder externe Abhängigkeiten einführt,
• neue Angriffsszenarien ermöglicht oder
• die Wahrscheinlichkeit oder die möglichen Auswirkungen bereits betrachteter Angriffe erheblich verändert.

Eine größere Funktionserweiterung muss dagegen nicht wesentlich sein, wenn sie bereits bei der ursprünglichen Entwicklung geplant und in der Risikobewertung berücksichtigt wurde. Updates, die ausschließlich Schwachstellen beheben oder bestehende Sicherheitsmaßnahmen stärken, stellen regelmäßig keine wesentliche Änderung dar, sofern sie weder den Verwendungszweck ändern noch neue oder höhere Cybersicherheitsrisiken verursachen.

Unternehmen sollten ihre Produkt-Roadmaps deshalb frühzeitig mit der Risikobewertung verknüpfen. Die technische Einstufung als Major- oder Minor-Release reicht für die rechtliche Bewertung nicht aus. Sinnvoll ist ein dokumentierter Prozess, mit dem sicherheitsrelevante Updates anhand der Kriterien des CRA geprüft werden.

5. Fünf Jahre sind kein pauschaler Supportzeitraum

Der CRA verlangt grundsätzlich einen Supportzeitraum von mindestens fünf Jahren. Wird ein Produkt voraussichtlich kürzer genutzt, darf auch der Supportzeitraum kürzer sein. Bei Produkten mit einer längeren erwarteten Nutzungsdauer reichen fünf Jahre dagegen nicht automatisch aus.

Das betrifft insbesondere Industrieanlagen, Steuerungen und andere langlebige Produkte. Bei ihnen muss sich der Supportzeitraum an der realistisch zu erwartenden Nutzungsdauer orientieren. Die Leitlinien stellen ausdrücklich klar, dass fünf Jahre nicht als pauschaler Standard für alle Produkte anzusehen sind.

Eine wesentliche Änderung führt zudem nicht automatisch dazu, dass ein neuer fünfjähriger Supportzeitraum beginnt. Entscheidend ist, ob die Änderung auch die erwartete Nutzungsdauer des Produkts beeinflusst. Ergänzt etwa ein Softwareupdate lediglich neue Funktionen, ohne die Lebensdauer der Hardware oder die Erwartungen der Nutzer zu verändern, bleibt es grundsätzlich bei der noch verbleibenden ursprünglichen Supportdauer.

Bei laufend weiterentwickelter Software darf sich die Behebung von Schwachstellen unter bestimmten Voraussetzungen auf die zuletzt in Verkehr gebrachte Version beschränken. Nutzer müssen kostenlos und ohne zusätzliche Kosten auf diese Version wechseln können. Normaler Aufwand für Tests oder Konfigurationsänderungen gilt dabei grundsätzlich nicht als zusätzliche Kosten. Ist hingegen der Kauf neuer Hardware oder ein grundlegender Umbau der Systemumgebung erforderlich, kann sich der Hersteller nicht auf diese Erleichterung berufen.

Praxistipp

Die Leitlinien schaffen keine zusätzlichen gesetzlichen Pflichten. Sie konkretisieren aber wichtige Fragen, die Unternehmen bei der Umsetzung des CRA beantworten müssen.

Hersteller sollten insbesondere prüfen, ob Softwareversionen und Updates nachvollziehbar dokumentiert werden, die Risikobewertung mit der Produktplanung verknüpft ist, Supportzeiträume realistisch festgelegt wurden und der Meldeprozess ab September 2026 einsatzbereit ist.

Darüber hinaus behandeln die Leitlinien unter anderem freie und quelloffene Software, cloudbasierte Funktionen, Ersatzteile sowie das Zusammenspiel des CRA mit der Fahrzeugregulierung, der Funkanlagenrichtlinie und der Maschinenverordnung.

Entdecken Sie auch unsere CRA Compliance Suite
Modulare Festpreis-Beratung zur Umsetzung der Anforderungen des Cyber Resilience Act (CRA) für Hersteller, Importeure und Händler digitaler Produkte. Mehr Informationen.