Cyber Resilience Act (CRA)

Langtitel: (Vorläufig) Proposal for a regulation of the European Parliament and of the Council on horizontal cybersecurity requirements for products with digital elements and amending Regulation (EU) 2019/1020 (COM(2022)0454 – C9-0308/2022 – 2022/0272(COD))

Kurztitel: Cyber Resilience Act (CRA)

Eine Einigung wurde im März 2024 im Europäischen Parlament erzielt. Im Oktober 2024 wurde der CRA vom Rat angenommen.

Die Verordnung ist aktuell (Oktober 2024) noch nicht im Amtsblatt der Europäischen Union veröffentlicht und nicht in Kraft.

im Folgenden wir die absehbare Rechtslage basierend auf dem Text des europäischen Parlaments dargestellt.

Kurzübersicht

Ziele	Anwendungsbereich	Inhalt	Synergie	Konsequenzen
Schwachstellen bei Produkten eindämmen.	Sachlich: Produkte mit digitalen Elementen (Hard- oder Softwareprodukte) deren Verwendung Datenverbindung mit einem Gerät oder Netz einschließt	Angemessenes Sicherheitsniveau von Produkten, Absenz bekannter Schwachstellen		Verstoß gegen Art. 13 und 14 CRA-E; bis zu 15.000.000 € oder von bis zu 2,5 %
Sicherheit während des gesamten Lebenszyklus eines Produkts sicherstellen.	Persönlich: Hersteller, Händler und Einführer	Versetzung in den Werkszustand muss (grundsätzlich) möglich sein.	Sicherheit der Verarbeitung (Art. 32 DSGVO), Technikgestaltung und Voreinstellung (Art. 25 DSGVO)	Verstoß gegen übrige Pflichten; bis zu 10.000.000 € oder 2 % des weltweit erzielten Vorjahresumsatzes
Bedingungen schaffen die es den Nutzern ermöglichen Cybersicherheit zu berücksichtigen.		Sicherheitsbewertungen je nach Sicherheitsklasse	Anforderungen der KI-VO (Art 6, 15) für Hochrisiko-KI-Systeme	Mangelhafte Auskünfte; bis zu 5.000.000 EUR oder 1 % des Vorjahresumsatzes

Einführung

Der Cyber Resilience Act – Entwurf (CRA-E, Parlamentsversion) folgt dem Ziel der Erhöhung der Cybersicherheit mit einheitlichen Cybersicherheitsanforderungen bei Produkten mit digitalen Elementen, vor Allem bei Hard- und Software. Hersteller, Händler und Importeure werden gegenüber ihren Kunden gezwungen transparent aufzuzeigen, wie sicher ihre Produkte sind, Schwachstellen bekannt zu geben und dafür zu sorgen, dass diese beseitigt werden. Darüber hinaus müssen oben genannte Akteure gewährleisten, dass ihre Produkte über deren gesamten Lebenszyklus sicher vor Cyberangriffen sind.

Anwendungsbereich

Sachlicher Anwendungsbereich

Die Verordnung gilt für Produkte mit digitalen Elementen (Hard- oder Softwareprodukte, und deren Datenfernverarbeitungslösungen, welche getrennt in Verkehr gebracht werden), deren bestimmungsgemäße oder vernünftigerweise vorhersehbare Verwendung eine direkte oder indirekte logische oder physische Datenverbindung mit einem Gerät oder Netz einschließt. Physische Datenverbindungen sind jene, welche zwischen elektronischen Informationssystemen oder Komponenten hergestellt werden und physisch oder optisch greifbar sind. Logische Verbindungen sind virtuelle Darstellungen einer Datenverbindung, welche über eine Softwareschnittstelle hergestellt werden.

Ausnahmen: (Art 1 CRA-E)

1. Produkte die sektorspezifischen Regelungen unterliegen: Medizinprodukte | In-vitro-Diagnostika | Kraftfahrzeuge | Zivilluftfahrt | Schiffsausrüstungen
2. Grundsätzlich überall dort wo sektorale Regeln einen gleichwertigen oder höheren Standard fordern.
3. Identische Ersatzteile
4. Produkte für Zwecke der nationalen Sicherheit oder Verteidigung oder für Produkte, die speziell für die Verarbeitung von Verschlusssachen bestimmt sind.

Beispiele: Vernetzten Kühlschränken oder Thermostaten, Laptops, Smartphones, Tablets, Smart Watches

