Quelltext der Seite Cyber Resilience Act (CRA)/de

<languages/>
{{Infobox Rechtsakt (EU)|Typ=Verordnung|Jahr=2024|Nummer=2847|Vertrag=EU|EWR=ja|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|Kurztitel=Cyber Resilience Act/Cyberresilienz-Verordnung|Bezeichnung=CRA|Rechtsmaterie=Binnenmarkt, Cybersicherheit|Grundlage=AEUV, insbesondere {{Art.|114|AEUV|dejure|}}
|Fundstelle=ABl L 2024/2847, 1|Anzuwenden=11. Dezember 2027 (mit Ausnahmen)|Gültig=inkraft}}

== Kurzübersicht ==

{| class="wikitable"
!Ziele
!Anwendungsbereich
!Inhalt<ref>https://www.nis.gv.at/nis-2-richtlinie.html</ref>
!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; bis zu 15.000.000 € oder von bis zu 2,5 % des weltweit erzielten Vorjahresumsatzes.
|-
|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 Nutzer*innen ermöglichen Cybersicherheit zu berücksichtigen. 
|
|Sicherheitsbewertungen je nach Sicherheitsklasse
|Anforderungen der KI-VO (Art 6 iVm 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 (CRA) folgt dem Ziel der Erhöhung der Cybersicherheit mit einheitlichen Cybersicherheitsanforderungen bei Produkten mit digitalen Elementen, vor allem bei Hard- und Software. Der CRA gibt vor, dass künftig '''alle vernetzen Produkte''' '''das''' '''CE-Kennzeichen''' tragen müssen. Das CE-Kennzeichen vermittelt nach außen, dass das vernetzte Produkt einen hinreichenden Schutz vor Cybergefahren gewährleistet.<ref>https://www.bmi.bund.de/SharedDocs/pressemitteilungen/DE/2024/10/cyber-resilience-act.html</ref> 

Hersteller, Händler und Importeure werden gegenüber ihren Kund*innen 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): ======

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

'''Beispiele:''' Vernetzte Kühlschränke oder Thermostate, Laptops, Smartphones, Tablets, Smart Watches

====== Spezialfall Open Source Software ======

Freie und quelloffene Softwareprodukte („Open-Source“), die außerhalb einer Geschäftstätigkeit entwickelt oder bereitgestellt werden, sind nicht verpflichtet.<ref>ErwGr 18 CRA-E: Finally, for the purposes of this Regulation, the development of products with digital elements qualifying as '''free and open-source software by not-for-profit organisations should not be considered to be a commercial activity provided that the organisation is set up in such a way that ensures that all earnings after costs are used to achieve not-for-profit objectives'''. This Regulation does not apply to natural or legal persons who contribute with source code to products with digital elements qualifying as free and open-source software that are not under their responsibility
</ref>  Ein explizite Ausnahme wurde nicht aufgenommen, die Ausnahme ergibt sich implizit aus der Definition der "Geschäftstätigkeit" und wird ErwGr 18 CRA weiter präzisiert.

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

==== 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).

'''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).

'''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).

