Wo endet meine CRA-Pflicht beim Software-Bundle?

Von Redaktion codAIx | 5. Juni 2026

Kaum ein Produkt entsteht heute aus einer Hand. Eine proprietäre Anwendung setzt auf Open-Source-Bibliotheken auf, integriert Dritt-Komponenten 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 zugrundeliegende 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 Kommentar zur CRA ordnet sie in den produzentenhaftungsrechtlichen Vertrauensgrundsatz der Arbeitsteilung ein: „Die vergleichsweise reduzierte Inpflichtnahme des Herstellers des Gesamtprodukts steht … im Einklang mit dem produzentenhaftungsrechtlichen Vertrauensgrundsatz in der Arbeitsteilung"; zugleich gilt: „Je höher das Cybersicherheitsrisiko und die Sicherheitskritikalität der Komponente, desto umfangreichere Massnahmen sind zu treffen"[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 sich diese abgestufte Pflichtenstruktur insgesamt ausgestaltet, haben wir in den abgestuften CRA-Pflichten nach Art. 13 dargestellt.

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]. Der Wiebe CRA-Kommentar betont, dass ein blosser Verdacht dafür nicht genügt[2]. Diese B2B-Meldekette steht neben der behördlichen Meldepflicht nach Art. 14 (dazu Artikel 8 dieser Serie).

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]. Der Kommentar bringt es auf den Punkt: „unterliegt FOSS nur dann dem CRA, wenn sie im Rahmen einer Geschäftstätigkeit verfügbar gemacht wird. Entscheidend ist dabei, ob die Tätigkeit … einen ‚kommerziellen Charakter' hat"[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 dafür fängt der proprietäre Bundle-Hersteller über seine Sorgfaltspflicht (Art. 13 Abs. 5/6) auf. Sobald die Open-Source-Komponente jedoch ihrerseits kommerziell bereitgestellt oder monetarisiert wird, treffen deren Anbieter eigene Herstellerpflichten.

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 eine Cybersicherheitsstrategie entwickeln und dokumentieren sowie mit Behörden kooperieren und Meldepflichten erfüllen, unterliegt aber nicht den vollen Herstellerpflichten[1]. 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 Kommentar bestätigt dieses reduzierte Pflichtenprofil ohne Konformitätsbewertung[2].

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 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 CRA beträgt dieser mindestens fünf Jahre; ist die voraussichtliche Nutzungsdauer kürzer, darf der Zeitraum entsprechend kürzer ausfallen[1]. Der CRA-Kommentar von Wiebe präzisiert, dass die fünf Jahre „nur auf den ersten Blick eine Mindestfrist" sind — bei kürzerer erwartbarer Nutzungsdauer darf der Unterstützungszeitraum der voraussichtlichen Nutzungsdauer entsprechen[2], bei langlebigen Produkten entsprechend länger.

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"; daneben bestehen zehnjährige Aufbewahrungspflichten für Dokumentation und Konformitätserklärung (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"; nicht-kommerziell ausserhalb einer Geschäftstätigkeit entwickelte oder bereitgestellte Open-Source-Software ist von der strikten Haftung ausgenommen (Art. 2 Abs. 2), und der Hersteller einer fehlerhaften Komponente haftet, wenn sie unter seiner Kontrolle integriert wurde (Art. 8) — gesamtschuldnerisch neben dem Produkthersteller. Die Richtlinie ist bis zum 9. Dezember 2026 in nationales Recht umzusetzen[3]. Die Grenze verläuft damit an derselben Stelle wie im CRA: bei der kommerziellen Bereitstellung.

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 ≥ 5 Jahre | 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; ErwG 18) | Ausgenommen (Art. 2 Abs. 2) | | Open-Source-Steward (Art. 3 Nr. 14) | Reduziertes Regime (Art. 24), keine CE | Wie sonstige OSS-Lage | | 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: Support-Verträge, Dual Licensing, Freemium-Modelle oder bezahltes Hosting lassen die Grenze verschwimmen, ab wann eine Komponente „im Rahmen einer Geschäftstätigkeit" bereitgestellt wird. Zweitens der konkrete Umfang der „gebotenen Sorgfalt" — welche Tests, welche Datenbankabfragen, welche Prüftiefe geschuldet sind, ist normativ noch nicht konturiert. Drittens der Regress: Die innenvertragliche Risikoverteilung zwischen Bundle-Hersteller und Komponenten- bzw. OSS-Anbieter bleibt vertraglich zu gestalten und ist nicht abschliessend harmonisiert.

crAIready bringt Ordnung in Ihre Lieferkette

crAIready ist die AI-gestützte SaaS-Plattform, die die Komponenten- und Open-Source-Verantwortung beherrschbar macht:

• SBOM & Lieferketten-Sorgfalt (Modul 2): automatische Stückliste aller integrierten Dritt- und Open-Source-Komponenten (CycloneDX 1.6 / SPDX 3.0.1) mit abgestufter Due Diligence nach Art. 13 Abs. 5 — Lieferantenbewertung oder Lifecycle-Check (Upstream aktiv, EOL-Datum).
• Schwachstellen & CVD (Modul 3): automatischer Abgleich Ihrer Komponenten gegen NVD, OSV, GitHub Advisory und CISA KEV — Auslöser für die Meldekette nach Art. 13 Abs. 6.
• Rollen & Übernahme-Erkennung: Pflichtenkatalog je Rolle (Hersteller, Einführer, Händler) und Erkennung nach Art. 21, wann Sie durch eigene Marke oder wesentliche Änderung selbst zum Hersteller werden.

Der Einstieg ist unser kostenloser CRA Quick-Check: eine erste, belastbare Orientierung zu Ihren Pflichten entlang der Lieferkette — ohne Beratungsabhängigkeit. Die verbindliche Beurteilung Ihres Einzelfalls bleibt Ihnen vorbehalten.

Methodik dieser Recherche

Alle rechtlichen Aussagen sind direkt gegen die Verordnung (EU) 2024/2847 (Cyber Resilience Act) geprüft und mit Artikel- und Erwägungsgrundnummern belegt. Ergänzend herangezogen wurde der Kommentar von Wiebe (Hrsg.), Das neue Recht der Cyberresilienz (Nomos 2025), mit Seiten- und Randnummernangabe. Die Aussagen zur Produkthaftung beruhen auf der Richtlinie (EU) 2024/2853.

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. 22, Art. 24, Anhang I Teil II, Erwägungsgründe 18, 19, 34, 35.

[2] Wiebe, G. (Hrsg.) — Das neue Recht der Cyberresilienz: Kommentar zur CRA, Verlag Nomos, Stand Juni 2025 — insbesondere S. 33 Rn. 4 (Open Source / kommerzieller Charakter), S. 111 Rn. 4 (Verwalter quelloffener Software), S. 116–117 Rn. 19 (Sorgfaltspflicht, Vertrauensgrundsatz), S. 118 Rn. 20 (Komponenten-Meldepflicht), S. 120 Rn. 27 (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. 2 (Ausnahme nicht-kommerzielle Open-Source-Software), Art. 8 (Komponentenhaftung); Umsetzungsfrist 9. Dezember 2026.

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. Die Produkthaftungsrichtlinie (EU) 2024/2853 ist bis zum 9. Dezember 2026 in nationales Recht umzusetzen; massgeblich ist die jeweilige nationale Umsetzung. Stand: 5. Juni 2026. Herausgeberin: codAIx GmbH, Thayngen (Schweiz).

Im nächsten Artikel dieser Serie: Ein Produkt, 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.

Veröffentlicht am: 05.06.2026 | Zuletzt geprüft am: 03.07.2026