Spezialfall Open Source Software

Freie und quelloffene Softwareprodukte („Open-Source“) sind, die außerhalb einer Geschäftstätigkeit entwickelt oder bereitgestellt werden. Ein explizite Ausnahme wurde nicht aufgenommen, die Ausnahme erhibt sich implizit aus der Definition der "Geschäftstätigkeit" und wird EG 18 CRA-E weiter präzisiert.

Produkte, die Open-Source-Produkte enthalten und in den Anwendungsbereich des CRA-E fallen, fallen als Ganzes - einschließlich der enthaltenen Open-Source-Produkte - in den Anwendungsbereich des CRA-E.

Persönlicher Anwendungsbereich

Betroffene Akteure sind primär Hersteller, Händler, Einführer von Produkten mit digitalen Elementen (Importeure) sowie Open-Source Stewards.

Hersteller ist, wer Produkte mit digitalen Elementen entwickelt, herstellt oder diese konzipiert und die Herstellung und Entwicklung beauftragt und jene Produkte unter ihrem Namen oder Markennamen vermarktet unentgeltlich oder monetarisiert (Art 3 Z 13 CRA-E).

Händler ist, wer Teil der Lieferkette ist und ein Produkt mit digitalen Elementen auf dem Unionsmarkt bereitstellt, ohne die Eigenschaften der Ware zu verändern. Hersteller und Einführer sind ausgenommen (Art 3 Z 17 CRA-E).

Importeur ist, wer ein Produkt mit digitalen Elementen einer außerhalb der Union befindende Person, Organisation oder Behörde erstmals am Unionsmarkt in Verkehr bringt (Art 3 Z 16 CRA-E).

Open-Source Steward ist eine juristische Person bei der es sich nicht um einen Hersteller handelt, die den Zweck oder das Ziel hat, die Entwicklung spezifischer Produkte mit digitalen Elementen, die als freie und quelloffene Software gelten und für kommerzielle Tätigkeiten bestimmt sind, systematisch und nachhaltig zu unterstützen, und die die Vermarktbarkeit dieser Produkte sicherstellt.“ (Art. 3 Nr. 14 CRA-E). Die Definition lässt Klassifizierung aufgrund objektiver Gesichtspunkte durch Außenstehende nur eingeschränkt zu. So wird es bei der Qualifizierung eher darauf ankommen ob die juristische Person im Rahmen der internen Zielsetzung der ein Open-Source-Stewardship für ein Produkts annimmt. Nach Art 25 kann die Kommission durch delegierte Rechtsakte Sicherheitsbescheinigungen für Open Source Software erlassen, diesbezüglich sind Stand Oktober 2024 keine Details bekannt. Art 9 CRA-E sieht vor, dass die „Open Source Community“ als Stakeholder bei der Durchführung der Verordnung von der Kommission zu konsultieren ist. So sind neben den wirtschaftlichen Vorteilen des Stwardships auch konkrete Gestaltungsmöglichkeiten verbrieft.

Territorialer Anwendungsbereich

Gegenstand der Regelung ist die Bereitstellung eines Produkts mit digitalen Elementen auf dem Unionsmarkt.

Wesentliche Pflichten:

Hersteller

Gem. Art. 13 Abs. 1 müssen Hersteller gewährleisten, dass die Eigenschaften ihrer Hard- und Softwareprodukte Mindestsicherheitsanforderungen bei Konzeption, Entwicklung und Herstellung erfüllen. Hierbei Ist Anex I Teil I beachtlich, welcher auf die Schaffung eines angemessenen Sicherheitssniveaus abziehlt.

Gem. Art. 13 Abs. 8 stellen Hersteller beim Inverkehrbringen eines Produkts mit digitalen Elementen und während des Unterstützungszeitraums sicher, dass Schwachstellen dieses Produkts, einschließlich seiner Komponenten, wirksam und im Einklang mit den in Anex I Teil II festgelegten grundlegenden Anforderungen behandelt werden.

Gem. Art. 13 Abs. 18 sind die Informationen des Anex II zu erteilen.

In Art. 14 legt der Cyber Resilience Act verschiedene Meldepflichten für Hersteller von Hard- und Softwareprodukten fest. Aktiv ausgenutzte Schwachstellen sind an die Agentur der Europäischen Union für Cybersicherheit (ENISA) zu melden:

