Gilt der Cyber Resilience Act auch für Open-Source-Software?

TL;DR

• Nicht-kommerzielle Open-Source-Software ist vom Cyber Resilience Act weitgehend ausgenommen.
• Der "Open-Source-Software-Steward" trägt unter dem CRA leichtere Pflichten als ein klassischer Hersteller.
• Kommerzielle Nutzung oder Verkauf kann die Ausnahme kippen, im Einzelfall ist dies gegen die Verordnung zu prüfen.
• Die Hauptpflichten des CRA für Hersteller greifen ab dem 11.12.2027, Meldepflichten nach Art. 14 CRA bereits ab dem 11.09.2026.
• Für Unternehmen, die Open-Source-Komponenten in kommerziellen Produkten einsetzen, bleibt die eigene Herstellerpflicht bestehen, auch wenn die Komponente selbst ausgenommen ist.

Warum nimmt der Cyber Resilience Act Open-Source-Software überhaupt in den Blick?

Der Cyber Resilience Act, Verordnung (EU) 2024/2847, in Kraft seit dem 10.12.2024, erfasst Produkte mit digitalen Elementen, die auf dem EU-Markt bereitgestellt werden. Da Software, einschließlich Open-Source-Komponenten, integraler Bestandteil vieler Produkte ist, musste der Verordnungsgeber eine Abgrenzung treffen: Wo endet freie, gemeinschaftlich entwickelte Software, und wo beginnt ein kommerzielles Produkt, das den vollen Pflichtenkatalog auslöst.

Welche Ausnahme gilt für nicht-kommerzielle Open-Source-Software?

Nach den vorliegenden Quellen ist nicht-kommerzielle Open-Source-Software vom Cyber Resilience Act weitgehend ausgenommen. Der Gedanke dahinter: Ehrenamtlich oder gemeinschaftlich entwickelte Software ohne kommerziellen Hintergrund soll nicht denselben Pflichten unterliegen wie ein Produkt, das ein Unternehmen gewerblich in Verkehr bringt. Diese Ausnahme betrifft die Entwicklung und Bereitstellung der Software selbst, sofern sie außerhalb eines kommerziellen Kontexts erfolgt.

Was ist ein Open-Source-Software-Steward und welche Pflichten hat er?

Für Organisationen, die Open-Source-Software im Rahmen ihrer Tätigkeit strukturell unterstützen, etwa Stiftungen oder Foundations, die Projekte hosten oder koordinieren, sieht der Cyber Resilience Act die Rolle des Open-Source-Software-Steward vor. Diese Rolle trägt nach den verfügbaren Quellen leichtere Pflichten als ein klassischer Hersteller im Sinne der Verordnung. Der Grundgedanke ist auch hier, die Governance-Struktur von Open-Source-Projekten zu berücksichtigen, ohne sie mit dem vollen Pflichtenkatalog eines kommerziellen Herstellers zu belasten. Welche konkreten Einzelpflichten im Detail für einen Steward gelten, ist im Einzelfall gegen den Verordnungstext zu prüfen, über die hier genannte Einordnung hinaus werden an dieser Stelle keine weiteren Detailregeln behauptet.

Wann kippt eine kommerzielle Nutzung die Ausnahme?

Die Ausnahme für nicht-kommerzielle Open-Source-Software ist an die Nicht-Kommerzialität geknüpft. Sobald eine kommerzielle Nutzung oder ein Verkauf hinzutritt, etwa wenn ein Unternehmen die Software als Teil eines bezahlten Produkts oder einer bezahlten Dienstleistung anbietet, stellt sich die Frage neu, ob die Ausnahme noch trägt. Pauschale Aussagen dazu, ab welchem konkreten Geschäftsmodell die Ausnahme im Einzelfall entfällt, lassen sich aus den vorliegenden Quellen nicht ableiten und sollten im Einzelfall geprüft werden.

Konstellation	Einordnung
Nicht-kommerzielle Entwicklung und Bereitstellung von Open-Source-Software	Weitgehend ausgenommen
Koordinierende Organisation/Foundation (Open-Source-Software-Steward)	Leichtere Pflichten als Hersteller
Kommerzielle Nutzung oder Verkauf auf Basis der Software	Im Einzelfall prüfen, Ausnahme kann entfallen

