CRA-Navigator

Artikel 3 Nummer 1 des CRA definiert ein Produkt mit digitalen Elementen als „ein Software- oder Hardwareprodukt und dessen Datenfernverarbeitungslösungen, einschließlich Software- oder Hardwarekomponenten, die getrennt in den Verkehr gebracht werden“. Solche Produkte mit digitalen Elementen fallen in den Anwendungsbereich des CRA, wenn ihr bestimmungsgemäßer Zweck oder ihre vernünftigerweise vorhersehbare Verwendung eine direkte oder indirekte logische oder physische Datenverbindung mit einem Gerät oder Netz einschließt.

Der CRA kann daher eine Reihe von Produkten mit digitalen Elementen erfassen, darunter: (i) eigenständige Software wie Apps und Computerprogramme, unabhängig davon, ob sie digital oder physisch vertrieben wird; (ii) Hardware mit eingebetteter Software (z. B. Geräte des Internets der Dinge, Laptops, Tablets); (iii) eigenständige Hardware (z. B. integrierte Schaltkreise, Hauptplatinen); und (iv) jede Kombination aus Hardware und Software, die getrennt geliefert wird, aber für den Betrieb im Zusammenwirken bestimmt ist.

Eigenständige Software fällt daher in den Anwendungsbereich des CRA, wenn sie als Produkt mit digitalen Elementen in Verkehr gebracht wird. Es ist hilfreich, zwischen Softwareprodukten mit digitalen Elementen, die dem CRA unterliegen, und der Erbringung von Diensten aus der Ferne zu unterscheiden, die nicht in den Anwendungsbereich des CRA fällt.

Damit Software in den Anwendungsbereich des CRA fällt, muss ein Softwareprodukt mit digitalen Elementen einem Nutzer bereitgestellt, von diesem Nutzer bezogen und auf einem elektronischen Informationssystem auf Seiten des Nutzers oder als Teil eines solchen Systems betrieben werden. Software, die heruntergeladen, installiert oder dem Nutzer auf andere Weise geliefert wird und die auf dem elektronischen Informationssystem des Nutzers ausgeführt wird, erfüllt diese Kriterien, auch wenn sie beispielsweise die Form einer Browsererweiterung oder einer Anwendung hat, die mit Webtechnologien entwickelt, aber zur lokalen Ausführung geliefert wird.

Software, die entfernt ausgeführt wird und auf die der Nutzer lediglich zugreift, ist hingegen allein aus diesem Grund kein Produkt mit digitalen Elementen. Die Erwägungsgründe 11 und 12 des CRA treffen nämlich diese Unterscheidung, indem sie erläutern, dass die Fernverarbeitung oder -speicherung nur insoweit dem CRA unterliegt, als sie notwendig ist, damit ein Produkt mit digitalen Elementen seine Funktionen erfüllen kann (d. h. über den Begriff der Datenfernverarbeitung im Sinne von Artikel 3 Nummer 2), und nicht selbst als Produkt mit digitalen Elementen. Dies ist typischerweise bei Webanwendungen einschließlich Progressive Web Apps der Fall, wenn auf sie ausschließlich über einen Webbrowser zugegriffen wird. Dasselbe gilt für Websites: Auch wenn Websites in begrenztem Umfang technisch auf dem Gerät des Nutzers laufen und ausgeführt werden können, ergibt sich aus Erwägungsgrund 12 des CRA, dass Websites selbst nicht als Produkte mit digitalen Elementen anzusehen sind und nur dann in den Anwendungsbereich des CRA fallen, wenn sie die Funktionalität eines Produkts mit digitalen Elementen unterstützen, d. h. soweit sie als Datenfernverarbeitung einzustufen sind (wie in Abschnitt 8 und insbesondere 8.1.2 Würde das Fehlen einer solchen Datenverarbeitung das Produkt mit digitalen Elementen daran hindern, eine seiner Funktionen zu erfüllen? näher erläutert).

Beispiel 3: Eine mobile Anwendung, die ein Nutzer aus einem App-Store herunterlädt und auf seinem Smartphone installiert, wird dem Nutzer geliefert und auf dem Gerät des Nutzers ausgeführt und ist daher ein Produkt mit digitalen Elementen. Wird sie im Rahmen einer Geschäftstätigkeit in Verkehr gebracht, kann sie in den Anwendungsbereich des CRA fallen.

Beispiel 4: Eine Desktop-Anwendung, die mit Webtechnologien entwickelt, aber für die lokale Installation paketiert wurde, wird dem Nutzer geliefert und auf dem Gerät des Nutzers ausgeführt und ist daher ein Produkt mit digitalen Elementen. Wird sie im Rahmen einer Geschäftstätigkeit in Verkehr gebracht, kann sie in den Anwendungsbereich des CRA fallen.

Beispiel 5: Eine Webanwendung, auf die der Nutzer ausschließlich über einen Webbrowser zugreift, ist kein Produkt mit digitalen Elementen. Sofern sie nicht die Funktionalität eines Produkts mit digitalen Elementen unterstützt, fällt sie nicht in den Anwendungsbereich des CRA. Eine Anwendung, die dem Nutzer hingegen als lokal installierter Client geliefert wird, der auf dem Gerät des Nutzers ausgeführt wird, ist ein Produkt mit digitalen Elementen. Wird sie im Rahmen einer Geschäftstätigkeit in Verkehr gebracht, kann sie in den Anwendungsbereich des CRA fallen. Ist dieser Client zur Erfüllung einer oder mehrerer seiner Funktionen auf eine entfernt stattfindende Datenverarbeitung angewiesen, die die Begriffsbestimmung der Datenfernverarbeitung erfüllt, so ist diese entfernt stattfindende Datenverarbeitung ebenfalls Teil des Produkts mit digitalen Elementen.

Beispiel 6: Eine Website, die ihren Besuchern lediglich Informationen darstellt und die Funktionalität eines Produkts mit digitalen Elementen nicht unterstützt, ist selbst kein Produkt mit digitalen Elementen. Sie fällt daher nicht in den Anwendungsbereich des CRA.

Ob Software Teil eines Produkts mit digitalen Elementen ist, sollte nicht danach bestimmt werden, wie oder wann diese Software dem Nutzer geliefert wird, sondern danach, ob die Software angesichts der Zweckbestimmung und der vernünftigerweise vorhersehbaren Verwendung des Produkts erforderlich ist, damit das Produkt mit digitalen Elementen seine bestimmungsgemäßen Funktionen erfüllen kann. Ist ein Hardwareprodukt mit digitalen Elementen so konzipiert, dass es zur Erfüllung seiner Funktionen mit einer bestimmten, vom selben Hersteller bereitgestellten Software zusammenwirkt, so bilden die Hardware und diese Software zusammen das Produkt mit digitalen Elementen. Software, die erforderlich ist, um ein Produkt mit digitalen Elementen entsprechend seiner Zweckbestimmung zu betreiben, zu konfigurieren, zu steuern oder zu verwenden, ist daher Teil des Produkts mit digitalen Elementen, auch wenn sie über einen gesonderten Kanal bezogen wird (z. B. über einen App-Store, einen Download-Link oder einen anderen digitalen Kanal, nachdem das Hardwareprodukt mit digitalen Elementen in Verkehr gebracht wurde). Ihr Inverkehrbringen erfolgt somit zum selben Zeitpunkt, zu dem Einheiten der Hardwareprodukte mit digitalen Elementen in Verkehr gebracht werden.

Beispiel 8: Ein Netzwerkdrucker wird als Hardwareprodukt mit digitalen Elementen in Verkehr gebracht, während die Softwaretreiber, die zum Senden von Druckaufträgen, zur Konfiguration des Geräts und zur Verwaltung seines Betriebs erforderlich sind, auf der Website des Herstellers zum Herunterladen bereitgestellt werden. Obwohl Drucker und Treiber über unterschiedliche Kanäle geliefert werden, bilden sie zusammen ein einziges Produkt mit digitalen Elementen, da der Drucker seine Zweckbestimmung ohne die Treiber nicht erfüllen kann.

Beispiel 9: Ein Fitness-Wearable wird in Verkehr gebracht, um die Herzfrequenz und die Aktivität eines Nutzers zu messen, während eine vom Hersteller bereitgestellte Smartphone-Anwendung erforderlich ist, um die Messwerte anzuzeigen, den Verlauf darzustellen und die Konfiguration des Geräts zu ermöglichen. Obwohl die Anwendung gesondert über einen App-Store heruntergeladen wird, bilden das Wearable und die Anwendung zusammen ein einziges Produkt mit digitalen Elementen, da sie dafür konzipiert und bestimmt sind, zusammenzuwirken, um die Funktionalität des Produkts mit digitalen Elementen bereitzustellen.

Produkte mit digitalen Elementen, die in den Anwendungsbereich des CRA fallen, können nicht nur aus einzelnen Geräten oder Softwarekomponenten bestehen, sondern auch aus komplexen Systemen, einschließlich Systemen, die aus mehreren Hardware- und Softwareelementen bestehen, die zusammenwirken, um eine bestimmte Funktion zu erfüllen. Wird ein solches System als einziges Produkt mit digitalen Elementen in Verkehr gebracht, so stellt es ein Produkt mit digitalen Elementen im Sinne des CRA dar.

Solche komplexen Systeme zeichnen sich häufig durch lange Konzeptions- und Entwicklungszyklen mit Verträgen, die möglicherweise vor dem Geltungsbeginn des CRA unterzeichnet wurden, durch eine lange Betriebsdauer sowie durch ein hohes Maß an technischer und organisatorischer Komplexität aus. Solche Systeme, die nach dem Geltungsbeginn des CRA in Verkehr gebracht werden sollen, können auf Komponenten, die vor dem Geltungsbeginn des CRA in Verkehr gebracht wurden, auf etablierten Architekturen oder auf weit verbreiteten Interoperabilitätsnormen beruhen, einschließlich Normen, auf die in anderen Rechtsvorschriften der EU oder in sektorspezifischen Rahmen Bezug genommen wird. Infolgedessen kann es schwierig oder unverhältnismäßig sein, bestimmte technische Merkmale dieser Systeme zu ändern, ohne ihre Zweckbestimmung, Sicherheit, Zuverlässigkeit oder Interoperabilität mit bestehender Infrastruktur zu beeinträchtigen.

Diese Merkmale schließen komplexe Systeme nicht an sich vom Anwendungsbereich des CRA aus. Sie veranschaulichen vielmehr die Anwendung des risikobasierten Ansatzes des CRA, der es gemäß Artikel 13 Absatz 3 des CRA ermöglicht, die Konformität je nach den Merkmalen und Beschränkungen des Produkts mit digitalen Elementen auf unterschiedliche Weise nachzuweisen. Diese Merkmale sind Teil seiner Zweckbestimmung und seines Betriebskontexts und daher bei der Bewertung der Einhaltung der grundlegenden Cybersicherheitsanforderungen (im Folgenden „grundlegende Anforderungen“) von Bedeutung. Insbesondere erkennt Erwägungsgrund 55 ausdrücklich an, dass bestimmte grundlegende Anforderungen mit der Art eines Produkts mit digitalen Elementen möglicherweise nicht vollständig vereinbar sind. Dies kann beispielsweise der Fall sein, wenn die Einhaltung verbindliche Interoperabilitätsanforderungen oder das ordnungsgemäße Funktionieren des Systems beeinträchtigen würde.

Dementsprechend müssen die Hersteller den Cybersicherheitsrisiken auf der Grundlage der in Artikel 13 Absatz 2 genannten Bewertung der Cybersicherheitsrisiken begegnen. Wie ebenfalls in Erwägungsgrund 55 erläutert, sind in einigen Fällen bestimmte grundlegende Anforderungen nicht anwendbar oder können nicht durch die Umsetzung von Sicherheitsmaßnahmen nach dem Stand der Technik erfüllt werden, beispielsweise aufgrund der Zweckbestimmung des Systems, die es erfordert, dass das Produkt mit digitalen Elementen mit bestehenden Abhängigkeiten interagiert oder bestimmte Interoperabilitätsanforderungen befolgt. In solchen Fällen sollten die Hersteller diese spezifischen Beschränkungen ermitteln und dokumentieren, die damit verbundenen Risiken bewerten und geeignete alternative oder ausgleichende Maßnahmen zur Risikominderung umsetzen, um die Sicherheit des Produkts mit digitalen Elementen nicht zu beeinträchtigen. Zu diesem Zweck spielen sowohl die in Artikel 31 genannte technische Dokumentation als auch die in Anhang II genannten Informationen und Anleitungen für den Nutzer eine zentrale Rolle, um die ermittelten Beschränkungen, die damit verbundenen Cybersicherheitsrisiken und die umgesetzten Maßnahmen zur Risikominderung transparent zu beschreiben. Im Einklang mit der Pflicht, die Risikobewertung während des Unterstützungszeitraums zu aktualisieren, sollten die Hersteller außerdem regelmäßig erneut prüfen, ob solche Beschränkungen weiterhin bestehen. Können solche Beschränkungen im Laufe der Zeit aufgehoben oder verringert werden, sollten die Hersteller das Produkt mit digitalen Elementen entsprechend aktualisieren, damit es sich einem angemessenen Cybersicherheitsniveau annähern kann¹⁰.

Beispiel 10: Ein Hersteller bringt ein Produkt mit digitalen Elementen in Verkehr, das über ein Netzwerkprotokoll mit externen Systemen kommuniziert. Im Rahmen der Anwendung der grundlegenden Anforderungen stellt der Hersteller auf der Grundlage der Bewertung der Cybersicherheitsrisiken fest, dass die Verwendung eines sicheren Kommunikationsprotokolls erforderlich ist, um die Vertraulichkeit und Integrität der vom Produkt mit digitalen Elementen ausgetauschten Daten zu gewährleisten. Seine Zweckbestimmung umfasst jedoch die Interoperabilität mit bestehenden Systemen, die nur ein älteres oder weniger sicheres Protokoll unterstützen. In solchen Fällen kann der Hersteller dieses Protokoll implementieren, soweit dies zur Herstellung der Interoperabilität erforderlich ist, sofern die damit verbundenen Cybersicherheitsrisiken ermittelt und mit anderen Mitteln gemindert werden. Ist es technisch machbar, dass das Produkt mit digitalen Elementen sowohl das sichere als auch das weniger sichere Protokoll unterstützt, so wird vom Hersteller erwartet, dass er das sichere Protokoll implementiert und dessen Verwendung standardmäßig aktiviert. Das weniger sichere Protokoll wäre nur zulässig, soweit es für die Interoperabilität erforderlich ist.

Beispiel 11: Ein Hersteller eines industriellen Automatisierungssystems kauft vor dem Geltungsbeginn des CRA einige Mikrocontroller. Der Hersteller führt die Bewertung der Cybersicherheitsrisiken für sein industrielles Automatisierungssystem durch, das nach dem Geltungsbeginn des CRA in Verkehr gebracht werden soll. Auf der Grundlage dieser Bewertung der Cybersicherheitsrisiken ermittelt der Hersteller keine spezifischen Cybersicherheitsrisiken im Zusammenhang mit der Verwendung eines dieser Mikrocontroller. Der Hersteller integriert ihn in sein industrielles Automatisierungssystem und stellt sicher, dass das Produkt mit digitalen Elementen als Ganzes (das industrielle Automatisierungssystem) die grundlegenden Anforderungen erfüllt.

Fn. 10 Es ist darauf hinzuweisen, dass die in dieser Randnummer dargelegten Erwägungen gegebenenfalls auf alle Produkte mit digitalen Elementen im Anwendungsbereich des CRA anwendbar sein können und nicht nur auf „komplexe Systeme“.

Artikel 3 Nummer 1 CRA definiert ein Produkt mit digitalen Elementen als „ein Software- oder Hardwareprodukt und dessen Datenfernverarbeitungslösungen, einschließlich Software- oder Hardwarekomponenten, die getrennt in den Verkehr gebracht werden“. Vor diesem Hintergrund muss der Hersteller das Produkt mit digitalen Elementen als Ganzes betrachten, einschließlich seiner Datenfernverarbeitungslösungen (RDPS). So müssen beispielsweise beim Nachweis, dass das Produkt mit digitalen Elementen die in Anhang I festgelegten grundlegenden Anforderungen erfüllt, die RDPS berücksichtigt werden, beginnend mit der Risikobewertung (Artikel 13 Absatz 2). Dasselbe gilt bei der Betrachtung der Pflichten über den Lebenszyklus, etwa der Meldung aktiv ausgenutzter Schwachstellen und schwerwiegender Sicherheitsvorfälle (Artikel 14).

Zweck dieser Leitlinien ist es, die Hersteller weiter dabei zu unterstützen, festzustellen, ob ihr Produkt mit digitalen Elementen RDPS im Sinne des CRA aufweist und wie sie ihre diesbezüglichen Konformitätspflichten erfüllen. Nach einer ersten Analyse der im CRA festgelegten Begriffsbestimmungen und Erwägungsgründe enthalten diese Leitlinien Fragen, die den Herstellern bei der Klärung helfen sollen, ob ihr Produkt mit digitalen Elementen RDPS umfasst (siehe Abschnitt 8.1 Was gilt als Datenfernverarbeitungslösung eines Produkts mit digitalen Elementen? ). Anschließend wird auf die technischen Auswirkungen von RDPS und darauf eingegangen, wie die Einhaltung des CRA zu bewerten ist (siehe Abschnitt 8.2 Praktische und technische Auswirkungen von Datenfernverarbeitungslösungen und des Rückgriffs auf Lösungen Dritter ).

Artikel 3 Nummer 2 definiert den Begriff „Datenfernverarbeitung“ nämlich als „entfernt stattfindende Datenverarbeitung, für die eine Software vom Hersteller selbst oder unter dessen Verantwortung konzipiert und entwickelt wird und ohne die das Produkt mit digitalen Elementen eine seiner Funktionen nicht erfüllen könnte“. RDPS sind daher definiert als die Softwareelemente („den Teil eines elektronischen Informationssystems, der aus Computercode besteht“, wie in Artikel 3 Nummer 4 definiert) der entfernt stattfindenden Datenverarbeitung. Es ist nicht beabsichtigt, die Hardware, auf die sich die Datenfernverarbeitung stützen kann, in den Umfang des Produkts mit digitalen Elementen einzubeziehen.

