Von Redaktion codAIx | 20. Juli 2026

Kaum ein Produkt entsteht heute aus einer Hand. Eine proprietäre Anwendung setzt auf Open-Source-Bibliotheken auf, integriert Drittkomponenten und wird als Bundle ausgeliefert. Die naheliegende Frage: Wo endet meine Verantwortung — bei der Installation? Bei der Komponentengrenze? Der CRA antwortet unmissverständlich: Wer das Bundle unter eigenem Namen in Verkehr bringt, verantwortet das Gesamtprodukt einschliesslich aller integrierten Komponenten. Eine echte Grenze gibt es nur gegenüber nicht-kommerzieller Open-Source-Software — und auch dort nur in Form einer abgestuften Sorgfaltspflicht.

Die „Set-up-Grenze“ ist ein Mythos

Die Vorstellung, die Herstellerverantwortung ende mit dem Set-up oder der Installation beim Kunden, hat im CRA keine Grundlage. Die Pflichten knüpfen nicht an die Installation an, sondern an das Inverkehrbringen des Bundles als ein Produkt — und sie umfassen das Produkt vollständig. Erwägungsgrund 34 CRA stellt klar, dass die Pflichten zum Umgang mit Schwachstellen „für Produkte mit digitalen Elementen in ihrer Gesamtheit, einschliesslich aller integrierten Komponenten“ gelten[1]. Es gibt also weder eine Komponentenlücke noch ein Ende bei der Installation; die Verantwortung läuft über den gesamten Unterstützungszeitraum weiter.

Die Sorgfaltspflicht: der Schlüssel bei „proprietär auf Open Source“

Für den häufigsten Fall — eine proprietäre Schicht setzt auf Open-Source-Komponenten auf — ist Art. 13 Abs. 5 CRA die zentrale Norm. Hersteller lassen danach „die gebotene Sorgfalt walten, wenn sie von Dritten bezogene Komponenten in ihre Produkte mit digitalen Elementen integrieren, sodass solche Komponenten die Cybersicherheit des Produkts mit digitalen Elementen nicht beeinträchtigen, auch nicht bei der Integration von freier und quelloffener Software, die nicht im Rahmen einer Geschäftstätigkeit auf dem Markt bereitgestellt wurde“[1]. Der letzte Halbsatz ist entscheidend: Selbst wenn die zugrunde liegende Open-Source-Komponente selbst nicht dem CRA unterliegt, bleibt der integrierende Hersteller verpflichtet, deren Sicherheitswirkung im Gesamtprodukt mit Sorgfalt zu prüfen.

Diese Sorgfaltspflicht ist allerdings keine grenzenlose Prüfpflicht, sondern abgestuft und risikoabhängig. Der von Wiebe herausgegebene Kommentar ordnet sie in den produzentenhaftungsrechtlichen Vertrauensgrundsatz der Arbeitsteilung ein: Dass der Hersteller des Gesamtprodukts vergleichsweise reduziert in die Pflicht genommen wird, entspricht diesem Grundsatz — wer arbeitsteilig produziert, darf bis zu einer gewissen Grenze auf die Sorgfalt der Vorlieferanten vertrauen. Der Umfang der gebotenen Massnahmen steigt dabei mit dem Cybersicherheitsrisiko und der Sicherheitskritikalität der jeweiligen Komponente (Wiebe, § 6 Rn. 19 mit Praxishinweis)[2]. Die Tiefe der Prüfung skaliert also mit dem Risiko der Komponente — von der blossen Sichtung bekannter Schwachstellen bis zu eigenen Sicherheitstests bei kritischen Bausteinen. Wie die Due-Diligence-Pflicht in der Praxis umgesetzt wird — Inventur, Nachweise, Verträge —, zeigen wir im Artikel zu den abgestuften CRA-Pflichten nach Art. 13.

