Antwort:

Die Klassifizierung der Open Source-Komponente führt nur dann zu einer entsprechenden Klassifizierung des Endprodukts, wenn es dessen Kernfunktion ausmacht. Denn gem. Art 7 (1) CRA bestimmt die Kernfunktion eines Produkts mit digitalen Elementen, ob das Produkt mit digitalen Elementen einer Klasse von wichtigen Elementen zugeschrieben werden muss (entsprechend gem. Art. 8 (1) CRA für kritische Produktkategorien).

Art 7 (1) CRA besagt:

„Produkte mit digitalen Elementen, die die Kernfunktionen einer in Anhang III aufgeführten Produktkategorie aufweisen, gelten als wichtige Produkte mit digitalen Elementen und unterliegen den in Artikel 32 Absätze 2 und 3 genannten Konformitätsbewertungsverfahren. Die Integration eines Produkts mit digitalen Elementen, das die Kernfunktionen einer in Anhang III aufgeführten Produktkategorie aufweist, führt für sich genommen nicht dazu, dass das Produkt, in das es integriert ist, den Konformitätsbewertungsverfahren gemäß Artikel 32 Absätze 2 und 3 unterliegt.“

Dies ist auch auf die Integration einer Open Source-Komponente anwendbar. Entsprechend kommt es alleine darauf an, was die Kernfunktion des Endprodukts ausmacht.

Wichtig ist zunächst das Verständnis darüber, was genau die 'Kernfunktion' eines Produkts ist. Hierzu liefert die Durchführungsverordnung 2025/2392 der Europäischen Kommission in Anhang I zunächst die Technischen Beschreibungen zu den Klassen I und II des Anhangs III im CRA.

Außerdem enthalten die Erwägungsgründe der Durchführungsverordnung 2025/2392 einige Beispiele zur Einordnung:

„So führt beispielsweise die Integration eines eingebetteten Browsers als Komponente einer Nachrichten-App zur Verwendung mit Smartphones für sich genommen nicht dazu, dass die Nachrichten-App dem Konformitätsbewertungsverfahren unterliegt, das für Produkte mit digitalen Elementen gilt, die die Kernfunktion von ‚eigenständigen und eingebetteten Browsern‘ aufweisen.“ (ErwGr 3, 2025/2392)

Weiterhin wird hier darauf hingewiesen, dass der Hersteller gem. dem CRA auch in diesen Fällen sicherstellen muss, „dass das Produkt mit digitalen Elementen insgesamt die grundlegenden Cybersicherheitsanforderungen erfüllt“ (ErwGr 3, 2025/2392). In dem genannten Beispiel muss der Hersteller der Nachrichten-App nachweisen, dass die App insgesamt CRA-konform ist. Je nach dem Ergebnis der Risikobewertung gem. Art. 13 (2) CRA muss hierfür gegebenenfalls auch der integrierte Browser berücksichtigt werden, auch wenn die Verantwortung aus dem CRA für den Browser grundsätzlich bei dem Hersteller des Browsers liegt. Hier ergibt sich daher ein Unterschied bei der Integration von proprietären Komponenten und Open Source-Komponenten: Bei proprietären Komponenten gibt es eine „Kette von Verantwortlichkeiten“, sodass zwar der Hersteller die Gesamtverantwortung für das Endprodukt trägt, er aber nur die Anforderungen für seine Kernfunktion selbst erfüllen muss. Im Übrigen obliegt die Erfüllung der CRA-Pflichten den Zulieferern der proprietären Komponenten. Bei der Integration von Open Source-Komponenten kann der Hersteller hingegen nicht einfach auf eine Konformitätserklärung des Open Source-Projekts zugreifen, sondern muss sicherstellen, dass diese Komponenten die Cybersicherheit seiner Produkte mit digitalen Elementen nicht beeinträchtigen (so auch die FAQ der Kommission, Kapitel 4.4). Zu den Besonderheiten der Integration von FOSS in ein Produkt siehe OSADL FAQ „Welche Pflichten müssen erfüllt werden, wenn FOSS-Komponenten in ein Produkt integriert werden, das in den Anwendungsbereich des CRA fällt?“

Weiterhin stellt die Durchführungsverordnung 2025/2392 klar, dass auch dann, wenn ein Produkt mit digitalen Elementen andere oder zusätzliche Nebenfunktionen enthält, als diejenigen, die in der Technischen Beschreibung des Anhang I, 2025/2392 aufgeführt sind, dies nicht zwangsweise darin resultiert, dass das Produkt mit digitalen Elementen nicht die Kernfunktion einer der in Anhang III oder IV des CRA aufgeführten Produktklassen aufweist. Es ist also nicht möglich, sich der Klassifizierung als wichtiges oder kritisches Produkt dadurch zu entziehen, dass eine Nebenfunktion hinzugefügt wird. Als Beispiel nennt ErwGr 4, 2025/2392 hierfür:

