Der Cyber Resilience Act (CRA) ist keine geplante Initiative mehr. Die EU-Verordnung 2024/2847 ist seit Dezember 2024 in Kraft und wird schrittweise wirksam. Meldepflichten gelten ab 11. September 2026, die meisten übrigen Vorschriften ab 11. Dezember 2027.
Die Verordnung setzt dort an, wo bisher häufig niemand dauerhaft verantwortlich war: Ein vernetztes Produkt kommt auf den Markt, erhält einige Zeit Updates und bleibt danach mit bekannten Schwachstellen im Einsatz. Künftig müssen Hersteller Cybersicherheit über den vorgesehenen Nutzungs- und Supportzeitraum systematisch behandeln.
Welche Produkte erfasst der CRA?
Der CRA betrifft Produkte mit digitalen Elementen, deren bestimmungsgemäße oder vernünftigerweise vorhersehbare Nutzung eine direkte oder indirekte Verbindung zu einem Gerät oder Netzwerk umfasst. Dazu können gehören:
- Software und Betriebssysteme
- vernetzte Geräte und IoT-Produkte
- Hardware mit digitalen Funktionen
- einzelne Komponenten, die separat auf dem Markt angeboten werden
Adressaten sind vor allem Hersteller, Importeure und Händler. Ein Unternehmen wird also nicht allein dadurch zum Verpflichteten, dass es Standardsoftware oder vernetzte Geräte nutzt. Relevant wird die Rolle, wenn es Produkte selbst entwickelt, unter eigenem Namen vertreibt, wesentlich verändert oder aus Drittstaaten in die EU einführt.
Für bestimmte freie und quelloffene Software gelten besondere Regeln. Nicht jede unentgeltliche Veröffentlichung eines Open-Source-Projekts wird wie ein kommerzielles Produkt behandelt. Sobald eine Software jedoch im Rahmen einer kommerziellen Tätigkeit bereitgestellt wird, muss die konkrete Rolle sorgfältig geprüft werden.
Was Hersteller leisten müssen
Die Anforderungen reichen deutlich weiter als ein einmaliger Sicherheitstest vor Veröffentlichung:
- Risiken bewerten und Sicherheitsanforderungen bereits in Entwicklung und Produktion berücksichtigen
- Produkte ohne bekannte ausnutzbare Schwachstellen bereitstellen
- Schwachstellen während des Supportzeitraums behandeln und Sicherheitsupdates liefern
- einen Prozess für koordinierte Offenlegung von Schwachstellen vorhalten
- technische Dokumentation, Konformitätsbewertung und EU-Konformitätserklärung erstellen
- den Supportzeitraum für Nutzer transparent angeben
- aktiv ausgenutzte Schwachstellen und schwere Sicherheitsvorfälle fristgerecht melden
Die CE-Kennzeichnung bleibt das sichtbare Zeichen der Konformität. Sie ist aber kein neues Gütesiegel, das absolute Sicherheit garantiert. Sie zeigt, dass der Hersteller die für das Produkt geltenden Anforderungen und das vorgesehene Konformitätsverfahren erfüllt hat.
Der Zeitplan
Die Übergangsfrist sollte nicht dazu verleiten, bis 2027 zu warten:
- 11. Juni 2026: Vorschriften für die Notifizierung von Konformitätsbewertungsstellen werden anwendbar.
- 11. September 2026: Die Meldepflichten für aktiv ausgenutzte Schwachstellen und schwere Vorfälle greifen.
- 11. Dezember 2027: Der CRA gilt grundsätzlich vollständig.
Vor allem die Meldepflichten benötigen funktionierende Prozesse, bevor der erste Vorfall eintritt. Unter Zeitdruck eine Produktinventur, Zuständigkeiten und belastbare technische Informationen zusammenzusuchen, ist eine schlechte Premiere.
Was Unternehmen jetzt konkret tun sollten
1. Rollen und Produkte inventarisieren
Erfasse, welche digitalen Produkte das Unternehmen entwickelt, anbietet, importiert oder wesentlich verändert. Ordne für jedes Produkt die eigene wirtschaftliche Rolle zu. Ohne diese Inventur bleibt jede weitere Maßnahme Spekulation.
2. Supportzeiträume festlegen
Kunden müssen wissen, wie lange sie mit Sicherheitsupdates rechnen können. Produktlebensdauer, erwartete Nutzung und Verfügbarkeit von Ersatzteilen oder Plattformen gehören deshalb zusammen betrachtet.
3. Schwachstellenprozess aufbauen
Definiere einen erreichbaren Meldeweg, eine verantwortliche Stelle, Bewertungsmaßstäbe und Fristen. Software Bill of Materials, Abhängigkeitsüberwachung und reproduzierbare Builds können helfen, ersetzen aber keine organisatorische Verantwortung.
4. Nachweise in den Entwicklungsprozess integrieren
Bedrohungsmodell, Sicherheitsanforderungen, Testergebnisse, bekannte Restrisiken und Freigaben sollten dort entstehen, wo das Produkt entwickelt wird. Eine Dokumentationsaktion kurz vor Markteinführung ist teuer und liefert meist schlechte Nachweise.
5. Lieferanten einbeziehen
Hersteller bleiben auf Informationen über Komponenten und Bibliotheken angewiesen. Verträge, Updatezusagen und Meldewege sollten deshalb zur Beschaffung gehören. Ein allgemeiner Satz wie „branchenübliche Sicherheit“ ist dafür zu wenig.
Was Einkäufer und IT-Verantwortliche daraus ableiten können
Auch Unternehmen ohne eigene Herstellerrolle profitieren von klareren Fragen an Lieferanten:
- Wie lange wird das Produkt mit Sicherheitsupdates versorgt?
- Wie werden Schwachstellen gemeldet und kommuniziert?
- Welche Abhängigkeiten sind enthalten?
- Was geschieht am Ende des Supportzeitraums?
- Lassen sich sicherheitsrelevante Updates zentral verteilen?
„CRA-konform“ sollte dabei nicht zum neuen Marketingstempel werden. Entscheidend sind prüfbare Antworten, dokumentierte Prozesse und ein Supportmodell, das zur tatsächlichen Nutzungsdauer passt.
Fazit
Der Cyber Resilience Act macht Produktsicherheit zu einer nachvollziehbaren Verantwortung über den Lebenszyklus. Das ist mehr als Patch-Management und weniger romantisch als „Security ist eine Haltung“: Es geht um Produktinventar, Prozesse, Nachweise, Meldefähigkeit und dauerhaft finanzierte Pflege. Wer damit vor den verbindlichen Fristen beginnt, reduziert nicht nur Compliance-Risiken, sondern baut Produkte, die im Betrieb weniger unangenehme Überraschungen erzeugen.