'''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 Z 14 CRA). 

Die Definition lässt eine 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 eine 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 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.

Beispiele hierfür sind:

* Stiftungen, die bestimmte Open-Source Projekte unterstützen
* Unternehmen, die Open-Source für den eigenen Gebrauch entwickeln, aber öffentlich zugänglich machen
* Gemeinnützige Organisationen, die Open-Source entwickeln

==== 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 Annex I Teil I beachtlich, welcher auf die Schaffung eines angemessenen Sicherheitsniveaus abzielt.

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 Annex I Teil II festgelegten grundlegenden Anforderungen behandelt werden.

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

In Art 14 legt der CRA 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

Art 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 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 Anleitungen für Nutzer*innen 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 (Verwalter quelloffener Software) ====

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

Art 24 CRA 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)
* 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)

Die Meldepflichten des Art 14 Abs 1 CRA 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 gelten soweit Netz- und Informationssysteme betroffen sind, welche für die Entwicklung solcher Produkte bereitgestellt werden.

== Kategorisierung von Produkten und Pflichten ==

[[Datei:CRA Zertifizierungen ri.png|mini|Zertifizierungsschemata des Cyber Resilience Act - CC BY 4.0]]
Der CRA unterscheidet zwischen der „Standardkategorie“, wichtigen Produkten Klasse I und Klasse II, sowie kritischen Produkten.

==== Standardkategorie (Art. 2 CRA) ====

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 Module B+C, oder Modul H freiwillig durchgeführt werden (Art 21 Abs 1 CRA)

==== Wichtige Produkte Klasse I (Art 7 CRA iVm Annex 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 Produkte dieser Klasse angewendet werden (Art 32 Abs. 3 lit c iVm Art 27 Abs 9 CRA). Zwar eliminiert Art 27 Abs 9 CRA die Verpflichtung des Herstellers zur Durchführung einer Konformitätsbewertung durch einen Dritten bei Anwendung des EU-Zertifizierungsstandards Vertrauenswürdigkeitsstufe „mittel“ doch sieht diese Zertifizierungsstufe eine Überprüfung durch Dritte vor (vgl. Art 53 Cybersecurity Act).
* Sind diese nicht vorhanden, hat eine unabhängige Zertifizierung nach Modul B+C oder Modul H zu erfolgen (Art 32 Abs 2 lit a und b iVm Art 27 Abs 9 CRA).

==== Wichtige Produkte Klasse II  (Art 7 CRA iVm Annex III Class II) ====

Beispiele:
* Firewalls
* Hypervisor / Containervirtualisierungssysteme
* Manipulationsgeschützte Mikroprozessoren (CPUs)
* Manipulationsgeschützte Mikrocontroller (MCUs)
Zertifizierungsschema:

* Harmonisierte EU-Zertifizierungsstandards können auf Produkte dieser Klasse angewendet werden (Art 32 Abs. 3 lit c iVm Art 27 Abs 9 CRA). ErwGr 92 CRA folgend sollte bei der Konformitätsbewertung wichtiger Produkte der Klasse II immer eine dritte Partei involviert sein. Zwar eliminiert Art 27 Abs 9 CRA die Verpflichtung des Herstellers zur Durchführung einer Konformitätsbewertung durch einen Dritten bei Anwendung des EU-Zertifizierungsstandards Vertrauenswürdigkeitsstufe „mittel“ doch sieht diese Zertifizierungsstufe eine Überprüfung durch Dritte vor (vgl. Art 53 Cybersecurity Act).
* Allenfalls hat eine unabhängige Zertifizierung nach Modul B+C oder Modul H zu erfolgen (Art 32 Abs 3 lit a und b iVm Art 27 Abs 9 CRA).

==== Kritische Produkte (Art 8 CRA iVm Annex III iVm Annex IV) ====

Beispiele:

# Hardware Security Modules (HSMs)
# Smart Meter
# Smartcards

Zertifizierungsschema:

* Soweit durch die EU-Kommission gemäß Art 8 Abs 1 CRA vorgegeben, können harmonisierte EU-Zertifizierungsstandards auf Produkte dieser Klasse angewendet werden (Art 32 Abs 4 lit a iVm Art 8 Abs 1 CRA)
* Sind diese nicht vorhanden, hat eine unabhängige 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)

== Synergien ==

====== [[Special:MyLanguage/Artificial Intelligence Act (AIA)|Artificial Intelligence Act (KI Verordnung)]] ======

* Für Hochrisiko-KI-Systeme, die gleichzeitig unter den CRA 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 gemäß Art 12 Abs 1 lit c CRA 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.

====== DSGVO ======

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

== Konsequenzen/Strafen ==

Gemäß Art 52 Abs 1 CRA haben die MS 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 geregelt. Bei Nichteinhaltung der Anforderungen in Anhang I oder bei Verstößen gegen die Pflichten des Herstellers in Art 13 und 14 CRA sind 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 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 bestraft.

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

== Weiterführende Literatur ==

=== Überblicksartikel ===

*''Erdelt'', Meldepflichten des Cyber Resilience Acts, ZfPC 2024, 176.
* ''Piltz/Weiß/Zwerschke'', Der Vorschlag für einen Cyber Resilience Act aus Sicht der DSGVO, CR 2023, 289.
* ''Poncza'', Der Entwurf des Cyber Resilience Act, ZfPC 2023, 44.
* ''Ruttloff/Wagner/Stilz'', Der Entwurf des Cyber Resilience Act (CRA) und seine Auswirkungen auf das Gewährleistungs- und Produkthaftungsrecht, BB 2024, 1603.
* ''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.
* ''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, 180.

=== Kommentare ===

* ''Heckmann/Paschke'', CRA. Cyber Resilience Act (2025, iE).

== Einzelnachweise ==