„Beispielsweise umfassen Produkte mit digitalen Elementen, die die Kernfunktion von ‚Betriebssystemen‘ aufweisen, häufig Software für Nebenfunktionen, die nicht in der technischen Beschreibung dieser Produktkategorie enthalten sind, wie z.B. Rechner oder einfache Grafikprogramme. Produkte mit digitalen Elementen enthalten häufig auch Komponenten, die die Funktion eines anderen wichtigen oder kritischen Produkts mit digitalen Elementen aufweisen, wie z.B. ein Betriebssystem mit integrierter Browserfunktion oder einen Router mit integrierter Firewall-Funktion. Dies bedeutet jedoch für sich genommen nicht, dass solche Produkte mit digitalen Elementen nicht die Kernfunktion von ‚Betriebssystemen‘ bzw. ‚Routern, Modems für die Internetanbindung und Switches‘ aufweisen.“

Ein Produkt mit digitalen Elementen, das zwar die Funktion einer in den Anhängen III und IV des CRA aufgeführten Produktkategorien aufweist, „dessen Kernfunktionen sich jedoch von der einer solchen Produktkategorie unterscheiden, gilt hingegen nicht als ein Produkt, das der technischen Beschreibung dieser Produktkategorie entspricht.“ (ErwGr 5, 2025/2392)

„So kann beispielsweise eine SOAR-Software (Security Orchestration, Automation and Response) häufig die Funktionen von Produkten mit digitalen Elementen in der Kategorie ‚Systeme für die Verwaltung von Sicherheitsinformationen und -ereignissen (SIEM)‘ erfüllen, d.h. Daten sammeln, analysieren und als umsetzbare Informationen für Sicherheitszwecke darstellen. Da ihre Kernfunktion jedoch eine andere als die eines SIEM ist, entspricht SOAR-Software in der Regel nicht der technischen Beschreibung von ‚Systemen für die Verwaltung von Sicherheitsinformationen und -ereignissen (SIEM)‘. Ein ähnliches Beispiel sind Smartphones, da diese üblicherweise Komponenten enthalten, die die Funktionen mehrerer in den Anhängen III und IV der Verordnung (EU) 2024/2847 aufgeführter Produktkategorien ausüben, wie z.B. ein Betriebssystem oder einen integrierten Passwort-Manager. Da die Kernfunktion eines Smartphones jedoch eine andere als die eines Betriebssystems oder eines Passwort-Managers ist, entspricht es in der Regel nicht der technischen Beschreibung dieser Produktkategorien.“ (ErwGr 5, 2025/2392)

Im Ergebnis ist also alleine auf die Kernfunktion des Endprodukts abzustellen. Die Funktion von eingefügten (Open Source)-Komponenten ist nur dann relevant, wenn diese auch die Kernfunktion des Endprodukts ausmacht.

Beispielszenario zur Frage:

Ein Hersteller einer Maschinensteuerung integriert ein Container-Runtime-System in sein Produkt. Dieses dient dem Ausführen vom Hersteller installierter Container, welche die Hauptfunktionalität des Produktes, nämlich die Steuerung der Maschine, bereitstellen. Alternativ kann der Empfänger der Steuerung eigene Container darauf installieren und ablaufen lassen, um das Gerät zu konfigurieren oder Zusatzfunktionalität zum Produkt hinzu zu fügen.

Bewertung des Szenarios und Hinweis zur Alternative:

Die Technische Beschreibung von 'Container-Runtime-Systemen' ist gem. Anhang I, 2025/2392:

„Container-Runtime-Systeme sind Softwareprodukte mit digitalen Elementen, die die Ausführung und den Lebenszyklus von Containern, die über ein einziges Host-Betriebssystem laufen, als isolierte Prozesse steuern, Ressourcen zuweisen und die Verwaltung und Orchestrierung einzelner Container ermöglichen.“

Vorliegend ist die Kernfunktion eines Container-Runtime-Systems zu verneinen. Die Kernfunktion des Produkts im Beispielszenario ist die Steuerung von Maschinen und nicht die Bereitstellung eines Container-Runtime-Systems. Anders würde die Bewertung dann ausfallen, wenn die Steuerung bestimmungsgemäß zum Management von Containern dienen würde.

Im Falle der Alternative ist die Tatsache, dass der Empfänger eigene Container installieren und ablaufen lassen kann, in der Risikobewertung gem. Art. 13 (2) CRA mit zu betrachten. Dies ergibt sich aus Art. 13 (3) CRA:

„Die Bewertung des Cybersicherheitsrisikos wird während eines gemäß Absatz 8 festzulegenden Unterstützungszeitraums dokumentiert und gegebenenfalls aktualisiert. Diese Bewertung des Cybersicherheitsrisikos umfasst mindestens eine Analyse der Cybersicherheitsrisiken auf der Grundlage der Zweckbestimmung und der vernünftigerweise vorhersehbaren Verwendung des Produkts mit digitalen Elementen, wie der Betriebsumgebung oder der zu schützenden Anlagen, wobei die voraussichtliche Nutzungsdauer des Produkts berücksichtigt wird.”

CRA; Cybersicherheit; Durchführungsverordnung (EU) 2025/2392; FOSS; Endnutzerprodukt; Integration von FOSS; Kernfunktion; Kritisches Produkt mit digitalen Elementen; Open Source-Software; Produkt mit digitalen Elementen; Produktkategorie; Wichtiges Produkt mit digitalen Elementen

Letzte inhaltliche Aktualisierung dieser FAQ: Juni 2026