Ein Router, der nach zwei Jahren keine Sicherheitsupdates mehr bekommt. Eine vernetzte Maschinensteuerung, bei der niemand mehr genau sagen kann, welche Open-Source-Bibliotheken darin stecken. Solche Fälle waren lange ein Ärgernis, aber kein Rechtsverstoß. Das ändert sich gerade: Mit dem Cyber Resilience Act (CRA) hat die EU erstmals verbindliche Cybersicherheitsanforderungen für vernetzte Produkte festgelegt. Die erste harte Frist ist der 11. September 2026 gewesen.
Was ist der Cyber Resilience Act?
Der Cyber Resilience Act (CRA) ist eine EU-Verordnung, die einheitliche Cybersicherheitsanforderungen für sogenannte „Produkte mit digitalen Elementen“ einführt. Gemeint sind Hardware und Software, die direkt oder indirekt mit anderen Geräten oder Netzwerken verbunden sind. Die Verordnung wurde am 20. November 2024 im Amtsblatt der EU veröffentlicht und trat am 10. Dezember 2024 in Kraft.
Der Grundgedanke: Cybersicherheit soll nicht länger etwas sein, das nach einem Vorfall nachgerüstet wird, sondern ein Merkmal, das über den gesamten Produktlebenszyklus hinweg mitgedacht wird – von der Konzeption über die Entwicklung und Produktion bis in die Nutzungsphase hinein. Als EU-Verordnung gilt der CRA unmittelbar in allen Mitgliedstaaten; es braucht keine nationale Umsetzung.
Damit reiht sich der CRA in eine Logik ein, die aus dem Produktsicherheitsrecht vertraut ist: Wer ein Produkt auf den europäischen Markt bringt, muss nachweisen können, dass es bestimmte Anforderungen erfüllt. Neu ist, dass Cybersicherheit nun ausdrücklich dazugehört.
Wen betrifft der CRA?
Betroffen sind Hersteller, Importeure und Händler von Produkten mit digitalen Elementen, die in der EU auf den Markt gebracht werden. Der Anwendungsbereich ist bewusst breit gefasst und reicht von Consumer-Geräten wie Smartwatches und Babyphonen bis hin zu Industriekomponenten, IoT-Sensorik, Firewalls und Routern. Auch reine Softwareprodukte fallen darunter.
Der CRA differenziert dabei risikobasiert: Neben der Grundkategorie gibt es „wichtige“ und „kritische“ Produkte mit digitalen Elementen, für die strengere Anforderungen an die Konformitätsbewertung gelten. Für Hersteller heißt das zunächst: Es lohnt sich, das eigene Portfolio früh daraufhin zu prüfen, welche Produkte überhaupt in den Anwendungsbereich fallen und in welcher Kategorie sie liegen.
Wichtig ist auch ein Punkt, der leicht übersehen wird: Die Meldepflichten ab September 2026 gelten nicht nur für Produkte, die nach diesem Datum neu auf den Markt kommen. Sie erfassen auch Produkte, die bereits seit Jahren im Feld sind. Für viele Unternehmen bedeutet das, sich mit einem Bestand auseinanderzusetzen, dessen Softwarestände nicht durchgängig dokumentiert sind.
Hinzu kommt die Lieferkette. Kaum ein vernetztes Produkt besteht heute nur aus eigenem Code – Open-Source-Bibliotheken, zugekaufte Module und Firmware von Zulieferern sind die Regel. Die Verantwortung gegenüber dem Markt bleibt beim Hersteller, unabhängig davon, wo eine Schwachstelle ihren Ursprung hat.
Zeitplan und Fristen
Der CRA wird gestaffelt wirksam. Diese Daten sollten Sie im Kalender haben:
Die Meldefristen sind der Teil, der Organisationen erfahrungsgemäß zuerst unter Druck setzt. 24 Stunden sind keine Zeitspanne, in der sich eine Meldekette noch improvisieren lässt – die Prozesse, Zuständigkeiten und Kontaktwege müssen vorher stehen.
Die zentralen Pflichten für Hersteller
Inhaltlich lassen sich die Anforderungen des CRA auf einige Kernpunkte verdichten:
Risikobewertung über den Lebenszyklus. Hersteller müssen Cybersicherheitsrisiken bewerten, dokumentieren und angemessene Schutzmaßnahmen umsetzen – und zwar nicht einmalig, sondern begleitend über Design, Entwicklung, Produktion und Nutzung.
Software Bill of Materials (SBOM). Für jedes betroffene Produkt muss eine maschinenlesbare Stückliste der enthaltenen Softwarekomponenten geführt werden, mindestens auf Ebene der direkten Abhängigkeiten. Gängige Formate sind SPDX und CycloneDX. Die SBOM muss nicht veröffentlicht werden, aber sie gehört in die technische Dokumentation und muss den Marktüberwachungsbehörden auf Verlangen vorgelegt werden. Und sie muss aktuell bleiben: Jedes Update verändert potenziell den Softwarestand.
Schwachstellen- und Patch-Management. Sicherheitsupdates müssen über einen angemessenen Unterstützungszeitraum bereitgestellt werden. Das setzt voraus, dass ein Hersteller überhaupt weiß, welcher Softwarestand in welchem ausgelieferten Produkt steckt.
Technische Dokumentation und CE-Kennzeichnung. Ab Dezember 2027 ist die CE-Kennzeichnung Voraussetzung für den Marktzugang. Sie basiert auf einer Dokumentation, die die Konformität belegbar macht.
Die Sanktionen sind erheblich: Verstöße können mit bis zu 15 Millionen Euro oder 2,5 Prozent des weltweiten Jahresumsatzes geahndet werden.
Was Unternehmen jetzt tun sollten
Unternehmen, die noch nicht vollständig für das Reporting gerüstet sind, sollten dies mit sofortiger Priorität operativ angehen. Vier Schritte sind ein sinnvoller Einstieg:
- Betroffenheit klären. Welche Produkte fallen in den Anwendungsbereich und welche Risikoklasse trifft zu?
- Meldeprozess aufsetzen. Die 24-Stunden-Frist ab September 2026 ist die nächstliegende Hürde. Wer meldet, an wen, auf welchem Weg – und wer entscheidet, ob eine Schwachstelle „aktiv ausgenutzt“ wird?
- SBOM-Fähigkeit aufbauen. Dies sollte nicht als einmaliges Projekt, sondern als Teil des Entwicklungs- und Release-Prozesses verstanden werden.
- Verantwortlichkeiten klären. Der CRA betrifft Security, Produktentwicklung, Qualitätssicherung und Compliance gleichzeitig. Ohne eine klare Zuordnung bleibt die Aufgabe zwischen den Bereichen liegen.
Es lohnt sich, diese Schritte nicht als Compliance-Projekt neben der Produktentwicklung zu führen, sondern in bestehende Entwicklungs- und Freigabeprozesse einzubetten. Anforderungen, die nur in einer separaten Nachweisakte leben, veralten schnell – solche, die im Release-Prozess verankert sind, bleiben aktuell.
Wo eine durchgängige Produktdatenbasis hilft
Die meisten CRA-Anforderungen laufen auf dieselbe Frage hinaus: Können Sie zu einem konkreten Produkt – auch fünf Jahre nach Auslieferung – sagen, aus welchen Komponenten es besteht, welche Anforderungen dafür galten und welcher Softwarestand ausgeliefert wurde?
Genau an dieser Stelle setzt eine PLM-Plattform an. CONTACT Elements bildet den Produktlebenszyklus durchgängig ab und verknüpft Anforderungen, Komponenten, Dokumente und Änderungsstände miteinander. Diese Nachvollziehbarkeit ist keine CRA-Konformität an sich – sie ist aber die Grundlage, auf der sich SBOM-Pflege, technische Dokumentation und Nachweisführung gegenüber Behörden praktikabel organisieren lassen, statt sie im Ernstfall aus verstreuten Quellen zusammenzusuchen.
Wenn Sie überlegen, wie sich die CRA-Anforderungen in Ihre bestehenden Entwicklungsprozesse einfügen lassen, sprechen Sie uns gerne an.
Fazit
Der Cyber Resilience Act verschiebt Cybersicherheit von einer freiwilligen Qualitätsfrage zu einer Marktzugangsvoraussetzung. Die Fristen im September 2026 und Dezember 2027 wirken auf den ersten Blick komfortabel, betreffen aber Prozesse, die sich nicht kurzfristig aufbauen lassen – insbesondere Meldeketten und eine belastbare Dokumentation des eigenen Softwarebestands. Der beste Zeitpunkt, damit anzufangen, ist deutlich vor der Frist.