CRA und Open Source: Hersteller, Verwalter, SBOM

Zum Inhaltsverzeichnis springen

Erstveröffentlicht am 8. September 2026Rechtsstand: 8. September 2026Änderungen anzeigen

Open Source unterliegt den Herstellerpflichten des Cyber Resilience Act nur, wenn sie im Rahmen einer Geschäftstätigkeit auf dem Markt bereitgestellt wird. Unabhängig davon kann eine juristische Person, die sie dauerhaft betreut, Verwalter mit eigenen, leichteren Pflichten sein, und wer fremde Komponenten einbaut, trägt die Sorgfalt für das eigene Produkt.

Art. 2, 3, 13, 14, 24, 25, 32, 64, 69, 71 und Anhang I CRA · Erwägungsgründe 15, 18, 19, 34 · Leitlinien der Kommission C(2026) 5252, Abschnitte 3, 7.3, 9.1, 9.2 · FAQ der Kommissionsdienststellen, Fassung 1.4 · ENISA-Koordinatorenliste · BT-Drs. 21/6134 · Sofortteil ca. 8 Minuten · Lesezeit ca. 66 Minuten

¶Vor dem ersten Stichtag sind vier Dinge zu klären

Der 11. September 2026 betrifft nur die Meldung nach Art. 14 und nur den Hersteller, die übrigen Pflichten der Hersteller und Verwalter gelten ab dem 11. Dezember 2027.Art. 71 Abs. 2 CRA Trotzdem entscheidet sich jetzt, mit welcher Rolle ein Unternehmen in die Verordnung geht.

Zurück zum Inhalt

¶Ohne Geschäftstätigkeit fällt Open Source aus dem CRA heraus

Die Verordnung gilt für Produkte mit digitalen Elementen, die auf dem Markt bereitgestellt werden und deren Zweck eine Datenverbindung einschließt.Art. 2 Abs. 1 CRA Bereitstellung ist die Abgabe zum Vertrieb oder zur Verwendung im Rahmen einer Geschäftstätigkeit, entgeltlich oder unentgeltlich.Art. 3 Nr. 22 CRA Ob Geld fließt, ist damit nicht die Frage. Die Frage ist, ob die Abgabe in einen geschäftlichen Zusammenhang gehört.

Für freie und quelloffene Software beantwortet der Gesetzgeber diese Frage selbst. Ihre Bereitstellung gilt nicht als Geschäftstätigkeit, wenn der Hersteller sie nicht zu Geld macht. Wie die Entwicklung finanziert wurde, bleibt außer Betracht, und regelmäßige Veröffentlichungen neuer Versionen sprechen für sich genommen nicht für ein Geschäft.Erwägungsgrund 18 CRA Wer nur Quellcode zu einem Projekt beiträgt, das nicht seiner Verantwortung unterliegt, fällt nicht unter die Verordnung.Erwägungsgrund 18 CRA

Normtext Die Definition verlangt zwei Dinge zugleich. Die Lizenz muss alle vier Freiheiten einräumen, und der Quellcode muss offen geteilt sein. Eine Software, deren Quellcode nur zahlende Kunden oder ein geschlossener Kreis erhält, ist keine freie und quelloffene Software im Sinne der Verordnung, auch wenn die Lizenz eine Open-Source-Lizenz ist.Leitlinien, Rn. 44 und 46 Die Lizenzfrage selbst, also Copyleft, Lizenzhinweise und Quellcodeangebot, steht auf Open-Source-Recht.

Die Auslegung der Kommission zu Open Source liegt seit dem 27. Juli 2026 vor, bisher nur in englischer Sprache.Kommission, Bibliothekseintrag vom 27. Juli 2026 Sie ist unverbindlich, aber bisher die amtliche Konkretisierung der Begriffe, und der Beitrag zitiert sie mit Randnummern.

Wer die Software verantwortet

Bevor die Frage nach dem Geld gestellt wird, ist zu klären, wer die Software überhaupt bereitstellt. Die Kommission ordnet die Verantwortung denen zu, die die Software veröffentlichen und die Entscheidungen über Entwicklung, Versionsfreigabe und Verteilung treffen. Wer Code beisteuert, aber weder Versionsfreigabe noch Entwicklungsplanung noch Leitung des Projekts bestimmt, ist Beitragender. Ein Schreibrecht im Quellcodeverzeichnis allein begründet keine Verantwortung.Leitlinien, Rn. 49 Eine Organisation, die das Projekt ohne eigene Versionsfreigabe systematisch unterstützt, kann gleichwohl Verwalter sein, dazu Abschnitt 4.

Zwei Klarstellungen der Kommission verdienen einen eigenen Satz. Das Teilen von Quellcode in öffentlichen Repositorien ist in der Regel kein Inverkehrbringen, ebenso wenig unfertiger Code zu Test- oder Prüfzwecken und Beispielcode in Schulungsunterlagen.Leitlinien, Rn. 23 Und die bloße Bereitstellung in offenen Archiven oder über eine Paketverwaltung macht den Betreiber der Plattform nicht zum Händler.Erwägungsgrund 20 CRA

Liegt keine Geschäftstätigkeit vor, ist der Fall damit nicht ungeregelt, sondern nach anderem Recht zu prüfen. Lizenz, Vertrag und Haftung bleiben. Die Bereichsausnahmen für Medizinprodukte, Fahrzeuge, Luftfahrt, Schiffsausrüstung und identische Ersatzteile gelten daneben für jede Rolle.Art. 2 Abs. 2 bis 7 CRA Ihre Prüfung führt der Beitrag zur Meldepflicht nach CRA in seiner ersten Abbildung.

Damit steht die erste Weiche. Wer die Software verantwortet und sie im Rahmen einer Geschäftstätigkeit abgibt, ist Hersteller. Wann das der Fall ist, entscheidet sich an den Formen, in denen Open Source Geld einbringt.

Zurück zum Inhalt

¶Der Preis für die Software macht den Anbieter zum Hersteller

Hersteller ist, wer Produkte mit digitalen Elementen entwickelt oder entwickeln lässt und sie unter eigenem Namen oder eigener Marke vermarktet, gegen Bezahlung, zur Monetarisierung oder unentgeltlich.Art. 3 Nr. 13 CRA Das Wort „unentgeltlich“ verwirrt viele Open-Source-Anbieter. Es bedeutet nicht, dass jede kostenlose Bereitstellung die Herstellerrolle auslöst. Die Rolle entsteht erst, wenn die Bereitstellung im Rahmen einer Geschäftstätigkeit erfolgt, und dafür nennt die Verordnung Anzeichen.

Eine Geschäftstätigkeit kann darin liegen, dass ein Preis verlangt wird oder technische Unterstützung mehr als kostendeckend berechnet wird. Sie kann auch darin liegen, dass über eine Softwareplattform andere Dienste gewinnorientiert angeboten werden, dass Datenverarbeitung zur Nutzungsbedingung wird oder dass Spenden die Kosten übersteigen. Spenden ohne Gewinnabsicht gelten nicht als Geschäftstätigkeit.Erwägungsgrund 15 CRA

Verwaltungsauslegung Die Tabelle gibt die Auslegung der Kommission wieder. Sie ist nicht bindend, aber Marktüberwachungsbehörden und notifizierte Stellen werden sich an ihr ausrichten, und sie ist bisher die amtliche Konkretisierung der Anzeichen aus Erwägungsgrund 15.Leitlinien, Rn. 8 Bei natürlichen Personen lässt die Kommission zusätzlich zu, dass eine an den Zugang gebundene technische Unterstützung nicht als Geschäftstätigkeit gilt, wenn das Entgelt nur die tatsächlichen Kosten deckt, einschließlich angemessener Lebenshaltungskosten.Leitlinien, Rn. 58