Die Erwägungsgründe 11 und 12 enthalten weitere Erläuterungen dazu, wie dieser Begriff auszulegen ist. Erwägungsgrund 11 stellt klar, dass mit der Einbeziehung von Datenfernverarbeitungslösungen sichergestellt werden soll, dass „solche Produkte in ihrer Gesamtheit von ihren Herstellern angemessen gesichert werden, unabhängig davon, ob die Daten lokal auf dem Gerät des Nutzers oder aus der Ferne durch den Hersteller verarbeitet oder gespeichert werden“. Er besagt außerdem: „Die Anforderungen an Datenfernverarbeitungslösungen, die in den Anwendungsbereich dieser Verordnung fallen, beinhalten daher keine technischen, betrieblichen oder organisatorischen Maßnahmen zur Beherrschung der Risiken für die Sicherheit der Netz- und Informationssysteme des Herstellers insgesamt.“

Aus Erwägungsgrund 11 ergibt sich daher, dass die Anforderungen des CRA nicht die gesamte IT-Infrastruktur einer Organisation erfassen sollen, sondern nur Softwarekomponenten, die die Ausführung der Datenverarbeitungslösung ermöglichen. So sollten beispielsweise interne Systeme im Zusammenhang mit der eigenen Personalverwaltung des Herstellers, Gehaltsabrechnungen, dem Kundenbeziehungsmanagement, Pipelines für Continuous Integration/Continuous Delivery (CI/CD) oder der Verteilung von Sicherheitsaktualisierungen an Edge-Standorte nicht als RDPS betrachtet werden. Ebenso liegen Systeme im Zusammenhang mit Audit- und Testtätigkeiten wie Penetrationstests, Threat Hunting und Red Teaming außerhalb des Umfangs eines Produkts mit digitalen Elementen im Sinne des CRA. Es ist wichtig festzuhalten, dass es zwar eine in Anhang I Teil II Nummer 3 CRA festgelegte grundlegende Anforderung ist, die Sicherheit des Produkts mit digitalen Elementen regelmäßig und wirksam zu testen und zu überprüfen, dies jedoch nicht bedeutet, dass solche Tätigkeiten als RDPS des Produkts mit digitalen Elementen zu betrachten sind.

Erwägungsgrund 12 befasst sich mit Cloud-Diensten und erläutert, unter welchen Umständen Cloud-Dienste als RDPS gelten können. Der Erwägungsgrund schließt mit dem Hinweis, dass Cloud-Computing-Dienste und Cloud-Dienstmodelle in den Anwendungsbereich der Richtlinie (EU) 2022/2555 (NIS 2)²⁸fallen, die Anforderungen an das Cybersicherheitsrisikomanagement für Anbieter von Cloud-Computing-Diensten festlegt. Diese Anforderungen werden durch die Durchführungsverordnung (EU) 2024/2690 der Kommission²⁹näher bestimmt.

Fn. 28 Richtlinie (EU) 2022/2555 des Europäischen Parlaments und des Rates vom 14. Dezember 2022 über Maßnahmen für ein hohes gemeinsames Cybersicherheitsniveau in der Union, zur Änderung der Verordnung (EU) Nr. 910/2014 und der Richtlinie (EU) 2018/1972 sowie zur Aufhebung der Richtlinie (EU) 2016/1148 (NIS-2-Richtlinie), ABl. L 333 vom 27.12.2022, S. 80, ELI: http://data.europa.eu/eli/dir/2022/2555/2022-12-27 .

Fn. 29 Durchführungsverordnung (EU) 2024/2690 der Kommission vom 17. Oktober 2024 mit Durchführungsbestimmungen zur Richtlinie (EU) 2022/2555 im Hinblick auf die technischen und methodischen Anforderungen der Risikomanagementmaßnahmen im Bereich der Cybersicherheit und die Präzisierung der Fälle, in denen ein Sicherheitsvorfall in Bezug auf DNS-Diensteanbieter, TLD-Namenregister, Anbieter von Cloud-Computing-Diensten, Anbieter von Rechenzentrumsdiensten, Betreiber von Inhaltszustellnetzen, Anbieter verwalteter Dienste, Anbieter verwalteter Sicherheitsdienste, Anbieter von Online-Marktplätzen, Online-Suchmaschinen und Plattformen für Dienste sozialer Netzwerke und Vertrauensdiensteanbieter als erheblich gilt, ABl. L, 2024/2690, 18.10.2024, ELI: http://data.europa.eu/eli/reg_impl/2024/2690/oj .

Die in Artikel 3 Nummer 2 festgelegte Begriffsbestimmung der Datenfernverarbeitung stützt sich somit auf drei Elemente: (i) ob die Datenverarbeitung „entfernt stattfindet“; (ii) ob das Fehlen einer solchen Datenverarbeitung das Produkt mit digitalen Elementen daran hindern würde, eine seiner Funktionen zu erfüllen; und (iii) ob die Software vom Hersteller selbst oder unter dessen Verantwortung konzipiert und entwickelt wird. In den nächsten drei Unterabschnitten wird auf jedes dieser Elemente näher eingegangen.

Der in Artikel 3 Nummer 2 genannte Begriff „entfernt stattfindend“ ist relevant, aber nicht ausreichend, um zu bestimmen, ob ein Produkt mit digitalen Elementen RDPS umfasst. Angesichts der Vielfalt der Lösungen, die unter diesen Begriff fallen könnten, ist es zudem nicht möglich, eine abschließende Definition von „entfernt stattfindend“ zu geben. Eine Einzelfallbewertung durch den Hersteller ist erforderlich.

Erwägungsgrund 11 CRA spricht von Daten, die „aus der Ferne durch den Hersteller“ verarbeitet oder gespeichert werden, im Gegensatz zu Daten, die „lokal auf dem Gerät des Nutzers“ verarbeitet oder gespeichert werden. Datenfernverarbeitung findet typischerweise außerhalb der Nutzerumgebung eines Produkts mit digitalen Elementen oder der Betriebsumgebung einer Organisation (bei einem beruflichen Nutzer) statt. Dies schließt jedoch nicht aus, dass die Verarbeitung auch in der Nähe des Geräts („at the edge“) stattfindet. Die Datenübertragung kann kabelgebunden (z. B. Ethernet-Kabel) oder drahtlos (z. B. WLAN, Bluetooth) erfolgen. Cloud-Computing, einschließlich Edge-Computing, ist ein typisches Beispiel für eine „entfernt stattfindende“ Datenverarbeitung. So findet beispielsweise bei einer cloudbasierten Funktion, auf die der Nutzer über eine mobile Anwendung zugreift, ein Teil der Datenverarbeitung in der Cloud, außerhalb der Umgebung des Nutzers, statt.

Es ist wichtig festzuhalten, dass RDPS nicht zwingend auf Cloud-Infrastruktur Dritter betrieben werden. Auch Datenfernverarbeitung, die auf lokalen Servern in den Räumlichkeiten des Herstellers läuft, kann RDPS darstellen. Mit anderen Worten: Eine On-Premises und in einer privaten Cloud betriebene Lösung kann ebenso als RDPS gelten wie eine Off-Premises in einer öffentlichen Cloud betriebene Lösung.

Die beiden entscheidenden und kumulativen Fragen, die bestimmen, ob eine Datenverarbeitung vom CRA als Datenfernverarbeitungslösung erfasst wird, werden nachstehend in den Abschnitten 8.1.2 und 8.2 dargelegt. Werden beide Fragen bejaht, gilt die Datenfernverarbeitung als RDPS.

Wie in der Begriffsbestimmung der „Datenfernverarbeitung“ in Artikel 3 Nummer 2 festgelegt, müsste das Fehlen einer entfernt stattfindenden Datenverarbeitung das Produkt mit digitalen Elementen daran hindern, eine seiner Funktionen zu erfüllen, damit diese als RDPS gilt. Der in dieser Begriffsbestimmung enthaltene Begriff der „Funktionen“ ist nicht auf die „Kernfunktion“ oder die „Zweckbestimmung“ des Produkts mit digitalen Elementen beschränkt, da der CRA keine solche Beschränkung vorsieht. Die Funktionen im Anwendungsbereich des CRA sind sowohl Funktionen, die unmittelbar die Zweckbestimmung des Produkts mit digitalen Elementen, wie sie von den Nutzern erlebt wird, erfüllen, als auch Funktionen, die die Gesamtleistung des Produkts unterstützen.

Beispiele für Funktionen, bei denen eine entfernt stattfindende Datenverarbeitung erfolgen kann und deren Fehlen ein Produkt mit digitalen Elementen daran hindern würde, eine seiner Funktionen zu erfüllen, wären: (i) das Senden von Befehlen an ein Gerät; (ii) das Synchronisieren von Dateien; (iii) das Onboarding des Nutzers; (iv) die Konfiguration (Personalisierung des Produkts mit digitalen Elementen); (v) die automatisierte Verteilung von Aktualisierungen, einschließlich Funktionsaktualisierungen und Sicherheits-Patches; (vi) die Identitäts- und Zugriffsverwaltung.

In einigen Fällen kann der Nutzer eine Funktion sowohl aus der Ferne als auch manuell nutzen (z. B. eine Glühbirne per App oder manuell schalten). Diese Möglichkeit schließt nicht aus, dass die mit der Ausführung der Funktion aus der Ferne verbundene Datenverarbeitung als RDPS eingestuft wird. Die Ausführung dieser Funktion aus der Ferne gilt ebenfalls als Teil der Funktionen, die das Produkt mit digitalen Elementen bietet.

Hindert dagegen das Fehlen einer bestimmten Datenverarbeitung das Produkt mit digitalen Elementen nicht daran, eine seiner Funktionen zu erfüllen, gilt diese Verarbeitung nicht als RDPS im Sinne des CRA. Dazu gehört beispielsweise die Fernanalyse von Telemetriedaten, die ausschließlich für statistische Zwecke oder für die künftige Produktentwicklung erhoben werden.

Aber auch wenn eine Datenverarbeitung keine Funktion eines Produkts mit digitalen Elementen unterstützt, müssen die Hersteller im Rahmen ihrer Bewertung der Cybersicherheitsrisiken gegebenenfalls prüfen, ob diese entfernten Komponenten Risiken für das Produkt mit digitalen Elementen mit sich bringen (z. B. im Hinblick auf die Betriebsumgebung des Produkts), und diese Risiken entsprechend mindern (z. B. durch Minderungsmaßnahmen auf Produktebene).

Websites sind ein Sonderfall, der einer weiteren Klarstellung bedarf, wie auch in Abschnitt 2.1 Inverkehrbringen erläutert. Websites fallen nicht unter RDPS, wenn sie keine Funktion eines Produkts mit digitalen Elementen unterstützen, wie in Erwägungsgrund 11 CRA erläutert. Dass eine Website Informationen über ein Produkt mit digitalen Elementen enthält, reicht nicht aus, damit sie als RDPS gilt, selbst wenn das Produkt auf diese Website weiterleitet. So ist beispielsweise die Weiterleitung von Nutzern auf eine externe Webseite, die Informationen und Anleitungen für die Nutzer bereitstellt, keine RDPS. Dagegen kann eine Website unter RDPS fallen, wenn sie eine Funktion eines Produkts mit digitalen Elementen ermöglicht oder unterstützt. So wäre beispielsweise ein Authentifizierungsportal, das Anmeldedaten oder Token ausstellt, die für den Betrieb des Produkts mit digitalen Elementen erforderlich sind, als RDPS anzusehen (sofern auch die übrigen Kriterien der Begriffsbestimmung erfüllt sind).

Die Begriffsbestimmung der „Datenfernverarbeitung“ in Artikel 3 Nummer 2 CRA legt ferner fest, dass die Software einer solchen entfernt stattfindenden Datenverarbeitung vom Hersteller selbst oder unter dessen Verantwortung konzipiert und entwickelt werden muss. Eine vollständig vom Hersteller (intern) entwickelte und konzipierte Datenfernverarbeitung würde naturgemäß als RDPS gelten. Dies wäre auch dann der Fall, wenn Hersteller für die Entwicklung und Konzeption einer Lösung auf einen externen Dienstleister zurückgreifen (d. h. „unter dessen Verantwortung“). Die Wendung „unter der Verantwortung des Herstellers“ bezieht sich auf Fernverarbeitungslösungen, die für den Hersteller maßgeschneidert sind. Dies sind Fälle, in denen der Hersteller nicht lediglich ein bestehendes Produkt mit digitalen Elementen oder einen bestehenden Dienst, das bzw. den ein Dienstleister seinen Kunden anbietet, oder leicht abgewandelte Versionen davon lizenziert. „[U]nter der Verantwortung des Herstellers“ bedeutet, dass die Software ausschließlich vom Hersteller oder in dessen Auftrag auf der Grundlage von ihm bereitgestellter Entwürfe und Spezifikationen erstellt wird.

Für das Verständnis von RDPS ist die Frage, „wer die Lösung betreibt“, kein entscheidender Faktor, da sich die Begriffsbestimmung des CRA nur auf die Konzeption und Entwicklung der RDPS bezieht. Dies steht im Einklang mit dem Ansatz des CRA, wonach sich die Anforderungen und Pflichten an die Hersteller richten und nicht an den Betrieb des Produkts mit digitalen Elementen. Konzipieren und entwickeln Hersteller Lösungen, die dann von einem Dritten betrieben werden, bleiben sie für die Einhaltung der grundlegenden Anforderungen des CRA für das Produkt mit digitalen Elementen, das sie in Verkehr bringen, verantwortlich.

Es ist zu unterscheiden zwischen Fällen, in denen Konzeption und Entwicklung durch die Hersteller (oder unter deren Verantwortung) erfolgen, und Fällen des Rückgriffs auf Lösungen Dritter, die nicht von den Herstellern (oder unter deren Verantwortung) konzipiert und entwickelt wurden. Als Beispiel ist es hilfreich, die gängigsten Cloud-Dienstmodelle zu betrachten, die unterschiedliche Grade an Kontrolle durch den Nutzer bieten und die auch in Erwägungsgrund 12 CRA genannt werden, nämlich Software as a Service (SaaS), Platform as a Service (PaaS) und Infrastructure as a Service (IaaS).

Im Fall einer IaaS-Lösung eines Dritten verwaltet oder kontrolliert der Hersteller die zugrunde liegenden physischen und virtuellen Ressourcen (wie die zugrunde liegende Hardware und den Hypervisor des Cloud-Diensteanbieters) nicht, kann aber mithilfe dieser Ressourcen beliebige Software wie Betriebssysteme und Anwendungen einsetzen und ausführen. Solche Software wird vom Hersteller selbst oder unter dessen Verantwortung konzipiert und entwickelt und kann daher als RDPS gelten (sofern sie die übrigen Elemente der Begriffsbestimmung erfüllt).

Im Fall einer PaaS-Lösung eines Dritten setzt der Hersteller seine eigene (erstellte oder erworbene) Anwendung unter Verwendung von Programmiersprachen und Ausführungsumgebungen ein, die vom Cloud-Diensteanbieter bereitgestellt werden, und integriert die Anwendung in sein Produkt mit digitalen Elementen. Der Hersteller hat die Kontrolle über die Anwendung und möglicherweise über die Konfigurationseinstellungen der Ausführungsumgebung. Die Anwendung wird daher vom Hersteller selbst oder unter dessen Verantwortung konzipiert und entwickelt und kann daher als RDPS gelten (sofern sie die übrigen Elemente der Begriffsbestimmung erfüllt).

Im Fall einer SaaS-Lösung eines Dritten bietet der SaaS-Anbieter dem Hersteller eine vollständig entwickelte Anwendung zur Integration in das Produkt mit digitalen Elementen des Herstellers an. Der Hersteller hat nur begrenzte Möglichkeiten, nutzerspezifische Konfigurationseinstellungen der Anwendung zu verwalten. Die Anwendung wird daher nicht vom Hersteller selbst oder unter dessen Verantwortung konzipiert und entwickelt.

Werden jedoch bestimmte Elemente, die nicht als RDPS gelten (z. B. der Hypervisor im Fall einer IaaS-Infrastruktur eines Dritten, das Betriebssystem im Fall einer PaaS-Lösung eines Dritten oder die SaaS-Anwendung eines Dritten), in einer Weise in das Produkt mit digitalen Elementen integriert, die sich auf dessen Sicherheit auswirkt, sollten solche Lösungen ähnlich wie Komponenten Dritter betrachtet werden. Der Hersteller ist verpflichtet, Risiken im Zusammenhang mit der Integration dieser Elemente zu ermitteln und zu bewerten und sie durch die Umsetzung der grundlegenden Anforderungen am Produkt mit digitalen Elementen selbst zu behandeln. Dies kann gegebenenfalls durch die Sicherheitsfunktionen unterstützt werden, die der Cloud-Diensteanbieter im Rahmen seines Modells der geteilten Verantwortung zur Verfügung stellt, sofern der Hersteller diese Funktionen nutzt oder konfiguriert, um die ermittelten Risiken zu behandeln. Darüber hinaus wird vom Hersteller erwartet, in Bezug auf die Sicherheit dieser Komponenten eine ähnliche Pflicht wie die in Artikel 13 Absatz 5 genannte Pflicht, die gebotene Sorgfalt walten zu lassen, zu erfüllen, und zwar in einer Weise, die in einem angemessenen Verhältnis zu dem Risiko steht, das die Fernlösung für die Sicherheit des Produkts mit digitalen Elementen darstellt.

Zusammenfassend lässt sich daher festhalten:

a. Damit eine Datenverarbeitung als RDPS gilt, müssen beide Fragen bejaht werden, die gestellt werden in den Abschnitten 8.1.2 Würde das Fehlen einer solchen Datenverarbeitung das Produkt mit digitalen Elementen daran hindern, eine seiner Funktionen zu erfüllen? und 8.1.3 Wurde die Software vom Hersteller selbst oder unter dessen Verantwortung konzipiert und entwickelt?

