Die neue Leitlinie der EU-Kommission hilft beim Umsetzen der Gesetzespflichten
Vielleicht sollte man den Cyber Resilience Act (CRA) mal nicht als Belastung betrachten. Warum? Artikel 26 verpflichtet die EU-Kommission dazu, Leitlinien zu veröffentlichen, mit denen sich die Anforderungen der Regulierung leichter umsetzen lassen. Zu Deutsch: Rat und Parlament verabschieden ein Gesetz, das die EU-Kommission auf den Weg gebracht hat. Dann wird die Kommission verpflichtet, den Unternehmen zu helfen. Nun ist es soweit. Nach einem umfangreichen FAQ, das bereits im vergangenen Dezember publiziert wurde, ist seit dem 27. Juli eine 83-seitige Leitlinie in englischer Sprache verfügbar. Auf ein paar Aspekte dieser Leitlinie wird im Folgenden eingegangen.
Das Dokument startet mit dem Scope, um dann die inhaltlichen Schwerpunkte zu setzen. Ausführlich werden Fragen zu Open Source, aber auch zum Umgang mit wesentlichen Änderungen oder mit Ersatzteilen, den Verpflichtungen zum Support, den Kritikalitätsklassen, Risikoanalyse und -assessment immer nah am Produkt mit digitalen Elementen beschrieben, erklärt und mit Beispielen anschaulich dargestellt. Zu Missverständnissen führt immer auch der Begriff der Datenfernverarbeitung. Dieser ist von enormer Bedeutung, um bestimmen zu können, ob man betroffen ist, denn Software as a Service (SaaS) fällt aus dem Geltungsbereich des CRA. Weitere Inhalte der Leitlinie beziehen sich aufs Reporting, das Schwachstellenmanagement und die Wechselwirkungen mit anderen EU-Regeln. Eigens genannt werden Verordnungen aus dem Fahrzeugbau ((EU) 2019/2144) und der zugehörigen Marktüberwachung und Genehmigung ((EU) 168/2013).
Binäre Identitäten
Zu Beginn verweist die Leitlinie in den Abschnitten 2.1.13 und 2.1.14 auf die binäre Identität von Software im Vorgang des Kopierens. Und dann gibt es sofort eine Lesehilfe zum Gesetz: Wird die Software nicht verändert, bleibt ihre nachgewiesene Compliance mit dem CRA so lange bestehen, bis sie verändert wird – aber gravierend. Dazu ein Beispiel: Wenn eine Firma eine Software mit digitalen Elementen am 1. Januar 2028 in der Version 1.0.0 auf den Markt bringt und ein Kunde die Lizenz einer Kopie davon am selben Tag erwirbt, ein zweiter Kunde die Version 1.0.0 zehn Tage später, dann gilt: Beide Kopien der Software wurden am 1. Januar 2028 in Verkehr gebracht. Und dann stellt sich die Frage, was wesentliche Änderungen sind. Gemäß dem Text nicht, wenn die ursprüngliche Fassung vom 1. Januar 2028 am 30. Januar 2028 auf den Stand 1.0.1 gehoben wird. Es gilt hier wie überall das, was unter 1.2.8 des Dokuments zu lesen ist: „Diese Beispiele sind nicht dazu da, eine Einzelfallprüfung zu ersetzen. Diese ist stets erforderlich ist, um den Besonderheiten jedes Einzelfalls Rechnung tragen zu können.“ Wer also eine Handlungsanweisung à la Kochrezept erwartet hat, wird enttäuscht. Es sind Zaunpfähle, die Orientierung verschaffen. Mehr aber auch nicht. Wie sollte es auch anders sein. Gesetze werden erst dann klarer auslegbar, wenn es Präzedenzfälle gibt. Das aber wird erst nach dem vollständigen Inkrafttreten nach dem 11. Dezember 2027 der Fall sein. Bis dahin gilt: Die Leitlinie ist Hilfestellung, aber keine Handlungsanweisung. Die Verantwortung bleibt bei jedem Unternehmen. Gesetz formulieren Verantwortung. Leitlinien orientieren. Unternehmen sollten dann verantwortlich handeln. Das kann man ihnen nicht abnehmen.
Leitlinienkonjunktiv
Hilfreich sind die Unterscheidungsmerkmale, mit denen das Dokument definiert, was unter den Schirm des CRA fällt. Absatz 2.2.20 stellt beispielsweise klar, dass im Grunde jede Software, die downgeloadet und installiert oder auf „andere Weise“ („or otherwise“) dem Nutzer zur Verfügung gestellt wird, betroffen ist. Kriterium: Sie wird auf dem elektronischen System des Nutzers ausgeführt. Genannt wird eine Browser-Extension. Die liegt auf dem lokalen Rechner des Users. Stichwort: lokale Ausführung („local execution“). Remote ausgeführte Software fällt nicht darunter. Software as a Service fällt nicht unter den CRA. Das nachfolgende dritte Beispiel wird Entwickler für Android oder iOS interessieren. Denn die Apps, die in den Stores für Smartphones gegen Entgelt vorgehalten werden, können CRA-relevant sein. Die Autor:innen des Textes gehen aber wie schon angemerkt mit Vorsicht vor. Sie sprechen immer von „it may fall within the scope of the CRA“ (es könnte in den Anwendungsbereich des CRA fallen). Das ist eins der wichtigsten Learnings, die sich aus der Beschäftigung ziehen lassen: Jedes Produkt mit digitalen Elementen ist ein Einzelfall und sollte deswegen immer einzeln einer Bewertung unterzogen werden.
Quellcode und CRA
Übrigens fällt Quellcode in der Entwicklung, der fürs Testen und Reviewing vorgehalten wird, nicht unter den CRA. Das gilt auch für Samples und Demo-Code, die Teil von Tutorials oder Schulungsmaterialien sind. Anders ist das, wenn Firma A der Firma B ihren Quellcode lizenziert, damit diese den Code auf ihre Plattformen hin anpassen kann. Dann bringt Firma A den Code auf den Markt. A ist dabei nicht für die Compliance von B zuständig (S. 10).
Was bislang immer zu Fragen führte, ist die Behandlung von Soft- und Hardwarekomponenten in einem Produkt. Es handelt sich um ein CRA-relevantes Objekt selbst dann, wenn Treiber und Hardware komplett voneinander getrennt distribuiert werden. Aber da macht der CRA ja noch nicht Halt. Industrielle Kontroll- und Steuerungssysteme (ICS) die der Einfachheit unter dem Kürzel OT (Operational Technology) gelabelt werden, stellen mit die komplexesten Gebilde dar. Hier gibt es andere Lebenszyklen, die mit denen von Verbraucher:innengeräten nicht vergleichbar sind. Außerdem sind Systeme in der Produktion nicht nur auf Protokollebene, sondern auch hinsichtlich der verschiedenen Gerätetypen in einem Produkt kompliziert. Auch hier führt der Blick in die Leitlinie weiter.
Unterm Strich lohnt die Lektüre. Ja, jedes Unternehmen, das Produkte mit digitalen Elementen produziert, in den Verkehr bringt oder importiert, sollte das Dokument lesen. Schön wäre es für viele, wenn Übersetzungen gleichzeitig in Umlauf gebracht werden könnten. Das schafft man ja auch für die Gesetzestexte, selbst wenn diese von Maschinen in andere Sprachen übertragen werden. Das EU-Englisch ist zwar gut verständlich, aber nicht für alle Unternehmer:innen.
Download: https://ec.europa.eu/newsroom/dae/redirection/document/131456