Was das für Nordkessel bedeutet

Zwei weitere Wege in die Herstellerrolle kommen bei Open Source häufig vor. Wer ein Produkt unter eigenem Namen oder eigener Marke in Verkehr bringt oder ein bereits in Verkehr gebrachtes Produkt wesentlich ändert, gilt als Hersteller, auch als Einführer oder Händler.Art. 21 CRA Dasselbe gilt für jede andere Person, die ein Produkt wesentlich ändert und dann bereitstellt, beschränkt auf den geänderten Teil oder, wenn die Änderung die Cybersicherheit des Ganzen berührt, für das gesamte Produkt.Art. 22 Abs. 1 und 2 CRA Ein Dienstleister, der fremde Open Source beim Kunden installiert, ohne sie wesentlich zu ändern, bringt sie nicht in Verkehr.Leitlinien, Rn. 59, Beispiel 19

Für Hersteller freier und quelloffener Software enthält die Verordnung eine Erleichterung beim Konformitätsverfahren. Wer ein wichtiges Produkt nach Anhang III als freie und quelloffene Software in Verkehr bringt, darf das interne Kontrollverfahren nutzen, wenn die technische Dokumentation beim Inverkehrbringen öffentlich zugänglich ist.Art. 32 Abs. 5 CRA Für kritische Produkte nach Anhang IV gilt das nicht.

Zurück zum Inhalt

¶Verwalter tragen Pflichten, aber keine CE-Kennzeichnung

Viele Open-Source-Projekte, die in kommerziellen Produkten stecken, werden von Stiftungen, Vereinen oder Unternehmen betreut, ohne dass jemand für sie bezahlt. Für diese Betreuer schafft die Verordnung eine eigene Rolle mit einem vereinfachten Pflichtenregime.Erwägungsgrund 19 CRA

Normtext Die Definition hat fünf Merkmale, die zusammen vorliegen müssen. Verwalter kann nur eine juristische Person sein, für diese Software darf sie nicht Hersteller sein.Art. 3 Nr. 14 CRA Sie muss die Entwicklung spezifischer Produkte systematisch und nachhaltig unterstützen, gelegentliche Hilfe genügt nicht. Die Software muss für kommerzielle Tätigkeiten bestimmt sein, etwa für den Einbau in bezahlte Produkte, und die Person muss ihre Brauchbarkeit sicherstellen.

Die Kommission legt das Merkmal der dauerhaften Unterstützung weit aus. Es umfasst das Betreiben von Plattformen für die Zusammenarbeit, das Hosting von Quellcode, das Verwalten und Administrieren der Software und die Steuerung ihrer Entwicklung.Erwägungsgrund 19 CRA Eine Stiftung, die viele Projekte beherbergt, ist deshalb nicht für alle Verwalter, sondern nur für diejenigen, die sie tatsächlich systematisch unterstützt und die für kommerzielle Zwecke bestimmt sind.Leitlinien, Rn. 78 Die Bestimmung für kommerzielle Tätigkeiten liegt nach dem Erwägungsgrund auch dann vor, wenn Hersteller, die die Komponente einbauen, regelmäßig zur Entwicklung beitragen oder sie regelmäßig finanzieren.Erwägungsgrund 19 CRA

Drei Pflichten, zwei Freistellungen

Die drei Pflichten sind Organisationspflichten, keine Produktpflichten. Der Verwalter schuldet keine Risikobewertung, keine grundlegenden Anforderungen nach Anhang I und keine Stückliste, wohl aber eine Strategie, die den Entwicklern des Projekts einen sicheren Umgang mit Schwachstellen erlaubt.Art. 24 Abs. 1 und 2 CRA Die Freistellung von der Geldbuße erfasst seit der Berichtigung auch den Rahmen, in dem die Art. 13 und 14 stehen.Art. 64 Abs. 10 lit. b CRA in der Fassung der Berichtigung vom 2. Juli 2025

Die Rolle ist nicht auf Dauer angelegt. Wer die systematische Unterstützung einstellt, erfüllt die Definition nicht mehr und sollte das nach Auffassung der Kommission erkennbar machen.Leitlinien, Rn. 83 Wer ein Projekt später zu Geld macht, wird von diesem Zeitpunkt an Hersteller, nicht rückwirkend für frühere Fassungen.Leitlinien, Rn. 84 Eine gemeinnützige Organisation, die ihre Software monetarisiert, aber alle Einnahmen nach Abzug der Kosten gemeinnützig verwendet, bleibt Verwalter.Leitlinien, Rn. 66 und 77, Beispiel 24

Nordkessel als Verwalter der freien Fassung

Lesart des Verfassers Das Merkmal „für kommerzielle Tätigkeiten bestimmt“ ist bei einem Unternehmen, das die Software in eigene Produkte einbaut, nach hiesiger Lesart regelmäßig erfüllt, weil die Verordnung gerade diesen Fall in Erwägungsgrund 19 nennt. Ob eine Bibliothek, die ein Unternehmen nur für interne Werkzeuge veröffentlicht, ohne dass Dritte sie einbauen, für kommerzielle Tätigkeiten bestimmt ist, lässt der Text offen. Bis eine Behörde oder ein Gericht das klärt, führt Nordkessel auch solche Projekte wie Verwalterprojekte. Die Strategie nach Art. 24 Abs. 1 lässt sich mit den Schwachstellenprozessen verzahnen, die die bezahlte Fassung als Produkt nach Anhang I Teil II ohnehin braucht.

Zurück zum Inhalt

¶Meldet ein Verwalter, gilt für ihn ein anderer Stichtag

Die Meldepflicht des Art. 14 ist auf den Hersteller zugeschnitten. Für den Verwalter gilt sie nur über eine Verweisung, und die ist zweigeteilt. Die Pflicht, aktiv ausgenutzte Schwachstellen zu melden, gilt für Verwalter, soweit sie an der Entwicklung der Produkte beteiligt sind. Die Pflicht, schwerwiegende Sicherheitsvorfälle zu melden und Nutzer zu informieren, gilt, soweit solche Vorfälle die Netz- und Informationssysteme beeinträchtigen, die der Verwalter für die Entwicklung bereitstellt.Art. 24 Abs. 3, Art. 14 Abs. 1, 3 und 8 CRA Fristen, Plattform und Inhalt der Meldung stehen im Beitrag zur Meldepflicht nach CRA.

Verwaltungsauslegung Die Kommission staffelt die Pflicht nach der Art der Unterstützung, die der Verwalter leistet.Leitlinien, Rn. 79 bis 82

Die Pflicht knüpft an die Kenntnis der aktiven Ausnutzung an, nicht an das Vorhandensein einer Schwachstelle im Quellcode. Weil Open-Source-Komponenten meist in fremden Produkten laufen, erfährt der Verwalter von einer Ausnutzung typischerweise durch Dritte, etwa durch einen Hersteller, der sie in seinem Produkt entdeckt, oder durch Sicherheitsforscher.Leitlinien, Rn. 216

Ab wann der Verwalter melden muss

Für Hersteller gilt Art. 14 ab dem 11.9.2026, auch für Produkte, die vor dem 11.12.2027 in Verkehr gebracht wurden.Art. 71 Abs. 2, Art. 69 Abs. 3 CRA Für den Verwalter gilt nach dem Wortlaut der 11.12.2027, denn Art. 71 Abs. 2 zieht nur Art. 14 und Kapitel IV vor, und die Pflicht des Verwalters entsteht erst durch Art. 24 Abs. 3.