Was bedeutet das für Unternehmen, die Open-Source-Komponenten in eigenen Produkten einsetzen?

Wer als Unternehmen ein kommerzielles Produkt mit digitalen Elementen in Verkehr bringt, das Open-Source-Komponenten enthält, bleibt selbst voller Hersteller im Sinne des Cyber Resilience Act, unabhängig davon, ob die einzelne Komponente ausgenommen wäre, wenn sie isoliert und nicht-kommerziell bereitgestellt würde. Genau hier setzt die Pflicht zur Software Bill of Materials, kurz SBOM, an: Sie schafft Transparenz darüber, welche Komponenten, einschließlich Open-Source-Bestandteilen, in einem kommerziellen Produkt stecken, und ist Voraussetzung für ein wirksames Schwachstellen-Management über den Support-Zeitraum des Produkts.

Wie hängt das mit den Meldepflichten nach Art. 14 CRA zusammen?

Die Meldepflichten für aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle nach Art. 14 CRA gelten ab dem 11.09.2026 für Hersteller von Produkten mit digitalen Elementen. Enthält ein kommerzielles Produkt eine Open-Source-Komponente, mit einer bekannt gewordenen Schwachstelle, trifft die Meldepflicht den Hersteller des Gesamtprodukts, nicht die ursprünglichen, nicht-kommerziellen Entwickler der Komponente. Die Meldung läuft über die CRA Single Reporting Platform an das CSIRT am Herstellersitz, das die Information an ENISA und andere CSIRTs weiterleitet.

Welche praktische Konsequenz ergibt sich für den deutschen Mittelstand?

Üblicherweise wird empfohlen, bei jedem Einsatz von Open-Source-Komponenten in einem kommerziellen Produkt die eigene Herstellerrolle unter dem CRA getrennt von der Frage der Ausnahme für die Komponente selbst zu betrachten. Die Ausnahme entlastet die ursprünglichen, nicht-kommerziellen Entwickler, nicht das Unternehmen, das die Komponente in ein bezahltes Produkt integriert. Eine erste strukturierte Einschätzung der eigenen Betroffenheit lässt sich über den CRA-Check vornehmen.

Ist ein privates GitHub-Projekt ohne Verkauf automatisch ausgenommen?

Nicht-kommerzielle Open-Source-Software ist nach den vorliegenden Quellen weitgehend ausgenommen. Ob ein konkretes Projekt im Einzelfall unter diese Ausnahme fällt, hängt von den genauen Umständen ab und sollte im Einzelfall geprüft werden.

Gilt die Steward-Regel auch für kleine, lose organisierte Projekte?

Die Rolle des Open-Source-Software-Steward mit ihren leichteren Pflichten betrifft nach den verfügbaren Quellen Organisationen, die Open-Source-Projekte strukturell unterstützen. Ob eine konkrete, kleinere Organisationsform darunterfällt, ist im Einzelfall zu prüfen.

Muss ein Unternehmen jede eingesetzte Open-Source-Bibliothek einzeln bewerten?

Die eigene Herstellerpflicht unter dem CRA bezieht sich auf das kommerzielle Gesamtprodukt. Die SBOM-Pflicht sorgt dafür, dass alle Komponenten, einschließlich Open-Source-Bibliotheken, erfasst und im Rahmen des Schwachstellen-Managements berücksichtigt werden. Einen Überblick über das gesamte Regelwerk bietet der Beitrag Cyber Resilience Act im Überblick.

Quellen

• Europäische Kommission, Cyber Resilience Act (Übersicht): https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act (verifiziert 11.08.2026)
• Europäische Kommission, CRA Reporting Obligations: https://digital-strategy.ec.europa.eu/en/policies/cra-reporting (verifiziert 11.08.2026)
• EUR-Lex, Verordnung (EU) 2024/2847: https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX:32024R2847 (verifiziert 11.08.2026)
• ENISA, Cyber Resilience Act: https://www.enisa.europa.eu/topics/cyber-resilience-act (verifiziert 11.08.2026)