b. Wird die Frage in Abschnitt 8.1.2 Würde das Fehlen einer solchen Datenverarbeitung das Produkt mit digitalen Elementen daran hindern, eine seiner Funktionen zu erfüllen? verneint, sollten die Hersteller die Risiken, die sich aus dem Bestehen einer solchen Datenverarbeitung ergeben, im Rahmen ihrer Risikobewertung bewerten.

c. Wird die Frage in Abschnitt 8.1.2 Würde das Fehlen einer solchen Datenverarbeitung das Produkt mit digitalen Elementen daran hindern, eine seiner Funktionen zu erfüllen? bejaht, die Frage in 8.1.3 Wurde die Software vom Hersteller selbst oder unter dessen Verantwortung konzipiert und entwickelt? jedoch verneint, sollten die Hersteller die Lösung des Dritten als Komponente behandeln. Im Rahmen der Risikobewertung sollten die Hersteller die Risiken bewerten, die sich aus der Integration einer solchen Lösung ergeben, und sie entsprechend mindern. Darüber hinaus sollten die Hersteller die gebotene Sorgfalt walten lassen.

Abbildung 9: Stilisiertes Flussdiagramm zur Bestimmung, ob ein Produkt mit digitalen Elementen RDPS enthält

Um Herstellern zusätzliche praktische Orientierung zu geben, stellt dieser Abschnitt eine Reihe fiktiver Anwendungsfälle vor, die archetypische Produkte mit digitalen Elementen beschreiben, die auf Datenfernverarbeitung beruhen, und veranschaulichen, ob diese Verarbeitung als Datenfernverarbeitungslösung im Sinne des CRA gilt.

Ein Finanzunternehmen bringt eine Mobile-Banking-Anwendung in Verkehr. Die Backend-Systeme der App unterstützen unter anderem Authentifizierung, Autorisierung, Kontoverwaltung und Zahlungen. Das Finanzunternehmen verfolgt eine hybride Strategie und stützt sich sowohl auf eigene Infrastruktur als auch auf Fernlösungen Dritter, um die Funktionalitäten der App zu unterstützen. Dazu gehören:

Vom Finanzunternehmen entwickelte, selbst betriebene Infrastruktur:

• Der Kunde öffnet die Mobile-Banking-Anwendung und wird über die Banking-Schnittstelle authentifiziert, eine vom Finanzunternehmen entwickelte, selbst betriebene Lösung, die die Anfragen der App entgegennimmt und die entsprechenden Antworten zurückgibt. Die Banking-Schnittstelle überprüft die Identität des Kunden durch eine Abfrage beim Kontoverwaltungssystem und gewährt Zugang zur Anwendung.
• Der Kunde veranlasst über die App eine Überweisung. Die App übermittelt den Auftrag an die Banking-Schnittstelle, die eine entsprechende Anfrage an das Hauptbuchsystem richtet.
• Das Kontoverwaltungssystem und das Hauptbuchsystem, beide selbst betrieben, aber logisch von der Banking-Schnittstelle getrennt, erfassen die Transaktion.
• Das Hauptbuchsystem gibt den Transaktionsstatus an die Banking-Schnittstelle zurück, die dem Kunden das Ergebnis anzeigt.

Folgen für RDPS:

• Die Banking-Schnittstelle ist erforderlich, damit die App ihre Funktionen erfüllen kann, nämlich den Kunden zu authentifizieren, die Aufträge des Kunden einschließlich Zahlungs- und Überweisungsaufträgen zu übermitteln und den daraus resultierenden Status zurückzugeben. Die Banking-Schnittstelle wird unter der Verantwortung des Herstellers konzipiert und entwickelt. Da beide in früheren Abschnitten dargestellten Fragen zu bejahen sind, ist die Banking-Schnittstelle als RDPS anzusehen. Sie muss daher in die Bewertung der Cybersicherheitsrisiken und in die Umsetzung der grundlegenden Anforderungen für das Produkt mit digitalen Elementen als Ganzes einbezogen werden. Die weitere Verarbeitung eines Auftrags nach seiner Übermittlung, insbesondere die Erfassung der Transaktion im Kontoverwaltungs- und im Hauptbuchsystem, die Abwicklung und das Clearing, erfolgt durch Systeme, mit denen die App nicht unmittelbar interagiert, und stellt aus diesem Grund keine RDPS dar.
• Das Kontoverwaltungssystem und das Hauptbuchsystem gelten nicht als RDPS der Banking-Anwendung. Die App interagiert nicht unmittelbar mit ihnen (sondern mit der Banking-Schnittstelle, die ihrerseits auf sie zurückgreift). Auch wenn ihre Verfügbarkeit für den Abschluss einer Funktion erforderlich sein kann, erfasst der CRA nur diejenigen Teile des Systems, die unmittelbar mit dem Produkt mit digitalen Elementen interagieren. Sie fallen daher für die Zwecke des CRA nicht unter die Begriffsbestimmung der RDPS. Diese Systeme bleiben jedoch externe Abhängigkeiten, die erhebliche Cybersicherheitsrisiken für das Produkt mit digitalen Elementen begründen können. So könnte etwa eine Kompromittierung des Hauptbuchsystems es einem Angreifer ermöglichen, Transaktionsergebnisse zu beeinflussen, die anschließend in der Anwendung angezeigt werden. Der Hersteller ist daher verpflichtet, diese Risiken im Rahmen der Bewertung der Cybersicherheitsrisiken zu ermitteln und zu bewerten und sie durch Maßnahmen auf Produktebene zu mindern, etwa durch eine starke Authentifizierung der Backend-Schnittstellen, einen Integritätsschutz der Transaktionsdaten, sichere Kommunikationskanäle und die Überprüfung der von der App empfangenen Antworten.

Abbildung 10: Schematische Darstellung einer Banking-App, die auf RDPS beruht

SaaS eines Dritten für den Kundensupport:

• Das Finanzunternehmen integriert in seine App eine Chat-Lösung für den Kundensupport, die von einem Drittanbieter entwickelt und betrieben wird; der Drittanbieter hat den Code des Chat-Servers geschrieben, die Benutzeroberfläche erstellt und betreibt die Infrastruktur, auf der der Chat bereitgestellt wird (d. h. SaaS-Modell).
• Stellt der Kunde eine Supportanfrage, verbindet die App den Kunden mit dem Dienst des Dritten, um eine Chatsitzung aufzubauen und den Nachrichtenfluss abzuwickeln, ohne dem Dritten Zugang zu den Kernbankensystemen zu gewähren.

Folgen für RDPS:

• Die Support-Chat-Lösung ist erforderlich, damit das Produkt mit digitalen Elementen eine seiner Funktionen erfüllen kann, wird aber nicht vom Finanzunternehmen oder unter seiner Verantwortung konzipiert und entwickelt; sie ist daher keine RDPS. Sie sollte jedoch wie eine Komponente eines Dritten behandelt werden. Die Abhängigkeit von diesem Dienst eines Dritten kann Cybersicherheitsrisiken für die Banking-Anwendung begründen, etwa wenn ein Angreifer den Chat-Kanal nutzen würde, um sich als die Bank auszugeben oder den Nutzern schädliche Inhalte zukommen zu lassen. Das Finanzunternehmen muss diese Risiken in seiner Bewertung der Cybersicherheitsrisiken berücksichtigen und sie durch Maßnahmen auf Produktebene mindern, etwa durch die Isolierung der Chat-Funktion von den Kernbankfunktionen, die Kontrolle der Datenflüsse und die Validierung von Inhalten. Auch in Bezug auf den SaaS-Dienst sollte die gebotene Sorgfalt walten gelassen werden.

Ein intelligentes Thermostat ermöglicht es Nutzern, die Temperatur in ihrer Wohnung über eine mobile Anwendung zu steuern. Die mobile Anwendung und das intelligente Thermostat stützen sich auf Datenfernverarbeitung, um Daten auszutauschen (z. B. die Anforderung, die Temperatur zu erhöhen) und Daten zu speichern (z. B. Nutzerpräferenzen). Diese Funktionen wurden unter der Verantwortung des Herstellers entwickelt und konzipiert, laufen aber auf einer zugrunde liegenden physischen und virtuellen Infrastruktur, die von einem Dritten bereitgestellt wird (IaaS eines Dritten).

Da das intelligente Thermostat seine intelligenten Funktionalitäten ohne diese Datenfernverarbeitung nicht erfüllen könnte, würde ihr Fehlen das Produkt mit digitalen Elementen daran hindern, eine oder mehrere seiner Funktionen zu erfüllen. Zudem wurde die Software unter der Verantwortung des Herstellers des intelligenten Thermostats entwickelt und konzipiert. Die Datenfernverarbeitung gilt daher als RDPS im Sinne des CRA.

Für die Zwecke der Einhaltung des CRA muss der Hersteller des intelligenten Thermostats die RDPS sowie die Abhängigkeit von der IaaS des Dritten in der technischen Dokumentation des Produkts mit digitalen Elementen dokumentieren, einschließlich Angaben zum vertraglich vereinbarten Dienst. Der Hersteller muss diese Elemente in der Risikobewertung berücksichtigen, die die Zweckbestimmung und die vernünftigerweise vorhersehbare Verwendung des Produkts mit digitalen Elementen einschließt. Der Hersteller setzt die grundlegenden Anforderungen des CRA auf der Grundlage der Risiken in Bezug auf die RDPS um. Für die IaaS des Dritten muss der Hersteller sicherstellen, dass die vom Drittanbieter bereitgestellten Sicherheitsmaßnahmen angemessen sind, und/oder einschlägige Maßnahmen in Bezug auf die Infrastruktur ergreifen. Für Ersteres könnte der Hersteller beispielsweise Nachweise dafür verlangen, dass die Pflichten aus NIS 2 erfüllt wurden.

Der Hersteller einer E-Reader-Software nutzt einen SaaS-Speicherdienst eines Dritten, um von Kunden gekaufte elektronische Bücher zu speichern und ihnen den Zugriff auf ihre Bücher zu ermöglichen. Das Fehlen dieses Speicherdienstes würde das Produkt mit digitalen Elementen daran hindern, eine seiner Funktionen zu erfüllen; der SaaS-Speicherdienst des Dritten wird jedoch nicht vom Hersteller oder unter seiner Verantwortung entwickelt; der SaaS-Anbieter stellt ihn Kunden für beliebige Anwendungsfälle zur Verfügung.

Der SaaS-Speicherdienst erfüllt nicht die Begriffsbestimmung der RDPS. Der Hersteller des E-Readers ist für das Funktionieren seines Produkts mit digitalen Elementen jedoch auf diesen externen Dienst angewiesen und muss die damit verbundenen Risiken daher in seiner Bewertung der Cybersicherheitsrisiken berücksichtigen. Der Hersteller des E-Readers sollte den SaaS-Dienst wie eine Komponente behandeln. Der Hersteller muss geeignete Sicherheitsmaßnahmen auf Produktebene umsetzen, etwa eine sichere Authentifizierung, Verschlüsselung und einen Integritätsschutz der Kommunikation mit dem Speicherdienst. Die gebotene Sorgfalt bei der Auswahl und Einbindung des SaaS-Anbieters unterstützt zudem die Erfüllung der Pflichten des Herstellers, sodass das Produkt mit digitalen Elementen als Ganzes die grundlegenden Anforderungen erfüllen kann.

Ein Industrieroboter hat die Aufgabe, Teile aufzunehmen. Der Roboter sendet über Kameras erfasste Informationen an einen vom Hersteller konzipierten und entwickelten Ferndienst. Dieser Dienst läuft auf einer zugrunde liegenden physischen und virtuellen Infrastruktur, die von einem dritten Dienstleister bereitgestellt wird (IaaS eines Dritten). Der Cloud-Dienst berechnet anhand der Kamerabilder die Position eines Teils und sendet Befehle an den Roboter zurück, damit dieser die Teile aufnimmt.

Das Fehlen dieser Datenverarbeitung würde den Industrieroboter daran hindern, Teile aufzunehmen, und damit daran, eine seiner Funktionen zu erfüllen. Außerdem wurde die auf der Infrastruktur laufende Software vom Hersteller konzipiert und entwickelt. Die vom Hersteller konzipierte und entwickelte Software erfüllt die Begriffsbestimmung der RDPS.

Der Hersteller des Industrieroboters muss die RDPS sowie die Abhängigkeit von der IaaS des Dritten in der technischen Dokumentation des Produkts mit digitalen Elementen dokumentieren (einschließlich Angaben zum vertraglich vereinbarten Dienst). Der Hersteller muss diese Elemente zudem in der Risikobewertung berücksichtigen, die die Zweckbestimmung und die vernünftigerweise vorhersehbare Verwendung des Produkts mit digitalen Elementen einschließt. Der Hersteller setzt die grundlegenden Anforderungen des CRA auf der Grundlage der Risiken am Produkt mit digitalen Elementen einschließlich seiner RDPS um. Die gebotene Sorgfalt bei der Auswahl des IaaS-Anbieters unterstützt zudem die Erfüllung der Pflichten des Herstellers. Beispielsweise könnte der Hersteller Nachweise dafür verlangen, dass die Pflichten aus NIS 2 erfüllt wurden.

Ein Smartphone ist auf ein 5G-Netz angewiesen, um seinen Nutzern Internetverbindung, Telefonate und Nachrichten bereitzustellen (mobile Konnektivität). Das Mobilfunknetz wird von Telekommunikationsbetreibern entwickelt und konzipiert. Das Netz umfasst Kleinzellen, Mobilfunkmasten und sonstige Netzausrüstung.

Das Produkt mit digitalen Elementen sollte in der Lage sein, sich ordnungsgemäß mit einem Netz zu verbinden; dies ist eine seiner Funktionen. Ob dieses Netz in Betrieb ist oder nicht, ist jedoch für die Feststellung, ob das Produkt mit digitalen Elementen ordnungsgemäß funktioniert, nicht maßgeblich. Das Netz ist lediglich ein Kommunikationskanal und ist nicht erforderlich, damit das Produkt mit digitalen Elementen seine Funktion „sich ordnungsgemäß mit einem Netz verbinden“ erfüllen kann. Ebenso gelten ein Ethernet-Kabel, ein Router oder ein WLAN-Signal nicht als Datenverarbeitung, deren Fehlen das Produkt mit digitalen Elementen daran hindern würde, eine seiner Funktionen zu erfüllen, sondern vielmehr als Mittel, das Kommunikation/Konnektivität ermöglicht.

Folglich erfüllt das Mobilfunknetz nicht die Begriffsbestimmung der RDPS. Das Netz sollte nicht wie eine Komponente eines Dritten betrachtet werden, da keine Software in das Produkt mit digitalen Elementen integriert ist; das Produkt stützt sich vielmehr lediglich auf dieses Netz. Daher ist es nicht erforderlich, dass der Hersteller gegenüber dem Netzbetreiber Pflichten zur Wahrung der gebotenen Sorgfalt wahrnimmt.

Es ist auch sinnvoll, klarzustellen, ob Quellcode ein Softwareprodukt mit digitalen Elementen darstellen kann. Der CRA definiert Software als „den Teil eines elektronischen Informationssystems, der aus Computercode besteht“ (Artikel 3 Nummer 4). Computercode kann die Form haben von (i) Maschinencode, d. h. dem in Binärformat geschriebenen Satz von Anweisungen, die unmittelbar vom Prozessor eines Computers ausgeführt werden; oder (ii) Quellcode, d. h. dem in einer Programmiersprache geschriebenen Satz von Anweisungen und Befehlen, der kompiliert oder interpretiert werden muss, um von einem Computer ausgeführt zu werden. Die im CRA festgelegte Begriffsbestimmung für Software erfasst beides.

Eine gesonderte Frage ist, ob eine bestimmte Abgabe von Computercode einem Inverkehrbringen eines Produkts mit digitalen Elementen auf dem EU-Markt gleichkommt, das eine Abgabe im Rahmen einer Geschäftstätigkeit voraussetzt. Bei Quellcode dürfte dies häufig nicht der Fall sein. So wird beispielsweise bei einer natürlichen oder juristischen Person, die freien und quelloffenen Computercode in öffentlich zugänglichen Repositorien teilt, im Allgemeinen nicht davon ausgegangen, dass sie diesen Code für die Zwecke des CRA auf dem EU-Markt in Verkehr bringt (wie in Abschnitt 3 Freie und quelloffene Software ausführlicher erörtert). Unfertiger Code, der während der Konzeptions- und Entwicklungsphase eines Produkts mit digitalen Elementen geteilt wird (z. B. zu Test- oder Prüfzwecken), gilt ebenfalls nicht als für die Zwecke des CRA in Verkehr gebracht, da seine Herstellungsphase nicht abgeschlossen ist. Ebenso gilt Beispiel- oder Democode, der im Rahmen von Tutorials oder Schulungsmaterialien bereitgestellt wird, nicht als für die Zwecke des CRA in Verkehr gebracht⁸.

Stellt ein Hersteller seinen Kunden hingegen Computercode als Produkt mit digitalen Elementen zur Verfügung, so gilt dieser Code als in Verkehr gebracht, unabhängig davon, ob es sich um Maschinencode oder Quellcode handelt⁹.

Beispiel 7: Unternehmen A lizenziert Unternehmen B Quellcode für eine anpassbare interne Plattform und stellt diesen Quellcode in einer Textdatei bereit. Auch wenn dieser Quellcode vor seiner Verwendung von Unternehmen B noch weiter angepasst und kompiliert werden muss, bringt Unternehmen A diesen Quellcode in Verkehr und unterliegt daher dem CRA. Unternehmen A ist nicht dafür verantwortlich, dass die späteren Anpassungen und die Kompilierung dieses Codes durch Unternehmen B mit dem CRA konform sind.