Die Kommissionsdienststellen haben das am 4.9.2026 in ihre FAQ aufgenommen, die ENISA am 7.9.2026 in ihre Fragen zur Meldeplattform.FAQ der Kommissionsdienststellen, Fassung 1.4, Nr. 5.5 Seit dem 8.9.2026 beschreibt die ENISA die Plattform zum Start als Weg für Pflichtmeldungen nach Art. 14.ENISA, Fragen zur Meldeplattform, Stand 8. September 2026, Nr. 4, 27 und 29

Überholte Gegenlesart Bis Anfang September war vertretbar, Art. 24 Abs. 3 als bloße Adressatenregel zu lesen, die mit Art. 14 vorgezogen ist. Dafür sprachen der Systemgedanke und die ENISA-Seite, die bis zum 4.9.2026 Verwalter als meldende Stellen ohne Datum führte.ENISA, Fragen zur Meldeplattform, Nr. 5 und 19 Der Beitrag zur Meldepflicht auf dieser Website vertrat diese Lesart mit ausgewiesener Unsicherheit und wird nachgezogen.Meldepflichten nach CRA, Abschnitt 4

Lesart des Verfassers Nach hiesiger Lesart besteht vor dem 11. Dezember 2027 keine Meldepflicht des Verwalters, und die Plattform bietet ihm zum Start auch keinen Weg. Bindend sind die FAQ nicht, sie sind ausdrücklich nicht die Position der Kommission selbst.FAQ der Kommissionsdienststellen, Fassung 1.4, Vorbemerkung

Was ein Verwalter bis zur Freischaltung freiwilliger Meldungen tut

Drei Dinge sind zu trennen: was rechtlich geschuldet ist, was die Plattform zum Start unterstützt und was vorsorglich sinnvoll ist. Die Karten ordnen sie.

Wer als Hersteller ein Produkt mit einer Komponente in Verkehr gebracht hat, steht anders da. Enthält das Produkt eine aktiv ausgenutzte Schwachstelle aus einer Komponente, meldet der Hersteller des Produkts. Ist die Schwachstelle im eigenen Produkt nicht ausnutzbar oder nicht ausgenutzt worden, besteht keine Pflicht nach Art. 14. Es bleiben die Rückmeldung an das Projekt nach Art. 13 Abs. 6 und die freiwillige Meldung nach Art. 15.Leitlinien, Rn. 218

Zurück zum Inhalt

¶Sorgfalt schuldet der Hersteller

Die Verordnung verlangt vom Hersteller, dass sein Produkt den grundlegenden Cybersicherheitsanforderungen entspricht, und sie weiß, dass ein Produkt aus fremden Teilen besteht. Deshalb ordnet sie an, dass der Hersteller beim Einbau von Komponenten Dritter die gebotene Sorgfalt walten lässt, damit diese Komponenten die Cybersicherheit des Produkts nicht beeinträchtigen. Das gilt ausdrücklich auch für freie und quelloffene Software, die nicht im Rahmen einer Geschäftstätigkeit bereitgestellt wurde.Art. 13 Abs. 5 CRA

Die Pflicht hat eine Kehrseite, die für Open-Source-Projekte wichtig ist. Wer eine Komponente einbaut, wird nicht für deren eigene Konformität verantwortlich, auch nicht, wenn er zu ihrer Pflege beiträgt. Ob die Komponente selbst unter die Verordnung fällt, hängt allein davon ab, ob ihr Herausgeber sie in Verkehr bringt.Leitlinien, Rn. 86 und 87 Verantwortlich ist der Hersteller für sein Produkt als Ganzes, einschließlich aller Komponenten, und zwar für die Dauer des Unterstützungszeitraums.Art. 13 Abs. 8 CRA, Erwägungsgrund 34

Was Sorgfalt nach der Verordnung bedeutet

Der Umfang richtet sich nach Art und Ausmaß des Cybersicherheitsrisikos, das mit der Komponente verbunden ist. Der Erwägungsgrund nennt vier Maßnahmen, von denen eine oder mehrere in Betracht kommen. Zu prüfen ist, ob der Hersteller der Komponente die Konformität nachgewiesen hat, etwa durch eine CE-Kennzeichnung, und ob die Komponente regelmäßig Sicherheitsaktualisierungen erhält. Zu prüfen ist ferner, ob sie frei von den in öffentlichen Datenbanken registrierten Schwachstellen ist, oder es sind zusätzliche Sicherheitstests durchzuführen.Erwägungsgrund 34 CRA

Verwaltungsauslegung Die Kommission trennt die Sorgfalt von der Risikobewertung des Produkts. Die Risikobewertung nach Art. 13 Abs. 2 erfasst das Produkt und die Risiken seiner Umgebung, die Sorgfalt nach Art. 13 Abs. 5 die Bestandteile, die im Produkt stecken. Sorgfalt heißt, festzulegen, was das Produkt von der Komponente braucht, etwa Kryptografie, Aktualisierungsmechanismus oder sichere Kommunikation, und risikobasiert zu prüfen, ob die Komponente das leistet. Nachweise sind die Dokumentation des Komponentenherstellers oder eigene Tests.Leitlinien, Rn. 167, 170 und 171

Zwei Klarstellungen nehmen der Pflicht ihren Schrecken. Ein Hersteller darf Komponenten einbauen, die keine CE-Kennzeichnung tragen, etwa Open Source außerhalb der Verordnung, Komponenten eines Verwalters oder Komponenten aus der Zeit vor dem Geltungsbeginn. Er muss sie nicht selbst konform machen, sondern dafür sorgen, dass sein Produkt konform ist.FAQ der Kommissionsdienststellen, Nr. 4.4.3 und 4.4.4 Und unmittelbar nach dem Geltungsbeginn wird er oft nicht prüfen können, ob eine Komponente eine CE-Kennzeichnung trägt, weil sie früher eingebaut wurde. Dann erfüllt er die Sorgfalt auf andere Weise.Erwägungsgrund 35 CRA

Bekannte ausnutzbare Schwachstellen

Beim Inverkehrbringen muss das Produkt, soweit zutreffend, frei von bekannten ausnutzbaren Schwachstellen sein.Anhang I Teil I Nr. 2 lit. a CRA Bekannt ist eine Schwachstelle nach der Kommission, wenn sie in einer einschlägigen öffentlichen Datenbank steht, wenn der Hersteller sie durch koordinierte Offenlegung, eigene Tests oder verlässliche Medienberichte erfahren hat. Ob sie im konkreten Produkt ausnutzbar ist, muss der Hersteller prüfen, und die Entscheidung über das Inverkehrbringen bleibt risikobasiert.Leitlinien, Rn. 233 bis 237

Nordkessel und seine vier Komponenten

Lesart des Verfassers Die Verordnung sagt nicht, wie viele Prüfungen genügen. Nach hiesiger Lesart bilden je Komponente drei Angaben die Grundstruktur der Sorgfaltsdokumentation nach Art. 13 Abs. 7 und Art. 31. Erstens die Anforderung des Produkts an sie, zweitens die gewählten Maßnahmen mit Grund, drittens der Rhythmus der Wiederholung, jeweils ergänzt um Ergebnis und Nachweis der Prüfung. Eine Liste der Abhängigkeiten ohne diese drei Angaben ist eine Stückliste, keine Sorgfalt.

Zurück zum Inhalt

¶Findet der Hersteller die Schwachstelle, meldet er sie

Sobald der Hersteller eine Schwachstelle in einer eingebauten Komponente feststellt, auch in einer quelloffenen, meldet er sie der Person oder Einrichtung, die die Komponente herstellt oder wartet, und behandelt sie nach Anhang I Teil II. Hat er eine Änderung entwickelt, um die Schwachstelle zu beheben, teilt er den Code oder die Unterlagen dieser Person oder Stelle mit, gegebenenfalls in maschinenlesbarem Format.Art. 13 Abs. 6 CRA Der Erwägungsgrund fasst es kürzer: informieren, beheben, die Änderung bereitstellen.Erwägungsgrund 34 CRA