• Frühwarnung innerhalb von 24 Stunden
• Benachrichtigung nach 72 Stunden
• Abschlussbericht innerhalb 14 Tage nach Behebung der Schwachstelle

Artikel 23 verpflichtet zur Führung einer umfassenden technischen Dokumentation. Diese Dokumentation muss nicht nur eine allgemeine Beschreibung des Produkts und seiner beabsichtigten Verwendung enthalten, sondern auch detaillierte Informationen zu den Aspekten des Produktdesigns, der Produktentwicklung und der Produktherstellung. Zudem ist eine gründliche Bewertung der Cybersicherheitsrisiken über den gesamten Lebenszyklus des Produkts erforderlich. Ein weiterer wichtiger Bestandteil der Dokumentation ist die Beschreibung der Verfahren zur Schwachstellenbehandlung. Hierzu gehören Informationen über das Design und die Entwicklung des Produkts, die gegebenenfalls durch Abbildungen, Schemata oder eine Beschreibung der Systemarchitektur ergänzt werden. Darüber hinaus muss ein Konzept für die koordinierte Offenlegung von Schwachstellen sowie Spezifikationen zu Herstellungs- und Überwachungsprozessen samt Validierung dokumentiert werden.

Händler

Ehe sie ein Hard- oder Softwareprodukt auf dem EU-Markt bereitstellen, müssen Händler gem. Art 19 CRA-E sicherstellen:

• dass das Produkt ordnungsgemäß mit einer CE-Kennzeichnung versehen ist
• dass die EU-Konformitätserklärung vorhanden ist
• dass die Mindestinformation des Herstellers bzw. des Importeurs vorhanden ist
• dass ausführliche Nutzeranleitungen vorhanden sind

Liegt aufgrund einer Schwachstelle ein erhebliches Cybersicherheitsrisiko vor, müssen Händler unverzüglich die Marktüberwachungsbehörden der Mitgliedstaaten unterrichten, in denen sie das Produkt vertreiben.

Wird bekannt, dass ein Hersteller seine Betriebstätigkeit einstellt, müssen Händler die zuständigen Marktüberwachungsbehörden hiervon unterrichten.

Importeur

Importeure müssen vor dem Inverkehrbringen eines Produkts aktiv sicherstellen, dass:

• Der Hersteller eine Konformitätsbewertung durchgeführt hat
• Die erforderliche technische Dokumentation vorhanden ist
• Das Produkt die CE-Kennzeichnung trägt
• Eine Bedienungsanleitung und relevante Informationen beiliegen

Importeure müssen ihren Namen, eingetragenen Handelsnamen oder eingetragene Marke sowie ihre Kontaktadresse auf dem Produkt oder dessen Verpackung angeben.

Liegt aufgrund einer Schwachstelle ein erhebliches Cybersicherheitsrisiko vor, müssen Importeure unverzüglich die Marktüberwachungsbehörden der Mitgliedstaaten unterrichten, in denen sie das Produkt vertreiben.

Open-Source Steward

Open Source Software Stewards sollen einer passgenauen und milderen Regulierung unterliegen sollen als klassische kommerziele Open-Source-Hersteller. (EG 19 CRA-E) Sie dürfen (eigenständig) keine CE-Kennzeichnung auf den Produkten mit digitalen Elementen anzubringen, deren Entwicklung sie unterstützen. (EG 20 CRA-E)

Art 24 CRA-E sieht folgende Pflichten vor:

Dokumentierte Cybersicherheitsrichtlinie umsetzen welche die sichere Entwicklung von Produkten, Umgang, Dokumentation, Behandlung und Behebung von Sicherheitslücken und den Austausch von Informationen über entdeckte Sicherheitslücken innerhalb der Open-Source-Gemeinschaft fördert. (Art. 24 Abs. 1 CRA-E)

Auf Ersuchen der Marktüberwachungsbehörden mit diesen zusammenarbeiten, um Cybersicherheitsrisiken zu mindern und auf begründeten Antrag die Cybersicherheitsrichtlinie zur Verfügung stellen. (Art. 24 Abs. 2 CRA-E)

Die Meldepflichten des Art 14 Abs 1 CRA-E gelten insoweit, als Open-Source Stewards an der Entwicklung der Produkte mit digitalen Elementen beteiligt sind. Die Meldepflichten der Art. 14 Abs. 3 und 8 CRA-E gelten soweit Netz- und Informationssysteme betroffen sind, welche für die Entwicklung solcher Produkte bereitgestellt werden.