Fn. 8 Es sei auch daran erinnert, dass Artikel 4 Absatz 3 es den Herstellern erlaubt, unfertige Software, die der Verordnung nicht entspricht, wie Alpha-Versionen, Beta-Versionen oder Release Candidates, auf dem Markt bereitzustellen, sofern die unfertige Software nur für den Zeitraum bereitgestellt wird, der erforderlich ist, um sie zu testen und Rückmeldungen einzuholen.

Fn. 9 Andererseits ist darauf hinzuweisen, dass Computercode für die Zwecke des Produkthaftungsrechts selbst kein Produkt darstellt und Hersteller, die solchen Code in Verkehr bringen, daher nicht nach der Richtlinie (EU) 2024/2853 (Produkthaftungsrichtlinie) haftbar gemacht werden können. In Erwägungsgrund 13 dieser Richtlinie heißt es: „Informationen sind jedoch nicht als Produkt zu betrachten, und die Produkthaftungsvorschriften sollten daher nicht für den Inhalt digitaler Dateien wie Mediendateien oder E-Books oder den reinen Quellcode von Software gelten.“ Dies schließt nicht aus, dass Hersteller nach nationalem Deliktsrecht haften können .

Der CRA führt die neue Rechtskategorie des „Verwalters quelloffener Software“ ein, und zwar angesichts „der Bedeutung für die Cybersicherheit, die vielen Produkten mit digitalen Elementen zukommt, die als freie und quelloffene Software eingestuft sind und im Sinne [des CRA] veröffentlicht, aber nicht auf dem Markt bereitgestellt werden“ (Erwägungsgrund 19 des CRA).

In manchen Fällen wird eine FOSS veröffentlicht, aber nicht im Sinne des CRA auf dem Markt bereitgestellt, und zwar von einer juristischen Person, die „den Zweck oder das Ziel hat, die Entwicklung spezifischer Produkte mit digitalen Elementen, die als [FOSS] gelten und für kommerzielle Tätigkeiten bestimmt sind, systematisch und nachhaltig zu unterstützen, und die die Brauchbarkeit dieser Produkte sicherstellt“ (Artikel 3 Nummer 14 des CRA). In solchen Fällen unterliegt diese juristische Person den Pflichten der Verwalter quelloffener Software.

Ein Verwalter quelloffener Software ist definiert als „eine juristische Person, bei der es sich nicht um einen Hersteller handelt“, weil ein Hersteller definitionsgemäß die natürliche oder juristische Person ist, die Produkte mit digitalen Elementen unter ihrem Namen oder ihrer Marke in Verkehr bringt („vermarktet“). Eine juristische Person kann nur für Produkte mit digitalen Elementen, die als FOSS gelten und veröffentlicht, aber nicht im Sinne des CRA auf dem Markt bereitgestellt werden, Verwalter quelloffener Software sein. Das Konzept des Verwalters quelloffener Software gilt daher für bestimmte FOSS, die „letztlich für kommerzielle Tätigkeiten wie die Integration in kommerzielle Dienste oder kostenpflichtige Produkte mit digitalen Elementen bestimmt sind“ (Erwägungsgrund 19 des CRA¹³), aber nicht im Sinne des CRA auf dem Markt bereitgestellt werden, und für die die juristische Person, die diese FOSS veröffentlicht, eine systematische Unterstützung sicherstellt.

Verwalter quelloffener Software für eine bestimmte FOSS zu sein, bedeutet nicht, dass diese juristische Person notwendigerweise auch Verwalter für andere FOSS ist, die sie veröffentlicht. Ebenso bedeutet der Umstand, Hersteller einer bestimmten FOSS zu sein, nicht, dass die juristische Person nicht Verwalter für andere FOSS sein kann. Dies schließt die Bereitstellung von „Community“-Versionen derselben FOSS ein, wie in Abschnitt 3.2.1 Verlangen eines Preises beschrieben.

Eine juristische Person kann daher gleichzeitig Verwalter quelloffener Software für eine bestimmte FOSS sein (wenn sie diese systematisch und nachhaltig unterstützt und die Brauchbarkeit der Software sicherstellt) und Hersteller einer anderen bestimmten FOSS (wenn sie diese in Verkehr bringt). Mit anderen Worten: Dieselbe juristische Einheit kann verpflichtet sein, für verschiedene FOSS-Projekte unterschiedliche Rollen zu erfüllen.

Für jede bestimmte FOSS, die sie veröffentlicht, muss die juristische Person feststellen, ob diese FOSS als im Sinne des CRA in Verkehr gebracht gilt. Ist dies der Fall, ist die juristische Einheit damit Hersteller der Software. Gilt die FOSS nicht als in Verkehr gebracht, kann die juristische Person ihr Verwalter quelloffener Software sein, wenn die Software für kommerzielle Tätigkeiten bestimmt ist und wenn die juristische Person sie im Einklang mit der Begriffsbestimmung des Verwalters quelloffener Software unterstützt¹⁴.

Fn. 13 Dieser Gedanke ist auch in der Formulierung „für kommerzielle Tätigkeiten bestimmt“ enthalten, die in der Begriffsbestimmung des „Verwalters quelloffener Software“ in Artikel 3 Nummer 14 des CRA enthalten ist.

Fn. 14 Die juristische Person unterliegt möglicherweise auch keinen Pflichten nach dem CRA, wenn (i) eine bestimmte FOSS nicht im Sinne des CRA in Verkehr gebracht wird und (ii) die juristische Einheit in Bezug auf diese bestimmte FOSS die Begriffsbestimmung des Verwalters quelloffener Software nicht erfüllt.

Handelt es sich bei einer juristischen Person, die eine FOSS veröffentlicht, um eine gemeinnützige Organisation, die „so angelegt ist, dass sichergestellt ist, dass alle Einnahmen nach Abzug der Kosten zur Verwirklichung gemeinnütziger Ziele verwendet werden“ (Erwägungsgrund 18 des CRA), gilt die von ihr veröffentlichte FOSS nicht als in Verkehr gebracht. Erfüllt diese juristische Person die Begriffsbestimmung des „Verwalters quelloffener Software“, unterliegt sie den entsprechenden Pflichten (Artikel 24 des CRA).

Beispiel 24: Eine juristische Person veröffentlicht einen freien und quelloffenen Browser, der über Partnerschaften mit Suchmaschinen unmittelbar monetarisiert wird, deren gesamte Einnahmen nach Abzug der Kosten jedoch für gemeinnützige Ziele verwendet werden. Der Browser gilt nicht als im Sinne des CRA in Verkehr gebracht. Die juristische Person, die ihn veröffentlicht, unterliegt den für Verwalter quelloffener Software geltenden Pflichten.

In manchen Fällen wird eine FOSS von einer eindeutig identifizierbaren natürlichen oder juristischen Person veröffentlicht, diese FOSS ist jedoch „zur Integration durch andere Hersteller in ihre eigenen Produkte mit digitalen Elementen bestimmt“. In solchen Fällen gilt diese FOSS nicht als auf dem EU-Markt in Verkehr gebracht, es sei denn, sie wird im Einklang mit den vorstehenden Abschnitten dieser Leitlinien auch von der Person monetarisiert, die sie veröffentlicht (d. h. vom ursprünglichen Hersteller).

Wird diese FOSS nicht in Verkehr gebracht, unterläge die juristische Person, die sie veröffentlicht, den Pflichten der Verwalter quelloffener Software, sofern sie im Einklang mit der Begriffsbestimmung des „Verwalters quelloffener Software“ dauerhaft Unterstützung leistet.

Beispiel 25: Eine juristische Person veröffentlicht eine FOSS-Bibliothek zum Erstellen von Benutzeroberflächen. Sie monetarisiert die Lieferung dieser Bibliothek nicht, integriert sie aber in eines ihrer Produkte mit digitalen Elementen (das seinerseits in Verkehr gebracht wird). Die Bibliothek gilt nicht als im Sinne des CRA in Verkehr gebracht, ist aber zur Integration in Produkte mit digitalen Elementen bestimmt. Die juristische Person, die sie veröffentlicht, ist ihr Verwalter quelloffener Software.

Beispiel 26: Eine juristische Person bringt ein Betriebssystem in Verkehr und veröffentlicht zudem FOSS-Bibliotheken, die als Referenzimplementierungen für Nutzer dieses Betriebssystems dienen. Die juristische Person monetarisiert die FOSS-Bibliotheken nicht, die zur Integration in andere Produkte mit digitalen Elementen bestimmt sind. Die juristische Person, die sie veröffentlicht, ist Verwalter quelloffener Software für diese FOSS-Bibliotheken.

Erwägungsgrund 19 erläutert, dass die dauerhafte Unterstützung der Entwicklung eines Produkts mit digitalen Elementen unter anderem Folgendes umfassen kann: (i) das Hosting und die Verwaltung von Plattformen für die Zusammenarbeit bei der Softwareentwicklung; (ii) das Hosting von Quellcode oder Software; (iii) das Verwalten oder Administrieren von Produkten mit digitalen Elementen, die als FOSS gelten; und (iv) die Steuerung der Entwicklung solcher Produkte mit digitalen Elementen.

Dies kann beispielsweise bei einer juristischen Einheit der Fall sein, die FOSS zur Integration in ihre eigenen Produkte mit digitalen Elementen entwickelt und sie dann veröffentlicht, ohne sie in Verkehr zu bringen. Dies wird auch in Abschnitt 3.2.7 Integration durch andere Hersteller erörtert. In diesem Fall ist die juristische Einheit nicht Hersteller der Software, kann aber ihr Verwalter quelloffener Software sein. Darüber hinaus gilt, wie ebenfalls in den vorstehenden Abschnitten erläutert, eine juristische Einheit, die eine kostenlose (oder Community-)Version und eine monetarisierte Version derselben FOSS veröffentlicht, als Verwalter quelloffener Software für die kostenlose (oder Community-)Version und als Hersteller der monetarisierten Version.

Ebenso ist eine juristische Einheit, die eine FOSS monetarisiert, aber eine gemeinnützige Einrichtung ist, deren Einnahmen nach Abzug der Kosten zur Verwirklichung gemeinnütziger Ziele verwendet werden (und deren FOSS daher nicht im Sinne des CRA in Verkehr gebracht wird, wie in Abschnitt 3.2.6 Gemeinnützige Einrichtungen erörtert), Verwalter quelloffener Software für die von ihr veröffentlichte FOSS.

Darüber hinaus bieten bestimmte Stiftungen Plattformen für die Zusammenarbeit mit verschiedenen Formen der Governance an, die es Herstellern ermöglichen, regelmäßig zur Entwicklung von FOSS beizutragen, und/oder die regelmäßig von Herstellern finanziert werden. Solche Stiftungen sind in Bezug auf bestimmte FOSS, die für kommerzielle Tätigkeiten bestimmt sind und für die die Stiftung dauerhafte Unterstützung leistet, als Verwalter quelloffener Software zu betrachten. Wie in Abschnitt 3.3 Verwalter quelloffener Software erläutert, unterliegt eine solche Stiftung jedoch für andere bestimmte FOSS, die sie hostet, möglicherweise keinen Pflichten nach dem CRA, wenn sie eine bestimmte FOSS nicht systematisch unterstützt, deren Brauchbarkeit nicht sicherstellt und/oder diese bestimmte Software nicht für kommerzielle Tätigkeiten bestimmt ist.

Die Art der „dauerhaften Unterstützung“, die Stiftungen und ähnliche Organisationen bestimmten FOSS-Projekten leisten, kann sehr unterschiedlich sein. Beispielsweise leisten bestimmte juristische Einheiten nur nicht-technische Unterstützung, etwa indem sie die Markenführung von Projekten verwalten, Governance-Regeln festlegen, Community-Veranstaltungen organisieren oder Spenden sammeln. Andere Einheiten stellen zudem die zugrunde liegende IT-Infrastruktur bereit, die für den Betrieb des Projekts erforderlich ist, etwa indem sie Quellcode-Repositorys hosten, Versionskontrollsysteme bereitstellen oder Signaturschlüssel erzeugen. Wieder andere gehen bei der Art der von ihnen geleisteten Unterstützung weiter, indem sie aktiv technische Ressourcen (Engineering-Ressourcen) in das Projekt einbringen, beispielsweise indem sie Entwickler beschäftigen, Entwicklungsarbeit koordinieren, Code prüfen oder zusammenführen, Releases verwalten oder Schwachstellenmeldungen und Sicherheitspatches bearbeiten. Während alle juristischen Einheiten, die nach dem CRA als Verwalter quelloffener Software gelten, die Pflichten nach Artikel 24 Absätze 1 und 2 erfüllen müssen, hängt es gemäß Artikel 24 Absatz 3 von der Art der geleisteten Unterstützung ab, inwieweit die in Artikel 14 Absätze 1, 3 und 8 festgelegten Pflichten für diese juristischen Einheiten gelten.

Stellt eine Einrichtung die systematische und nachhaltige Unterstützung für eine bestimmte FOSS ein, erfüllt sie möglicherweise nicht mehr die Begriffsbestimmung des Verwalters quelloffener Software und unterliegt daher möglicherweise nicht mehr den entsprechenden Pflichten. In solchen Fällen wird dieser Einrichtung empfohlen, die Änderung ihres Status für diese bestimmte FOSS klar zu kommunizieren.

In bestimmten Situationen kann eine Einrichtung, die Verwalter quelloffener Software für ein bestimmtes Projekt war, beschließen, dieses Projekt unmittelbar zu monetarisieren, wodurch sie das Produkt mit digitalen Elementen in Verkehr bringt und die Pflichten des Herstellers nach dem CRA ausgelöst werden. Unter diesen Umständen gilt diese Einrichtung ab dem Tag, an dem sie das Produkt mit digitalen Elementen in Verkehr bringt, als dessen Hersteller (jedoch nicht in Bezug auf frühere Versionen, für die sie als Verwalter quelloffener Software tätig war).

Der CRA gilt für Produkte mit digitalen Elementen, die auf dem EU-Markt bereitgestellt werden. Der Begriff der Bereitstellung auf dem Markt ist in Artikel 3 Nummer 22 des CRA definiert als „die entgeltliche oder unentgeltliche Abgabe eines Produkts mit digitalen Elementen zum Vertrieb oder zur Verwendung auf dem Unionsmarkt im Rahmen einer Geschäftstätigkeit“. Gemäß Artikel 3 Nummer 21 wird ein Produkt mit digitalen Elementen in dem Zeitpunkt auf dem EU-Markt in Verkehr gebracht, in dem es erstmals bereitgestellt wird.

Die 2022 veröffentlichte neueste Ausgabe des Leitfadens für die Umsetzung der Produktvorschriften der EU (im Folgenden „Blue Guide“)⁶enthält Leitlinien, die das Verständnis der Produktvorschriften der EU und ihre einheitliche Anwendung in den verschiedenen sektoralen Rechtsrahmen erleichtern, die am neuen Rechtsrahmen (NLF) ausgerichtet sind, wie etwa dem CRA. Nach dem Blue Guide sind die Begriffe „Inverkehrbringen“ und „Bereitstellung“ so zu verstehen, dass sie sich „nicht auf eine Produktart, sondern auf jedes einzelne Produkt, unabhängig davon, ob es als Einzelstück oder in Serie hergestellt wurde“, beziehen (Abschnitt 2.3).

Bei eher „herkömmlichen“ Produkten mit digitalen Elementen, die unter den NLF fallen, wie etwa Hardware in Form von Maschinen oder Funkanlagen, die Produkte mit digitalen Elementen sind, ist der Begriff des „Inverkehrbringens“ gut etabliert, und der Blue Guide enthält weitere Leitlinien zur Klärung, wann solche Produkte als in Verkehr gebracht gelten. Die „zusammenfassenden Beispiele“ in Abschnitt 2.12 des Blue Guide liefern weitere Beispiele für den Begriff des „Inverkehrbringens“.

Angesichts der Beschaffenheit nicht körperlicher Produkte mit digitalen Elementen wie eigenständiger Software bedarf es jedoch weiterer Leitlinien dazu, wann solche Produkte mit digitalen Elementen als in Verkehr gebracht gelten. Sobald die Herstellungsphase der Software abgeschlossen ist und das Produkt mit digitalen Elementen potenziellen Nutzern auf dem EU-Markt angeboten wird, kann davon ausgegangen werden, dass sein Hersteller mehrere Kopien desselben Softwareprodukts mit digitalen Elementen hergestellt und zum Vertrieb oder zur Verwendung abgegeben hat. Anders als körperliche Produkte mit digitalen Elementen unterliegt eigenständige Software nämlich keiner physischen Produktion und keinen Bestandsbeschränkungen: Mit jedem Vorgang, durch den die Software zum Herunterladen oder zum Vertrieb bereitgestellt wird, entsteht für den Nutzer eine neue identische Kopie. Solange diese Version der Software nicht in einer Weise geändert wird, die sich auf die Konformität mit dem CRA auswirkt, ist davon auszugehen, dass das Inverkehrbringen auf dem EU-Markt im Zeitpunkt des ersten Angebots zum Vertrieb oder zur Verwendung erfolgt ist. Die Möglichkeit, diese Version des Softwareprodukts mit digitalen Elementen später herunterzuladen oder zu vertreiben, ist daher als ein Fall anzusehen, in dem dieses Softwareprodukt mit digitalen Elementen bereitgestellt wird⁷.

Daher sollte ein eigenständiges Softwareprodukt mit digitalen Elementen als in Verkehr gebracht gelten, wenn seine Herstellungsphase abgeschlossen ist und diese Software erstmals im Rahmen einer Geschäftstätigkeit zum Vertrieb oder zur Verwendung auf dem EU-Markt abgegeben wird. Es sollte davon ausgegangen werden, dass der Hersteller mehrere Kopien desselben Softwareprodukts mit digitalen Elementen gleichzeitig in Verkehr gebracht hat. Mehrere Kopien derselben Software bleiben daher zwar einzelne Produkte mit digitalen Elementen, gelten aber als gleichzeitig in Verkehr gebracht, unabhängig davon, wann der Besitz oder die Nutzung jeder einzelnen Kopie auf eine andere natürliche oder juristische Person übergeht. Stellt der Hersteller Software hingegen in verschiedenen Varianten bereit, die sich in den enthaltenen Komponenten, den Konfigurationen oder den aktivierten Funktionen unterscheiden (z. B. Builds für verschiedene Betriebssysteme oder Pakete mit unterschiedlichem Funktionsumfang), so können diese Varianten nicht als mehrere Kopien desselben Softwareprodukts mit digitalen Elementen angesehen werden. Sie sollten daher für die Zwecke des Inverkehrbringens als unterschiedliche Produkte mit digitalen Elementen behandelt werden.

