Leitfaden Stand 7. Oktober 2026 Lesezeit 9 Min.

Open Source und CRA: Steward, gewerbliche Nutzung, Meldepflichten

Open Source ist nicht pauschal vom Cyber Resilience Act ausgenommen. Entscheidend ist, ob die Software im Rahmen einer Geschäftstätigkeit bereitgestellt wird. Für den Mittelstand zählt vor allem die andere Seite: Jeder Hersteller baut Open-Source-Komponenten ein und schuldet dafür Sorgfalt.

Freie und quelloffene Software fällt nur dann unter den Cyber Resilience Act, wenn sie im Rahmen einer Geschäftstätigkeit auf dem Markt bereitgestellt wird (Artikel 3 Nummer 22, Erwägungsgründe 15 und 18). Wer ein Projekt ohne Geschäft veröffentlicht, bleibt außerhalb. Wer es als Stiftung oder Verein für kommerziell bestimmte Produkte dauerhaft trägt, ist "Verwalter quelloffener Software", im Englischen Open-Source-Steward, mit leichten Pflichten nach Artikel 24, ohne CE und ohne Bußgeld. Wer Open Source verkauft, ist Hersteller wie jeder andere. Und jeder Hersteller, der Open-Source-Komponenten einbaut, schuldet Sorgfalt nach Artikel 13 Absatz 5 und meldet Schwachstellen an das Projekt zurück (Absatz 6).

Das Wichtigste

Die Grenze ist die Geschäftstätigkeit: Preis, Support über die Kostendeckung hinaus, Gewinnabsicht oder Datenverarbeitung als Nutzungsbedingung machen Open Source zum Produkt (Erwägungsgrund 15).
Ein Steward ist eine juristische Person, die ein Open-Source-Projekt für kommerziell bestimmte Produkte dauerhaft unterstützt (Artikel 3 Nummer 14). Pflichten: Cybersicherheitsstrategie, Kooperation mit Behörden, eingeschränkte Meldepflicht ab dem 11. Dezember 2027 (Artikel 24).
Stewards bringen kein CE an (Erwägungsgrund 19) und zahlen keine Bußgelder (Artikel 64 Absatz 10 Buchstabe b).
Hersteller prüfen Open-Source-Komponenten mit Sorgfalt (Artikel 13 Absatz 5, Erwägungsgrund 34) und geben Schwachstellen und eigene Fixes an das Projekt zurück (Artikel 13 Absatz 6).
Kostenpflichtige Editionen und Open-Core-Modelle (kostenloser Kern, bezahlte Erweiterungen) sind Produkte; die kostenlose Community-Edition bewertet die Leitlinie der Kommission laut Sekundärquellen gesondert.

Was ist freie und quelloffene Software im Sinne des CRA?

Artikel 3 Nummer 48 definiert sie als Software, deren Quellcode offen geteilt wird und die unter einer kostenlosen Open-Source-Lizenz mit allen Rechten bereitgestellt wird: zugänglich machen, nutzen, verändern, weiterverteilen. "Offen geteilt" heißt nach der Leitlinie der Kommission (Sekundärquelle) öffentlich verfügbar, nicht nur für zahlende Kunden. Die Definition sagt noch nichts darüber, ob der CRA gilt; das entscheidet die Geschäftstätigkeit.

Wann wird Open Source zur Geschäftstätigkeit?

Die Bereitstellung auf dem Markt setzt eine Geschäftstätigkeit voraus (Artikel 3 Nummer 22). Erwägungsgrund 15 nennt die Anhaltspunkte:

Ein Preis für das Produkt.
Ein Entgelt für technischen Support, das über die Kostendeckung hinausgeht.
Eine Gewinnerzielungsabsicht, etwa wenn die Software als Plattform für andere Dienste dient.
Die Verarbeitung personenbezogener Daten als Bedingung für die Nutzung, außer sie dient allein Sicherheit oder Kompatibilität.
Spenden, die über die Kosten hinausgehen. Spenden ohne Gewinnabsicht sind keine Geschäftstätigkeit.

