Leitfaden Stand 8. Oktober 2026 Lesezeit 11 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, Erwägungsgrund 120).
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 ist nach der Leitlinie der Kommission ein eigenes, nicht in Verkehr gebrachtes Produkt, für das eine juristische Person als Steward gilt (Leitlinie Rn. 52 und 53).

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 öffentlich verfügbar, nicht nur für zahlende Kunden oder eine begrenzte Gruppe (Leitlinie Rn. 46). 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 die Kosten für Konzeption, Entwicklung und Bereitstellung übersteigen. Erwägungsgrund 15 fügt selbst hinzu, dass die Annahme von Spenden ohne Gewinnabsicht keine Geschäftstätigkeit ist, und die Leitlinie der Kommission engt diesen Anhaltspunkt weiter ein: Ein Spendenlink ist keine Gewinnabsicht, auch wenn die Spenden die Kosten übersteigen (Rn. 61).

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 C(2026) 5252 konkretisiert das in Abschnitt 3. Ein Inverkehrbringen liegt vor bei einem Preis für Software oder Binaries (Rn. 51), bei einer Plattform zur Monetarisierung anderer Produkte oder Dienste (Rn. 54) und bei kostenpflichtigen Editionen, deren Zugang samt technischer Hilfe oder Leistungsoptimierung an ein Entgelt gebunden ist (Rn. 57). Kein Inverkehrbringen sind getrennt angebotene Beratung, Schulung oder Support (Rn. 55 und 56), freiwillige Spenden, solange Releases und Updates nicht Spendern vorbehalten sind (Rn. 61 und 62), und die gemeinnützige Verwendung von Einnahmen (Rn. 77). Hersteller von Open Source ist, wer sie veröffentlicht und die primäre Kontrolle über Entwicklung, Releases und Verteilung hat, also der Maintainer; Beitragende ohne Release-Kontrolle sind nicht verantwortlich (Rn. 49).

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 (Artikel 71 Absatz 2; so auch die ENISA in den FAQ zur Meldeplattform), 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 den Geldbußen der Absätze 2 bis 9 aus, also auch von denen für Verstöße gegen Artikel 14 (Fassung nach der Berichtigung im ABl. L 2025/90555 vom 2. Juli 2025); nach Erwägungsgrund 120 sollen die Mitgliedstaaten gegen sie auch keine anderen finanziellen Sanktionen verhängen. Steward-Meldungen laufen nach Angaben der ENISA über dieselbe Meldeplattform wie Herstellermeldungen; freiwillige Meldungen nach Artikel 15 hat die ENISA für eine spätere Phase angekündigt.

Welche Rolle gilt in welchem Fall?

Fall	Rolle	Pflichten
Hobbyprojekt auf einer Code-Plattform mit Spendenlink; Releases und Updates sind nicht Spendern vorbehalten	keine (außerhalb des CRA)	keine (Erwägungsgründe 15, 18, 20; Leitlinie Rn. 61 und 62)
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, Steward für die Community-Edition (Leitlinie Rn. 52 und 53)	Artikel 13 und 14 in vollem Umfang für die Enterprise-Edition; Artikel 24 für die Community-Edition
Open-Source-Software wird verkauft, oder der Zugang zur Software samt Wartung ist an ein Entgelt gebunden (Erwägungsgrund 15, Leitlinie Rn. 56 und 57)	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 der Leitlinie nicht verantwortlich, auch wenn er zu ihr beiträgt (Beispiel 32), für das Endprodukt aber vollständig (Rn. 120). 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 meldepflichtig, sobald sie im eigenen Produkt enthalten ist und dort ausgenutzt wird (Leitlinie Rn. 218), mit der 24-Stunden-Frist nach Artikel 14 Absatz 2 Buchstabe a. CRA Response Center erkennt solche Meldungen an der Meldeadresse des Herstellers, auch Hinweise zu verbauten Bibliotheken, und benachrichtigt die zuständigen Personen; die Meldung an die ENISA-Plattform reicht der Hersteller selbst ein.

Kostenlose VorlagenCRA-Meldepflicht-KitMelde-Playbook, Kenntnisvermerk, Meldevorlagen für die ENISA-Plattform, Rufkette und Fristenrechner. Sechs Word-Vorlagen, zwei Excel-Mappen und ein Handbuch, kostenlos per E-Mail.Kit anfordern

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 oder Datenverarbeitung als Nutzungsbedingung (Erwägungsgrund 15). Erwägungsgrund 15 nennt auch Spenden über die Kosten hinaus, nach der Leitlinie der Kommission zeigt ein Spendenlink aber selbst dann keine Gewinnabsicht (Rn. 61); wie ein Preis wirken Spenden erst, wenn Releases, wesentliche Funktionen oder Updates in der Praxis Spendern vorbehalten sind (Rn. 62). Die Leitlinie nennt zusätzlich bezahlte Editionen und Plattform-Monetarisierung (Rn. 54 und 57).

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 nicht verantwortlich (Rn. 49, Beispiel 13). 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; Artikel 64 Absatz 10 in der Fassung der Berichtigung ABl. L 2025/90555 vom 2. Juli 2025.
Leitlinie der Kommission C(2026) 5252, Annex, Abschnitt 3 (Rn. 44 bis 81, Beispiele 13 bis 33), Rn. 120 und 218, Europäische Kommission, 27. Juli 2026.
The CRA Single Reporting Platform is launched, ENISA, 11. September 2026.
Single Reporting Platform: Frequently Asked Questions, ENISA, Stand 3. Oktober 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, 29. Juli 2026.
CRA Commission guidance, Noze, 28. Juli 2026.