Hinzu kommt eine eigenständige Meldekette. Nach Art. 13 Abs. 6 CRA meldet der Hersteller, sobald er „eine Schwachstelle in einer in das Produkt mit digitalen Elementen integrierten Komponente, einschliesslich einer quelloffenen Komponente, feststellt“, diese „der Person oder Einrichtung, die diese Komponente herstellt oder wartet“, und behebt sie nach Anhang I Teil II[1]. Wiebe betont in seiner Kommentierung, dass ein blosser Verdacht dafür nicht genügt (Wiebe, § 6 Rn. 20)[2]. Diese B2B-Meldekette steht neben der behördlichen Meldepflicht nach Art. 14 (dazu Teil 8 dieser Serie).

Mit der Meldung ist es dabei nicht getan. Entwickelt der integrierende Hersteller selbst eine Softwareänderung, um die Schwachstelle in der Komponente zu beheben, muss er diesen Sicherheitsfix nach Art. 13 Abs. 6 CRA auch mit der Person oder Einrichtung teilen, die die Komponente herstellt oder pflegt[1] — die FAQ der Kommissionsdienststellen bestätigt das ausdrücklich (Ziff. 4.3.6)[4]. Die Kommissions-Guidance konkretisiert in Kapitel 9.2.1, dass der Fix, soweit angemessen, in einem maschinenlesbaren und leicht überprüfbaren Format bereitzustellen ist; bei einer quelloffenen Komponente muss die Weitergabe mit deren Lizenz vereinbar sein — etwa unter derselben Lizenz oder unter einer Lizenz, die dem Maintainer die Weiterverbreitung erlaubt (Rn. 226–227)[5]. Einen Anspruch darauf, dass der Maintainer den Fix übernimmt, hat der Hersteller nicht (Rn. 228)[5]. Umgekehrt begrenzt dieselbe Guidance den Aufwand: Vor einer Meldung sollen Hersteller öffentlich zugängliche Schwachstellendatenbanken, projektspezifische Sicherheits-Advisories und etablierte Issue-Tracker konsultieren, um Doppelmeldungen zu vermeiden; die Meldepflicht entfällt, wenn der Maintainer die Schwachstelle nachweislich bereits kennt oder die Komponente keinen Maintainer mehr hat (Rn. 223 und 225)[5].

Open Source: Wann die Pflicht entfällt — und wann nicht

Wo Open-Source-Software selbst unter den CRA fällt, entscheidet nicht der Entwicklungskontext, sondern die kommerzielle Bereitstellung. Erwägungsgrund 18 CRA stellt klar, dass „nur freie und quelloffene Software, die auf dem Markt bereitgestellt und somit zum Vertrieb oder zur Nutzung im Rahmen einer Geschäftstätigkeit verfügbar gemacht wird, in den Anwendungsbereich dieser Verordnung fallen“ soll[1]. Massgeblich ist die „Bereitstellung auf dem Markt“ im Rahmen einer Geschäftstätigkeit (Art. 3 Nr. 22) sowie der Herstellerbegriff (Art. 3 Nr. 13) und die Definition freier und quelloffener Software (Art. 3 Nr. 48)[1]. Auch der Wiebe-Kommentar stellt darauf ab, ob die Bereitstellung im Rahmen einer Geschäftstätigkeit erfolgt und damit kommerziellen Charakter hat (Wiebe/Jossen, § 4 Rn. 4; vertiefend Wiebe, § 4 Rn. 19)[2].

Daraus folgt die Verantwortungsverteilung bei „proprietär auf Open Source“: Der Anbieter der nicht-kommerziell bereitgestellten Open-Source-Schicht ist selbst kein Hersteller im Sinne des CRA — die Verantwortung für die Integration trägt der proprietäre Bundle-Hersteller aufgrund seiner Sorgfaltspflicht nach Art. 13 Abs. 5 und der Melde- und Weitergabepflichten nach Art. 13 Abs. 6. Sobald die Open-Source-Komponente jedoch ihrerseits entgeltlich bereitgestellt oder anderweitig monetarisiert wird, treffen deren Anbieter grundsätzlich eigene Herstellerpflichten (ErwGr 18 CRA). Ausgenommen sind gemeinnützige Organisationen, die so angelegt sind, dass alle Einnahmen nach Abzug der Kosten gemeinnützigen Zielen zufliessen; erfüllen sie Art. 3 Nr. 14 CRA, gilt das Verwalterregime des Art. 24 (Rn. 66, Beispiel 24)[5].