Kategorisierung von Produkten und Pflichten

Der CRA-E unterscheidet neben der „Standardkategorie“ zudem gestaffelt in „kritische“ nach Art. 2 Nr. 3, 6 Abs. 2 und „sehr kritische“ Produkte mit digitalen Elementen nach Art. 2 Nr. 4, 6 Abs. 5 CRA-E, die entsprechend höhere Cybersecurity Risiken mit sich bringen. Beispielhaft nennt die Kommission hier etwa folgende Produktkategorien:

Standardkategorie (Art. 2 CRA-E)

Zertifizierungsschema:

Bei Standardprodukten kann der Hersteller von Hard- und Softwareprodukten die Konformitätsbewertung selbst auf der Grundlage eines internen Kontrollverfahrens gemäß Modul A durchführen.

Alternativ können auch die Zertifizierungsschemata der Modul B+C, oder Modul H freiwillig durchgeführt werden.(Art. 21 Abs. 1 CRA-E)

Wichtige Produkte Klasse I (Art. 6 CRA-E iVm Anex III Class I)

Beispiele:

• Passwortmanager
• Identitäts- und Zugangsmanagementsysteme
• Produkte mit digitalen Elementen, die eine VPN-Funktion haben
• Browser
• Antiviren-Programme
• SIEM-Tools (Security Information and Event Management)
• Public-Key-Infrastruktur und Aussteller digitaler Zertifikate
• Mikroprozessoren mit sicherheitsrelevanten Funktionalitäten (CPUs)
• Mikrocontroller mit sicherheitsrelevanten Funktionalitäten (MCUs)

Zertifizierungsschema:

Harmonisierte EU-Zertifizierungsstandards können auf der Grundlage eines internen Kontrollverfahrens auf Produkte dieser Klasse angewendet werden. (Art. 32 Abs. 2 iVm Art. 27 Abs. 9 CRA-E. Siehe auch EG 92 CRA-E). Sind diese nicht vorhanden, hat eine unabähngige Zertifizierung nach odul B+C oder Modul H zu erfolgen. (Art. 32 Abs. 2 lit. a und b iVm Art 27 Abs 9 CRA-E).

Wichtige Produkte Klasse II (Art. 6 CRA-E iVm Anex III Class II)

Beispiele:

• Firewalls
• Hypervisor / Containervirtualisierungssysteme
• Manipulationsgeschützte Mikroprozessoren (CPUs)
• Manipulationsgeschützte Mikrocontroller (MCUs)

Zertifizierungsschema:

Harmonisierte EU-Zertifizierungsstandards auf Produkte dieser Klasse angewendet werden, (Art. 32 Abs. 3 lit. c iVm Art. 27 Abs. 9 CRA-E). EG 92 CRA-E folgend sollte bei der Konformitätsbewertung wichtiger Produkte der Klasse II immer eine dritte Partei involviert sein, Art 27. Abs. 9 CRA-E eliminiert jedoch expliziet die Verpflichtung des Herstellers zur Durchführung einer Konformitätsbewertung durch einen Dritten bei Anwendung des EU-Zertifizierungsstandards. In enger Auslegung des Art. 27 Abs. 9 CRA-E kommt man zu dem Schluss, dass Dritte in diesem Fall nur zu prüfen haben, ob das Zertifizierungsschema tatsächlich anwendbar ist und eingehalten wird, aber keine weitere Prüfung vornehmen müssen. Allenfalls hat eine unabähngige Zertifizierung nach odul B+C oder Modul H zu erfolgen. (Art. 32 Abs. 3 lit. a und b iVm Art. 27 Abs. 9 CRA-E).

Kritische Produkte (Art. 2 CRA-E iVm Anex III iVm Anex IV)

Beispiele:

1. Hardware Scurity Modules (HSMs)
2. Smart Meter
3. Smartcards

Zertifizierungsschema:

Soweit durch die EU-Kommission gemäß Art 8 Abs 1 CRA-E, können harmonisierte EU-Zertifizierungsstandards auf Produkte dieser Klasse angewendet werden. (Art. 32 Abs. 4 lit. a iVm Art.8 Abs 1 CRA-E) Sind diese nicht vorhanden, hat eine unabähngige Zertifizierung nach harmonisierten EU-Zertifizierungsstandards, Modul B+C oder Modul H zu erfolgen. (Art. 32 Abs. 4 lit.b iVm Art. 32 Abs. 3 CRA-E)