Beispiel 1: Am 1. Januar 2028 bietet Unternehmen A über seine Website erstmals die Version 1.0.0 seiner Software X zum Vertrieb an. Am selben Tag erwirbt Kunde 1 eine Kopie der Version 1.0.0 der Software X. Am 15. Januar 2028 erwirbt Kunde 2 eine Kopie der Version 1.0.0 der Software X. Beide Kopien der Version 1.0.0 der Software X werden am 1. Januar 2028 in Verkehr gebracht.

Angesichts des iterativen Charakters der Softwareentwicklung sollte ferner klargestellt werden, dass spätere Iterationen eines Softwareprodukts mit digitalen Elementen als neu in Verkehr gebracht gelten, wenn diese Iterationen als „wesentliche Änderung“ eines bereits in Verkehr gebrachten Softwareprodukts mit digitalen Elementen einzustufen sind, wie in Erwägungsgrund 41 des CRA angegeben. Iterationen, die keine wesentlichen Änderungen darstellen, erfordern vom Hersteller kein neues Konformitätsbewertungsverfahren und ändern daher nicht den Zeitpunkt des Inverkehrbringens dieser Software. Weitere Leitlinien zum Begriff der wesentlichen Änderung siehe Abschnitt 4 Wesentliche Änderungen .

Beispiel 2: Am 1. Januar 2028 bietet Unternehmen A über seine Website erstmals die Version 1.0.0 der Software X zum Vertrieb an. Am selben Tag erwirbt Kunde 1 eine Kopie der Version 1.0.0 der Software X. Am 15. Januar 2028 veröffentlicht Unternehmen A eine aktualisierte Version 1.0.1 der Software X, die keine wesentliche Änderung darstellt. Am 30. Januar 2028 erwirbt Kunde 2 eine Kopie der Version 1.0.1 der Software X. Beide Kopien, die der Version 1.0.0 und die der Version 1.0.1 der Software X, gelten als am 1. Januar 2028 in Verkehr gebracht.

Die in den Randnummern 13, 14 und 15 dargelegten Leitlinien gelten ausschließlich, soweit es sich bei dem Produkt mit digitalen Elementen um eigenständige Software handelt. Dies ist beispielsweise nicht der Fall, wenn die Software mit Hardware kombiniert wird, wie in Abschnitt 2.4 Kombination von Hardware und Software, die ein Produkt bilden erörtert.

Fn. 6 Bekanntmachung der Kommission – Leitfaden für die Umsetzung der Produktvorschriften der EU 2022 („Blue Guide“) (Text von Bedeutung für den EWR) 2022/C 247/01, ABl. C 247 vom 29.6.2022, S. 1–152.

Fn. 7 Gemäß Artikel 13 Absatz 11 können die Hersteller öffentliche Softwarearchive unterhalten, die den Nutzern den Zugang zu historischen Versionen erleichtern. In diesen Fällen werden die Nutzer klar und in leicht zugänglicher Form über die Risiken im Zusammenhang mit der Verwendung nicht unterstützter Software informiert.

Steht fest, dass eine FOSS der Verantwortung einer natürlichen oder juristischen Person unterliegt, so muss festgestellt werden, ob diese Person sie im Rahmen einer Geschäftstätigkeit liefert und damit ein Inverkehrbringen vorliegt.

Verlangt die natürliche oder juristische Person, die eine FOSS liefert, einen Preis für die Software selbst (z. B. indem sie einen Preis für die vorkompilierten Binärdateien verlangt), bringt diese Person ein Produkt mit digitalen Elementen in Verkehr. Die Person, die eine FOSS in Verkehr bringt, ist daher Hersteller im Sinne des CRA.

Häufig liefern Hersteller von FOSS kostenlose Versionen dieser Software (oft als „Community“-Versionen bezeichnet), deren Codebasis mit der kostenpflichtigen Version (nahezu) identisch ist. Diese Produkte mit digitalen Elementen sind jedoch unterschiedliche Produkte: Die kostenpflichtige Version wird in irgendeiner Weise monetarisiert (z. B. entweder durch das Verlangen eines Preises oder durch andere Mittel, wie in diesem Abschnitt erörtert) und gilt daher als in Verkehr gebracht, wodurch die Pflichten des Herstellers ausgelöst werden. Die kostenlos bereitgestellte Version (oder Community-Version) wird nicht monetarisiert und gilt daher für die Zwecke des CRA nicht als in Verkehr gebracht. Dies gilt auch dann, wenn die kostenpflichtige Version eine „erweiterte“ kommerzielle Version ist, die die Codebasis der kostenlos bereitgestellten Version erweitert oder diese Version in ein umfassenderes Produkt mit digitalen Elementen einbindet (z. B. wie beim „Open-Core“-Modell).

Ist die Person, die die Community-Version liefert, eine juristische Person, unterliegt diese juristische Person für die Version, die sie kostenlos liefert (die Community-Version), zudem den Pflichten der Verwalter quelloffener Software. Ist die Einrichtung eine natürliche Person, fällt die kostenlos bereitgestellte Version (die Community-Version) nicht in den Anwendungsbereich des CRA.

Eine natürliche oder juristische Person, die eine FOSS veröffentlicht, kann diese auch dann in Verkehr bringen (d. h. im Rahmen einer Geschäftstätigkeit liefern), wenn sie die Software bereitstellt, über die sie andere Produkte mit digitalen Elementen oder Dienste monetarisiert, oder wenn sie als Bedingung für die Nutzung die Verarbeitung personenbezogener Daten zu anderen Zwecken als der alleinigen Verbesserung der Sicherheit, Kompatibilität oder Interoperabilität der Software verlangt.

Beispiel 14: Eine natürliche oder juristische Person veröffentlicht eine freie und quelloffene Marktplatz-Anwendung. Die Anwendung ist kostenlos erhältlich und ermöglicht es Nutzern, darüber Waren oder Dienstleistungen zu erwerben. Die App ermöglicht es der Person, die sie veröffentlicht hat, andere darüber angebotene Produkte mit digitalen Elementen und Dienste zu monetarisieren (z. B. durch Werbung, Provisionen oder Abonnementgebühren). Daher gilt die Anwendung als im Rahmen einer Geschäftstätigkeit in Verkehr gebracht.

Beispiel 15: Eine natürliche oder juristische Person veröffentlicht ein freies und quelloffenes VPN. Die Anwendung ist kostenlos erhältlich, ermöglicht es Nutzern aber, für den Zugang zu zusätzlichen Servern oder dedizierten IP-Adressen zu bezahlen. Diese Anwendung ermöglicht es dieser Person, andere darüber angebotene Dienste zu monetarisieren; daher gilt sie als im Rahmen einer Geschäftstätigkeit in Verkehr gebracht.

Beispiel 16: Eine natürliche oder juristische Person veröffentlicht eine freie und quelloffene Fitness-Tracking-Anwendung. Die Anwendung ist kostenlos erhältlich, ihre Nutzung ist jedoch an die Verarbeitung personenbezogener Daten der Nutzer zu Zwecken wie gezielter Werbung oder Analysen geknüpft, die nichts mit der Sicherheit, Kompatibilität oder Interoperabilität der Software zu tun haben. Da eine solche Datenverarbeitung als Bedingung für die Nutzung verlangt wird, gilt die Anwendung daher als im Rahmen einer Geschäftstätigkeit in Verkehr gebracht.

Der bloße Umstand, dass eine natürliche oder juristische Person, die eine FOSS veröffentlicht, auch kostenpflichtige Supportleistungen dazu anbietet, bedeutet für sich genommen nicht, dass das Produkt mit digitalen Elementen im Rahmen einer Geschäftstätigkeit geliefert wird. Supportleistungen können Tätigkeiten wie Beratung, Schulung oder professionelle Dienstleistungen im Zusammenhang mit der Nutzung, Dokumentation, Konfiguration und dem Einsatz der Software durch einen Kunden umfassen.

Ausschlaggebend ist, ob der Zugang zur FOSS selbst (d. h. die Bereitstellung des Produkts mit digitalen Elementen), einschließlich ihrer Wartung, von einem Entgelt abhängig gemacht wird, und nicht das bloße Angebot professioneller Dienstleistungen rund um ein frei verfügbares Produkt mit digitalen Elementen, wie in Erwägungsgrund 18 des CRA ausgeführt („[sollte] die Bereitstellung von Produkten mit digitalen Elementen, die als freie und quelloffene Software eingestuft und von ihren Herstellern nicht zu Geld gemacht werden, nicht als Geschäftstätigkeit betrachtet werden“). Kann die FOSS frei heruntergeladen und installiert werden und können Nutzer optional separat professionelle Dienstleistungen erwerben, gilt diese FOSS nicht als in Verkehr gebracht.

Dagegen wird in manchen Fällen der Zugang zu einer bestimmten Version des Produkts mit digitalen Elementen, die bestimmte Vorteile wie technische Unterstützung oder Leistungsoptimierung umfasst, von einem Entgelt abhängig gemacht. In solchen Fällen stellt diese Bereitstellung eine monetarisierte Bereitstellung eines Produkts mit digitalen Elementen dar, das im Rahmen einer Geschäftstätigkeit geliefert wird, und gilt daher als in Verkehr gebracht. Dies umfasst Fälle, in denen eine kostenpflichtige Edition oder Enterprise-Version im Rahmen einer kommerziellen Vereinbarung bereitgestellt wird, unabhängig davon, ob funktional gleichwertige Software auch kostenlos unter einer freien und quelloffenen Lizenz erhältlich ist.

Beispiel 17: Eine natürliche oder juristische Person veröffentlicht ein freies und quelloffenes Betriebssystem und bietet eine kostenpflichtige Version dieses Betriebssystems an, die Supportleistungen wie technische Unterstützung oder Leistungsoptimierung umfasst. Die kostenpflichtige Version des Betriebssystems gilt als im Rahmen einer Geschäftstätigkeit in Verkehr gebracht.

Beispiel 18: Eine natürliche oder juristische Person veröffentlicht ein freies und quelloffenes Kommandozeilenwerkzeug. Das Werkzeug ist frei zugänglich, und jeder kann es herunterladen und installieren. Diese natürliche oder juristische Person bietet separat professionelle Dienstleistungen an, etwa optionale Beratungsleistungen, um Nutzer zu schulen und sie bei der Installation und Nutzung des Werkzeugs zu unterstützen. Diese FOSS gilt nicht als im Sinne des CRA in Verkehr gebracht.

Insbesondere bei natürlichen Personen, die FOSS veröffentlichen, wäre technische Unterstützung, die unmittelbar mit dem Zugang zum Produkt mit digitalen Elementen gebündelt ist, dennoch nicht als Geschäftstätigkeit einzustufen, wenn, wie in Erwägungsgrund 15 des CRA ausgeführt, der verlangte Preis nur der Deckung der tatsächlichen Kosten dient. Zu diesen tatsächlichen Kosten gehören vielfältige Kosten im Zusammenhang mit der Konzeption, Entwicklung und Wartung dieser Software, einschließlich angemessener Lebenshaltungskosten der Person. Daher ist eine natürliche Person, die eine FOSS veröffentlicht und technische Unterstützung anbietet, um ihre Kosten zu decken und eine angemessene Vergütung zu erhalten, allein aus diesem Grund nicht so zu betrachten, als bringe sie diese Software auf dem EU-Markt in Verkehr.

Eine natürliche oder juristische Person, die technische Unterstützung im Zusammenhang mit einer FOSS anbietet, die nicht ihrer Verantwortung unterliegt, gilt nicht als Person, die diese Software in Verkehr bringt, es sei denn, diese Person nimmt im Rahmen der Erbringung dieser Unterstützung eine wesentliche Änderung an der FOSS gemäß Artikel 22 vor.

Beispiel 19: Ein Dienstleister veröffentlicht keine FOSS, hilft aber einem Kunden, sie auf dessen lokalem Server (on-premises) zu installieren. Dabei nimmt er keine wesentliche Änderung an dieser FOSS vor. Der Dienstleister gilt daher nicht als Person, die die FOSS in Verkehr bringt.

Natürliche oder juristische Personen, die FOSS-Projekte veröffentlichen, sehen routinemäßig Möglichkeiten vor, mit denen Nutzer dieser Software freiwillig Geld spenden können, um sich bei dem oder den Herausgebern des Projekts zu bedanken und auch um sicherzustellen, dass das Projekt aktiv gepflegt wird.

Wie in Erwägungsgrund 15 des CRA ausgeführt: „Die Annahme von Spenden ohne Gewinnabsicht sollte nicht als Geschäftstätigkeit gelten.“ Der bloße Umstand, dass ein Link zu einer Spendenplattform oder ähnliche Werkzeuge zum Sammeln von Spenden eingebunden werden, sollte nicht als Gewinnabsicht angesehen werden, selbst wenn der über Spenden eingenommene Betrag die bloßen Kosten übersteigt, die mit der Konzeption, Entwicklung und Bereitstellung eines Produkts mit digitalen Elementen verbunden sind. Dies umfasst eine angemessene Vergütung der von einer juristischen Person beschäftigten Beitragenden und/oder angemessene Lebenshaltungskosten einer natürlichen Person. Spenden schwanken naturgemäß im Laufe der Zeit; daher ist bei der Beurteilung, ob eine ausschließlich über Spenden monetarisierte FOSS als in Verkehr gebracht gilt, ein gewisses Maß an Flexibilität anzuwenden. Bei einer FOSS, die nur durch Spenden unterstützt wird, ist es daher unwahrscheinlich, dass sie als im Sinne des CRA in Verkehr gebracht gilt.

Beispiel 20: Eine natürliche oder juristische Person veröffentlicht ein FOSS-Werkzeug in einem öffentlichen Online-Repository, sodass jeder es unter einer freien und quelloffenen Lizenz herunterladen, nutzen, verändern und weiterverteilen kann. Der Herausgeber bittet die Nutzer, über eine Spendenplattform freiwillig zu spenden, um die weitere Entwicklung und Wartung des Projekts zu unterstützen. Der Zugang zur Software, zu ihrem Quellcode und zu ihren Aktualisierungen hängt nicht von einer Spende ab. Diese FOSS gilt nicht als im Rahmen einer Geschäftstätigkeit geliefert und gilt nicht als im Sinne des CRA in Verkehr gebracht.

Dennoch gibt es Fälle, in denen eine durch Spenden unterstützte FOSS als in Verkehr gebracht gelten kann. Dies ist der Fall, wenn die Spenden auf der Grundlage einer Gesamtbeurteilung der Umstände de facto dem Verlangen eines Preises für den Zugang zum Produkt mit digitalen Elementen oder zu bestimmten seiner Funktionen gleichkommen. Dies kann insbesondere dann der Fall sein, wenn der Zugang zur FOSS, zu wesentlichen Funktionen oder zu Aktualisierungen in der Praxis von einer Spende abhängig gemacht wird oder wenn Spenden mit vertraglichen Vorteilen oder exklusiven Vergünstigungen verbunden sind, die über Community-Vergünstigungen hinausgehen.

Beispiel 21: Eine natürliche oder juristische Person veröffentlicht ein Softwareprodukt mit digitalen Elementen unter einer freien und quelloffenen Lizenz, stellt herunterladbare Releases und Sicherheitsaktualisierungen aber nur Nutzern zur Verfügung, die spenden. Nutzer, die nicht spenden, haben keinen Zugang zur aktuellen Version der Software. In diesem Fall sind die Spenden de facto eine Bedingung für den Zugang zum Produkt mit digitalen Elementen und kommen daher dem Verlangen eines Preises gleich. Diese FOSS gilt daher als im Sinne des CRA in Verkehr gebracht.

Beispiel 22: Eine natürliche oder juristische Person macht den Quellcode einer FOSS öffentlich zugänglich, stellt vorkompilierte Binärdateien, regelmäßige Aktualisierungen und garantierte Sicherheitskorrekturen aber nur Spendern zur Verfügung. In diesem Fall sind die Spenden mit dem Zugang zu wesentlichen Aspekten des Produkts mit digitalen Elementen verknüpft und stellen ein Entgelt für die Lieferung dieses Produkts dar. Diese FOSS gilt daher als im Rahmen einer Geschäftstätigkeit in Verkehr gebracht.

Der bloße Umstand, dass ein Dritter die Entwicklung einer FOSS bezahlt, gesponsert oder anderweitig finanziert hat, bestimmt für sich genommen nicht, ob diese FOSS in Verkehr gebracht wird. Im FOSS-Ökosystem ist es gängige Praxis, dass einzelne Entwickler, Stiftungen oder Communitys Finanzmittel von Unternehmen, öffentlichen Stellen oder anderen Sponsoren erhalten, um an bestimmten Funktionen zu arbeiten, Fehler zu beheben oder kritische Komponenten zu pflegen. Diese Finanzierung kann viele Formen annehmen, darunter Zuschüsse, Bug Bounties, Sponsoring, Dienstleistungsverträge oder bezahlte Entwicklungsarbeit.

Wie bereits erwähnt, stellt Erwägungsgrund 18 des CRA klar, dass die bloßen Umstände, unter denen das Produkt mit digitalen Elementen entwickelt wurde, oder die Art und Weise, wie die Entwicklung finanziert wurde, bei der Bestimmung des kommerziellen Charakters der entsprechenden Tätigkeit nicht berücksichtigt werden sollten.