Erwägungsgrund 18 stellt klar, dass Entwicklungsumstände und Finanzierung keine Rolle spielen. Dass Hersteller ein Projekt finanziell unterstützen, dass es regelmäßige Releases gibt oder dass eine gemeinnützige Organisation entwickelt, macht Open Source nicht kommerziell. Komponenten, die andere Hersteller einbauen, gelten nur als bereitgestellt, wenn der ursprüngliche Hersteller sie monetarisiert. Erwägungsgrund 20 nimmt die Infrastruktur aus: Die Bereitstellung in Paketverwaltungen und auf Code-Plattformen ist kein Inverkehrbringen.

Die Leitlinie der Kommission konkretisiert das laut Sekundärquellen. Ein Inverkehrbringen liegt vor bei einem Preis für Software oder Binaries, bei einer Plattform zur Monetarisierung anderer Produkte und bei kostenpflichtigen Editionen, die Zugang, Support oder Leistung beschränken. Kein Inverkehrbringen sind getrennt angebotene Beratung, Schulung oder Support, freiwillige Spenden, solange Releases nicht Spendern vorbehalten sind, und die gemeinnützige Verwendung von Einnahmen. Hersteller von Open Source ist, wer die primäre Kontrolle über Entwicklung, Releases und Verteilung hat, also der Maintainer; Beitragende ohne Release-Kontrolle sind nicht verantwortlich.

Was ist ein Open-Source-Steward und was muss er tun?

Ein Verwalter quelloffener Software ist nach Artikel 3 Nummer 14 eine juristische Person, die kein Hersteller ist und die Entwicklung von Open-Source-Produkten für kommerzielle Tätigkeiten systematisch und nachhaltig unterstützt. Erwägungsgrund 19 nennt Stiftungen und gemeinnützige Einrichtungen, die Open Source im wirtschaftlichen Kontext entwickeln; Unterstützung umfasst Hosting von Plattformen und Quellcode, Verwaltung und Steuerung der Entwicklung. Erfasst sind nur Projekte, deren Ergebnis in kommerzielle Dienste oder kostenpflichtige Produkte fließt. Ein Einzelentwickler kann kein Steward sein.

Die Pflichten nach Artikel 24 sind bewusst leicht:

Cybersicherheitsstrategie (Absatz 1): überprüfbar dokumentiert, mit sicherer Entwicklung, Schwachstellenbehandlung, Förderung freiwilliger Meldungen nach Artikel 15, Dokumentation und Behebung von Schwachstellen und Informationsaustausch in der Community.
Kooperation (Absatz 2): mit den Marktüberwachungsbehörden zusammenarbeiten und Unterlagen auf begründetes Verlangen vorlegen.
Eingeschränkte Meldepflicht (Absatz 3): aktiv ausgenutzte Schwachstellen nach Artikel 14 Absatz 1 melden, soweit der Steward an der Entwicklung beteiligt ist; schwerwiegende Vorfälle und Nutzerinformation nach Artikel 14 Absatz 3 und 8, soweit die vom Steward bereitgestellten Netz- und Informationssysteme betroffen sind.

Die Pflichten für Stewards gelten erst ab dem 11. Dezember 2027, anders als die Meldepflicht der Hersteller, die seit dem 11. September 2026 läuft. Stewards dürfen kein CE-Zeichen anbringen (Erwägungsgrund 19), und Artikel 64 Absatz 10 Buchstabe b nimmt sie von allen Geldbußen aus. Ob Steward-Meldungen über dieselbe ENISA-Plattform laufen wie Herstellermeldungen, ist nicht belegt; die ENISA hat freiwillige Meldungen nach Artikel 15 für eine spätere Phase angekündigt.

Welche Rolle gilt in welchem Fall?

