ÜbersichtCyber Resilience Act
Das Ende der sorgenfreien Softwareentwicklung
Der Cyber Resilience Act (auch „EU-Gesetz über Cyberresilienz“ oder „Cybersicherheitsgesetz“) ist Teil des sogenannten New Legislative Framework der EU mit einem risikobasierten Regulierungsansatz sowie Teil der „Cybersecurity Strategie“ der EU aus 2020.
Anlass des Cyber Resilience Acts ist gemäß der EU-Kommission die Erkenntnis, dass gegenwärtig ein geringes Maß an Cybersicherheit und ein unzureichendes Verständnis über die Cybersicherheitsrisiken im Markt bestehen. Insoweit seien ganze Lieferketten betroffen und es könnten sich nicht nur schwerwiegende Störungen wirtschaftlicher und sozialer Tätigkeiten ergeben, sondern sogar lebensbedrohliche Situationen.
Mit dem Cyber Resilience Act sollen somit die Schwachstellen in digitalen Produkten reduziert werden. Zudem sollen Hersteller während des gesamten Produktlebenszyklus die Cybersicherheit gewährleisten (längstens aber für einen Zeitraum von fünf Jahren nach dem Inverkehrbringen). Insgesamt soll die Transparenz der Sicherheit von Software- und Hardwareprodukten erhöht werden.
Nachfolgend ein Überblick über den Cyber Resilience Act:
Persönlicher Anwendungsbereich
Mit dem Cyber Resilience Act werden vornehmlich Hersteller in die Pflicht genommen. Auch Importeuren und Händler werden allerdings Pflichten auferlegt; dies ist beispielsweise bei White-Label-Produkten von Bedeutung.Sachlicher Anwendungsbereich
In sachlicher Hinsicht sind verschiedene Voraussetzungen maßgeblich:Produkt mit digitalen Elementen
In sachlicher Hinsicht werden über den Cyber Resilience Act „Produkte mit digitalen Elementen“ erfasst. Diese „Produkte mit digitalen Elementen“ sind sehr weitreichend definiert, nämlich wie folgt:„ein Software- oder Hardwareprodukt und dessen Datenfernverarbeitungslösungen, einschließlich Software- oder Hardwarekomponenten, die getrennt in Verkehr gebracht werden sollen“.
Nur „vernetzte“ Produkte
Eine zusätzliche Voraussetzung für die Anwendung des Cyber Resilience Acts ist, dass das Produkt „vernetzt“ ist. Dies ist im Cyber Resilience Act gegenwärtig wie folgt geregelt:„Diese Verordnung gilt für Produkte mit digitalen Elementen, deren bestimmungsgemäße oder vernünftigerweise vorhersehbare Verwendung eine direkte oder indirekte logische oder physische Datenverbindung mit einem Gerät oder Netz einschließt.“Das allgemein aus dieser Formulierung abgeleitete Verständnis ist, dass nur „vernetzte“ Produkte erfasst sein sollen. Allerdings mag der Begriff der „Vernetzung“ etwas irreführend sein, weil für die Anwendung des Cyber Resilience Acts auch eine indirekte Datenverbindung mit einem Gerät oder Netz genügt sowie die vorhersehbare Verwendung des Produkts. Auch Produkte, die nicht netzwerkfähig sind, werden daher vom Cyber Resilience Act erfasst werden. Es dürfte beispielsweise genügen, dass eine Software bestimmungsgemäß in eine Maschine eingebaut wird, die wiederum mit weiteren Gerät kommuniziert oder „interagiert“ (z. B. in einer Fertigungsstraße).
Die Frage nach dem genauen Regelungsumfang dieser zusätzlichen Anforderung nach der Vernetzung birgt gewiss einigen Streitstoff. Etliche Produkte dürften aber unter den Cyber Resilience Act fallen, auch wenn sie selbst nicht netzwerkfähig sind. Stand-Alone-Software dürfte etwa regelmäßig erfasst sein. Dies zeigt sich z. B. an den im Cyber Resilience Act ausdrücklich genannten Beispielen für erfasste Produkte, nämlich u. a.: Browser, Passwort-Manager und Antivirensoftware.
Ausnahmen für SaaS, Dienstleistungen und bestimmte Sektoren
Ausgenommen vom Cyber Resilience Act sind SaaS-Angebote. Auch Dienstleistungen werden nicht über den Cyber Resilience Act erfasst. Nicht von der Ausnahme umfasst (und also unter den Cyber Resilience Act fallend) sind sog. „Datenfernübertragungslösungen“. Damit soll u. a. eine Umgehungen des Anwendungsbereichs des Cyber Resilience Acts vermieden werden, indem klassische Produkte mit digitalen Elementen so umgestaltet werden, dass Teile nun als SaaS ausgestaltet sind. Für SaaS-Angebote kann jedoch die NIS2-Richtlinie (EU-Richtlinie 2022/2555) bzw. das die NIS2-Richtlinie in nationales Recht umsetzende Gesetz („NIS-2-Umsetzungs- und Cybersicherheitsstärkungsgesetz“ bzw. das hierdurch angepasste BSIG) greifen.Ebenfalls vom Anwendungsbereich ausgenommen sind bestimmte Produkte, für die sektorspezifische Regelungen gelten, insbesondere die MDR (VO 2017/745) bzw. IVDR (VO 2017/746) fallende Medizinprodukte, die VO 2018/1139 im Bereich Flugsicherheit und die VO 2019/2144 im Bereich Kraftfahrzeuge.
Die sektorspezifischen Bereichsausnahmen sind jedoch sorgfältig zu prüfen. Oftmals sind neben den Produkten, die von den sektorspezifischen Regelungen erfasst werden, weitere Produkte vorhanden. Dies war bislang ein wünschenswertes Ergebnis, da so regulatorische Vorgaben vermieden wurden sowie Aufwand erspart wird. Dies mag sich mit dem Cyber Resilience Act nun jedoch ändern. Beispiel: Bislang wurde mitunter bewusst die Schwelle zu einem Medizinprodukt nach der MDR nicht überschritten, sodass nur ein bloßes „Wellness-Produkt” vorlag, für das die zahlreichen regulatorischen Anforderungen der MDR nicht einzuhalten waren. Ein solches „Wellness-Produkt” kann nun aber über den Cyber Resilience Act zu „zertifizieren” sein. Entsprechend kann ein bislang von den sektorspezifischen Regelungen nicht erfasstes Zubehör-Produkt nun unter den Cyber Resilience Act fallen.
Risikoklassen
Der Cyber Resilience Act ist Teil des New Legislative Framework mit einem risikobasierten Ansatz. Entsprechend werden vier Risikoklassen an Produkten mit digitalen Elementen unterschieden. Produkte sämtlicher Risikoklassen haben sog. grundlegende Anforderungen einzuhalten, die im Anhang I des Cyber Resilience Acts näher geregelt sind. Abhängig von der genauen Risikoklasse, in die ein Produkt mit digitalen Elementen fällt, sind weitergehende Anforderungen zu beachten.Die vier folgenden Risikoklassen werden unterschieden:
- Normale / nicht kritische „Produkte mit digitalen Elementen“
- „Kritische Produkte mit digitalen Elementen“ der Klasse I
- „Kritische Produkte mit digitalen Elementen“ der Klasse II
- „Hochkritische Produkte mit digitalen Elementen“
„Einfache Produkte mit digitalen Elementen“
Die niedrigste Risikoklasse ist eine „Auffang-Klasse“. Sämtliche Produkte mit digitalen Elementen, die nicht in eine der anderen Risikoklassen fallen, sind dieser niedrigsten Risikoklasse zuzuordnen. Nach Berechnungen der EU-Kommission sollen rund 90 % der Produkte in diese Risikoklasse fallen.„Kritische Produkte mit digitalen Elementen der Klasse I“
Welche Produkte unter die kritischen Produkte der Klasse I fallen, ist im Anhang des Cyber Resilience Acts näher definiert. Genannt werden unter anderem: Passwortmanager, eigenständige und eingebettete Browser, VPN-Systeme, Software für Fernzugriff und gemeinsame Datennutzung sowie Aktualisierungs- und Patchverwaltung.„Kritische Produkte mit digitalen Elementen der Klasse II“
Die kritischen Produkte der Klasse II sind ebenfalls im Anhang des Cyber Resilience Acts aufgeführt. Hierzu zählen unter anderem Betriebssysteme für Server, Desktops und Mobilgeräte, Sicherheitselemente, Container-Runtime-Systeme, die eine virtualisierte Ausführung von Betriebssystemen und ähnlichen Umgebungen unterstützen, Public-Key-Infrastrukturen und Aussteller digitaler Zertifikate, Chipkarten und IIoT-Geräte (Internet der Dinge).„Hochkritische Produkte mit digitalen Elementen“
Welche Produkte unter die hochkritischen Produkte mit digitalen Elementen fallen, wird von der EU-Kommission noch über sog. delegierte Rechtsakte festgelegt werden. Maßgeblich ist hierbei insbesondere, ob die Produkte für die Widerstandsfähigkeit eines gesamten Lieferkette von Bedeutung sind, und ob die Nutzung von wesentlichen Einrichtungen im Sinne der NIS2-Richtlinie erfolgt (also von kritischen Infrastrukturen).Konformitätsbewertungsverfahren
Erst nach einem erfolgreichen Abschluss des Konformitätsbewertungsverfahrens, das im Cyber Resilience Act und in dessen Anlagen näher geregelt ist, darf das CE-Kennzeichen angebracht werden.Im Rahmen der niedrigsten Risikoklasse können Hersteller selbst das Konformitätsbewertungsverfahren durchführen und sich selbst die EU-Konformitätserklärung aus dem Anhang zum Cyber Resilience Act ausstellen bzw. diese unterzeichnen.
In Fällen der mittleren und höchsten Risikoklasse sind die Möglichkeiten zur Konformitätsbewertung eingeschränkt. Es stehen dann das sogenannten Verfahren der EU-Baumusterprüfung und die „Konformitätsbewertung auf der Grundlage einer umfassenden Qualitätssicherung“ zur Verfügung. Hierbei kann insbesondere die Hinzuziehung einer externen Stelle, nämlich einer sogenannten Benannten Stelle (Notified Body) erforderlich werden. Diese Benannte Stelle kann dann die Konformität bestätigen – oder diese nachgehend aussetzen, einschränken oder widerrufen, womit die Verkehrsfähigkeit des Produkts eingeschränkt würde oder insgesamt entfiele.
Konformitätsvermutung nach dem Cyber Security Act
Der Cyber Resilience Act ist in eine breit angelegte Gesetzgebungsinitiative eingebettet. Neben dem Cyber Resilience Act ist z. B. der Cyber Security Act zu berücksichtigen.Auf der Grundlage des Cyber Security Acts, der bereits seit 2019 in Kraft ist, wird es möglich, Cybersicherheitszertifikate auszustellen bzw. zu erhalten. Liegt ein solches Cybersicherheitszertifikat in Ansehung eines bestimmten Produkts mit digitalen Elementen vor, gilt eine Konformitätsvermutung gemäß dem Cyber Resilience Act. Das Konformitätsbewertungsverfahren muss dann nicht mehr vollumfänglich durchgeführt werden, was zu einem erheblichen Zeit- und Aufwandsersparnis führt.
Nach dem Cyber Security Act werden sogenannte Schemata „beschlossen“. Diese Schemata wiederum dienen als Grundlage für dann durchzuführende Sicherheitszertifizierungen von Unternehmen, die auf derartige Zertifizierungen spezialisiert sind.
Bislang wurde die Ausarbeitung von drei Schemata angestoßen:
- European Union Common Criteria Scheme (EUCC)
- European Union Cybersecurity Certification Scheme on Cloud Services (EUCS)
- Cyber-Sicherheit von 5G-Netzwerken (EU5G)
Pflicht zur Information und Gebrauchsanleitung für Nutzer
Jedem Produkt mit digitalen Elementen sind verpflichtend neun Informationen beizufügen. Unter diesen Informationen befinden sich „einfache“ Angaben, wie der Name des Herstellers und dessen E-Mail-Adresse.Anzugeben sind jedoch auch alle bekannten oder vorhersehbaren Umstände im Zusammenhang mit der bestimmungsgemäßen Verwendung des Produkts mit digitalen Elementen oder dessen vernünftigerweise vorhersehbaren Fehlanwendung, die zu erheblichen Cybersicherheitsrisiken führen können. Welche Angaben hier sinnvoll und ohne zusätzliches Risiko erteilt werden können, wird sehr genau zu überlegen sein.
SBOM / Software-Stückliste
Von erheblicher Tragweite wird zudem die neue Verpflichtung sein, „ob und gegebenenfalls wo die Software-Stückliste abrufbar ist“. Implizit enthalten ist damit die Verpflichtung, eine Software-Stückliste anzufertigen, also die sogenannte SBOM (Software Bill of Material). Diese Software-Stückliste ist wie folgt definiert:„Software-Stückliste“ eine formale Aufzeichnung der Einzelheiten und Lieferkettenbeziehungen der Komponenten, die in den Softwareelementen eines Produkts mit digitalen Elementen enthalten sind;Damit müssen letztlich auch sämtliche Drittkomponenten dargestellt werden. Der Grund hierfür ist nachvollziehbar: Wird eine Sicherheitslücke in einer Drittkomponente (z. B. einer üblichen Softwarebibliothek aus dem Open-Source-Bereich, wie jüngst z. B. hinsichtlich der glibc) bekannt, muss jedes Unternehmen feststellen können, ob diese Softwarebibliothek im eigenen Produkt enthalten ist – und möglichst auch jeder Nutzer. In der Praxis ist die Erstellung einer solchen Liste und deren Pflege jedoch mit einem erheblichen Aufwand verbunden. Oftmals müssen dabei Verträge mit Lieferanten angepasst und interne Prozessabläufe angepasst werden. Selbst bei einfachsten Software-Produkten kann diese Liste einen erheblichen Umfang annehmen.
Ausnahme für Open-Source-Software?
Erst zuletzt ist aufgrund weitergehender Verhandlungen über den Cyber Resilience Act eine Regelung zu Open-Source-Software (OSS) in einem Kompromisspapier wie folgt aufgenommen worden:„This Regulation applies to free and open-source software only when made available on the market in the course of a commercial activity.“Danach kommt es maßgeblich darauf an, ob in Ansehung der Open-Source-Software eine „kommerzielle Aktivität vorliegt“. In den Erwägungsgründen, die lediglich zur Auslegung des Cyber Resilience Acts herangezogen werden können, jedoch nicht rechtlich verbindlich sind, finden sich die folgenden Leitlinien zur Beantwortung der Frage, ob eine kommerzielle Aktivität vorliegt:(Art. 2 Nr. 3a Compromise Draft)
„For example, a fully decentralised development model, where no single commercial entity exercises control over what is accepted into the project’s code base, should be taken as an indication that the product has been developed in a non-commercial setting.Diese Ausnahmen dürften unzureichend sein oder zu einem erheblichen Kollateralschaden im Open-Source-Bereich führen, sollten die Regelungen und „Leitlinien“ so verbleiben. Es stellen sich z. B. Abgrenzungsfragen, wenn Non-Profit-Organisationen Spenden entgegen nehmen, oder wenn Wirtschaftsunternehmen Mitarbeiter beschäftigen, um Open-Source-Software zum allgemeinen Nutzen zu programmieren.On the other hand, where free and open source software is developed by a single organisation or an asymmetric community, where a single organisation is generating revenues from related use in business relationships, this should be considered to be a commercial activity.
Similarly, where the main contributors to free and open-source projects are developers employed by commercial entities and when such developers or the employer can exercise control as to which modifications are accepted in the code base, the project should generally be considered to be of a commercial nature.“
Ausnahmen für Messen und für Testzwecke
Der Cyber Resilience Act sieht vor, dass Software weiterhin für Messen, Ausstellungen und Präsentationen auch ohne vollständige Konformitätsbewertung genutzt werden kann.Zudem soll die unregulierte Zurverfügungstellung von Software für Testzwecke möglich bleiben, wenn dies lediglich für einen überschaubaren Zeitraum erfolgt.
Neue Meldepflichten
Im Cyber Resilience Act sind zudem Meldepflichten vorgesehen. Danach muss der Hersteller unverzüglich, jedenfalls aber innerhalb von 24 Stunden, nachdem der Hersteller von aktiv ausgenutzten Schwachstellen Kenntnis erhalten hat, die ENISA (Cybersicherheitsagentur der EU) eine Meldung erstatten.Zudem hat ein Hersteller unverzüglich, jedenfalls aber innerhalb von 24 Stunden, nachdem er Kenntnis von einem Vorfall, der sich auf die Sicherheit des Produkts auswirkt, eine Meldung zu erstatten.
Darüber hinaus kann der Hersteller nicht nur eine Meldung an die ENISA zu erstatten haben, sondern sogar die verschiedenen Nutzer des Produktes (also die Endnutzer) zu informieren haben. Neben Aspekten der Art und Weise einer solchen Kommunikation kann dies – je nach genauem Produkt – einen erheblichen Aufwand bedeuten.
Langfristige Pflegeverpflichtung
Anders als nach dem bisherigen deutschen Recht (mit jüngeren Ausnahmen im Bereich der Verbraucherprodukte) ergibt sich eine maßgebliche Änderung im Hinblick auf die Sicherstellung der Mangelfreiheit – zumindest soweit diese auf Schwachstellen der IT-Sicherheit bezogen ist.Nach dem Cyber Resilience Act ist der Hersteller nämlich dazu verpflichtet, während der erwarteten Produktlebensdauer oder während eines Zeitraums von fünf Jahren ab dem Inverkehrbringen des Produkts (je nachdem, welcher Zeitraum kürzer ist) Schwachstellen wirksam „zu behandeln“. Dies wird in der Regel die zur Verfügungstellung von Sicherheitsupdates bedeuten.
Bemerkenswert an dieser Regelung ist, dass diese Verpflichtung den Hersteller trifft, nicht den Verkäufer. Je nach der genauen Art des betroffenen Produktes kann dies jedoch dazu führen, dass vertraglich in der Lieferkette Regelungen aufgenommen werden müssen, um über Updates zu informieren und diese auch ausspielen zu können.
Verknüpfung mit anderen aktuellen „Acts“
Der Cyber Resilience Act soll „verknüpft“ werden mit verschiedenen anderen, aktuell im Entwurfsstadium befindlichen Verordnungen der EU.
- Hinsichtlich verschiedener Grundanforderungen parallel zu beachten ist z. B. die kommende EU-Verordnung über die allgemeine Produktsicherheit.
- Soweit das Produkt zugleich der EU-Maschinenverordnung unterliegt, gelten im Hinblick auf Schutz und Korruption sowie die Sicherheit und Zuverlässigkeit von Steuerungssystemen gewisse Konformitätsvermutungen mit Wirkung auch für den Cyber Resilience Act.
- Soweit ein Hochrisiko-KI-System nach der kommenden KI-Verordnung vorliegt und nach der KI-Verordnung die Genauigkeit und Robustheit bestätigt ist, gilt dieser Aspekt auch als nach dem Cyber Resilience Act konform. Erfreulich ist zudem die Feststellung, dass dieselbe Benannte Stelle (Notified Body), die für die Konformitätsbewertung nach der KI-Verordnung zuständig ist, auch nach dem Cyber Resilience Act prüfen darf. Damit wird ein „One-Stop-Shop“-Verfahren für die Konformitätsbewertung ermöglicht. Voraussetzung hierfür ist selbstverständlich eine entsprechende Benennung der Benannten Stelle, sodass diese die Konformitätsbewertung auch nach dem Cyber Resilience Act durchführen darf.
- Ebenso sind EHR-Systeme nach der EU-Verordnung über den europäischen Raum für Gesundheitsdaten (European Health Data Space – EHDS) in Bezug genommen.
Technische Dokumentation
Nicht zu unterschätzen sein, wird der Aufwand, der für die Anfertigung der nun erforderlichen sogenannten technischen Dokumentation anfällt.Aus Einzelaspekten können sich zudem besondere Schwierigkeiten oder gar die Unmöglichkeit der Anfertigung einer technischen Dokumentation ergeben. Liegt z. B. ein Hochrisiko-KI-System vor oder ein EHR-System, muss die technische Dokumentation als „einzige technische Dokumentation“ erstellt werden. Damit wird nicht auf technische Dokumentationen „modular“ bei Lieferanten verwiesen werden dürfen. Vielmehr dürfte die Regelung so zu verstehen sein, dass auch die technischen Dokumentation der verschiedenen Lieferanten einheitlich beim Hersteller vorliegen müssen, wobei die Details hierzu noch nicht geregelt sind. Wie bereits die Erfahrungen im Bereich der Medizinprodukteverordnung der EU (MDR) zeigen, kann die Zusammenstellung einer solchen technischen Dokumentation zu erheblichen Schwierigkeiten führen. Insbesondere sind hierbei die Interessen hinsichtlich der Geschäfts- und Betriebsgeheimnisse der Lieferanten zu bedenken.
Pflicht zur Anbringung eines CE-Kennzeichens
Sämtliche Produkte mit digitalen Elementen müssen ab der Geltung des Cyber Resilience Acts mit einem CE-Kennzeichen versehen werden. Mit der Anbringung des CE-Kennzeichens und der vorausgehenden Unterzeichnung der EU-Konformitätserklärung übernimmt der Hersteller die Verantwortung für das Produkt.Mit Blick auf die denkbar weite Definition eines Produkts mit digitalen Elementen dürften die Tage, in denen ein neues Produkt „einfach so“ auf den Markt gebracht werden darf, gezählt sein. Dies ist durchaus das erklärte Ziel des Cyber Resilience Acts, über den ein „Security by Design“ erzielt werden soll.
Rechtsfolgen
Bestimmte Verstöße gegen den Cyber Resilience Act sind bußgeldbewehrt. Es kann ein Bußgeld von bis zu 15 Mio. EUR oder 2,5 % des weltweiten Jahresumsatzes festgesetzt werden – je nachdem, welcher Rahmen größer ist.Veranstaltungshinweise
Dieser Beitrag fasst den Vortrag von Dr. Hötzel auf dem Forum Digitalisierungsrecht am 17.10.2023 zusammen.Zudem trägt Dr. Hötzel am 05.12.2023 auf dem 34. Cyber-Sicherheits-Tag der Allianz für Cyber-Sicherheit zu diesem Thema vor.
Bitte melden Sie sich gerne:
Dr. Gerrit Hötzel
+49 711 22 07 09 80
stuttgart@voelker-gruppe.com
Stand: 08.11.2023
voelker-partner-mbb