Diese Pflicht ist der Preis dafür, dass die Verordnung Open-Source-Projekte außerhalb des Marktes weitgehend verschont. Wer von der Arbeit der Projekte profitiert, gibt gefundene Fehler zurück. Für die Frage, wann und wie, hat die Kommission vier Regeln formuliert, die den Aufwand auf beiden Seiten begrenzen.Leitlinien, Rn. 222 bis 229

Verwaltungsauslegung Die Kommission stellt klar, dass der Hersteller weder dafür sorgen muss, dass seine Änderung angenommen wird, noch dafür, dass er in das Repositorium gelangt. Zieht das Projekt eine andere Lösung vor, bleibt das seine Sache. Wählt der Hersteller statt einer Änderung an der Komponente eine Abhilfe an anderer Stelle seines Produkts, etwa in dessen Konfiguration, muss er sie nicht zurückgeben, auch wenn die Kommission es empfiehlt. Mitzuteilen sind nur Änderungen an der Komponente selbst.Leitlinien, Rn. 228 und 229

Verhältnis zur Meldung an die Behörde

Die Rückmeldung an das Projekt und die Meldung an CSIRT und ENISA sind zwei verschiedene Pflichten mit verschiedenen Auslösern. Die Rückmeldung greift bei jeder festgestellten Schwachstelle in der Komponente. Die Meldung nach Art. 14 greift nur bei einer aktiv ausgenutzten Schwachstelle im eigenen Produkt oder bei einem schwerwiegenden Vorfall.Art. 13 Abs. 6, Art. 14 Abs. 1 und 3 CRA Eine Schwachstelle in einer Komponente, die im eigenen Produkt nicht erreichbar ist, wird also dem Projekt gemeldet, der Behörde aber nicht, es sei denn freiwillig.FAQ der Kommissionsdienststellen, Nr. 5.4

Lesart des Verfassers Die Verordnung nennt für die Rückmeldung keine Frist, nur das Wort „sobald“. Nach hiesiger Lesart ist das enger als „unverzüglich“ im Sinne einer Prüfungsfrist: Die Rückmeldung folgt der Feststellung, nicht der Behebung. Wer erst die eigene Änderung fertigstellt und dann meldet, verschiebt die Kenntnis des Projekts um Wochen. Die Änderung kann nachgereicht werden, die Meldung nicht.

Zurück zum Inhalt

¶Stückliste und CE-Kennzeichnung sind nicht dasselbe

Drei Nachweise werden im Zusammenhang mit Open Source ständig verwechselt. Die Software-Stückliste ist eine Pflicht des Herstellers für sein Produkt. Die Sicherheitsbescheinigung ist ein freiwilliges Programm, das es noch nicht gibt. Die CE-Kennzeichnung ist die Erklärung des Herstellers, dass sein Produkt konform ist, und dem Verwalter untersagt.

Die Stückliste

Normtext Die Stückliste ist eine formale Aufzeichnung der Einzelheiten und Lieferkettenbeziehungen der Komponenten in den Softwareelementen des Produkts.Art. 3 Nr. 39 CRA Drei Dinge fallen auf. Die Verordnung verlangt kein bestimmtes Format, sie nennt als Mindestmaß die obersten Abhängigkeiten, und sie verlangt keine Veröffentlichung.

Die ersten beiden Punkte können sich ändern. Die Kommission kann Format und Elemente der Stückliste durch Durchführungsrechtsakt festlegen.Art. 13 Abs. 24 CRA Davon zu trennen ist die Vorlage: Marktüberwachungsbehörden können Hersteller bestimmter Produktkategorien auffordern, ihre Stücklisten vorzulegen, wenn die Verwaltungskooperationsgruppe eine unionsweite Bewertung der Abhängigkeit von Softwarekomponenten beschließt, insbesondere von quelloffenen.Art. 13 Abs. 25 CRA Eine Vorlage gegenüber der Behörde ist keine Veröffentlichung, und eine Veröffentlichungspflicht folgt aus keiner der beiden Vorschriften. Ein Durchführungsrechtsakt zum Format lag zum Rechtsstand dieses Beitrags nicht vor.

Lesart des Verfassers Die Stückliste nach der Verordnung dient der Schwachstellenbehandlung, die Stückliste nach dem Lizenzrecht der Rechtekette, und beide brauchen andere Felder. Wer bereits eine Lizenz-Stückliste führt, hat einen Anfang, nicht das Ergebnis. Die Lizenzliste fragt nach Urheber, Lizenz und Weitergabepflichten, die Verordnung nach Version, Herkunft, Pflegestand und Schwachstellen. Nach hiesiger Lesart genügt eine Aufzeichnung beiden Zwecken nur, wenn sie je Komponente die genaue Version, die Bezugsquelle und den Stand der Sicherheitsaktualisierung führt. Die Lizenzseite prüft der Open-Source- und SBOM-Check.

Die Bescheinigung nach Art. 25

Die Programme sollen so angelegt sein, dass auch Hersteller, die die Komponente einbauen, oder öffentliche Verwaltungen eine Bescheinigung anstoßen und finanzieren können.Erwägungsgrund 21 CRA

Normtext Art. 25 ist eine Ermächtigung, keine Pflicht und kein bestehendes Programm. Ein delegierter Rechtsakt lag zum Rechtsstand nicht vor, und die Kommissionsdienststellen sprechen davon, dass solche Programme die Sorgfalt erleichtern würden, „sofern verfügbar“.FAQ der Kommissionsdienststellen, Nr. 4.4.4 Eine Bescheinigung ersetzt die Sorgfalt des Herstellers nicht, sie ist eines ihrer Beweismittel.

Die CE-Kennzeichnung

Mit der CE-Kennzeichnung erklärt der Hersteller, dass das Produkt und seine Verfahren den grundlegenden Cybersicherheitsanforderungen genügen. Sie setzt das Konformitätsverfahren, die technische Dokumentation und die EU-Konformitätserklärung voraus.Art. 3 Nr. 31, Art. 13 Abs. 12 CRA Verwalter dürfen sie nicht anbringen, weil ihr Pflichtenregime hinter dem der Hersteller zurückbleibt.Erwägungsgrund 19 CRA

Zurück zum Inhalt

¶Auch in Deutschland steht nur der Meldeempfänger fest

Die Verordnung gilt unmittelbar, aber jeder Mitgliedstaat benennt die Stellen, die sie vollziehen, und regelt das Bußgeldverfahren.Art. 64 Abs. 1 CRA Für Deutschland stehen zwei Dinge fest und eines noch nicht.

Fest steht der Empfänger der Meldung. Die ENISA führt seit dem 4. September 2026 für jeden Mitgliedstaat das als Koordinator benannte CSIRT, für Deutschland das CERT-Bund beim Bundesamt für Sicherheit in der Informationstechnik.ENISA, Koordinatorenliste vom 4. September 2026

Fest steht auch der unionsrechtliche Bußgeldrahmen. Verstöße gegen Anhang I oder gegen die Art. 13 und 14 können Geldbußen bis zu 15 Millionen Euro nach sich ziehen, bei Unternehmen bis zu 2,5 Prozent des weltweiten Jahresumsatzes, wenn das mehr ist. Verwalter quelloffener Software sind davon ausgenommen.Art. 64 Abs. 2 und Abs. 10 lit. b CRA

