Cyber Resilience Act: Was der neue Leitfaden für Open Source klärt

Was die EU-Kommission neu veröffentlicht hat

Die EU-Kommission hat am 27. Juli 2026 den Leitlinienentwurf C(2026) 5252 zum Cyber Resilience Act veröffentlicht. Das 84-seitige Dokument enthält 67 Praxisbeispiele, Ablaufdiagramme und Erläuterungen. Ein großer Teil beschäftigt sich mit freier und quelloffener Software.

Der Leitfaden ist nicht bindend. Er zeigt aber, wie die Kommission Begriffe wie kommerzielle Tätigkeit, Hersteller und Open-Source-Steward versteht. Das ist für Softwareanbieter wichtig, weil die Meldepflichten des CRA schon am 11. September 2026 starten. Die meisten übrigen Pflichten gelten ab 11. Dezember 2027.

Open Source ist keine automatische Ausnahme

Damit Software im Sinne des CRA als freie und quelloffene Software gilt, müssen zwei Voraussetzungen zusammenkommen: Der Quellcode wird offen geteilt, und die Lizenz erlaubt freien Zugang, Nutzung, Änderung und Weiterverbreitung.

Dann folgt die zweite Frage: Wird die Software im Rahmen einer kommerziellen Tätigkeit auf dem EU-Markt bereitgestellt? Nicht monetarisierte Open-Source-Software soll nach dem Leitfaden nicht als kommerziell gelten. Allein die Entwicklungsfinanzierung entscheidet darüber noch nicht.

Bei Spenden wird die Trennlinie anschaulich. Ein freiwilliger Spendenlink ohne Gewinnerzielungsabsicht macht ein Projekt nicht automatisch kommerziell. Erhalten dagegen nur Spender die aktuelle Version, regelmäßige Updates oder garantierte Sicherheitskorrekturen, wertet der Leitfaden die Spende faktisch als Preis. Dann kann die Software in den Anwendungsbereich fallen.

Wann ein Open-Source-Steward Pflichten hat

Eine juristische Person kann als Open-Source-Software-Steward gelten, wenn sie ein Projekt dauerhaft unterstützt und seine Tragfähigkeit sicherstellt, ohne die Software selbst als Hersteller kommerziell bereitzustellen. Für solche Stewards gelten gezielte Pflichten aus Artikel 24 statt des vollständigen Herstellerprogramms.

• Sie müssen eine nachvollziehbar dokumentierte Cybersicherheitsrichtlinie für sichere Entwicklung und wirksame Schwachstellenbehandlung einrichten.
• Sie müssen auf begründete Anfrage mit Marktüberwachungsbehörden zusammenarbeiten.
• Bestimmte Meldepflichten greifen, soweit der Steward an der Entwicklung beteiligt ist oder schwere Vorfälle seine Entwicklungsinfrastruktur betreffen.

Das ist keine Freistellung von Verantwortung. Es ist eine eigene, auf die Rolle zugeschnittene Kategorie.

Wer Open Source einbaut, bleibt Hersteller seines Produkts

Der häufigste Denkfehler lautet: „Die Bibliothek ist Open Source, deshalb liegt die Sicherheit beim Projekt.“ Für ein Unternehmen, das eine Komponente in ein eigenes kommerzielles Produkt integriert, trägt dieser Satz nicht.

Der Hersteller des Gesamtprodukts muss die Komponente in seine Risikobewertung und Schwachstellenprozesse aufnehmen. Dazu gehören zumindest klare Zuständigkeiten, eine Übersicht der verwendeten Komponenten, ein Weg für Sicherheitsmeldungen und ein Verfahren für Updates. Der CRA behandelt damit nicht den Lizenztyp als Sicherheitsnachweis.

Ob dein Angebot überhaupt ein „Produkt mit digitalen Elementen“ ist, hängt ebenfalls vom konkreten Modell ab. Der Leitfaden nennt etwa lokal installierte Anwendungen als mögliches CRA-Produkt, während eine ausschließlich im Browser genutzte Webanwendung grundsätzlich nicht darunter fällt, sofern sie nicht die Funktion eines solchen Produkts unterstützt.

Was Softwareanbieter jetzt vorbereiten sollten

1. Angebote trennen: Halte fest, welche Software du auslieferst, welche Funktionen nur als Onlinedienst laufen und welche Open-Source-Bausteine enthalten sind.
2. Geschäftsmodell prüfen: Dokumentiere, ob Zugang, Binärdateien, Updates oder Sicherheitskorrekturen an Zahlungen, Spenden oder Supportverträge gekoppelt sind.
3. Rollen zuordnen: Kläre für jedes Produkt, wer Hersteller, Importeur, Händler oder möglicher Open-Source-Steward ist.
4. Meldeweg testen: Die Meldung aktiv ausgenutzter Schwachstellen und schwerer Sicherheitsvorfälle muss vor dem 11. September 2026 organisatorisch funktionieren.

Für die organisatorische Einordnung digitaler Vorhaben hilft ein klarer Verantwortungsrahmen. Der Wissens-Hub bündelt die passenden Grundlagen; bei der Umsetzung kann eine frühe technische und organisatorische Bestandsaufnahme spätere Umbauten vermeiden.