Wird die FOSS daher offen geteilt und für alle frei zugänglich, nutzbar, veränderbar und weiterverteilbar gemacht, sollte der Umstand, dass ein kommerzielles Unternehmen dieses Projekt bezahlt haben mag, nicht zur Bestimmung beitragen, ob die Software in Verkehr gebracht wird. Tatsächlich ist diese FOSS, wenn sie nicht anderweitig monetarisiert wird, nicht als in Verkehr gebracht zu betrachten. Integriert das Unternehmen, das die Entwicklung der FOSS finanziert hat (wie auch jedes andere Unternehmen), sie in sein Produkt mit digitalen Elementen, hat dieses Unternehmen gemäß Artikel 13 Absatz 5 des CRA die gebotene Sorgfalt walten zu lassen.

Beispiel 23: Ein einzelner Entwickler veröffentlicht ein FOSS-Projekt und pflegt es aktiv. Hersteller A bittet den einzelnen Entwickler, eine bestimmte Funktion für diese FOSS hinzuzufügen, und finanziert diese Entwicklung. Der Entwickler fügt die Funktion der Codebasis der FOSS hinzu, teilt sie offen und macht sie für alle frei zugänglich, nutzbar, veränderbar und weiterverteilbar. Der einzelne Entwickler gilt nicht als Person, die diese FOSS in Verkehr gebracht hat. Integriert der Hersteller die FOSS in sein Produkt mit digitalen Elementen, muss er gemäß Artikel 13 Absatz 5 die gebotene Sorgfalt walten lassen.

Die nachstehend aufgeführten Beispiele sind vollständig hypothetisch und sollen lediglich verschiedene Fälle veranschaulichen, wie sie in den vorstehenden Abschnitten erläutert wurden.

Beispiel 27: Der einzelne Entwickler A hat eine FOSS entwickelt. Entwickler A veröffentlicht diese FOSS unter seinem eigenen Namen oder seiner eigenen Marke, verlangt aber keinen Preis für ihre Nutzung. Die Software wird offen geteilt und ist für alle frei zugänglich, nutzbar, veränderbar und weiterverteilbar. Entwickler A bindet zudem einen Link zu einer Plattform zum Sammeln freiwilliger Spenden ein. Die Unternehmen B, C und D integrieren diese FOSS in ihre eigenen Produkte mit digitalen Elementen. Um die laufende Wartung zu unterstützen, leisten die Unternehmen B, C und D freiwillige Spenden an Entwickler A. Diese Spenden ermöglichen es Entwickler A, das Projekt aktiv zu pflegen. Diese FOSS wird nicht im Sinne des CRA in Verkehr gebracht. Entwickler A hat keine Pflichten nach dem CRA. Die Unternehmen B, C und D haben bei der Integration dieser FOSS in ihre eigenen Produkte mit digitalen Elementen gemäß Artikel 13 Absatz 5 die gebotene Sorgfalt walten zu lassen.

Beispiel 28: Die gemeinnützige Stiftung F veröffentlicht eine FOSS-Komponente zur Integration in andere kommerzielle Produkte mit digitalen Elementen. Stiftung F verpflichtet sich, diese FOSS dauerhaft zu unterstützen, um ihre Brauchbarkeit und Verbreitung sicherzustellen. Die Unternehmen A, B und C integrieren diese FOSS in ihre eigenen Produkte mit digitalen Elementen. Die Unternehmen A und B stellen freiwillig einen Teil der Arbeitszeit ihrer Entwickler für die Entwicklung und Wartung von FOSS-Projekten innerhalb der Stiftung F zur Verfügung, auch für diese FOSS. Da Stiftung F eine gemeinnützige Einrichtung ist, die so angelegt ist, dass ihre Einnahmen nach Abzug der Kosten zur Verwirklichung gemeinnütziger Ziele verwendet werden, gilt die FOSS nicht als im Sinne des CRA in Verkehr gebracht. Stiftung F ist der Verwalter quelloffener Software für die FOSS und unterliegt den entsprechenden Pflichten nach Artikel 24. Die Unternehmen A, B und C haben bei der Integration dieser FOSS in ihre eigenen Produkte mit digitalen Elementen gemäß Artikel 13 Absatz 5 die gebotene Sorgfalt walten zu lassen.

Beispiel 29: Unternehmen A hat eine FOSS-Komponente zur Integration in seine eigenen Produkte mit digitalen Elementen entwickelt. Es veröffentlicht diese FOSS zudem separat unter seinem eigenen Namen oder seiner eigenen Marke und pflegt sie aktiv. Es verlangt jedoch kein Entgelt für ihre Nutzung und monetarisiert sie auch nicht auf andere Weise. Die Unternehmen B, C und D integrieren diese FOSS in ihre eigenen Produkte mit digitalen Elementen und stellen freiwillig einen Teil der Arbeitszeit ihrer Entwickler für deren Wartung zur Verfügung. Diese FOSS gilt nicht als im Sinne des CRA in Verkehr gebracht. Unternehmen A ist nicht ihr Hersteller, sondern ihr Verwalter quelloffener Software. Die Unternehmen B, C und D haben bei der Integration der FOSS in ihre eigenen Produkte mit digitalen Elementen gemäß Artikel 13 Absatz 5 die gebotene Sorgfalt walten zu lassen.

Beispiel 30: Unternehmen A veröffentlicht eine FOSS unter seinem eigenen Namen oder seiner eigenen Marke und bietet sie als kostenpflichtige Version an, die bestimmte Vorteile wie technische Unterstützung oder Leistungsoptimierung umfasst. Entwickler der Unternehmen B, C und D tragen zur Wartung der FOSS bei, sie bleibt aber unter der Kontrolle von Unternehmen A. Unternehmen A gilt als Hersteller dieser FOSS¹⁵. Die Unternehmen B, C und D unterliegen für diese bestimmte FOSS keinen Pflichten nach dem CRA. Integrieren sie diese FOSS in ihre eigenen Produkte mit digitalen Elementen, müssen sie gemäß Artikel 13 Absatz 5 die gebotene Sorgfalt walten lassen.

Beispiel 31: Unternehmen A veröffentlicht eine FOSS unter seinem eigenen Namen oder seiner eigenen Marke und sorgt für eine laufende Wartung, um ihre langfristige Brauchbarkeit sicherzustellen und die Integration dieser Software in Produkte mit digitalen Elementen anderer Unternehmen zu ermöglichen. Unternehmen A verlangt kein Entgelt für ihre Nutzung, verarbeitet keine personenbezogenen Daten, die es über das Produkt mit digitalen Elementen erhebt, und verkauft keine Supportleistungen im Zusammenhang mit der Veröffentlichung der FOSS. Unternehmen B trägt Code und Arbeitszeit seiner Entwickler zur Wartung der FOSS bei, vertreibt sie aber nicht kommerziell. Unternehmen B bietet technische Supportleistungen unabhängig vom Vertrieb der FOSS an. Unternehmen A gilt als Verwalter quelloffener Software für diese FOSS, während Unternehmen B für diese FOSS keine Pflichten nach dem CRA hat.

Beispiel 32: Eine FOSS-Komponente wird von einer gemeinnützigen Einrichtung veröffentlicht, die so angelegt ist, dass sichergestellt ist, dass alle Einnahmen nach Abzug der Kosten zur Verwirklichung gemeinnütziger Ziele verwendet werden. Die Einrichtung leistet dauerhafte Unterstützung, um die langfristige Brauchbarkeit des Projekts sicherzustellen. Die Wartung wird aus öffentlichen Mitteln finanziert, etwa durch Forschungszuschüsse. Weiterentwicklungen, einschließlich neuer Funktionen, werden durch Spenden und spezifische Projekte finanziert, die in Partnerschaft mit Herstellern durchgeführt werden, die diese FOSS in ihre Produkte mit digitalen Elementen integrieren. Solche Funktionen werden in die Codebasis der FOSS aufgenommen. Die gemeinnützige Einrichtung, die die FOSS veröffentlicht, gilt als Verwalter quelloffener Software für diese FOSS-Komponente. Ein Hersteller, der zur Entwicklung bestimmter Funktionen beigetragen hat, wird dadurch nicht zum Hersteller dieser FOSS-Komponente. Integriert der Hersteller diese FOSS-Komponente in sein eigenes Produkt mit digitalen Elementen, muss er gemäß Artikel 13 Absatz 5 die gebotene Sorgfalt walten lassen.

Beispiel 33: Eine gemeinnützige Einrichtung, die so angelegt ist, dass sichergestellt ist, dass alle Einnahmen nach Abzug der Kosten zur Verwirklichung gemeinnütziger Ziele verwendet werden, veröffentlicht ein FOSS-Softwareentwicklungskit (SDK) und stellt dessen laufende Wartung sicher. Das SDK wird offen geteilt und ist für alle frei zugänglich, nutzbar, veränderbar und weiterverteilbar. Die Finanzierung erfolgt über Mitgliedsbeiträge an die gemeinnützige Einrichtung, und bei Mitgliedsorganisationen beschäftigte Entwickler tragen Code und andere Ressourcen zur Entwicklung des SDK bei. Hersteller verwenden das SDK als Komponente, um andere Produkte mit digitalen Elementen zu erstellen. Die gemeinnützige Einrichtung, die dieses SDK veröffentlicht, ist dessen Verwalter quelloffener Software. Die Mitglieder der Stiftung sind nicht für die Konformität des SDK mit dem CRA verantwortlich. Verwenden Hersteller das SDK, um ihr eigenes Produkt mit digitalen Elementen zu erstellen, müssen sie gemäß Artikel 13 Absatz 5 die gebotene Sorgfalt walten lassen.

Beispiel 34: Ein einzelner Entwickler veröffentlicht eine FOSS-Bibliothek in einem öffentlichen Paket-Repository für eine bestimmte Programmiersprache und pflegt sie aktiv. In der Paketdokumentation fügt der Entwickler einen Link zum Sammeln von Spenden hinzu. Ein Hersteller lädt diese Bibliothek kostenlos aus dem Repository herunter und integriert sie in sein eigenes Produkt mit digitalen Elementen. Der einzelne Entwickler und das Paket-Repository haben keine Pflichten nach dem CRA. Der Hersteller, der die Bibliothek integriert, muss gemäß Artikel 13 Absatz 5 die gebotene Sorgfalt walten lassen.

Abbildung 1: Schematisches Ablaufdiagramm zur Erfassung freier und quelloffener Software durch den CRA

Fn. 15 Es sei denn, Unternehmen A ist eine gemeinnützige Einrichtung, die so angelegt ist, dass sichergestellt ist, dass alle Einnahmen nach Abzug der Kosten zur Verwirklichung gemeinnütziger Ziele verwendet werden; in diesem Fall wäre es der Verwalter quelloffener Software für diese FOSS.

Artikel 3 Nummer 30 des CRA definiert eine „wesentliche Änderung“ als eine Änderung des Produkts mit digitalen Elementen nach dessen Inverkehrbringen, die (i) sich auf die Konformität des Produkts mit digitalen Elementen mit den grundlegenden Anforderungen in Anhang I Teil I auswirkt oder (ii) zu einer Änderung des bestimmungsgemäßen Zwecks führt, für den das Produkt mit digitalen Elementen geprüft wurde.

Der Begriff der wesentlichen Änderung ist für die Feststellung der Pflichten nach dem CRA in einer Reihe von Fällen maßgeblich, darunter die folgenden:

a. gemäß Artikel 21 gilt ein Einführer oder Händler, der eine wesentliche Änderung an einem bereits in Verkehr gebrachten Produkt mit digitalen Elementen vornimmt, als dessen Hersteller;

b. gemäß Artikel 22 gilt jede natürliche oder juristische Person, die eine wesentliche Änderung an einem Produkt mit digitalen Elementen vornimmt und es auf dem Markt bereitstellt, als dessen Hersteller;

c. gemäß Artikel 69 Absatz 2 gilt jede natürliche oder juristische Person, die nach dem 11. Dezember 2027 eine wesentliche Änderung an einem vor dem 11. Dezember 2027 in Verkehr gebrachten Produkt mit digitalen Elementen vornimmt und es in Verkehr bringt, als dessen Hersteller;

d. für Hersteller von Produkten mit digitalen Elementen, die nach dem 11. Dezember 2027 in Verkehr gebracht werden, um festzustellen, ob ein Produkt mit digitalen Elementen aufgrund von nach diesem Datum vorgenommenen Änderungen einem neuen Konformitätsbewertungsverfahren unterzogen werden muss, insbesondere angesichts des iterativen Charakters der Softwareentwicklung.

Daher ist es wichtig, Hinweise bereitzustellen, die den Wirtschaftsakteuren helfen zu verstehen, wann Hardware- oder Softwareänderungen als wesentliche Änderungen gelten.

Wie in Erwägungsgrund 42 des CRA ausgeführt: „Wird ein Produkt mit digitalen Elementen einer ‚Überholung‘, ‚Wartung‘ und ‚Reparatur‘ im Sinne des Artikels 2 Nummern 18, 19 und 20 der Verordnung (EU) 2024/1781 des Europäischen Parlaments und des Rates unterzogen, führt dies nicht unbedingt zu einer wesentlichen Änderung des Produkts, wenn z. B. die Zweckbestimmung und die Funktionen nicht geändert werden und das Risikoniveau gleich bleibt. Die Aufrüstung eines Produkts mit digitalen Elementen durch den Hersteller könnte jedoch zu Änderungen in der Konzeption und Entwicklung des Produkts führen und sich daher auf seine Zweckbestimmung und die Konformität mit den in dieser Verordnung festgelegten Anforderungen auswirken.“ Dies steht im Einklang mit Abschnitt 2.1 des Blue Guide, in dem daran erinnert wird: „Ein Produkt, an dem nach seiner Inbetriebnahme wesentliche Änderungen oder Überarbeitungen vorgenommen wurden, kann als neues Produkt angesehen werden, wenn i) seine ursprüngliche Leistung, Verwendung oder Bauart geändert wurde, ohne dass dies bei der ursprünglichen Risikobewertung vorgesehen war, ii) sich die Art der Gefahr geändert oder das Risikoniveau im Vergleich zu den einschlägigen Harmonisierungsrechtsvorschriften der Union erhöht hat, iii) das Produkt zur Verfügung gestellt wird (oder in Betrieb genommen wird, wenn die Inbetriebnahme ebenfalls in den Anwendungsbereich der geltenden Rechtsvorschriften fällt). Dies ist von Fall zu Fall und insbesondere vor dem Hintergrund des Ziels der Rechtsvorschriften und der Art der Produkte im Anwendungsbereich der betreffenden Rechtsvorschrift zu entscheiden“.

Überholungs-, Wartungs- oder Reparaturvorgänge, die zu physischen Änderungen an bereits in Verkehr gebrachten Produkten mit digitalen Elementen führen, kommen nicht zwangsläufig einer wesentlichen Änderung gleich. Daher sollte eine Einzelfallprüfung durchgeführt werden, um festzustellen, ob sich eine solche physische Änderung auf die Konformität des Produkts mit digitalen Elementen mit den grundlegenden Anforderungen in Anhang I Teil I auswirkt oder zu einer Änderung der von der Bewertung der Cybersicherheitsrisiken erfassten Zweckbestimmung des Produkts führt.

Der Austausch defekter oder verschlissener Teile durch leistungsfähigere Teile (z. B. aufgrund des technischen Fortschritts oder weil das alte Teil nicht mehr hergestellt wird) löst für sich genommen keine wesentliche Änderung des reparierten Produkts mit digitalen Elementen aus. Dies ist nur dann der Fall, wenn die Leistungsänderung oder die Funktionsweise des reparierten Produkts mit digitalen Elementen (i) sich auf dessen Konformität mit den grundlegenden Anforderungen auswirkt oder (ii) zu einer Änderung der Zweckbestimmung führt, die von der Risikobewertung nicht erfasst war.

Beispiel 35: Der Hersteller eines Computerservers führt eine Reparatur durch, bei der er einen defekten Arbeitsspeicher (RAM) gegen einen neuen, leistungsfähigeren austauscht. Die Konformität des Servers mit den grundlegenden Anforderungen wird nicht beeinträchtigt. Der Server arbeitet leistungsfähiger, seine neue Leistung bleibt jedoch innerhalb der in der Bewertung der Cybersicherheitsrisiken berücksichtigten bestimmungsgemäßen Verwendung des Servers. Der Computerserver gilt nicht als wesentlich geändert.

Softwareentwicklung ist ihrem Wesen nach iterativ; bereits in Verkehr gebrachte Softwareprodukte mit digitalen Elementen werden häufig und fortlaufend aktualisiert. In diesem Zusammenhang ist es sinnvoll, weitere Orientierungshilfe dazu zu geben, wann Software als wesentlich geändert anzusehen ist. Diese Orientierungshilfe soll insbesondere Herstellern von Softwareprodukten mit digitalen Elementen, die Änderungen an ihren eigenen Produkten vornehmen, helfen festzustellen, ob diese Änderungen eine wesentliche Änderung darstellen.

Nach Erwägungsgrund 39 ist ein Produkt mit digitalen Elementen wesentlich geändert, wenn eine Änderung das Niveau des Cybersicherheitsrisikos verändert und dieses veränderte oder zusätzliche Risiko vom Hersteller in seiner Risikobewertung und folglich bei seiner Umsetzung der grundlegenden Anforderungen nicht berücksichtigt wurde. Ein Hersteller sollte daher im Einzelfall beurteilen, ob eine Softwareaktualisierung neue oder erhöhte Cybersicherheitsrisiken mit sich bringt und ob diese Risiken bereits in seiner Risikobewertung behandelt wurden.

Führt ein Hersteller in ein Produkt mit digitalen Elementen neue Funktionen ein, die zu einer Änderung der Zweckbestimmung des Produkts insgesamt führen, ist es wahrscheinlich, dass der Hersteller diese Änderungen in seiner Risikobewertung nicht berücksichtigt hat. Unter solchen Umständen wäre die Änderung in der Regel als wesentliche Änderung einzustufen.