Lesart des Verfassers Der Beitrag zur Meldepflicht nach CRA legt dar, warum der Bußgeldrahmen des Art. 64 nach dem Wortlaut des Art. 71 Abs. 2 erst am 11. Dezember 2027 anwendbar wird und der Entwurf diese Lesart teilt. Für Open Source folgt daraus wenig Neues. Für Verwalter gibt es ohnehin keine Geldbuße, und für Hersteller entsteht der Druck vor Dezember 2027 über Kunden, Vergabe und Zusicherungen, nicht über das Bundesamt.

Was der Entwurf für Open-Source-Projekte vorsieht

Verstöße von Wirtschaftsakteuren gegen die Verordnung, die Kollektivinteressen der Verbraucher beeinträchtigen, können Gegenstand einer Verbandsklage nach der Richtlinie (EU) 2020/1828 sein.Art. 65 CRA Für Hersteller von Verbraucherprodukten mit Open-Source-Anteil ist das die zweite Flanke neben der Behörde.

Zurück zum Inhalt

¶Erst die Rolle, dann der Plan

Die folgende Prüfung ist eine Lesart des Verfassers. Sie ordnet die Fragen der Abschnitte 2 bis 6 in der Reihenfolge, in der sie zu stellen sind, und sagt bei jedem Nein, welcher Weg bleibt. Sie ersetzt die Einzelfallprüfung nicht, weil jede Stufe eine Bewertung verlangt.

Der Umsetzungsplan in sechs Schritten

Die Schritte sind eine Empfehlung des Verfassers. Sie folgen nicht unmittelbar aus der Verordnung, sondern aus der Bewertung, welche Nachweise Behörden, Kunden und Projekte voraussichtlich erwarten.

1. Software-Inventar mit RolleJede veröffentlichte und jede eingebaute Software mit Version, Herausgeber, Lizenz, Bezugsquelle und der Rolle nach dem Prüfbaum erfassen. Das Inventar ist der Anfang der Stückliste nach Anhang I Teil II Nr. 1.
2. Cybersicherheitsstrategie für VerwalterprojekteFür jede Software in der Verwalterrolle die Strategie nach Art. 24 Abs. 1 dokumentieren: Meldekanal für Schwachstellen, Behebung, Offenlegung, Informationsaustausch, Förderung freiwilliger Meldungen. Überprüfbar heißt datiert und versioniert.
3. Sorgfaltsdokumentation je KomponenteFür jede eingebaute Komponente festhalten, was das Produkt von ihr braucht, welche Maßnahmen aus Erwägungsgrund 34 und den Fragen der Kommission gewählt wurden und wann sie wiederholt werden. Für Komponenten ohne Pflegezusage einen Ersatzplan hinterlegen.
4. Rückmeldeweg zu jedem ProjektFür jede Komponente den Kanal des Projekts für Schwachstellen ermitteln und intern zuordnen, wer meldet und wer die Änderung lizenzverträglich aufbereitet. Fehlt ein Kanal, den Ersatzweg nach Leitlinien Rn. 225 festlegen.
5. Meldekette mit beiden RollenDen Meldeprozess nach Art. 14 aus dem Beitrag zur Meldepflicht um die Verwalterrolle ergänzen. Festzulegen ist, wer für welche Software meldet, ab wann, und wie eine vorsorgliche Information vor dem 11. Dezember 2027 dokumentiert wird. Registrierung bei der Meldeplattform mit EU-Login vorbereiten.
6. Nachweise für Dezember 2027 anlegenFür jedes in Verkehr gebrachte Produkt das Konformitätsverfahren wählen und die technische Dokumentation beginnen. Bei freier und quelloffener Software nach Anhang III prüfen, ob Art. 32 Abs. 5 das interne Verfahren gegen die Veröffentlichung der Dokumentation eröffnet.

Die Reihenfolge folgt der Abhängigkeit. Ohne Inventar keine Rolle, ohne Rolle keine Strategie, ohne Sorgfaltsdokumentation keine belastbare Stückliste, und ohne Rückmeldeweg bleibt die beste Änderung im eigenen Haus. Wer den ersten Schritt gründlich geht, hat für die übrigen fünf die Hälfte der Arbeit getan.

Zurück zum Inhalt

¶Behörde, Kunde und Projekt sehen die Rolle anders

Wer seine Rolle nach dem Prüfbaum bestimmt hat, sollte wissen, was die Gegenseite sagen wird. Drei Gegenseiten kommen in Betracht, und jede hat ein Argument, das im eigenen Haus leicht überhört wird.

Die Rolle nach dem CRA sagt nichts über Lizenz und Haftung

Wer außerhalb der Verordnung steht, steht nicht außerhalb des Rechts, und wer Hersteller ist, hat damit weder die Lizenzfrage noch die Haftungsfrage beantwortet. Die Lizenz einer eingebauten Komponente, ihre Copyleft-Wirkung und die Pflicht zur Weitergabe des Quellcodes folgen dem Urheberrecht und dem Lizenzvertrag, nicht dem CRA. Ein Verstoß dort kann einen Mangel des Produkts begründen, wie der Beitrag Open-Source-Verstoß im Fahrzeug zeigt.

Die Produkthaftung läuft ebenfalls getrennt. Die Kommission weist darauf hin, dass reiner Quellcode nach der neuen Produkthaftungsrichtlinie kein Produkt ist, Software als solche aber schon, sodass ein Hersteller, der Quellcode in Verkehr bringt, nach nationalem Deliktsrecht haften kann.Leitlinien, Rn. 24 mit Fußnote 9 Wer als Verwalter keine Pflichten nach Art. 13 hat, kann gleichwohl für einen Schaden einstehen müssen, den seine Software verursacht. Diese Fragen behandelt Software als Produkt ab 9. Dezember 2026.

Die Parallelregime in einem Satz: NIS 2 und das BSI-Gesetz treffen den Betreiber, die Datenschutz-Grundverordnung den Verantwortlichen bei einer Datenpanne, die Produkthaftung den Hersteller des Endprodukts. Ein Vorfall kann alle vier Regime zugleich auslösen, wie Cybervorfall melden ausführt.

Erfahrung der Kanzlei Der häufigste Fehler in Gesprächen mit Herstellern ist der Umkehrschluss: Weil das Projekt keine Pflichten hat, habe die Komponente auch kein Risiko. Der zweithäufigste ist der Umkehrschluss bei Projekten: Weil die freie Fassung keine Pflichten auslöst, dürfe man Sicherheitsaktualisierungen für die bezahlte Fassung zurückhalten. Beides löst genau die Prüfung aus, die vermieden werden sollte.

Zurück zum Inhalt

¶Welche Annahmen der Verordnung nicht standhalten

Zehn Annahmen aus Erstgesprächen mit Herstellern und Projekten. Jede lässt sich an einer behandelten Norm oder an den Leitlinien messen, und jede hat eine Folge für das eigene Vorgehen.

Zurück zum Inhalt

¶Ob die Plattform freiwillige Meldungen öffnet, ist offen

Ob die Plattform freiwillige Meldungen öffnet, ist offenAbschnitt 13 von 1413/14

Rechtsprechung zur Cyberresilienz-Verordnung gibt es nicht, weder zu Open Source noch zu irgendeiner anderen Frage. Was es gibt, sind der Wortlaut, die unverbindlichen Leitlinien der Kommission, die Fragen und Antworten ihrer Dienststellen und die Praxis der ENISA. Wo diese Quellen auseinanderfallen oder schweigen, steht unten der Stand, die Lesart des Verfassers und was heute zu tun ist, solange die Lesart nicht bestätigt ist.

Vier offene Fragen mit Stand, Lesart des Verfassers und heutigem Verhalten