Zwischen voller Herstellerpflicht und Freistellung steht eine dritte Kategorie: der Verwalter quelloffener Software (Open-Source-Steward) nach Art. 3 Nr. 14 und Art. 24 CRA. Für ihn gilt ein reduziertes Regime: Er muss auf überprüfbare Weise eine Cybersicherheitsstrategie entwickeln und dokumentieren, die auch freiwillige Meldungen nach Art. 15 CRA fördert (Art. 24 Abs. 1). Ausserdem muss er auf Verlangen mit den Marktüberwachungsbehörden zusammenarbeiten und ihnen auf begründetes Verlangen die Unterlagen zur Strategie übermitteln (Art. 24 Abs. 2). Ab dem 11. Dezember 2027 muss er aktiv ausgenutzte Schwachstellen melden, soweit er an der Entwicklung beteiligt ist, und schwerwiegende Sicherheitsvorfälle, soweit von ihm für die Entwicklung bereitgestellte Netz- und Informationssysteme betroffen sind (Art. 24 Abs. 3, Art. 71 Abs. 2 CRA; FAQ Nr. 5.5)[1][4]. Eine CE-Kennzeichnung ist ihm ausdrücklich nicht gestattet: Erwägungsgrund 19 CRA hält fest, dass es ihnen „nicht gestattet sein [sollte], die CE-Kennzeichnung auf Produkten mit digitalen Elementen, deren Entwicklung sie unterstützen, anzubringen“[1]. Der Wiebe-Kommentar beschreibt dieses reduzierte Pflichtenprofil; der Verwalter ist danach kein Wirtschaftsakteur (Wiebe, § 6 Rn. 4; § 4 Rn. 38)[2]. Eine Konformitätsbewertung sieht Art. 24 CRA für ihn nicht vor[1].

Wer als Verwalter in Betracht kommt, bestimmt sich nach Art. 3 Nr. 14 CRA. Erwägungsgrund 19 nennt bestimmte Stiftungen sowie Einrichtungen, die freie und quelloffene Software im wirtschaftlichen Kontext entwickeln und veröffentlichen, einschliesslich gemeinnütziger Einrichtungen; nach der Guidance kann auch ein Unternehmen Verwalter sein, etwa für eine kostenlose Community-Version (Rn. 53, 76)[5]. Praktisch am wichtigsten ist die Rechtsform: Die Definition verlangt eine juristische Person. Natürliche Personen können daher nicht Verwalter quelloffener Software sein — unabhängig davon, ob sie gewerblich oder privat entwickeln (NK-CRA/Schmidt Art. 3 Rn. 88)[6]. Der Sitz der juristischen Person darf innerhalb oder ausserhalb der Union liegen; zu verneinen ist die Verwaltereigenschaft dagegen bei Software, die nicht für kommerzielle Tätigkeiten bestimmt ist oder deren kommerzielle Nutzung die Lizenzbedingungen ausschliessen (NK-CRA/Schmidt Art. 3 Rn. 89)[6].

Ebenfalls in der Kommentierung (NK-CRA/Schmidt Art. 3 Rn. 88) heisst es, wer zugleich Hersteller sei, scheide als Verwalter aus. Diese Aussage ist produktbezogen zu lesen, nicht rechtsträgerbezogen: Verwalter- und Herstellerrolle schliessen einander für ein und dieselbe quelloffene Software aus — schon weil Art. 3 Nr. 14 CRA den Verwalter als „eine juristische Person, bei der es sich nicht um einen Hersteller handelt“, definiert und die Figur gerade den Fall erfassen soll, in dem die betreffende Software nicht auf dem Markt bereitgestellt wird. Für die juristische Person als solche gilt das nicht. Die Kommissions-Guidance stellt das ausdrücklich klar: Wer für eine bestimmte quelloffene Software Hersteller ist, kann für eine andere Verwalter sein, und dieselbe juristische Person kann beide Rollen gleichzeitig innehaben — für unterschiedliche Projekte (Rn. 72–74)[5]. Ausdrücklich genannt wird auch die Konstellation, dass eine Einrichtung eine freie Community-Version und eine monetarisierte Version derselben Software herausgibt: Für die Community-Version ist sie Verwalterin, für die monetarisierte Version Herstellerin (Rn. 76)[5]. Ein Widerspruch zwischen NK-CRA und Guidance besteht damit nicht — die Aussagen liegen auf unterschiedlichen Bezugsebenen. Praktische Folge: Die Rollenzuordnung ist je Projekt und je Version zu prüfen und zu dokumentieren, nicht pauschal für die Organisation.