Beispiel 40: Ein Hersteller bringt ein Dashboard in Verkehr, das Daten von Maschinen erfasst und Trends und Warnmeldungen anzeigt, ohne diese Maschinen steuern zu können. Anschließend entwickelt der Hersteller eine neue Version dieses Dashboards und führt Funktionen ein, mit denen es die Maschinen steuern kann, unter anderem durch Anpassung von Betriebsparametern und den Neustart von Maschinen nach Störungszuständen. Infolge dieser Änderungen hat sich die Zweckbestimmung des Dashboards über das hinaus entwickelt, was in der Risikobewertung vorgesehen war: Aus einem Werkzeug für das Lagebewusstsein ist ein Produkt mit digitalen Elementen geworden, das dazu bestimmt ist, die operative Steuerung anderer Geräte auszuüben. Das Dashboard wurde daher wesentlich geändert.

Beispiel 41: Ein Hersteller bringt eine Softwareanwendung für Verbraucher in Verkehr, die dazu bestimmt ist, personenbezogene Daten wie E-Mails, Nachrichten oder Dokumente zu organisieren und anzuzeigen und grundlegende Such- und Filterfunktionen zu unterstützen. Anschließend führt der Hersteller eine Aktualisierung ein, die es der Anwendung ermöglicht, Nutzerinhalte automatisch zu analysieren, um Verhaltensprofile zu erstellen und ohne Eingreifen des Nutzers automatisierte Entscheidungen zu treffen, die sich auf die Priorisierung, Unterdrückung oder Empfehlung von Inhalten auswirken. Infolge dieser Änderung wandelt sich die Zweckbestimmung der Software von einem vom Nutzer gesteuerten Werkzeug für die Informationsverwaltung zu einem System für automatisierte Entscheidungen, das in der Risikobewertung nicht vorgesehen war. Die Anwendung wurde daher wesentlich geändert.

Gleichzeitig ist es jedoch möglich, dass ein Hersteller schrittweise neue Funktionen einführt, die bereits in seiner Risikobewertung enthalten sind oder die für sich genommen das Cybersicherheitsrisikoprofil des Produkts mit digitalen Elementen nicht verändern. Dies kann beispielsweise der Fall sein, wenn der Hersteller die Entwicklung dieser Funktionen vorhergesehen, die damit verbundenen Risiken bereits beschrieben und bewertet und geeignete Maßnahmen zur Risikominderung umgesetzt hat, um die fortdauernde Einhaltung der grundlegenden Anforderungen sicherzustellen. Dies kann auch der Fall sein, wenn die neuen Funktionen keine Änderungen umsetzen, die neue oder erhöhte Risiken mit sich bringen. Aktualisierungen dieser Art sollten daher nicht als wesentliche Änderungen angesehen werden, da sie das Cybersicherheitsrisiko nicht erhöhen und folglich die Umsetzung der grundlegenden Anforderungen nicht verändern.

Beispiel 42: Eine Messaging-Anwendung wird zunächst mit einer auf Einzelnachrichten (one-to-one) beschränkten Funktion veröffentlicht. Die Risikobewertung des Herstellers umfasst die spätere Einführung von Gruppennachrichten, einschließlich beispielsweise der erhöhten Komplexität der Nachrichtenweiterleitung. In einer späteren Aktualisierung fügt der Hersteller eine Gruppenchat-Funktion zusammen mit Administratorsteuerungen und Moderationswerkzeugen hinzu, die bereits im ursprünglichen Entwurf vorgesehen und bewertet waren. Die Aktualisierung setzt Funktionen um, die in den Rahmen der ursprünglichen Zweckbestimmung und Risikobewertung fallen. Die Messaging-Anwendung wurde daher nicht wesentlich geändert.

Beispiel 43: Ein Produktionsüberwachungssystem wird mit aktivierten, rein lesenden Dashboards in Verkehr gebracht, während Funktionen zur automatisierten Steuerung in der Systemarchitektur vorhanden, aber deaktiviert sind. Die Risikobewertung des Herstellers umfasst ausdrücklich die künftige Aktivierung automatisierter Regelkreise, einschließlich der mit geschlossenen Regelkreisen verbundenen Cybersicherheitsrisiken, sowie Schutzvorkehrungen wie Mechanismen zur Übersteuerung durch den Bediener und ausfallsichere Zustände. In einer späteren Aktualisierung aktiviert der Hersteller die Funktionen zur automatisierten Steuerung und aktiviert die Schutzvorkehrungen wie ursprünglich bewertet. Das Produktionsüberwachungssystem wurde daher nicht wesentlich geändert.

Umgekehrt können selbst begrenzte oder scheinbar geringfügige neue Funktionen erhebliche Cybersicherheitsrisiken mit sich bringen, die sich auf die Einhaltung der grundlegenden Anforderungen auswirken. Die Beurteilung einer wesentlichen Änderung sollte daher nicht auf dem Umfang oder der Komplexität der Änderung beruhen, sondern auf deren möglichen nachteiligen Auswirkungen auf das Cybersicherheitsrisikoprofil des Produkts mit digitalen Elementen und folglich auf die Umsetzung der grundlegenden Anforderungen.

Beispiel 44: Ein Hersteller führt eine Aktualisierung einer Softwareanwendung ein, mit der eine „Angemeldet bleiben“-Funktion bzw. eine dauerhafte Anmeldung hinzugefügt wird, bei der zur Verbesserung des Nutzerkomforts Authentifizierungstoken lokal gespeichert werden. Obwohl die Funktion in ihrem Umfang begrenzt ist, bringt sie neue Risiken im Zusammenhang mit Token-Diebstahl, unbefugtem Zugriff und Session-Hijacking mit sich, die in der Risikobewertung nicht berücksichtigt wurden. Die Aktualisierung wirkt sich daher auf die Einhaltung der grundlegenden Anforderungen aus. Die Softwareanwendung wurde wesentlich geändert.

Beispiel 45: Ein Hersteller fügt einem bestehenden Softwareprodukt mit digitalen Elementen eine neue Protokollierungs- und Diagnosefunktion hinzu, mit der detaillierte Systemprotokolle zur Fehlerbehebung exportiert werden können. Obwohl die Funktion geringfügig erscheint, führt sie dazu, dass sensible Betriebsdaten in unverschlüsseltem Format erfasst und gespeichert werden, wodurch Risiken der Offenlegung von Daten entstehen, die zuvor weder bewertet noch gemindert wurden. Die Änderung kann daher erhebliche Auswirkungen auf das Cybersicherheitsrisikoprofil des Produkts mit digitalen Elementen haben. Das Softwareprodukt mit digitalen Elementen wurde wesentlich geändert.

Im Einklang mit Erwägungsgrund 39 des CRA sind Sicherheitsaktualisierungen in der Regel nicht als wesentliche Änderungen anzusehen, da ihr Hauptzweck darin besteht, das Niveau des mit dem Produkt mit digitalen Elementen verbundenen Cybersicherheitsrisikos zu verringern. Eine Sicherheitsaktualisierung, die die Zweckbestimmung dieses Produkts nicht verändert und keine neuen Cybersicherheitsrisiken mit sich bringt, sollte daher nicht als wesentliche Änderung betrachtet werden, selbst wenn diese Aktualisierung erhebliche technische Änderungen mit sich bringen kann. Dies schließt Fälle ein, in denen bestimmte Funktionen ausschließlich zu dem Zweck geändert oder eingeschränkt werden, festgestellte Schwachstellen zu mindern und die fortdauernde Einhaltung der grundlegenden Anforderungen sicherzustellen.

Beispiel 46: Ein Hersteller spielt eine Sicherheitsaktualisierung ein, um eine Schwachstelle im Code eines Produkts mit digitalen Elementen zu beheben, indem er einen Fehler bei der Eingabevalidierung korrigiert, der zu einem Pufferüberlauf führen könnte, oder indem er einen Logikfehler behebt, der durch unzureichende Validierung von Sitzungstoken eine Umgehung der Authentifizierung ermöglicht. Die Aktualisierung ändert die interne Implementierung der Software, ohne die Zweckbestimmung dieses Produkts zu beeinträchtigen oder eine neue Exposition zu schaffen. Eine solche Aktualisierung dient ausschließlich der Verringerung des Cybersicherheitsrisikos. Die Sicherheitsaktualisierung sollte nicht als wesentliche Änderung betrachtet werden.

Beispiel 47: Ein Hersteller führt eine Sicherheitsaktualisierung ein, die bestehende Sicherheitskonfigurationen verschärft, etwa durch strengere Firewall-Regeln, die Deaktivierung ungenutzter Netzwerkports, die Änderung der Standardrichtlinien für Administratorpasswörter oder die verpflichtende Einführung der Multi-Faktor-Authentifizierung, sofern diese Funktion bereits verfügbar oder vorgesehen war. Auch wenn sich die Aktualisierung darauf auswirken kann, wie Nutzer das Produkt mit digitalen Elementen konfigurieren oder darauf zugreifen, verändert sie dessen Zweckbestimmung nicht und dient ausschließlich der Verbesserung seines Sicherheitsniveaus. Die Sicherheitsaktualisierung sollte nicht als wesentliche Änderung betrachtet werden.

Beispiel 48: Ein Hersteller bringt ein Softwareprodukt mit digitalen Elementen in Verkehr, das die Kommunikation mithilfe eines konfigurierbaren Verschlüsselungsframeworks sichert, das mehrere kryptografische Algorithmen und Schlüssellängen unterstützt, wie in der technischen Dokumentation und der Risikobewertung des Produkts beschrieben. Die Risikobewertung umfasst alle im Produkt mit digitalen Elementen bereitgestellten kryptografischen Optionen und sieht die künftige Abkündigung bestimmter Algorithmen vor. Die Risikobewertung umfasst zudem Maßnahmen zur Risikominderung wie kryptografische Agilität, interne Schlüsselverwaltung und Kompatibilitätstests. Als Reaktion auf neue kryptografische Empfehlungen spielt der Hersteller eine Sicherheitsaktualisierung ein, die einen abgekündigten Algorithmus deaktiviert und eine stärkere, bereits unterstützte Alternative aktiviert, ohne neue externe Abhängigkeiten einzuführen oder Datenflüsse zu verändern. Da die Aktualisierung eine Sicherheitsmaßnahme umsetzt, die im Rahmen des ursprünglichen Entwurfs vorgesehen und bewertet wurde, und keine neuen Cybersicherheitsrisiken mit sich bringt, sollte die Sicherheitsaktualisierung nicht als wesentliche Änderung betrachtet werden.

Im Gegensatz dazu kann eine Sicherheitsaktualisierung ungeachtet ihres Sicherheitsziels als wesentliche Änderung einzustufen sein, wenn die Aktualisierung dazu führt, dass die Zweckbestimmung des Produkts mit digitalen Elementen über das ursprünglich Vorgesehene hinaus geändert wird, oder wenn sie neue oder erhöhte Cybersicherheitsrisiken mit sich bringt. Dies kann beispielsweise der Fall sein, wenn eine Aktualisierung die Grenzen oder die Abhängigkeitsstruktur dieses Produkts in einer in der Risikobewertung nicht vorgesehenen Weise wesentlich verändert, z. B. durch eine wesentliche Veränderung von Datenflüssen oder das Hinzufügen neuer, von außen erreichbarer Schnittstellen.

Beispiel 49: Ein Hersteller bringt ein Softwareprodukt mit digitalen Elementen in Verkehr, das dazu bestimmt ist, auf dem Gerät eines Nutzers gespeicherte Daten lokal zu verschlüsseln, und es Nutzern ermöglicht, Dateien bei Bedarf zu verschlüsseln und zu entschlüsseln. Nach der Entdeckung einer Schwachstelle im Verschlüsselungsablauf spielt der Hersteller eine Sicherheitsaktualisierung ein, die die lokale Verschlüsselungsfunktion entfernt und stattdessen verlangt, dass alle Dateien in einen vom Hersteller betriebenen Fern-Verschlüsselungsdienst hochgeladen, dort gespeichert und von diesem verarbeitet werden. Infolge dieser Änderung führt das Produkt mit digitalen Elementen keine lokale Verschlüsselung mehr durch, wie ursprünglich vorgesehen, sondern fungiert als Dienst für Fernverschlüsselung und Datenverarbeitung. Obwohl die Aktualisierung aus Sicherheitsgründen eingeführt wird, verändert sie die Zweckbestimmung dieses Produkts grundlegend in einer in der Risikobewertung nicht vorgesehenen Weise und ist daher als wesentliche Änderung einzustufen.

Beispiel 50: Ein Hersteller bringt ein Softwareprodukt mit digitalen Elementen in Verkehr, das sich auf ein etabliertes Verschlüsselungsprotokoll und einen intern verwalteten Schlüssellebenszyklus stützt, um die Kommunikation zwischen Komponenten des Produkts mit digitalen Elementen zu sichern. Als Reaktion auf neu festgestellte kryptografische Schwächen führt der Hersteller eine Sicherheitsaktualisierung ein, die den bestehenden Verschlüsselungsmechanismus durch ein anderes Protokoll ersetzt, das die Nutzung eines von einem Dritten betriebenen externen Schlüsselverwaltungsdienstes erfordert. Infolge dieser Änderung werden die Abhängigkeiten und Datenflüsse des Produkts mit digitalen Elementen wesentlich verändert, wodurch neue externe Schnittstellen und eine Abhängigkeit von Diensten Dritter entstehen, die in der Risikobewertung nicht berücksichtigt wurden. Obwohl die Aktualisierung sicherheitsgetrieben ist, bringt sie neue Cybersicherheitsrisiken mit sich und ist daher als wesentliche Änderung einzustufen.

Wie in Randnummer 104 ausgeführt, sollte im Einzelfall beurteilt werden, ob eine Softwareaktualisierung eine wesentliche Änderung darstellt. Bei dieser Beurteilung können die Hersteller – ohne Anspruch auf Vollständigkeit – prüfen, ob die Softwareaktualisierung

a. neue Bedrohungsvektoren einführt, etwa zusätzliche Schnittstellen, Kommunikationskanäle, Ausführungsumgebungen oder externe Abhängigkeiten, über die sich Bedrohungen verwirklichen könnten;

b. neue Angriffsszenarien ermöglicht, darunter beispielsweise neue Wege, auf denen ein unbefugter Zugriff auf das Produkt mit digitalen Elementen oder auf die von ihm verarbeiteten Daten, deren Manipulation, eine Störung oder ein Missbrauch plausibel erfolgen könnte;

c. die Wahrscheinlichkeit zuvor ermittelter Angriffsszenarien verändert, beispielsweise indem sie den zu ihrer Ausnutzung erforderlichen Aufwand oder das erforderliche Fachwissen verringert, die Exposition gegenüber nicht vertrauenswürdigen Akteuren erhöht oder bestehende Schutzvorkehrungen schwächt;

d. die möglichen Auswirkungen zuvor ermittelter Angriffsszenarien verändert, darunter beispielsweise den Umfang der betroffenen Daten oder Funktionen, die Schwere der betrieblichen, sicherheitsbezogenen oder wirtschaftlichen Folgen oder die Fähigkeit, einen Sicherheitsvorfall zu erkennen, einzudämmen oder sich davon zu erholen.

In manchen Fällen führt eine Softwareaktualisierung keine neuen Bedrohungsvektoren ein, ermöglicht keine neuen Angriffsszenarien und verändert die Wahrscheinlichkeit oder die Auswirkungen zuvor ermittelter Angriffsszenarien nicht wesentlich. Dies kann darauf hindeuten, dass die Aktualisierung keine neuen oder erhöhten Cybersicherheitsrisiken mit sich bringt, sofern die in der Risikobewertung zugrunde gelegten Annahmen und Maßnahmen zur Risikominderung gültig und wirksam bleiben. Es ist daher wahrscheinlich, dass die Aktualisierung nicht als wesentliche Änderung einzustufen ist.

Umgekehrt kann eine Softwareaktualisierung neue Bedrohungsvektoren einführen, neue Angriffsszenarien ermöglichen oder die Wahrscheinlichkeit oder die Auswirkungen bestehender Angriffsszenarien wesentlich verändern. In solchen Fällen sollte der Hersteller die Cybersicherheitsrisiken des Produkts mit digitalen Elementen neu bewerten und feststellen, ob die grundlegenden Anforderungen weiterhin erfüllt sind, einschließlich der Frage, ob die Aktualisierung neue oder erhöhte Risiken mit sich bringt, die in der Risikobewertung nicht vorgesehen waren.

Ob eine Softwareaktualisierung als wesentliche Änderung einzustufen ist, ist für die Feststellung von Bedeutung, ob bestimmte Pflichten aus dem CRA gelten, wie in Randnummer 91 dargelegt. Unabhängig von dieser Einstufung bleiben die Hersteller jedoch dafür verantwortlich, die Sicherheit von Softwareaktualisierungen und ihres Produkts mit digitalen Elementen während dessen Unterstützungszeitraums im Einklang mit den Anforderungen an die Behandlung von Schwachstellen gemäß Anhang I Teil II des CRA zu gewährleisten. Darüber hinaus sind die Hersteller unabhängig davon, ob Softwareaktualisierungen als wesentliche Änderungen einzustufen sind oder nicht, verpflichtet, die Risikobewertung und die technische Dokumentation gemäß Artikel 13 Absatz 7 und Artikel 31 Absatz 2 zutreffend, vollständig und fortlaufend auf dem neuesten Stand zu halten.

Eine der grundlegenden Anforderungen in Anhang I Teil I des CRA sieht vor, dass Produkte mit digitalen Elementen auf der Grundlage der Bewertung der Cybersicherheitsrisiken gemäß Artikel 13 Absatz 2 und soweit zutreffend ohne bekannte ausnutzbare Schwachstellen auf dem Markt bereitgestellt werden müssen.