Frage	Stand	Lesart des Verfassers	Heute
Wann öffnet die Plattform freiwillige Meldungen, und wie informiert ein Verwalter bis dahin?	Die Pflicht gilt ab dem 11.12.2027, so Wortlaut, Kommissionsdienststellen und ENISA (Abschnitt 5). Die Plattform unterstützt zum Start Pflichtmeldungen nach Art. 14, freiwillige Meldungen nach Art. 15 folgen ohne Termin, ENISA Nr. 4 und 27. Wer nicht Hersteller ist und eine Schwachstelle melden will, wendet sich nach ENISA Nr. 30 direkt an das zuständige CSIRT.	Zum Plattformstart sind nur Pflichtmeldungen der Hersteller vorgesehen, freiwillige Meldungen sollen später möglich werden, einen Termin nennt die ENISA nicht. Bis dahin ist das CSIRT der direkte Weg. Die Ergänzungslesart, Art. 24 sei mit Art. 14 vorgezogen, ist ohne Stütze.	Keine Pflicht annehmen, Informationen über Projektkanäle an Maintainer und Hersteller weitergeben, eine vorsorgliche Information an das CERT-Bund je Fall abwägen und dokumentieren.
Wann werden Spenden zum Preis?	Spenden ohne Gewinnabsicht sind keine Geschäftstätigkeit, Erwägungsgrund 15. Die Kommission verlangt eine Gesamtwürdigung und sieht die Grenze dort, wo Zugang, Kernfunktionen oder Aktualisierungen faktisch von der Spende abhängen, Rn. 61 und 62.	Entscheidend ist die Bindung des Zugangs, nicht die Höhe. Ein Projekt, das neue Versionen und Sicherheitsaktualisierungen für alle gleich freigibt, bleibt außerhalb, auch mit hohen Spenden.	Neue Versionen, Binärdateien und Sicherheitsaktualisierungen für alle Nutzer gleich zugänglich halten, Spendenvorteile auf Nennung und Zugang zu Gesprächen beschränken.
Welches Format braucht die Stückliste?	Verlangt ist ein gängiges maschinenlesbares Format mit mindestens den obersten Abhängigkeiten, Anhang I Teil II Nr. 1. Ein Durchführungsrechtsakt nach Art. 13 Abs. 24 lag zum Rechtsstand nicht vor.	Solange kein Rechtsakt ergeht, genügt jedes verbreitete maschinenlesbare Format. Eine Vorgabe der Kommission dürfte an bestehende Formate anknüpfen, nicht ein neues schaffen.	Ein verbreitetes maschinenlesbares Format wählen, Version und Bezugsquelle je Komponente führen, tiefer als die oberste Ebene, wo die Sorgfalt es verlangt.
Kommt die Sicherheitsbescheinigung nach Art. 25?	Art. 25 ermächtigt die Kommission zu freiwilligen Programmen. Ein delegierter Rechtsakt lag zum Rechtsstand nicht vor, die Dienststellen sprechen von Programmen, „sofern verfügbar“, FAQ 4.4.4.	Mit einem Programm vor dem Geltungsbeginn im Dezember 2027 rechnet der Verfasser nicht, das ist eine Prognose. Bis dahin bleibt die Sorgfalt des Herstellers der Nachweis, den die Verordnung vorsieht, Art. 13 Abs. 5.	Sorgfaltsdokumentation je Komponente führen und Nachweise des Projekts sammeln, statt auf eine Bescheinigung zu warten.

Eine fünfte Frage betrifft das Merkmal „für kommerzielle Tätigkeiten bestimmt“ bei Bibliotheken, die ein Unternehmen nur für eigene interne Werkzeuge veröffentlicht. Der Wortlaut und Erwägungsgrund 19 zielen auf Software, die in kommerzielle Dienste oder bezahlte Produkte eingeht.Art. 3 Nr. 14, Erwägungsgrund 19 CRA Offene Frage Ob eine Veröffentlichung ohne Einbau in ein Produkt darunter fällt, ist nicht geklärt. Solange das so ist, führt ein Unternehmen wie Nordkessel auch diese Projekte mit einer Strategie nach Art. 24 Abs. 1. Der Aufwand ist gering, und die Strategie lässt sich mit den Schwachstellenprozessen verzahnen, die die bezahlten Fassungen nach Anhang I Teil II ohnehin brauchen.

Fortgeschrieben wird dieser Beitrag bei vier Ereignissen: einem Durchführungsrechtsakt zur Stückliste, einem Programm nach Art. 25, der deutschen Fassung der Leitlinien und der Verkündung des Durchführungsgesetzes. Die Kommission hat im Juli nur den Inhalt des Entwurfs gebilligt und die förmliche Annahme an das Vorliegen aller Sprachfassungen geknüpft.Mitteilung C(2026) 5252 final, Deckblatt Ebenso, sobald eine Behörde oder ein Gericht den Verwalterstichtag entscheidet.

Zurück zum Inhalt

Zurück zum Inhalt

¶Häufige Fragen

Zehn Fragen aus Gesprächen mit Herstellern und Projekten. Jede Antwort beruht auf einem Abschnitt dieses Beitrags und trägt dessen Vorbehalte.

Wann unterliegt Open Source den Herstellerpflichten des Cyber Resilience Act?

Wenn sie im Rahmen einer Geschäftstätigkeit auf dem Markt bereitgestellt wird. Freie und quelloffene Software, die ihr Hersteller nicht zu Geld macht, gilt nach Erwägungsgrund 18 nicht als Geschäftstätigkeit. Zur Geschäftstätigkeit führen ein Preis, eine an den Zugang gebundene technische Unterstützung oder Spenden als faktische Zugangsbedingung. Ebenso die Verarbeitung personenbezogener Daten als Nutzungsbedingung, außer sie dient allein der Sicherheit, Kompatibilität oder Interoperabilität. Unabhängig davon können juristische Personen als Verwalter quelloffener Software eigenen Pflichten unterliegen.

Was ist ein Verwalter quelloffener Software?

Eine juristische Person, die nicht Hersteller ist und bestimmte freie und quelloffene Software systematisch und nachhaltig unterstützt (Art. 3 Nr. 14 CRA). Die Software muss für kommerzielle Tätigkeiten bestimmt sein, und die Person sichert ihre Brauchbarkeit. Sie muss eine Cybersicherheitsstrategie dokumentieren, mit der Marktüberwachung zusammenarbeiten und in engen Grenzen melden. Sie darf keine CE-Kennzeichnung anbringen, und Von den Geldbußen nach Art. 64 Abs. 2 bis 9 ist sie ausgenommen.

Ist eine GmbH mit einer freien und einer bezahlten Fassung derselben Software Hersteller oder Verwalter?

Beides, aber für verschiedene Produkte. Für die bezahlte Fassung ist sie Hersteller, für die freie in der Regel Verwalter, wenn sie diese dauerhaft betreut. Die Kommission behandelt die beiden Fassungen als zwei Produkte, auch beim Open-Core-Modell (Leitlinien Rn. 52, 53 und 76).

Ab wann muss ein Verwalter Schwachstellen melden?

Nach dem Wortlaut des Art. 71 Abs. 2 CRA gilt Art. 24 Abs. 3 erst ab dem 11.12.2027. So auch die Kommissionsdienststellen in der Fassung 1.4 ihrer Fragen und die ENISA. Die Meldeplattform unterstützt zum Start Pflichtmeldungen der Hersteller nach Art. 14. Nach hiesiger Lesart besteht vor Dezember 2027 keine Meldepflicht des Verwalters. Er gibt Informationen über Projektkanäle weiter, prüft eine eigene Herstellerrolle gesondert und wägt eine vorsorgliche Information an das CERT-Bund je Fall ab.

