Lesezeit 6 min
Das Inkrafttreten des Cyber Resilience Act (CRA, deutsch: Cyberresilienz-Verordnung (CRV)) bedeutet, das fast kein elektronisches Produkt mehr ohne Berücksichtigung der Cybersicherheit, ohne einen Damm zum Internet entwickelt werden kann.
Was heisst das für Sie? Hier haben wir allgemeine Informationen zu verschiedenen Aspekten der CRA zusammengetragen. Melden Sie sich gerne bei mir, wenn Sie zusätzliche Fragen haben!
Für Informationen spezifisch für Entwickler, sehen Sie CRA für Entwicklung. Für die Situation der harmonisierten Normen, besuchen Sie Cyber-Regulierung: CRA und NIS.
Beide Abkürzungen bedeuten dasselbe. CRA steht für den englischen Begriff «Cyber Resilience Act» und CRV für den deutschen Begriff «Cyberresilienz-Verordnung».
EU-Verordnungen und EU-Richtlinien sind zwei Formen von Rechtsakten in der EU-Gesetzgebung. Während Richtlinien von den Mitgliedstaaten in nationales Recht umgesetzt werden müssen, gelten Verordnungen grundsätzlich direkt und unmittelbar in allen Mitgliedstaaten.
Die Verordnung trägt den Titel «Verordnung (EU) 2024/2847 des europäischen Parlaments und des Rates vom 23. Oktober 2024 über horizontale Cybersicherheitsanforderungen für Produkte mit digitalen Elementen und zur Änderung der Verordnungen (EU) Nr. 168/2013 und (EU) 2019/1020 und der Richtlinie (EU) 2020/1828 (Cyberresilienz-Verordnung)» und kann direkt vom EUR-Lex-Portal heruntergeladen werden.
Die Verordnung gliedert sich in drei Bereiche. Zu Beginn kommen die Erwägungsgründe (Erwgr.), danach der eigentliche Verordnungstext (Art.) und zum Schluss die Anhänge (Anhang).
Die Erwägungsgründe erläutern den Hintergrund, die Ziele und die Überlegungen, die den einzelnen Bestimmungen der Verordnung zugrunde liegen. Sie dienen als Orientierungshilfe für die Auslegung und Anwendung der Artikel und Anhänge, haben aber keine unmittelbare Rechtswirkung. Sie sind jedoch zu berücksichtigen.
Zwei Hauptprobleme, die angegangen werden müssen, da sie hohe Kosten für die Nutzer und die Gesellschaft verursachen (Erwgr. 1):
Bei u.a. falschen oder unvollständigen Informationen - bis zu 5 Mio. € oder 1 % des Jahresumsatzes (Art. 64 Abs. 4). Siehe auch «Welche Dokumentation muss ich erstellen?»
Bei Verstoss gegen u.a. die Herstellerpflichten - bis zu 15 Mio. € oder 2,5 % des Jahresumsatzes (Art. 64 Abs. 1).
Die Europäische Union (EU) und Staaten des Europäischen Wirtschaftsraum (EWR).
Die Verordnung sieht ein stufenweises Vorgehen vor, bis sie ab dem 11. Dezember 2027 für alle neuen Produkte eingehalten werden muss (Art. 71 Abs.2).
Wichtig zu wissen ist, dass aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle bereits ab dem 11. September 2026 gemeldet werden müssen (Art. 71 Abs.2).
Ja, alle Produkte müssen der CRA genügen (Art. 69 Abs. 2), auch solche, welche so (als «Produkt Typ») schon lange verkauft werden. Produkte, die schon vorher auf den Markt gebracht wurden, unterstehen der CRA bei wesentlichen Änderungen.
Der Absatz besagt: «Produkte mit digitalen Elementen, die vor dem 11. Dezember 2027 in den Verkehr gebracht wurden, unterliegen den in dieser Verordnung festgelegten Anforderungen nur dann, wenn nach diesem Zeitpunkt diese Produkte einer wesentlichen Änderung unterliegen.» Zur Interpretation dieses Absatzes ist die Definition des Begriffes «Produkt» und seine Unterscheidung von «Produktart» in der EU Gesetzgebung sehr wichtig.
Gemäss dem «Blue Guide» der EU, Kapitel 2.3, zweiter Absatz:
«Hinsichtlich der „Bereitstellung“ bezieht sich der Begriff „Inverkehrbringen“ nicht auf eine Produktart, sondern auf jedes einzelne Produkt, unabhängig davon, ob es als Einzelstück oder in Serie hergestellt wurde. Folglich kann das Inverkehrbringen in der Union für jedes einzelne Produkt nur einmal in der gesamten EU und nicht in jedem einzelnen Mitgliedstaat erfolgen. Daher muss jedes einzelne Produkt eines Produktmodells oder einer Produktart, das nach dem Inkrafttreten neuer Anforderungen in Verkehr gebracht wird, diese erfüllen, auch wenn die Bereitstellung des Produktmodells oder der Produktart vor dem Inkrafttreten neuer Harmonisierungsrechtsvorschriften der Union mit neuen obligatorischen Anforderungen erfolgte.»
Das heisst, das «Produkt» ist die Verkörperung, ein konkretes Exemplar (d.h. hergestelltes Gerät) einer «Produktart» / eines «Produktmodells». Für dieses konkrete Exemplar, d.h. das konkrete, einzelne Produkt gelten die Vorschriften und das CE-Zeichen. Und dies ist unabhängig davon, ob eine Verkörperung, ein «Produkt» derselben «Produktart» vorher schon auf dem Markt war oder nicht.
Nehmen wir an, es wurden von einem Modell eines Routers 100'000 Router hergestellt. Nun wurden davon vor dem Inkrafttreten der CRA 70'000 verkauft, d.h. 30'000 sind noch an Lager. Diese 30'000 Router müssen die CRA erfüllen, damit sie nach dem Inkrafttreten der Verordnung noch verkauft werden dürfen.
Die EU-Kommission wird den Begriff der wesentlichen Änderung mit einer Leitlinie noch genauer definieren (Art. 26 Abs. 1, 2d).
Bis dahin hilft uns der CRA, indem er ihn an verschiedenen Stellen aufnimmt, z.B.
«… auf die Konformität des Produkts mit den grundlegenden Cybersicherheitsanforderungen in Anhang I Teil I auswirkt … des bestimmungsgemäßen Zwecks, für den das Produkt geprüft wurde, führt» (Art. 3 Abs. 30).
«… wenn sich die wesentliche Änderung auf die Cybersicherheit des Produkts mit digitalen Elementen insgesamt auswirkt …» (Art. 22 Abs. 2)
Daraus folgt, dass die Auswirkungen einer Änderung untersucht werden müssen. Dies geschieht in der Regel durch eine Risikobewertung.
Der CRA bezieht sich auf Software- und Hardwareprodukte und deren (zugehörige) Datenfernverarbeitungslösungen (Art. 2 Abs. 1). Damit sind reine Softwareprodukte und -komponenten (z.B. Anwendungen, Betriebssysteme), reine Hardwareprodukte und -komponenten (z.B. Mikrocontroller) und Kombinationen davon (z.B. Messgeräte, Kaffeemaschinen) gemeint.
«… deren bestimmungsgemässer Zweck oder vernünftigerweise vorhersehbare Verwendung eine direkte oder indirekte logische oder physische Datenverbindung mit einem Gerät oder Netz einschließt»
Betroffen sind also alle Geräte, die direkt oder indirekt mit anderen Geräten verbunden werden können.
Ja. Siehe oben.
Ja. Siehe oben.
Der CRA gilt nicht für (Art. 2 Abs. 2 – 8, Erwgr. 12):
Es kommt darauf an, ob es sich bei den angebotenen Cloud-Funktionen um Gerätefunktionen handelt, z. B. Fernsteuerung oder Fernkonfiguration von Geräten. Dann ist die Cloud-Software durch den CRA betroffen (Erwgr. 11, 12).
Die Cloud-Plattformen selbst fallen nicht unter den CRA, da sie in der EU-Richtlinie 2022/2555 (NIS2) geregelt sind.
Im Einzelfall kann die Abgrenzung zwischen Dienstleistung und Produkt mit digitalen Elementen bei Cloud-Diensten komplex sein.
Der gesamte Produktlebenszyklus von der Entwicklung über den Betrieb bis zur Ausserbetriebnahme (Art. 13 Abs. 2).
Nein, es sei denn, es handelt sich um ein massgefertigtes Produkt für einen gewerblichen Nutzer, für das etwas anderes vereinbart wurde (Anhang I Teil II Abs. 8).
Die Cybersicherheit muss für die erwartete Lebensdauer des Produkts, mindestens jedoch für 5 Jahre, gewährleistet sein.
Die CRA verwendet die Definition gemäss Artikel 2 Nummer 1 der Verordnung (EU) 2019/881 (Art. 3 Abs. 3)):
«`Cybersicherheit` bezeichnet alle Tätigkeiten, die notwendig sind, um Netz- und Informationssysteme, die Nutzer solcher Systeme und andere von Cyberbedrohungen betroffene Personen zu schützen»
Art. 3 Abs. 1 - 51 definiert die in der CRA verwendeten Begriffe und wie diese zu verstehen sind, z.B. Software, Hardware, Komponenten, Inverkehrbringen etc.
Die Anforderungen hängen davon ab was für ein Wirtschaftsakteure ich bin. Der CRA unterscheidet Hersteller (Art. 13), Einführer (Art. 19), Händler (Art. 20) und Verwalter quelloffener Software (Art. 24).
Importeure und Händler werden automatisch zu Herstellern, wenn sie Produkte unter ihrem eigenen Namen oder ihrer eigenen Marke in Verkehr bringen oder diese wesentlich verändern (Art. 21, 22).
In Anhang I sind die Anforderungen an die Hersteller eines Produkts festgelegt, die während der gesamten Lebensdauer des Produkts erfüllt werden müssen.
Die Bewertung der Cybersicherheitsrisiken muss während dieser Phase (Herstellungs-, Liefer- und Wartungsphase) ständig aktualisiert werden (Teil I Abs. 2).
Es dürfen keine Produkte mit bekannten ausnutzbaren Schwachstellen auf dem Markt bereitgestellt werden. Dies ist durch aktive Massnahmen sicherzustellen (Teil II Abs. 3). Eine Software-Stückliste hilft dabei (Teil II Abs. 1).
Eine erkannte Schwachstelle muss unverzüglich gemeldet und geschlossen werden. Dazu muss ein Prozess vorhanden sein und gelebt werden (Teil II Abs. 5).
Sicherheitsaktualisierungen sind kostenlos zeitnah und sicher bereitzustellen, möglichst getrennt von funktionalen Aktualisierungen (Teil II Abs. 2, 7). Eine automatisierte und sichere Aktualisierung der Software ist anzustreben (Teil II Abs. 7).
Dritte müssen auf einfache Weise auf Schwachstellen im Produkt hinweisen können (Teil II Abs. 6). Dafür eignet sich der Quasistandard security.txt welcher auch vom Bundesamt für Cybersicherheit BACS empfohlen wird.
Eine erkannte Schwachstelle muss unverzüglich gemeldet und geschlossen werden.
Die Meldung muss eine Beschreibung der Schwachstelle mit Angaben enthalten, die es dem Nutzer ermöglichen, das betroffene Produkt, die Auswirkungen der Schwachstelle und deren Schweregrad zu erkennen.
Eine maschinenlesbare Meldung ist wünschenswert, da die manuelle Auswertung zeitaufwendig ist. Das Common Security Advisory Framework (CSAF) ist ein standardisiertes und quelloffenes Framework, um maschinenverarbeitbare Schwachstellen- und Mitigationsinformationen zu kommunizieren und automatisiert zu verteilen.
Die Technische Richtlinie TR-03183-3 des BSI und die dazugehörige Leitlinie geben Hinweise zum Umgang mit Schwachstellenmeldungen.
Sie haben eine Meldepflicht, mit folgenden Zeithorizonten:
Die Meldestellen im DACH Raum sind die folgenden:
Sie müssen ein Schwachstellenmanagement betreiben, was für Sie heisst:
Alois Cavelti
Haben Sie zusätzliche Fragen? Haben Sie eine andere Meinung? Wenn ja, mailen Sie mir oder kommentieren Sie Ihre Gedanken unten!

ist Dipl. Elektroingenieur FH , Mitgründer, stellvertretender Geschäftsführer und Software-Entwickler. Er ist Spezialist für Architekturen und Software in C, C++ und C#. Er setzt sich für wartbare Architektur, Security und sauberen Code ein. Dafür schaut er gerne über den «embedded» Tellerand in andere Bereiche der Softwareentwicklung. Gesamtsysteme jeglicher Art und deren Zusammenhänge interessieren ihn. Alois bewirtschaftet eine 5'000 m2 Biodiversitätsinsel und bringt dabei Natur, Pferd und Mensch in Einklang. Er liebt gute (Film)Geschichten und gutes Essen.

ist Dipl. Ing./BSc ZFH in Informatik und macht Software vom Sensor bis in die Cloud. Seine berufliche Laufbahn ist geprägt von einer tiefen Neugier für Innovationen und alles Neue in der digitalen Welt. Als Ausgleich zum technologischen Alltag hält er sich mit vielseitigem Sport fit und aktiv.
Projekte? Ideen? Fragen? Machen wir einen kostenlosen Erst-Workshop!
Keine Kommentare