Wo endet meine CRA-Pflicht beim Software-Bundle?

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

| 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 KI-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 — Mindestversionen nach der Technischen Richtlinie BSI TR-03183 Teil 2, Version 2.1.0 vom 20.08.2025[6]) 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 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 der im Annex zu C(2026) 5252 final veröffentlichte Guidance-Entwurf (Kapitel 3.3 und 9.2.1). Dessen Inhalt wurde von der Kommission am 27.07.2026 gebilligt; die förmliche Annahme soll nach Vorliegen aller Sprachfassungen erfolgen. Erst danach soll die Guidance als offizielle Auslegungshilfe der Kommission verwendet werden. Sie schafft keine zusätzlichen verbindlichen 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.

Stand: 12.08.2026 (v13 — Erscheinungsdatum im Rahmen des festgelegten Veröffentlichungsrhythmus auf den 20.07.2026 gesetzt und das bereits durch die v12-Prüfung belegte Prüfdatum im Footer auf den 12.08.2026 berichtigt; zeitabhängige Formulierungen unverändert. v12 — Status des im Annex zu C(2026) 5252 final veröffentlichten Guidance-Entwurfs in Methodik, Quelle [5] und Haftungsausschluss ergänzt; inhaltliche Billigung, noch ausstehende förmliche Annahme und fehlende Bindungswirkung klargestellt. Die historischen Versionshinweise bleiben unverändert).

Stand: 06.08.2026 (v11 — Präzisierung der Rollenabgrenzung beim Verwalter quelloffener Software: Verwalter- und Herstellerrolle schliessen einander bezogen auf dasselbe Produkt aus, nicht bezogen auf die juristische Person; dieselbe Einrichtung kann für ein Projekt Verwalter und für ein anderes — oder für die monetarisierte Variante desselben Codes — Hersteller sein (Kommissions-Guidance C(2026) 5252, Kapitel 3.3, Rn. 72–74 und 76). Der scheinbare Widerspruch zwischen NK-CRA/Schmidt, CRA Art. 3 Rn. 88, und der Guidance löst sich damit auf; Methodik und Quelle [5] entsprechend ergänzt. v10 — belegte Ergänzungen aus dem juristischen Kommentar NK-CRA (Schröder/Hartl (Hrsg.), Cyber Resilience Act: CRA, 1. Aufl. 2026, Nomos), keine Korrekturen: Verwalter quelloffener Software präzisiert — juristische Person zwingend, natürliche Personen und zugleich als Hersteller Auftretende scheiden aus, Sitz innerhalb oder ausserhalb der Union, Entstehungsgeschichte nach Erwägungsgrund 19, Unbestimmtheit des Massstabs „systematisch und nachhaltig“ sowie Vermarktbarkeit als zusätzliches Kriterium (NK-CRA/Schmidt, CRA Art. 3 Rn. 86–90); Klarstellung, dass der Modul-A-Pfad nach Art. 32 Abs. 5 CRA auch ohne Anwendung harmonisierter Normen oder gemeinsamer Spezifikationen offensteht (NK-CRA/Hessel, CRA Art. 32 Rn. 35); Methodik und Quellenverzeichnis um [7] erweitert. v9 — belegte Ergänzungen, keine Korrekturen: Weitergabepflicht für selbst entwickelte Sicherheitsfixes nach Art. 13 Abs. 6 CRA ergänzt (FAQ 4.3.6, Guidance Kapitel 9.2.1, Rn. 223 und 225–228), Fall des vorzeitigen End-of-Life einer integrierten Komponente nach FAQ 4.3.7 aufgenommen, SBOM-Formatangaben mit BSI TR-03183 Teil 2 belegt, Modul-A-Pfad für quelloffene wichtige Produkte nach Art. 32 Abs. 5 CRA und die einzige Veröffentlichungspflicht für die technische Dokumentation ergänzt (FAQ 6.1 und 6.6), Aussage zur CE-gekennzeichneten Komponente mit FAQ 4.4.3 belegt; Quellenverzeichnis um [4], [5] und [6] erweitert.)

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. Verfügbar unter: https://digital-strategy.ec.europa.eu/en/library/cyber-resilience-act-implementation-frequently-asked-questions.

[5] Europäische Kommission, Communication C(2026) 5252 final, Annex, „Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act)“ — Inhalt von der Kommission am 27.07.2026 gebilligt. Sobald alle Sprachfassungen vorliegen, soll die Guidance förmlich angenommen werden. Erst ab dieser Annahme soll sie als offizielle Auslegungshilfe der Kommission verwendet werden. Sie schafft keine zusätzlichen verbindlichen Pflichten; diese ergeben sich aus dem CRA und anderen verbindlichen Rechtsakten. 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). Verfügbar unter: https://digital-strategy.ec.europa.eu/en/library/commission-publishes-new-guidance-support-timely-cyber-resilience-act-implementation.

[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. Der im Annex zu C(2026) 5252 final veröffentlichte Guidance-Entwurf ist inhaltlich gebilligt, aber noch nicht förmlich angenommen. Auch nach der Annahme schafft die Guidance keine zusätzlichen verbindlichen Pflichten. Die Produkthaftungsrichtlinie (EU) 2024/2853 ist bis zum 9. Dezember 2026 in nationales Recht umzusetzen; massgeblich ist die jeweilige nationale Umsetzung. Stand: 12.08.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: 20.07.2026 | Zuletzt geprüft am: 13.08.2026

Stand: 13.08.2026 (v14 — freigegebene Schlusskorrektur: Klammerzeichensetzung, Anführungszeichen und „KI-gestützt“ vereinheitlicht. Vorherige Fassung: v13; zeitabhängige Formulierungen unverändert.)