Fall	Rolle	Pflichten
Hobbyprojekt auf einer Code-Plattform mit Spendenlink, Spenden decken höchstens die Kosten	keine (außerhalb des CRA)	keine (Erwägungsgründe 15, 18, 20)
Verein pflegt ein Framework für ein Industrieprotokoll, das Steuerungshersteller einbauen und finanziell unterstützen	Steward (Artikel 3 Nummer 14)	Artikel 24: Strategie, Kooperation, eingeschränkte Meldepflicht ab 11. Dezember 2027; kein CE, kein Bußgeld
GmbH bietet eine kostenlose Community-Edition und eine Enterprise-Edition mit zusätzlichen Sicherheitsfunktionen gegen Lizenzgebühr	Hersteller für die Enterprise-Edition	Artikel 13 und 14 in vollem Umfang; Community-Edition laut Leitlinie gesondert zu bewerten (nicht verifiziert)
Open-Source-Software wird verkauft, oder Support über die Kostendeckung hinaus ist Bedingung der Nutzung (Erwägungsgrund 15)	Hersteller	Artikel 13 und 14 in vollem Umfang, Konformitätsbewertung, CE
Maschinenbauer baut eine Open-Source-Bibliothek in seine Steuerung ein	Hersteller des Endprodukts	Sorgfalt für die Komponente (Artikel 13 Absatz 5), Rückmeldung von Schwachstellen (Absatz 6), SBOM
Betreiber einer Paketverwaltung oder eines Repositorys	keine; Händler nur bei Lieferung im Rahmen einer Geschäftstätigkeit	Erwägungsgrund 20

Was gilt für Open-Source-Komponenten im eigenen Produkt?

Das ist der Teil, der jeden Hersteller betrifft. Artikel 13 Absatz 5 verpflichtet Hersteller zur Sorgfalt bei der Integration von Komponenten Dritter, ausdrücklich auch bei nicht-kommerzieller Open Source. Erwägungsgrund 34 beschreibt den Umfang nach Risiko: prüfen, ob die Komponente eine CE-Kennzeichnung trägt, die Update-Historie ansehen, bekannte Schwachstellen mit der europäischen Schwachstellendatenbank abgleichen, bei Bedarf zusätzlich testen. Ein Projekt ohne Maintainer ist nach diesem Maßstab eine Entscheidung, die dokumentiert gehört.

Artikel 13 Absatz 6 regelt die Rückmeldung. Findet ein Hersteller eine Schwachstelle in einer Komponente, auch einer quelloffenen, meldet er sie der Person oder Organisation, die die Komponente pflegt, und behebt sie für sein Produkt. Eigene Fixes teilt er dem Projekt mit, als Code oder als Unterlagen, möglichst in maschinenlesbarer Form. Ein Maschinenbauer, der in einer Open-Source-TLS-Bibliothek einen Fehler findet, behält den Patch also nicht intern. Für die Konformität der Komponente selbst ist der integrierende Hersteller nach Sekundärquellen nicht verantwortlich, für das Endprodukt aber vollständig. Die Grundlage dafür ist die Stückliste der Software; was hinein muss, steht unter SBOM nach CRA.

Gibt es ein Gütesiegel für Open Source?

Artikel 25 erlaubt der Kommission, per delegiertem Rechtsakt freiwillige Programme für Sicherheitsbescheinigungen einzuführen, mit denen die Konformität von Open-Source-Produkten mit Anhang I belegt werden kann. Nach Erwägungsgrund 21 können auch Dritte, etwa integrierende Hersteller oder Verwaltungen, eine Bescheinigung anstoßen oder finanzieren. Ein solcher Rechtsakt ist bisher nicht bekannt (Stand Oktober 2026). Eine Erleichterung gibt es schon: Open-Source-Produkte in den Kategorien des Anhangs III dürfen nach Artikel 32 Absatz 5 jedes Verfahren der Konformitätsbewertung nutzen, auch die interne Kontrolle, wenn die technische Dokumentation öffentlich ist.

Typische Fehler

"Open Source ist ausgenommen" als Pauschalannahme. Monetarisierte Open Source ist voll erfasst, und die Enterprise-Edition macht aus einem Projekt einen Hersteller.
Open-Core nicht als solches erkennen. Wer eine Community-Edition und eine kostenpflichtige Edition anbietet, sollte beide ausdrücklich getrennt bewerten und die Monetarisierung offen benennen, statt das Modell als "Open Source" zu führen.
Komponenten ohne Prüfung der Pflege einsetzen. Erwägungsgrund 34 verlangt eine Sorgfalt nach Risiko; ein verwaistes Projekt in der Steuerung ist ein dokumentationspflichtiger Befund.
Fixes intern behalten. Artikel 13 Absatz 6 verlangt die Rückmeldung an das Projekt.
Steward-Regime für Einzelpersonen oder für das eigene Unternehmen annehmen. Steward kann nur eine juristische Person sein, die nicht Hersteller ist.
Spenden und Sponsoring als Freibrief verstehen. Sie schaden nicht, solange keine Gewinnabsicht dahintersteht. Sobald ein Preis oder eine bezahlte Stufe dazukommt, kippt die Einordnung.