Unscharf bleibt, wann die Unterstützung „systematisch und nachhaltig“ ist. Erwägungsgrund 19 nennt Beispiele — das Hosting und die Verwaltung von Kollaborationsplattformen, das Hosting von Quellcode sowie die Verwaltung und Steuerung der Entwicklung —, die Guidance konkretisiert sie (Rn. 75, 79); einen festen Schwellenwert gibt es nicht. Nach NK-CRA/Schmidt genügt kurzfristige Unterstützung nicht, vielmehr sind auf Dauer angelegte Mindeststrukturen erforderlich. Hinzu kommt das zweite Kriterium aus Art. 3 Nr. 14 CRA: Der Verwalter muss die Brauchbarkeit der Software sicherstellen. Ob die Schwelle von einer blossen Förderung zu einer systematischen und nachhaltigen Unterstützung überschritten ist, lässt sich nur im Einzelfall anhand des Schwerpunkts der Tätigkeit beurteilen (NK-CRA/Schmidt Art. 3 Rn. 90)[6].

Eine eigene Erleichterung sieht der CRA bei der Konformitätsbewertung vor: Handelt es sich bei einem wichtigen Produkt der Klasse I oder II (Anhang III CRA) um freie und quelloffene Software, darf der Hersteller nach Art. 32 Abs. 5 CRA die interne Kontrolle nach Modul A anwenden — vorausgesetzt, er macht die technische Dokumentation öffentlich zugänglich[1]. Das ist zugleich die einzige Konstellation, in der der CRA eine Veröffentlichung der technischen Dokumentation verlangt; sonst genügt es, sie den Marktüberwachungsbehörden auf Verlangen vorzulegen (FAQ der Kommissionsdienststellen, Ziff. 6.1 und 6.6)[4]. Der eigentliche Vorteil dieses Pfades liegt darin, dass er auch dann offensteht, wenn keine harmonisierten Normen oder gemeinsamen Spezifikationen angewandt werden — bei wichtigen Produkten der Klasse I ist gerade deren Anwendung sonst Voraussetzung für Modul A (NK-CRA/Hessel Art. 32 Rn. 35)[6].

Was eine CE-gekennzeichnete Komponente bedeutet — und was nicht

Ist eine integrierte Komponente bereits CE-gekennzeichnet, erleichtert das den Sorgfaltsnachweis, ersetzt ihn aber nicht. Erwägungsgrund 34 nennt die Kontrolle, „ob die Komponente bereits mit der CE-Kennzeichnung versehen ist“, als ein Element der Sorgfalt[1]. Für den Übergangszeitraum, in dem eine Komponente integriert wurde, bevor der CRA auf deren Hersteller anwendbar war, stellt Erwägungsgrund 35 klar, dass der integrierende Hersteller seiner Sorgfaltspflicht dann „auf andere Weise“ nachkommen muss[1]. Die FAQ der Kommissionsdienststellen bringt dieselbe Linie auf den Punkt: Die Integration CE-gekennzeichneter Komponenten kann bestimmte Pflichten erleichtern, ist vom CRA aber nicht verlangt (Ziff. 4.4.3)[4]. Die CE-Kennzeichnung einer Komponente ist also ein Indiz, kein Freibrief: Die Gesamtkonformität des Bundles — eigene Risikobewertung, Schwachstellenmanagement, eigene CE-Kennzeichnung — bleibt Sache des Bundle-Herstellers.

Wie lange? Unterstützungszeitraum und die „10-Jahre“-Verwechslung

