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: 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[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).

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]. 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].

Wer überhaupt als Verwalter in Betracht kommt, ist enger gefasst, als der Begriff vermuten lässt. Nach Erwägungsgrund 19 CRA zielt er vor allem auf Stiftungen und gemeinnützige Einrichtungen, die quelloffene Software im wirtschaftlichen Kontext entwickeln und veröffentlichen; die Figur wurde erst mit der letzten Entwurfsfassung des Europäischen Parlaments eingefügt, nachdem grosse Open-Source-Stiftungen die frühen Entwürfe kritisiert hatten — zuvor war offen, ob und in welchem Umfang Open-Source-Projekte und ihre Entwickler überhaupt erfasst würden (juristischer Kommentar NK-CRA/Schmidt, 1. Aufl. 2026, CRA Art. 3 Rn. 86–87)[7]. 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 (Rn. 88)[7]. 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 — praktisch ein seltener Fall, weil sich die überwiegende Mehrheit quelloffener Software kommerziell verwenden lässt (Rn. 89)[7].

Ebenfalls in 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 Kommentar 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: Weder die Definition noch die Erwägungsgründe geben dafür einen Massstab vor. Kurzfristige Unterstützung genügt nach dem Kommentar jedenfalls nicht — erforderlich sind auf Dauer angelegte Mindeststrukturen. Hinzu kommt ein leicht zu übersehendes zweites Kriterium: Der Verwalter muss auch die Vermarktbarkeit sicherstellen, also systematische Aktivitäten zur Verbreitung der Software ergreifen. Ob die Schwelle von einer blossen Förderung zu einer systematischen und nachhaltigen Unterstützung überschritten ist, lässt sich nur im Einzelfall und anhand des Schwerpunkts der Tätigkeit beurteilen (Rn. 90)[7].

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 (juristischer Kommentar NK-CRA/Hessel, 1. Aufl. 2026, CRA Art. 32 Rn. 35)[7].

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 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 feste Mindestfrist darstellen — bei kürzerer erwartbarer Nutzungsdauer darf der Unterstützungszeitraum der voraussichtlichen Nutzungsdauer entsprechen[2], bei langlebigen Produkten entsprechend länger.

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 Mitigationsmassnahmen 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“; 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

  • Bundle-Hersteller (vermarktet unter eigenem Namen, kommerziell) — CRA: Volle Pflichten für das Gesamtprodukt inkl. aller Komponenten; abgestufte Sorgfaltspflicht (Art. 13 Abs. 5/6); eigene CE-Kennzeichnung; Unterstützungszeitraum ≥ 5 Jahre. Produkthaftung (PLD 2024/2853): Haftet für das integrierte Produkt; gesamtschuldnerisch neben Komponentenherstellern.
  • Kommerzieller Komponenten-/OSS-Anbieter — CRA: Eigene Herstellerpflichten für seine Komponente; CE. Produkthaftung: Eigene Komponentenhaftung (Art. 8).
  • Nicht-kommerzieller OSS-Anbieter — CRA: Kein Hersteller (Art. 3 Nr. 13/22; ErwG 18). Produkthaftung: Ausgenommen (Art. 2 Abs. 2).
  • Open-Source-Steward (Art. 3 Nr. 14) — CRA: Reduziertes Regime (Art. 24), keine CE. Produkthaftung: Wie sonstige OSS-Lage.
  • Integrator mit wesentlicher Änderung (Art. 22) — CRA: Gilt als Hersteller — für den betroffenen Teil bzw. das Gesamtprodukt. Produkthaftung: 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 strukturiert die zentralen CRA-Arbeitsschritte für Komponenten, Lieferkette und unterschiedliche Wirtschaftsakteure:

  • SBOM & Lieferkette: crAIready übernimmt maschinenlesbare SBOMs per Upload oder über eine angebundene CI-Pipeline, verwaltet sie zentral und hält sie während der Vertragsdauer versioniert und exportierbar. Für jede eingebundene Drittkomponente unterstützt die Plattform die abgestufte Due Diligence nach Art. 13 Abs. 5.
  • Schwachstellen & CVD: crAIready gleicht die SBOM-Komponenten regelmässig mit den angebundenen Schwachstellenquellen (OSV, NVD, CISA KEV und EUVD) ab, ordnet Hinweise den betroffenen Komponenten zu und bereitet verfügbare Bewertungsinformationen für die Triage auf. Die Art.-14-Prüfung erfolgt gesondert, denn ein Schwachstellenhinweis startet noch keine 24-Stunden-Frist. Ergänzend unterstützt crAIready den CVD-Prozess nach Anhang I Teil II Nr. 4–6 CRA.
  • CRA-Pflichten passend zur eigenen Rolle bearbeiten: crAIready bildet die Aufgaben von Bevollmächtigten, Einführern und Händlern produktbezogen ab. Rollen, Zuständigkeiten, Mandate und erforderliche Nachweise werden zentral zugeordnet. Zusätzlich unterstützt die Plattform die Prüfung, ob ein Einführer, Händler oder eine andere Person aufgrund der Vermarktung oder Veränderung eines Produkts als Hersteller gilt.

Der Einstieg ist unser kostenloser CRA-Quick-Check. Er unterstützt mit wenigen Fragen 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. Keine Rechtsberatung im Sinne des RDG.

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 wurden die juristischen Kommentare von Wiebe (Hrsg.), Das neue Recht der Cyberresilienz (Nomos 2025), mit Seiten- und Randnummernangabe, sowie Schröder/Hartl (Hrsg.), Cyber Resilience Act: CRA, 1. Auflage 2026 (Nomos, 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.3 vom 01.07.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.3 und 9.2.1). Auch die Guidance ist nicht verbindlich und schafft keine zusätzlichen Pflichten. Für die SBOM-Formatangaben wurde die Technische Richtlinie BSI TR-03183 Teil 2 in der Version 2.1.0 vom 20.08.2025 herangezogen.

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, 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 — 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.

[4] Europäische Kommission (Dienststellen) — „FAQs on the Cyber Resilience Act“, Version 1.3 vom 01.07.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.3, 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 9.2.1 (Rn. 222–228: Meldung an den Upstream-Maintainer und Weitergabe von Sicherheitsfixes nach Art. 13 Abs. 6 CRA) und Kapitel 3.3 (Rn. 71–74 und 76: Abgrenzung von Verwalter- und Herstellerrolle je quelloffenem Produkt, Doppelrolle derselben juristischen Person, Community- gegenüber monetarisierter Version).

[6] Bundesamt für Sicherheit in der Informationstechnik (BSI), Technische Richtlinie BSI TR-03183 „Cyber Resilience Requirements for Manufacturers and Products“, Teil 2: Software Bill of Materials (SBOM), Version 2.1.0 vom 20.08.2025 — insbesondere Abschnitt 4 (SBOM-Formate: CycloneDX ab Version 1.6, SPDX ab Version 3.0.1, jeweils nur in offiziell freigegebenen Fassungen und in JSON oder XML). Technische Richtlinie des BSI, kein unmittelbar geltendes Unionsrecht.

[7] Schröder, M./Hartl, K. (Hrsg.) — Cyber Resilience Act: CRA, 1. Auflage 2026, Nomos (zitiert als NK-CRA/Bearbeiter) — artikelweiser Kommentar zur Verordnung (EU) 2024/2847; Art. 3 Nr. 14 kommentiert von Schmidt, Art. 32 von Hessel. Insbesondere NK-CRA/Schmidt, CRA Art. 3 Rn. 86–90 (Verwalter quelloffener Software) und NK-CRA/Hessel, CRA 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. 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. Fachlich geprüft am: 13. August 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.