Für Hersteller, die Open-Source-Komponenten einsetzen, hat das eine praktische Folge für die Bereitschaft: Eine aktiv ausgenutzte Schwachstelle in einer Bibliothek ist eine aktiv ausgenutzte Schwachstelle im eigenen Produkt, mit der 24-Stunden-Frist nach Artikel 14. CRA Response Center nimmt solche Meldungen an der Meldeadresse des Herstellers entgegen, prüft sie und weckt die Rufkette; die Meldung an die ENISA-Plattform reicht der Hersteller selbst ein.

Häufige Fragen

Fällt kostenlose Open Source unter den CRA?

Nur, wenn sie im Rahmen einer Geschäftstätigkeit bereitgestellt wird (Artikel 3 Nummer 22, Erwägungsgründe 15 und 18). Ein Projekt ohne Preis, ohne bezahlte Stufen und ohne Gewinnabsicht bleibt außerhalb, auch wenn Unternehmen es einsetzen.

Was macht Open Source kommerziell?

Ein Preis, Support-Entgelt über die Kostendeckung hinaus, Gewinnabsicht, Datenverarbeitung als Nutzungsbedingung oder Spenden über die Kosten hinaus (Erwägungsgrund 15). Die Leitlinie der Kommission nennt laut Sekundärquellen zusätzlich bezahlte Editionen und Plattform-Monetarisierung.

Was ist ein Open-Source-Steward?

Eine juristische Person, die kein Hersteller ist und die Entwicklung von Open-Source-Produkten für kommerziell bestimmte Zwecke dauerhaft unterstützt (Artikel 3 Nummer 14), typischerweise eine Stiftung oder ein Verein. Die Pflichten stehen in Artikel 24.

Muss ein Steward Schwachstellen melden?

Ja, aktiv ausgenutzte Schwachstellen nach Artikel 24 Absatz 3, soweit er an der Entwicklung beteiligt ist, und schwerwiegende Vorfälle in seinen eigenen Systemen. Die Pflicht gilt ab dem 11. Dezember 2027. Bußgelder gibt es für Stewards nicht (Artikel 64 Absatz 10 Buchstabe b).

Darf ein Steward ein CE-Zeichen anbringen?

Nein. Erwägungsgrund 19 schließt das aus. Das CE-Zeichen bleibt Herstellern vorbehalten.

Was muss ich als Hersteller mit Open-Source-Komponenten tun?

Sorgfältig prüfen (Artikel 13 Absatz 5, Erwägungsgrund 34), die Komponenten in der SBOM führen, gefundene Schwachstellen an das Projekt melden, selbst beheben und eigene Fixes zurückgeben (Artikel 13 Absatz 6).

Haftet ein Einzelentwickler?

Ohne Geschäftstätigkeit ist er außerhalb des CRA. Beitragende ohne Kontrolle über Releases sind nach der Leitlinie (Sekundärquelle) nicht verantwortlich. Verkauft ein Einzelentwickler seine Software, ist er Hersteller.

Was gilt für Open-Source-Produkte in Klasse I?

Sie dürfen nach Artikel 32 Absatz 5 jedes Verfahren der Konformitätsbewertung nutzen, auch die interne Kontrolle, wenn die technische Dokumentation öffentlich ist.

Weiterlesen

Quellen

Verordnung (EU) 2024/2847 (Cyber Resilience Act), Artikel 3 Nummer 14, 22 und 48, Artikel 13 Absatz 5 und 6, Artikel 24, 25, 32 Absatz 5, Artikel 64 Absatz 10, Erwägungsgründe 15, 18, 19, 20, 21 und 34, Amt für Veröffentlichungen der EU, abgerufen am 7. Oktober 2026.
The CRA Single Reporting Platform is launched, ENISA, 11. September 2026.
Cyber Resilience Act guidance: products and obligations, Gamingtechlaw, 5. August 2026.
EU clarifies CRA rules for non-commercial open source, Open Source For U, Juli 2026.
CRA Commission guidance, Noze, 28. Juli 2026.