Die Verantwortung endet nicht mit der Auslieferung, sondern läuft über den Unterstützungszeitraum. Nach Art. 13 Abs. 8 UAbs. 3 CRA beträgt dieser mindestens fünf Jahre; ein Regelwert ist das nach der Guidance nicht (Rn. 126)[5]. Beträgt die voraussichtliche Nutzungsdauer weniger als fünf Jahre, entspricht der Unterstützungszeitraum dieser kürzeren Dauer; bei langlebigen Produkten fällt er entsprechend länger aus (Wiebe, § 6 Rn. 27)[1][2].

Ein praktisch wichtiger Sonderfall betrifft integrierte Komponenten: Läuft deren Unterstützungszeitraum vor dem eigenen ab und lässt sich eine Schwachstelle deshalb weder über den Komponentenhersteller noch durch Minderungsmassnahmen ausreichend beheben, entfällt die Pflicht des Bundle-Herstellers nicht. Er muss die Schwachstelle dann auf anderem Weg beseitigen — etwa durch Austausch der Komponente oder durch Entwicklung eines eigenen Patches (FAQ der Kommissionsdienststellen, Ziff. 4.3.7)[4].

Wichtig ist eine häufige Verwechslung: Die im CRA genannten „zehn Jahre“ verpflichten nicht dazu, ein Jahrzehnt lang Sicherheitsupdates zu liefern. Art. 13 Abs. 9 CRA verlangt lediglich, dass jede bereits bereitgestellte Sicherheitsaktualisierung nach ihrer Bereitstellung „für mindestens zehn Jahre oder für die verbleibende Dauer des Unterstützungszeitraums, je nachdem, welcher Zeitraum länger ist, verfügbar bleibt“. Technische Dokumentation und EU-Konformitätserklärung sind mindestens zehn Jahre oder für den Unterstützungszeitraum aufzubewahren, je nachdem, welcher Zeitraum länger ist (Art. 13 Abs. 13)[1]. Es geht also um Verfügbarhalten und Aufbewahrung, nicht um eine zehnjährige Update-Pflicht.

Andere Gesetze: Die Produkthaftung zieht dieselbe Linie

Der CRA regelt die öffentlich-rechtliche Produktsicherheit. Davon getrennt — und parallel anwendbar — regelt die neue Produkthaftungsrichtlinie (EU) 2024/2853 die zivilrechtliche, verschuldensunabhängige Haftung. Auch dort sind Software und Software-Komponenten „Produkte“; ausserhalb einer Geschäftstätigkeit entwickelte oder bereitgestellte Open-Source-Software ist von der verschuldensunabhängigen Haftung ausgenommen (Art. 2 Abs. 2), und der Hersteller einer fehlerhaften Komponente haftet, wenn diese in ein Produkt integriert oder mit ihm verbunden wurde, das der Kontrolle des Produktherstellers unterliegt, und dessen Fehlerhaftigkeit verursacht hat — gesamtschuldnerisch neben dem Produkthersteller (Art. 8 Abs. 1 lit. b, Art. 12 Abs. 1 PLD). Der Rückgriff gegen den Hersteller einer fehlerhaften Softwarekomponente ist nur ausgeschlossen, wenn dieser zum Zeitpunkt des Inverkehrbringens der Komponente ein Kleinst- oder kleines Unternehmen war und der Integrator vertraglich darauf verzichtet hat (Art. 12 Abs. 2). In die Fehlerbewertung fliessen auch sicherheitsrelevante Cybersicherheitsanforderungen ein (Art. 7 Abs. 2 lit. f). Die Grenze verläuft damit an derselben Stelle wie im CRA: bei der kommerziellen Bereitstellung. Die Richtlinie ist bis zum 9. Dezember 2026 in nationales Recht umzusetzen und gilt für Produkte, die nach dem 9. Dezember 2026 in Verkehr gebracht oder in Betrieb genommen werden (Art. 2 Abs. 1)[3].

Die Verantwortungsgrenzen auf einen Blick