Muss ich als Hersteller für Schwachstellen in eingebauter Open Source einstehen?

Sie schulden Sorgfalt beim Einbau nach dem Risiko der Komponente (Art. 13 Abs. 5 CRA). Dazu die Behandlung von Schwachstellen in Ihrem Produkt einschließlich seiner Komponenten (Art. 13 Abs. 8 CRA). Die eigene Konformitätsverantwortung des Komponentenherstellers übernehmen Sie nicht (Leitlinien Rn. 86). Maßnahmen sind unter anderem die Prüfung der Aktualisierungshistorie, der Abgleich mit Schwachstellendatenbanken und zusätzliche Tests (Erwägungsgrund 34).

Was muss ich dem Open-Source-Projekt melden, wenn ich eine Schwachstelle finde?

Jede in der eingebauten Komponente festgestellte Schwachstelle, an die Person oder Einrichtung, die sie herstellt oder wartet, über deren Meldekanal (Art. 13 Abs. 6 CRA). Dazu eine selbst entwickelte Änderung in maschinenlesbarer, lizenzverträglicher Form. Nicht geschuldet sind Meldungen, die das Projekt nachweislich schon kennt, und die Annahme Ihrer Änderung (Leitlinien Rn. 223 und 228).

Muss die Software-Stückliste veröffentlicht werden?

Die Verordnung verlangt eine Stückliste in einem gängigen maschinenlesbaren Format, aus der mindestens die obersten Abhängigkeiten hervorgehen (Anhang I Teil II Nr. 1 CRA). Eine Veröffentlichungspflicht enthält sie nicht. Marktüberwachungsbehörden können die Stückliste anfordern, wenn die Verwaltungskooperationsgruppe eine Abhängigkeitsbewertung beschließt (Art. 13 Abs. 25 CRA). Kunden können die Vorlage vertraglich verlangen.

Kann ich eine eingebaute Komponente ohne CE-Kennzeichnung verwenden?

Ja. Komponenten ohne CE-Kennzeichnung, etwa Open Source außerhalb der Verordnung oder Komponenten eines Verwalters, dürfen eingebaut werden. Sie müssen sie nicht selbst konform machen, sondern durch Sorgfalt dafür sorgen, dass Ihr Produkt konform ist (FAQ 4.4.3, Erwägungsgrund 35).

Gibt es die Sicherheitsbescheinigung für Open Source nach Art. 25 schon?

Nein. Art. 25 CRA ermächtigt die Kommission, freiwillige Bescheinigungsprogramme durch delegierte Rechtsakte einzuführen. Ein solcher Rechtsakt lag zum Rechtsstand dieses Beitrags nicht vor. Eine Bescheinigung würde die Sorgfalt des Herstellers erleichtern, nicht ersetzen.

Wer ist in Deutschland zuständig, und wann drohen Bußgelder?

Meldungen gehen über die Plattform der ENISA an das CERT-Bund beim BSI, das die ENISA seit dem 4. September 2026 als Koordinator führt. Nach dem Regierungsentwurf des Durchführungsgesetzes soll das BSI auch Marktüberwachungs- und Bußgeldbehörde werden. Der Bußgeldrahmen des Art. 64 wird nach der im Beitrag zur Meldepflicht vertretenen Auslegung erst am 11. Dezember 2027 anwendbar, und Verwalter sind von Geldbußen ausgenommen.

Zurück zum Inhalt

Begriffe

Freie und quelloffene Software

Software, deren Quellcode offen geteilt wird und die unter einer kostenlosen Open-Source-Lizenz steht, die alle Rechte vorsieht, sie frei zugänglich, nutzbar, veränderbar und weiterverteilbar zu machen. Beide Merkmale müssen vorliegen. Art. 3 Nr. 48 CRA.

Bereitstellung auf dem Markt

Die entgeltliche oder unentgeltliche Abgabe eines Produkts mit digitalen Elementen zum Vertrieb oder zur Verwendung auf dem Unionsmarkt im Rahmen einer Geschäftstätigkeit. Ohne Geschäftstätigkeit keine Bereitstellung. Art. 3 Nr. 22 CRA.

Hersteller

Wer Produkte mit digitalen Elementen entwickelt oder entwickeln lässt und unter eigenem Namen oder eigener Marke vermarktet, gegen Bezahlung, zur Monetarisierung oder unentgeltlich. Als Hersteller gilt auch, wer ein Produkt unter eigenem Namen in Verkehr bringt oder wesentlich ändert. Art. 3 Nr. 13, Art. 21, 22 CRA.

Verwalter quelloffener Software

Juristische Person, die nicht Hersteller ist und die Entwicklung bestimmter freier und quelloffener Software, die für kommerzielle Tätigkeiten bestimmt ist, systematisch und nachhaltig unterstützt und deren Brauchbarkeit sicherstellt. Pflichten nach Art. 24, keine CE-Kennzeichnung, ausgenommen von den Geldbußen nach Art. 64 Abs. 2 bis 9. Art. 3 Nr. 14, Art. 24, Art. 64 Abs. 10 lit. b CRA.

Beitragender

Wer Quellcode zu einer Software beisteuert, die nicht seiner Verantwortung unterliegt, weil er weder Versionsfreigabe noch Verteilung noch Leitung des Projekts steuert. Die Verordnung gilt für ihn nicht. Kein Begriff der Verordnung, Umschreibung nach Erwägungsgrund 18 CRA und Leitlinien Rn. 49.

Sorgfaltspflicht beim Einbau

Pflicht des Herstellers, beim Einbau fremder Komponenten dafür zu sorgen, dass sie die Cybersicherheit seines Produkts nicht beeinträchtigen, im Umfang nach dem Risiko der Komponente. Art. 13 Abs. 5, Erwägungsgrund 34 CRA.

Rückmeldung an das Projekt

Pflicht des Herstellers, eine in einer Komponente festgestellte Schwachstelle der Person oder Einrichtung zu melden, die die Komponente herstellt oder wartet, und eine entwickelte Änderung mitzuteilen. Art. 13 Abs. 6 CRA.

Software-Stückliste

Formale Aufzeichnung der Einzelheiten und Lieferkettenbeziehungen der Komponenten in den Softwareelementen eines Produkts, in gängigem maschinenlesbarem Format mit mindestens den obersten Abhängigkeiten. Art. 3 Nr. 39, Anhang I Teil II Nr. 1 CRA.

Sicherheitsbescheinigung

Freiwilliges Programm zur Bewertung der Konformität freier und quelloffener Software, das die Kommission durch delegierten Rechtsakt einführen darf. Zum Rechtsstand nicht eingerichtet. Art. 25 CRA.

Aktiv ausgenutzte Schwachstelle

Schwachstelle, zu der verlässliche Nachweise vorliegen, dass ein böswilliger Akteur sie in einem System ohne Zustimmung des Systemeigners ausgenutzt hat. Nur sie löst die Meldung nach Art. 14 Abs. 1 aus. Art. 3 Nr. 42 CRA.

Quellen