Artikel 3 Nummer 41 bestimmt den Begriff „ausnutzbare Schwachstelle“ als „eine Schwachstelle, die von einem unbefugten Dritten unter praktischen Betriebsbedingungen wirksam genutzt werden kann“. Nicht alle Schwachstellen sind unter praktischen Betriebsbedingungen ausnutzbar, und manche Schwachstellen können nur unter theoretischen Bedingungen (z. B. in einem Labor oder in einer Simulation) und/oder nicht unter Bedingungen ausgenutzt werden, die in der Betriebsumgebung eines Produkts mit digitalen Elementen auftreten würden.

Der CRA verpflichtet die Hersteller, über geeignete Konzepte und Verfahren zur Behandlung und Behebung potenzieller Schwachstellen zu verfügen, die aus internen oder externen Quellen gemeldet werden (Artikel 13 Absatz 8). Er legt jedoch nicht ausdrücklich fest, wann eine ausnutzbare Schwachstelle als dem Hersteller bekannt anzusehen ist und damit zum Zeitpunkt des Inverkehrbringens die Pflicht zur Erfüllung dieser grundlegenden Anforderung auslöst.

Eine Schwachstelle sollte als bekannt gelten, wenn sie in einschlägigen öffentlich zugänglichen Schwachstellendatenbanken aufgeführt ist, etwa in der durch Artikel 12 Absatz 2 der Richtlinie (EU) 2022/2555 eingerichteten europäischen Schwachstellendatenbank oder in anderen bedeutenden Schwachstellendatenbanken.

Darüber hinaus kann eine Schwachstelle auch dann bekannt sein, wenn der Hersteller über nicht öffentliche Informationen auf sie aufmerksam gemacht wurde, beispielsweise durch eine koordinierte Offenlegung durch einen Sicherheitsforscher oder durch eigene interne Tests und Analysen des Herstellers, einschließlich beispielsweise beim Einsatz KI-gestützter Dienste. Ebenso kann eine Schwachstelle bekannt sein, wenn in verlässlichen Medien, einschließlich spezialisierter Cybersicherheitspublikationen oder allgemeiner Massenmedien, öffentlich und an prominenter Stelle über sie berichtet wurde.

Allerdings bedeutet der bloße Umstand, dass eine Schwachstelle gemeldet oder gefunden wird, für sich genommen nicht, dass sie in der Praxis ausnutzbar ist oder auf das betreffende Produkt mit digitalen Elementen zutrifft. Der Hersteller muss ihr nachgehen und die Richtigkeit dieser Informationen sowie ihre Relevanz für sein eigenes Produkt mit digitalen Elementen bestätigen. Dementsprechend kann zwischen der ersten Meldung der Schwachstelle und ihrer Bestätigung ein begrenzter Zeitraum vergehen. Wie in Abschnitt 9.1 Meldepflichten dargelegt, sollte der Schwerpunkt auf raschem Handeln zur Untersuchung und Reaktion liegen.

Ferner gilt die Pflicht der Hersteller zur Erfüllung der grundlegenden Anforderungen in Anhang I Teil I gemäß Artikel 13 Absatz 1 zum Zeitpunkt des Inverkehrbringens. In der Praxis kann es vorkommen, dass in den letzten Phasen des Entwicklungslebenszyklus des Produkts mit digitalen Elementen neue potenziell ausnutzbare Schwachstellen entdeckt werden, auch kurz bevor es in die Vertriebskette gelangt (und damit in Verkehr gebracht wird).

Da die Pflicht, Produkte mit digitalen Elementen ohne bekannte ausnutzbare Schwachstellen in Verkehr zu bringen, eine risikobasierte Pflicht ist, obliegt es dem Hersteller, auf der Grundlage der Bewertung der Cybersicherheitsrisiken zu bestimmen, ob das Produkt mit digitalen Elementen im Einklang mit dem CRA sicher in Verkehr gebracht werden kann. Alternativ kann der Hersteller feststellen, dass eine möglicherweise bekannt gewordene neue Schwachstelle behoben werden muss, bevor das Produkt mit digitalen Elementen in Verkehr gebracht werden kann. Bei dieser Feststellung sollten die Hersteller den Schweregrad, die Ausnutzbarkeit und die möglichen Auswirkungen der Schwachstelle sowie die Risiken berücksichtigen, die sich für das Produkt mit digitalen Elementen selbst ergeben, sobald es in Gebrauch ist. Sie können auch die Risiken einer Verschiebung der Veröffentlichung des Produkts bis zur Behebung der Schwachstelle berücksichtigen, beispielsweise weil die neue Version auch andere ausnutzbare Schwachstellen behebt oder für den fortgesetzten Betrieb kritischer Systeme erforderlich ist. In jedem Fall unterliegt der Hersteller, sobald ein Produkt mit digitalen Elementen in Verkehr gebracht wurde, weiterhin der Pflicht, Schwachstellen wirksam und im Einklang mit den in Anhang I Teil II festgelegten Anforderungen an die Behandlung von Schwachstellen zu behandeln.

Wie in Abschnitt 2.1 Inverkehrbringen in Erinnerung gerufen, gilt der CRA für Produkte mit digitalen Elementen, die erstmals im Rahmen einer Geschäftstätigkeit auf dem EU-Markt bereitgestellt werden (d. h. „in Verkehr gebracht“ werden), sowie für jeden späteren Vorgang, der eine Bereitstellung desselben Produkts mit digitalen Elementen auf dem Markt darstellt. Der Blue Guide (Abschnitt 2.2) stellt klar, dass unter „Geschäftstätigkeit“ die entgeltliche oder unentgeltliche Bereitstellung von Waren in einem geschäftsbezogenen Zusammenhang zu verstehen ist und dies nur im Einzelfall beurteilt werden kann, wobei unter anderem die Regelmäßigkeit der Lieferungen, die Merkmale des Produkts und die Absichten des Lieferanten zu berücksichtigen sind.

Eine Lieferung im Rahmen einer Geschäftstätigkeit ist durch eine Reihe von Umständen gekennzeichnet, die im Blue Guide ausführlich dokumentiert sind und in Erwägungsgrund 15 des CRA in Erinnerung gerufen werden. Dazu kann gehören, dass unmittelbar ein Preis verlangt wird, aber auch, „dass für technische Unterstützungsleistungen ein Entgelt verlangt wird, das nicht nur der Deckung der tatsächlichen Kosten dient, dass eine Gewinnerzielungsabsicht besteht, beispielsweise durch Bereitstellung einer Softwareplattform, über die der Hersteller andere Dienste gewinnorientiert anbietet, oder dass als Bedingung für die Nutzung die Verarbeitung personenbezogener Daten zu anderen Zwecken als der alleinigen Verbesserung der Sicherheit, Kompatibilität oder Interoperabilität der Software verlangt wird oder dass Spenden angenommen werden, die die mit der Konzeption, Entwicklung und Bereitstellung eines Produkts mit digitalen Elementen verbundenen Kosten übersteigen“ (Erwägungsgrund 15)¹¹.

Der CRA erkennt jedoch die Besonderheiten der unterschiedlichen Arten der Entwicklung und Veröffentlichung „freier und quelloffener Software“ (FOSS) an und bietet einige Orientierungshilfen, um festzustellen, ob eine FOSS ein Produkt mit digitalen Elementen ist, das im Sinne des CRA in Verkehr gebracht (d. h. im Rahmen einer Geschäftstätigkeit bereitgestellt) wird. Wie in Erwägungsgrund 18 erläutert, sollten „[d]ie bloßen Umstände, unter denen das Produkt mit digitalen Elementen entwickelt wurde, oder die Art und Weise, wie die Entwicklung finanziert wurde, […] bei der Bestimmung des kommerziellen oder nichtkommerziellen Charakters der entsprechenden Tätigkeit nicht berücksichtigt werden“. Genauer gesagt sollte „die Bereitstellung von Produkten mit digitalen Elementen, die als freie und quelloffene Software eingestuft und von ihren Herstellern nicht zu Geld gemacht werden, nicht als Geschäftstätigkeit betrachtet werden, damit sichergestellt ist, dass klar zwischen der Entwicklungs- und der Lieferphase unterschieden wird“.

Es ist daher sinnvoll, (i) zu klären, was FOSS ist; (ii) wann davon auszugehen ist, dass sie der Verantwortung einer natürlichen oder juristischen Person unterliegt; und (iii) Beispiele zu geben, die den Interessenträgern helfen zu verstehen, wann der Vertrieb von FOSS ein Inverkehrbringen darstellt. Wird FOSS nicht in Verkehr gebracht, so fällt sie nicht in den Anwendungsbereich des CRA, es sei denn, die sie veröffentlichende Einrichtung ist eine juristische Person, die die Begriffsbestimmung des „Verwalters quelloffener Software“ (im Folgenden „Verwalter“) nach Artikel 3 Nummer 14 erfüllt. In diesem Fall unterliegt sie ausschließlich den in Artikel 24 festgelegten Pflichten.

Artikel 3 Nummer 48 definiert FOSS als „eine Software, deren Quellcode offen geteilt wird und die im Rahmen einer kostenlosen Open-Source-Lizenz zur Verfügung gestellt wird, die alle Rechte vorsieht, um sie frei zugänglich, nutzbar, veränderbar und weiterverteilbar zu machen“. Auch wenn in diesen Leitlinien keine bestimmten freien und quelloffenen Lizenzen benannt werden, die mit der Begriffsbestimmung in Artikel 3 Nummer 48 vereinbar sind, ergibt sich aus dem Wortlaut dieser Bestimmung, dass nur Software, die kumulativ zwei Voraussetzungen erfüllt, für die Zwecke des CRA als FOSS gilt: (i) Die Software muss im Rahmen einer kostenlosen Open-Source-Lizenz zur Verfügung gestellt werden, die sämtliche in Artikel 3 Nummer 48 genannten Rechte gewährt; und (ii) ihr Quellcode muss offen geteilt werden.

Das Erfordernis, dass die Lizenz vorsehen muss, dass die Software „frei zugänglich, nutzbar, veränderbar und weiterverteilbar“ ist, spiegelt das herkömmliche Verständnis von FOSS wider, wonach die Nutzer in der Lage sein müssen, auf den Quellcode zuzugreifen, ihn ohne unangemessene Einschränkungen zu nutzen, ihn zu verändern und ursprüngliche oder veränderte Versionen weiterzuverteilen. Der Zugang zum Quellcode ist daher eine notwendige Voraussetzung für die Ausübung der übrigen Rechte: Ohne Zugang zum Quellcode ist es praktisch nicht möglich, die Software zu verändern oder sinnvoll weiterzuverwenden.

Artikel 3 Nummer 48 geht jedoch über eine bloße Bezugnahme auf die Lizenzbedingungen hinaus, da er ausdrücklich verlangt, dass der Quellcode „offen geteilt wird“. Der Begriff „offen geteilt“ weist darauf hin, dass der Quellcode öffentlich zugänglich gemacht werden muss (entweder „upstream“ oder „downstream“) und nicht lediglich auf eingeschränkter oder bedingter Grundlage bereitgestellt werden darf. Dementsprechend ist Software, die unter einer freien und quelloffenen Lizenz vertrieben wird, deren Quellcode aber nur mit zahlenden Kunden oder einem begrenzten Kreis von Nutzern geteilt wird (oder geteilt werden darf), nicht als FOSS im Sinne von Artikel 3 Nummer 48 anzusehen. Für die Zwecke des CRA sollte daher nur Software, deren Quellcode öffentlich zugänglich ist und die unter einer kostenlosen Open-Source-Lizenz lizenziert ist, die sämtliche in Artikel 3 Nummer 48 genannten Rechte gewährt, als FOSS gelten.

Fn. 11 Es sei auch daran erinnert, dass Produkte mit digitalen Elementen zwar häufig (auch) über die Verarbeitung personenbezogener Daten zu Geld gemacht werden, der Schutz personenbezogener Daten jedoch ein Grundrecht ist und personenbezogene Daten daher nicht als Ware betrachtet werden können, wie in Erwägungsgrund 24 der Richtlinie 2019/770 des Europäischen Parlaments und des Rates vom 20. Mai 2019 über bestimmte vertragsrechtliche Aspekte der Bereitstellung digitaler Inhalte und digitaler Dienstleistungen, ABl. L 136 vom 22.5.2019, S. 1–27, ELI: http://data.europa.eu/eli/dir/2019/770/oj , ausgeführt.

Der CRA weist Wirtschaftsakteuren, die Produkte mit digitalen Elementen auf dem EU-Markt liefern, zentrale Verantwortlichkeiten zu. Er definiert den Hersteller als die natürliche oder juristische Person, die ein Produkt mit digitalen Elementen unter ihrem Namen oder ihrer Marke liefert und dies im Rahmen einer Geschäftstätigkeit tut (und es damit in Verkehr bringt). Ebenso ist ein Einführer die in der EU niedergelassene natürliche oder juristische Person, die das Produkt mit digitalen Elementen einer außerhalb der EU niedergelassenen Person liefert und dies im Rahmen einer Geschäftstätigkeit tut (und es damit in Verkehr bringt). Die Pflichten der Verwalter gelten für die juristische Person, die eine für kommerzielle Tätigkeiten bestimmte FOSS liefert¹², sie aber nicht im Sinne des CRA in Verkehr bringt.

Um festzustellen, ob eine natürliche oder juristische Person FOSS auf dem EU-Markt in Verkehr bringt, muss daher zunächst geklärt werden, ob diese natürliche oder juristische Person die FOSS tatsächlich liefert. Um die nach dem CRA anwendbaren Pflichten korrekt zu bestimmen, ist es unerlässlich festzustellen, ob die natürliche oder juristische Person tatsächlich die Handlung der Lieferung einer FOSS vornimmt. Wie in Erwägungsgrund 18 in Erinnerung gerufen, gilt der CRA nämlich nicht für natürliche oder juristische Personen, die mit Quellcode zu Produkten mit digitalen Elementen beitragen, die als freie und quelloffene Software eingestuft sind und nicht ihrer Verantwortung unterliegen.

Angesichts der Besonderheiten der Entwicklung von FOSS, an der häufig mehrere Beitragende beteiligt sind und die durch dezentrale Kooperationsmodelle und eine Trennung zwischen Beitrag und Entscheidungsfindung geprägt ist, ist es sinnvoll klarzustellen, dass FOSS als „der Verantwortung“ derjenigen natürlichen oder juristischen Personen unterliegend gilt, die sie veröffentlichen und die maßgebliche Kontrolle über ihre Entwicklung, ihre Releases und die Entscheidungen über ihren Vertrieb ausüben (häufig als „Maintainer“ bezeichnet). Personen, die Quellcode beitragen, aber nicht über Releases, Roadmaps oder Governance-Entscheidungen bestimmen, gelten als „Beitragende“ (Contributors); in solchen Fällen unterliegt die FOSS nicht ihrer Verantwortung, obwohl sie Code dazu beigetragen haben. Das bloße Bestehen technischer Berechtigungen wie Commit-Rechte reicht nicht aus, um zu begründen, dass die FOSS der Verantwortung dieser Person unterliegt; die Verantwortung liegt bei denjenigen, die die FOSS veröffentlichen und kontrollieren.

Beispiel 13: Ein einzelner Entwickler oder ein Beschäftigter eines Unternehmens reicht bei einem FOSS-Projekt einen „Pull“- oder „Merge“-Request ein, der einen Sicherheitspatch oder eine neue Funktion enthält. Die Maintainer des Projekts prüfen den Code, nehmen ihn an und führen ihn in das Haupt-Repository zusammen und nehmen ihn anschließend in ein neues Release auf. In diesem Szenario ist die Person, die den Pull-Request eingereicht hat, ein „Beitragender“ und unterliegt nicht dem CRA. Obwohl diese Person Quellcode beigetragen hat, übt sie keine maßgebliche Kontrolle über die Entwicklung, die Releases oder die Entscheidungen über den Vertrieb aus.

Fn. 12 Dies ist eine notwendige, aber keine hinreichende Bedingung dafür, dass eine juristische Person als Verwalter quelloffener Software gilt, da die Begriffsbestimmung in Artikel 3 Nummer 14 weitere Bedingungen dafür festlegt, dass eine juristische Person als Verwalter gilt.

Wie bereits in Abschnitt 3.1 Feststellung, ob freie und quelloffene Software der eigenen Verantwortung unterliegt, erwähnt, stellt der CRA klar, dass er nicht „für natürliche oder juristische Personen, die mit Quellcode zu Produkten mit digitalen Elementen beitragen, die als freie und quelloffene Software eingestuft sind und nicht ihrer Verantwortung unterliegen“, gilt (Erwägungsgrund 18).

Hersteller von Produkten mit digitalen Elementen, die FOSS-Komponenten in ihre eigenen Produkte mit digitalen Elementen integrieren, werden auch nicht für die individuelle Konformität dieser Komponenten mit dem CRA verantwortlich, selbst wenn die Hersteller Quellcode zu deren Wartung beitragen.

Ebenso hat der bloße Umstand, dass Hersteller FOSS-Komponenten in ihre eigenen (monetarisierten) Produkte mit digitalen Elementen integrieren, keine Auswirkungen auf den Status dieser FOSS-Komponente nach dem CRA. Maintainer von FOSS-Komponenten, die nicht in Verkehr gebracht werden, haben keine Pflichten gegenüber anderen Einrichtungen, die solche Komponenten in ihre Produkte mit digitalen Elementen integrieren. Ob der CRA für eine bestimmte FOSS-Komponente gilt, hängt allein davon ab, ob die natürliche oder juristische Person, die sie veröffentlicht, sie in Verkehr bringt.

Dennoch müssen Hersteller von Produkten mit digitalen Elementen, die FOSS-Komponenten integrieren, den CRA für ihre eigenen Produkte mit digitalen Elementen einhalten. Sie haben zudem gemäß Artikel 13 Absatz 5 eine Sorgfaltspflicht in Bezug auf die FOSS-Komponenten, die sie integrieren. Darüber hinaus müssen sie gemäß Artikel 13 Absatz 6 Schwachstellen in integrierten Komponenten melden und Sicherheitskorrekturen teilen. Weitere Hinweise zu diesem Thema siehe Abschnitt 9.2.1 Upstream-Meldung und Weitergabe von Sicherheitskorrekturen.