| Akteur | CRA | Produkthaftung (PLD 2024/2853) | |---|---|---| | Bundle-Hersteller (vermarktet unter eigenem Namen, kommerziell) | Volle Pflichten für das Gesamtprodukt inkl. aller Komponenten; abgestufte Sorgfaltspflicht (Art. 13 Abs. 5/6); eigene CE-Kennzeichnung; Unterstützungszeitraum mindestens 5 Jahre, kein Regelwert (Art. 13 Abs. 8; Guidance Rn. 126) | Haftet für das integrierte Produkt; gesamtschuldnerisch neben Komponentenherstellern | | Kommerzieller Komponenten-/OSS-Anbieter | Eigene Herstellerpflichten für seine Komponente; CE | Eigene Komponentenhaftung (Art. 8) | | Nicht-kommerzieller OSS-Anbieter | Kein Hersteller (Art. 3 Nr. 13/22; ErwGr 18) | Ausgenommen (Art. 2 Abs. 2) | | Verwalter quelloffener Software (Art. 3 Nr. 14) | Reduziertes Regime (Art. 24), keine CE | Wie bei sonstiger Open-Source-Software | | Beitragende (Quellcode zu fremder OSS, nicht unter eigener Verantwortung) | Keine CRA-Pflichten aus der Beitragstätigkeit (ErwGr 18; Guidance Rn. 85–86); Sorgfalt und Meldepflichten bleiben beim integrierenden Hersteller | Keine eigene Regel für Beitragende; ausgenommen ist OSS, die ausserhalb einer Geschäftstätigkeit entwickelt oder bereitgestellt wird (Art. 2 Abs. 2) | | Integrator mit wesentlicher Änderung (Art. 22) | Gilt als Hersteller — für den betroffenen Teil bzw. das Gesamtprodukt | Ggf. Produkthersteller-Haftung |

Echte Graubereiche

Drei Punkte bleiben auslegungsbedürftig. Erstens die Abgrenzung kommerziell/nicht-kommerziell bei Open Source: Die nicht bindende Guidance konkretisiert zahlreiche Standardfälle (Kapitel 3.2, Rn. 50–57). Ein Preis für die Software selbst oder eine nur gegen Entgelt zugängliche Version mit Support spricht für ein Inverkehrbringen; bloss optional zubuchbare Beratungs- und Supportleistungen zu frei verfügbarer Software dagegen nicht[5]. Bei Misch- und Bündelmodellen bleibt eine Einzelfallprüfung. Zweitens ist der Massstab der „gebotenen Sorgfalt“ unbestimmt, aber beschreibbar: Erwägungsgrund 34 CRA und FAQ Nr. 4.4.1 nennen vier Prüfpfade, von denen je nach Risiko einer oder mehrere zu berücksichtigen sind[1][4]. Die Guidance verlangt, die Anforderungen des Produkts an jede Komponente festzulegen und risikobasiert zu verifizieren, gegebenenfalls mit eigenen Tests (Rn. 170–171)[5]. Offen bleibt die geschuldete Prüftiefe im Einzelfall. Drittens bleibt die innenvertragliche Risikoverteilung zwischen Bundle-Hersteller und Komponenten- beziehungsweise OSS-Anbieter vertraglich zu gestalten und ist nicht abschliessend harmonisiert.

Das Wichtigste für Hersteller

  • Wer ein Bundle unter eigenem Namen in Verkehr bringt, verantwortet das Gesamtprodukt einschliesslich aller integrierten Komponenten — über den gesamten Unterstützungszeitraum, nicht nur bis zur Installation.
  • Für integrierte Dritt- und Open-Source-Komponenten gilt die risikoabhängige Sorgfaltspflicht nach Art. 13 Abs. 5 CRA; Schwachstellen in Komponenten sind nach Art. 13 Abs. 6 CRA zu melden, selbst entwickelte Sicherheitsfixes weiterzugeben.
  • Nicht kommerziell bereitgestellte Open-Source-Software unterliegt selbst nicht dem CRA; Verwalter quelloffener Software haben ein reduziertes Pflichtenprofil (Art. 24 CRA). Die Rolle ist je Projekt und Version zu prüfen.
  • Eine CE-gekennzeichnete Komponente erleichtert den Sorgfaltsnachweis, ersetzt ihn aber nicht.
  • Die „zehn Jahre“ des CRA betreffen das Verfügbarhalten von Sicherheitsupdates und die Aufbewahrung der Dokumentation, keine zehnjährige Update-Pflicht.

So unterstützt crAIready