Synergien

Artificial Intelligence Act (KI Verordnung) Für Hochrisiko-KI-Systeme, die gleichzeitig unter den CRA-E fallen, gibt es eine spezielle Regelung:

• Die Cybersicherheitsanforderungen des Art. 15. AI Act gelten als erfüllt, wenn alle Vorgaben des CRA eingehalten und soweit sie durch das Konformitätsbewertungsverfahren abgedeckt sind. Die Konformität wird daher gemäß Art. 12 Abs. 1 lit. c CRA-E nur soweit bescheinigt als die Anforderungen des Konformitätsverfahrens die Anforderungen des Art. 15 AI Act abdecken. Wo dies der Fall ist, muss jedoch im Einzelfall geprüft werden.

Datenschutz Grundverordnung

Sowohl Art. 32 DSGVO als auch Art. 13 CRA-E verfolgen einen risikobasierten Ansatz. Die zu ergreifenden Maßnahmen sollen dem Risiko angemessen sein und verschiedene Faktoren berücksichtigen. Anex I Abs. 1 CRA-E fordert ein angemessenes Sicherheitsniveau. Dies trifft auch auf Art. 32 DSGVO zu, anders als Anex I Abs. 1 CRA-E erwähnt dieser aber auch explizit, dass bei der Betrachtung insbesondere auch die Implementierungskosten einzubeziehen sind.

Konsequenzen/Strafen

Gemäß Art. 52 Abs. 1 CRA-E haben die Mitgliedstaaten Vorschriften über Sanktionen zu erlassen, die bei Verstößen der Wirtschaftsakteure gegen diese Verordnung zu verhängen sind und treffen die zur Durchsetzung erforderlichen Maßnahmen.

Die Höhe der Geldbußen ist in Art. 64 Abs. 2 – 5 CRA-E geregelt. Bei Nichteinhaltung der Anforderungen in Anhang I oder bei Verstößen gegen die Pflichten des Herstellers in Art. 13 und 14 CRA-E Geldbußen von bis zu 15.000.000 € oder von bis zu 2,5 % des gesamten weltweit erzielten

Vorjahresumsatzes zu verhängen.

Bei Verstößen gegen die übrigen Pflichten des CRA-E können Geldbußen von bis zu 10.000.000 € oder 2 % des weltweit erzielten Vorjahresumsatzes verhängt werden.

Die Erteilung unrichtiger, unvollständiger oder irreführender Auskünfte an notifizierte Stellen und Marktüberwachungsbehörden in Beantwortung einer Aufforderung wird mit Geldbußen bis zu 5.000.000 EUR oder bis zu 1 % des gesamten weltweit erzielten Vorjahresumsatzes.

Aufsicht über Open-Source-Stewards obliegt gemäß Art. 52 Z. 3 CRA-E den Marktüberwachungsbehörden, diese können nach Art. 64 Z. 10 litt. b CRA-E keine Geldbußen verhängen.

Weiterführende Literatur

• Ruttloff/Wagner/Stilz, Der Entwurf des Cyber Resilience Act (CRA) und seine Auswirkungen auf das Gewährleistungs- und Produkthaftungsrecht, BB 2024, 1603
• Erdelt, Meldepflichten des Cyber Resilience Acts, ZfPC 2024, 176
• Schöttle, Cyber Resilience Act, Produkthaftungsrichtlinie und andere Baustellen für die Open Source Communities, ZfPC 2023, 215
• Siglmüller, Cyber Resilience Act und Digital Operational Resilience Act - Lässt sich IT-Sicherheit rechtlich erzwingen? ZfPC 2023, 221
• Poncza, Der Entwurf des Cyber Resilience Act, ZfPC 2023, 44
• Voigt/Falk, Der Cyber Resilience Act, MMR 2023, 88
• Wiebe/Daelen, Der Cyber Resilience Act aus produktsicherheitsrechtlicher Perspektive, EuZW 2023, 257
• Zußner, Das Inverkehrbringen von Produkten mit digitalen Elementen nach dem Vorschlag der EU-Kommission für eine Verordnung über horizontale Cybersicherheitsanforderungen, ALJ 2022, Heft 2, 180
• Piltz/Weiß/Zwerschke, Der Vorschlag für einen Cyber Resilience Act aus Sicht der DSGVO, CR 5/2023, 289