1. Verordnung (EU) 2024/2847 des Europäischen Parlaments und des Rates vom 23. Oktober 2024 über horizontale Cybersicherheitsanforderungen für Produkte mit digitalen Elementen (Cyberresilienz-Verordnung), ABl. L, 2024/2847 vom 20.11.2024, deutsche Sprachfassung, EUR-Lex, abgerufen am 7.9.2026. Zitiert in der Fassung der Berichtigungen vom 2.7.2025 (Quelle 2), vom 17.10.2025 (ABl. L, 2025/90828, Art. 67) und vom 6.8.2026 (ABl. L, 2026/90667, deutsche Sprachfassung: Art. 7 Abs. 2, Art. 13 Abs. 15, Art. 17 Abs. 1, Art. 55 Abs. 4, Anhang VIII), die beiden letzten ohne Auswirkung auf die hier zitierten Stellen. Geändert durch Art. 104 der Verordnung (EU) 2025/327 in Art. 13 Abs. 4, Art. 31 Abs. 3 und Art. 32, hier nicht zitierte Stellen ausgenommen Art. 32 Abs. 5.
2. Berichtigung der Verordnung (EU) 2024/2847, ABl. L, 2025/90555 vom 2.7.2025, betreffend Art. 13 Abs. 8 und Art. 64 Abs. 10, EUR-Lex, abgerufen am 7.9.2026.
3. Europäische Kommission, Leitlinien zur Anwendung der Verordnung (EU) 2024/2847 (Cyber Resilience Act), Anhang zu C(2026) 5252 final vom 27.7.2026, englische Fassung, 84 Seiten, Abschnitte 2.3, 3, 7.3, 9.1 und 9.2, Randnummern nach dem Dokument, digital-strategy.ec.europa.eu, abgerufen am 7.9.2026.
4. Europäische Kommission, Mitteilung an die Kommission, Billigung des Inhalts des Entwurfs einer Mitteilung der Kommission, C(2026) 5252 final vom 27.7.2026, digital-strategy.ec.europa.eu, abgerufen am 7.9.2026.
5. Kommissionsdienststellen, FAQs on the Cyber Resilience Act, Fassung 1.4 vom 4.9.2026, Nr. 4.4, 5.3, 5.4, 5.5 und 6.1, ec.europa.eu, abgerufen am 7.9.2026. Nach eigener Vorbemerkung nicht die offizielle Position der Kommission.
6. ENISA, Cyber Resilience Act Single Reporting Platform, Frequently Asked Questions, Seitenvermerk „Updated: 08 September 2026“, Nr. 4, 5, 7, 9, 19, 25, 27, 28, 29 und 30, enisa.europa.eu, abgerufen am 8.9.2026 im Browser. Die Seite wurde am 4., 7. und 8.9.2026 geändert (Verwalterstichtag, Plattformumfang zum Start), zwischengespeicherte Abrufe lieferten ältere Fassungen. Nummerierung und Wortlaut können abweichen.
7. ENISA, List of CSIRTs Designated as Coordinators, Stand 4.9.2026, enisa.europa.eu, abgerufen am 7.9.2026.
8. Bundesministerium des Innern, Referentenentwurf eines Gesetzes zur Durchführung der Verordnung (EU) 2024/2847, Bearbeitungsstand 12.3.2026, überholt durch den Regierungsentwurf (Quelle 9), herangezogen für die Abweichungen zwischen beiden Fassungen.
9. Deutscher Bundestag, Drucksache 21/6134 vom 26.5.2026, Entwurf eines Gesetzes zur Durchführung der Verordnung (EU) 2024/2847, Art. 1 (§§ 65 bis 70 BSIG-E), Art. 4 und Begründung, dazu Drucksache 21/6512 vom 15.6.2026 (Stellungnahme des Bundesrates), dserver.bundestag.de, abgerufen am 7.9.2026. Erste Lesung am 11.6.2026, federführend der Innenausschuss.
10. Europäische Kommission, Kommission veröffentlicht neue Leitlinien zur Unterstützung der rechtzeitigen Umsetzung des Cyberresilienzgesetzes, Bibliothekseintrag vom 27.7.2026, digital-strategy.ec.europa.eu, abgerufen am 7.9.2026.
11. Bohne, Cyber Resilience Act: Meldepflichten nach CRA, Art. 14 Cyberresilienz-Verordnung in der Praxis, ITMR Rechtsanwälte, Rechtsstand 6.8.2026, itmr-legal.de/blog/cra-meldepflicht-art-14, abgerufen am 7.9.2026.

Zur Quellenlage

Rechtsstand ist der 8.9.2026. Der Beitrag beruht auf der deutschen Sprachfassung der Verordnung im Amtsblatt in der Fassung der Berichtigung vom 2.7.2025 und auf den Leitlinien der Kommission in englischer Sprache. Hinzu kommen die Fragen und Antworten der Kommissionsdienststellen in der Fassung vom 4.9.2026 und die Verfahrensangaben der ENISA.

Die Berichtigungen vom 17.10.2025 und vom 6.8.2026 wurden im Amtsblatt gelesen. Sie betreffen Art. 67 sowie fünf redaktionelle Stellen der deutschen Sprachfassung außerhalb der hier zitierten Vorschriften.

Die Leitlinien und die Fragen und Antworten sind unverbindlich. Letztverbindlich legt allein der Gerichtshof der Europäischen Union die Verordnung aus. Randnummern der Leitlinien folgen der Zählung des amtlichen Dokuments. Eine deutsche Fassung der Leitlinien lag nicht vor.

Rechtsprechung zur Verordnung liegt nicht vor. Der deutsche Regierungsentwurf ist nicht verkündet, seine Vorschriften geben Entwurfsstand wieder und sind im Text als solcher gekennzeichnet. Der Fall Nordkessel ist erfunden. Eigene Lesarten sind als solche gekennzeichnet, ebenso Angaben aus der Beratungspraxis, die auf Beobachtung beruhen, nicht auf einer Erhebung.

Zitiervorschlag: Bohne, CRA und Open Source: Hersteller, Verwalter, SBOM, ITMR Rechtsanwälte, 8. September 2026, itmr-legal.de/blog/cra-open-source.

Änderungsprotokoll

• 8. September 2026: Erstveröffentlichung. Rechtsstand 8. September 2026.

Inhalt

1. Worum es geht
2. Die Antwort in fünf Sätzen
3. Was dieser Beitrag praktisch liefert
4. Vor dem ersten Stichtag sind vier Dinge zu klären
5. Welche Lage dieser Beitrag behandelt
6. Ohne Geschäftstätigkeit fällt Open Source aus dem CRA heraus
7. Abbildung 1: Vier Stationen zur eigenen Rolle
8. Der Preis für die Software macht den Anbieter zum Hersteller
9. Verwalter tragen Pflichten, aber keine CE-Kennzeichnung
10. Abbildung 2: Hersteller und Verwalter im Vergleich
11. Meldet ein Verwalter, gilt für ihn ein anderer Stichtag
12. Abbildung 3: Vier Termine, zwei Adressaten
13. Sorgfalt schuldet der Hersteller
14. Abbildung 4: Sorgfalt nach dem Risiko der Komponente
15. Findet der Hersteller die Schwachstelle, meldet er sie
16. Stückliste und CE-Kennzeichnung sind nicht dasselbe
17. Auch in Deutschland steht nur der Meldeempfänger fest
18. Abbildung 5: Wer in Deutschland zuständig ist
19. Erst die Rolle, dann der Plan
20. Behörde, Kunde und Projekt sehen die Rolle anders
21. Welche Annahmen der Verordnung nicht standhalten
22. Ob die Plattform freiwillige Meldungen öffnet, ist offen
23. Der Fall Nordkessel in dreizehn Stationen
24. Häufige Fragen
25. Mehr zum Thema
26. Begriffe
27. Quellen
28. Änderungsprotokoll
29. Verfasser und Zuständigkeit

Rechtsstand: 8. September 2026. Der Beitrag gibt die Rechtslage zum genannten Datum wieder. Die Einordnung jeder Software und jeder Komponente hängt von den Umständen des Einzelfalls ab. Zur Freischaltung freiwilliger Meldungen auf der Plattform, zum Format der Stückliste und zur Bescheinigung nach Art. 25 stehen amtliche Festlegungen aus.