Hinweis der Herausgeberin: crAIready ist die CRA-Compliance-Plattform der codAIx GmbH.

  • SBOM & Lieferkette: erstellt die Software-Stückliste auf Wunsch automatisch aus Ihrem Code (Git-Repository, Quellcode-Archiv oder CI-Pipeline) oder übernimmt vorhandene SBOMs per Upload; Bestandteile ohne eigenen Quellcode, etwa zugekaufte Firmware, werden manuell erfasst. Für eingebundene Drittkomponenten unterstützt die Plattform die Sorgfaltspflicht nach Art. 13 Abs. 5 CRA.
  • Schwachstellen & CVD: gleicht die SBOM-Komponenten regelmässig mit OSV, NVD, CISA KEV und EUVD ab, ordnet Hinweise den betroffenen Komponenten zu und bereitet sie für die Triage auf. Ob eine Meldepflicht nach Art. 14 besteht, wird gesondert geprüft.
  • Rollen & Wirtschaftsakteure: bildet die Rollen Hersteller, Einführer, Händler und Bevollmächtigter mit ihren jeweiligen Pflichten ab.

Der Einstieg in die Plattform ist unser kostenloser CRA-Quick-Check: Mit wenigen Fragen erhalten Sie eine unverbindliche Ersteinschätzung dazu, ob und wie der CRA Ihr Produkt betreffen könnte. Die vertiefte Prüfung der Lieferkette und die abschliessende Beurteilung des Einzelfalls bleiben dem verantwortlichen Unternehmen vorbehalten.

Methodik dieser Recherche

Die rechtlichen Aussagen dieses Beitrags wurden gegen die Verordnung (EU) 2024/2847 (Cyber Resilience Act) geprüft und mit Artikel- und Erwägungsgrundnummern belegt. Ergänzend herangezogen wurden die juristischen Kommentare von Wiebe (Hrsg.), Das neue Recht der Cyberresilienz (Nomos, Stand Juni 2025), mit §-, Rn.- und Seitenangabe, sowie Schröder/Hartl (Hrsg.), Cyberresilienz-Verordnung, Nomos Kommentar, 1. Aufl. 2026, Stand Dezember 2025 (zitiert als NK-CRA/Bearbeiter) — dort insbesondere die Kommentierung von Schmidt zu Art. 3 Nr. 14 CRA und von Hessel zu Art. 32 CRA. Die Aussagen zur Produkthaftung beruhen auf der Richtlinie (EU) 2024/2853. Ergänzend herangezogen wurden die „FAQs on the Cyber Resilience Act“ in der Version 1.4 vom 04.09.2026 — ein von den Kommissionsdienststellen erstelltes, nach eigener Angabe nicht verbindliches und laufend fortgeschriebenes Dokument, das keine offizielle Position der Kommission wiedergibt — sowie die am 27.07.2026 mit Communication C(2026) 5252 final veröffentlichte Guidance der Kommission (Kapitel 3.2, 3.3, 3.4, 5, 7.3 und 9.2.1).

Quellen

[1] Verordnung (EU) 2024/2847 des Europäischen Parlaments und des Rates vom 23. Oktober 2024 (Cyber Resilience Act) – EUR-Lex — insbesondere Art. 3 Nr. 13, 14, 22, 48, Art. 13 Abs. 5, 6, 8, 9, 13, Art. 15, Art. 22, Art. 24, Art. 32 Abs. 5, Anhang I Teil II, Anhang III, Erwägungsgründe 18, 19, 34, 35.

[2] Wiebe, G. (Hrsg.) — Das neue Recht der Cyberresilienz: Kommentar zur CRA, Verlag Nomos, Stand Juni 2025 — Wiebe/Jossen, § 4 Rn. 4 (S. 33; Open Source, kommerzieller Charakter); Wiebe, § 4 Rn. 19 (vertiefend) und Rn. 38 (Verwalter kein Wirtschaftsakteur); Wiebe, § 6 Rn. 4 (S. 111; Verwalter quelloffener Software), Rn. 19 mit Praxishinweis (S. 116–118; Sorgfaltspflicht, Vertrauensgrundsatz), Rn. 20 (S. 118; Komponenten-Meldepflicht), Rn. 27 (S. 120; Unterstützungszeitraum).

[3] Richtlinie (EU) 2024/2853 des Europäischen Parlaments und des Rates vom 23. Oktober 2024 über die Haftung für fehlerhafte Produkte – EUR-Lex — insbesondere Art. 2 Abs. 1 (zeitlicher Anwendungsbereich) und Abs. 2 (Ausnahme für ausserhalb einer Geschäftstätigkeit entwickelte oder bereitgestellte Open-Source-Software), Art. 7 Abs. 2 lit. f (Cybersicherheitsanforderungen bei der Beurteilung der Fehlerhaftigkeit), Art. 8 Abs. 1 lit. b (Komponentenhaftung), Art. 12 (gesamtschuldnerische Haftung, Ausschluss des Rückgriffs); Umsetzungsfrist 9. Dezember 2026.

[4] Europäische Kommission (Dienststellen) — „FAQs on the Cyber Resilience Act“, Version 1.4 vom 04.09.2026. Von den Kommissionsdienststellen erstellt; nach eigener Angabe keine offizielle Position der Europäischen Kommission und nicht verbindlich; lebendes Dokument, das fortlaufend aktualisiert wird. Insbesondere Ziff. 4.3.6, 4.3.7, 4.4.1, 4.4.3, 5.5, 6.1 und 6.6.

[5] Europäische Kommission, Communication C(2026) 5252 final mit Annex, „Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act)“. Veröffentlicht am 27.07.2026. Die Guidance ist nicht verbindlich und schafft keine zusätzlichen Pflichten; massgeblich bleiben der CRA und andere verbindliche Rechtsakte. Herangezogen wurden insbesondere Kapitel 3.2 (Rn. 50–57: kommerzielle und nicht kommerzielle Bereitstellung; Rn. 66 mit Beispiel 24: gemeinnützige Organisationen), Kapitel 3.3 (Rn. 71–79: Verwalter- und Herstellerrolle), Kapitel 3.4 (Rn. 85–88: Beitragende und Integration quelloffener Komponenten), Kapitel 5 (Rn. 126: Unterstützungszeitraum), Kapitel 7.3 (Rn. 170–171: Sorgfaltspflicht bei integrierten Komponenten) sowie Kapitel 9.2.1 (Rn. 222–229: Meldung an den Upstream-Maintainer und Weitergabe von Sicherheitsfixes nach Art. 13 Abs. 6 CRA).

[6] Schröder/Hartl (Hrsg.), Cyberresilienz-Verordnung, Nomos Kommentar, 1. Aufl. 2026, Stand Dezember 2025 (zit.: NK-CRA/Bearbeiter) — Schmidt, Art. 3 Rn. 86–90 (Verwalter quelloffener Software, Art. 3 Nr. 14 CRA); Hessel, Art. 32 Rn. 35 (Konformitätsbewertung freier und quelloffener Software nach Art. 32 Abs. 5 CRA).

Haftungsausschluss: Dieser Beitrag ist eine allgemeine Information zum Cyber Resilience Act und ersetzt keine individuelle Rechtsberatung. Eine verbindliche Beurteilung Ihres konkreten Produkts und Ihrer konkreten Pflichten setzt eine Einzelfallprüfung voraus. Keine Rechtsberatung im Sinne des RDG. Die mit Communication C(2026) 5252 final veröffentlichte Guidance ist nicht verbindlich und schafft keine zusätzlichen Pflichten. Die Produkthaftungsrichtlinie (EU) 2024/2853 ist bis zum 9. Dezember 2026 in nationales Recht umzusetzen; massgeblich ist die jeweilige nationale Umsetzung. Herausgeberin: codAIx GmbH, Thayngen (Schweiz). Veröffentlicht am 20.07.2026, zuletzt geändert am 18.10.2026.

Im nächsten Artikel dieser Serie: CE-Kennzeichnung und CRA: Eingebettete Software, ein CE-Zeichen — warum eingebettete Software in physischen Produkten kein eigenes „CRA-CE“ bekommt, sondern in das gemeinsame CE-Siegel einfliesst, und wie sich der CRA zur Maschinenverordnung und zur Funkanlagenrichtlinie verhält.