EU Cyber Resilience Act und die Open-Source-Community - Der Countdown läuft

Der 11. September 2026 ist ein Datum, das sich jeder Entwickler, Maker und Hersteller von vernetzten Produkten rot im Kalender markieren sollte. Ab diesem Tag greifen die ersten verbindlichen Meldepflichten des EU Cyber Resilience Act (CRA) – der Verordnung (EU) 2024/2847, die erstmals europaweite Cybersicherheitsanforderungen für alle Produkte mit digitalen Elementen festlegt. Das sind weniger als fünf Monate. Gleichzeitig zeigt eine Studie der Linux Foundation alarmierende Wissenslücken im Open-Source-Ökosystem. Und für Maker, Hobbyentwickler und kleine Open-Source-Projekte stellt sich eine ganz praktische Frage: Bin ich überhaupt betroffen – und wenn ja, was muss ich tun?

Dieser Artikel erklärt die wichtigsten Fristen, beleuchtet die Sonderregelung für Open-Source-Stewards und zeigt, was die Regulierung konkret für die Community bedeutet.

CRA auf einen Blick: Die wichtigsten Fakten

Was: EU-Verordnung 2024/2847 mit verbindlichen Cybersicherheitsanforderungen für alle Produkte mit digitalen Elementen.
Wann: In Kraft seit 10.12.2024. Erste Meldepflicht ab 11.09.2026. Vollständig anwendbar ab 11.12.2027.
Wer ist betroffen: Hersteller, Importeure und Händler von Hardware, Software und vernetzten Produkten auf dem EU-Markt.
Strafen: Bis zu 15 Mio. Euro oder 2,5 Prozent des weltweiten Jahresumsatzes.
Open Source: Nicht-kommerzielle FOSS bleibt ausgenommen. Stewards (Foundations) haben Light-Touch-Pflichten und sind komplett bußgeldbefreit.

Was ist der EU Cyber Resilience Act (CRA)?

Der CRA ist die erste EU-weite Produktsicherheitsverordnung speziell für Cybersicherheit. Er richtet sich an Hersteller, Importeure und Händler von sogenannten „Produkten mit digitalen Elementen“ – also praktisch alles, was Software enthält oder eine Netzwerkverbindung hat. Das reicht vom smarten Babyphone über Industriesensorik und IoT-Gateways bis hin zu eigenständiger Software, die auf dem EU-Markt vertrieben wird.

Die Verordnung ist am 10. Dezember 2024 in Kraft getreten. Die vollständige Anwendbarkeit aller Pflichten ist auf den 11. Dezember 2027 terminiert. Aber – und das ist der entscheidende Punkt – einige Pflichten greifen deutlich früher. Der CRA verfolgt einen gestaffelten Zeitplan, und die erste harte Frist steht unmittelbar bevor.

Im Kern verlangt der CRA von Herstellern einen fundamentalen Paradigmenwechsel: Cybersicherheit wird von einem optionalen Feature zu einer verbindlichen Marktzugangsvoraussetzung für den gesamten EU-Binnenmarkt. Produkte müssen „secure by design“ entwickelt werden, Schwachstellen über den gesamten Lebenszyklus gemanagt und Sicherheitsupdates mindestens fünf Jahre lang bereitgestellt werden.

Cyber Resilience Act Fristen: Wann tritt das Gesetz in Kraft?

Viele Unternehmen gehen davon aus, dass sie bis Dezember 2027 Zeit haben. Diese Annahme ist falsch – und gefährlich. Der CRA arbeitet mit einem Stufenmodell, und die erste operative Frist kommt bereits im Sommer 2026.

Die wichtigsten Termine im Überblick:

10. Dezember 2024: Die Verordnung ist offiziell in Kraft getreten.
11. Juni 2026: Vorschriften zur Notifizierung von Konformitätsbewertungsstellen greifen.
11. September 2026: Kritische Frist! Meldepflicht für aktiv ausgenutzte Schwachstellen tritt in Kraft.
11. Dezember 2027: Vollständige Anwendbarkeit. Ab hier dürfen nur noch CRA-konforme Produkte mit CE-Kennzeichnung in der EU in Verkehr gebracht werden.

Parallel dazu laufen die Arbeiten an den harmonisierten europäischen Normen, die Herstellern die Konformitätsvermutung ermöglichen werden. Die EU-Kommission hat im März 2025 mit dem Mandat M/606 die europäischen Normungsorganisationen CEN, CENELEC und ETSI mit der Erarbeitung dieser Standards beauftragt. Diese Normen werden in drei Typen unterteilt:

Typ A umfasst grundlegende Cyber-Resilience-Prinzipien.
Typ B beschreibt produktagnostische horizontale Anforderungen wie Vulnerability Handling.
Typ C definiert produktspezifische vertikale Standards für bestimmte Gerätekategorien.

Die geplanten Veröffentlichungstermine liegen bei 30. August 2026 für den Typ-A-Standard und den Typ-B-Standard zum Schwachstellenmanagement, bei 30. Oktober 2026 für Typ-C-Standards für wichtige und kritische Produkte und bei 30. Oktober 2027 für den Typ-B-Standard zu den generischen Cybersicherheitsanforderungen. Wichtig zur Klarstellung: Diese Daten betreffen die Veröffentlichung der Normen, nicht direkte Compliance-Fristen für Produkte. Für die Produkt-Konformität gilt einheitlich der 11. Dezember 2027.

Die Produkte selbst werden im CRA übrigens in vier Risikoklassen eingeteilt: Standard/Default (Annex I), Important Class I und Class II (Annex III) sowie Critical (Annex IV). Die Klasse bestimmt, ob eine Selbstbewertung des Herstellers ausreicht oder ob eine Drittprüfung durch eine Notified Body verpflichtend ist.

Die 24-Stunden-Meldepflicht: Was ab September 2026 gilt

Die Meldepflicht ab September 2026 ist der operativ kritischste Teil des CRA. Sie funktioniert dreistufig und setzt für Hersteller massive Vorbereitung voraus:

24 Stunden nach Kenntnisnahme einer aktiv ausgenutzten Schwachstelle muss eine Frühwarnung (Early Warning) an das zuständige nationale CSIRT und in der Regel gleichzeitig an die EU-Cybersicherheitsagentur ENISA erfolgen.
72 Stunden danach folgt ein detaillierter Vollbericht mit technischen Details, betroffenen Produktversionen, Belegen für die aktive Ausnutzung und vorhandenen Abhilfemaßnahmen.
14 Tage nach Verfügbarkeit einer Korrekturmaßnahme muss ein Abschlussbericht vorliegen.

ENISA richtet dafür eine zentrale Single Reporting Platform (SRP) ein, die zum 11. September 2026 betriebsbereit sein soll. Hersteller melden nur einmal über diese Plattform – die Weiterleitung an die zuständigen nationalen Stellen erfolgt automatisch.

Was bedeutet das in der Praxis?

Wer als Hersteller bis September 2026 keine internen Prozesse für das Schwachstellenmanagement aufgebaut hat, kann schlicht nicht rechtskonform handeln. Ein 24-Stunden-Fenster für eine Erstmeldung setzt voraus, dass man überhaupt weiß, welche Komponenten in den eigenen Produkten stecken. Dafür braucht man eine Software Bill of Materials (SBOM) – eine strukturierte Inventarliste aller Softwarekomponenten eines Produkts. Der CRA schreibt in Anhang I, Teil II explizit vor, dass Hersteller eine SBOM in einem gängigen, maschinenlesbaren Format erstellen müssen, die mindestens die Top-Level-Abhängigkeiten abdeckt.

Ohne SBOM und automatisiertes Vulnerability-Tracking ist die Einhaltung der Meldefristen bei realistischer Betrachtung unmöglich. Die BSI-Technische Richtlinie TR-03183 spezifiziert die formalen und technischen Anforderungen an SBOMs weiter und dient als Qualitätsmaßstab. In der Praxis bedeutet das: Wer sich erst 2027 vorbereitet, ist bereits über ein Jahr nicht-konform.

Zusätzlich braucht jedes betroffene Unternehmen klare Verantwortlichkeiten: Wer meldet, unter welcher Vollmacht, auf welcher Rechtsgrundlage? Der Aufbau eines Product Security Incident Response Teams (PSIRT) ist für die meisten Hersteller der entscheidende organisatorische Schritt – und der sollte nicht auf den letzten Drücker erfolgen.

CRA Bußgelder: Was bei Verstößen droht

Der CRA arbeitet mit einem dreistufigen Bußgeldrahmen, der sich an der DSGVO orientiert. Gemäß Artikel 64 der Verordnung drohen Herstellern empfindliche Strafen:

Verstoß gegen wesentliche Sicherheitsanforderungen oder Meldepflichten: Bis zu 15 Mio. Euro oder 2,5 Prozent des weltweiten Jahresumsatzes – je nachdem, welcher Betrag höher ist.
Verstoß gegen sonstige CRA-Pflichten (Konformitätsbewertung, Pflichten von Importeuren und Händlern): Bis zu 10 Mio. Euro oder 2 Prozent des Umsatzes.
Falsche, unvollständige oder irreführende Informationen an Behörden: Bis zu 5 Mio. Euro oder 1 Prozent des Umsatzes.

Neben den finanziellen Sanktionen können Marktaufsichtsbehörden Produkte vom EU-Markt zurückrufen, ihren Verkauf untersagen oder einschränken lassen. Für viele Hersteller wäre der Verlust des Marktzugangs wirtschaftlich verheerender als jede Geldstrafe.

Wichtig zu wissen: Für Kleinstunternehmen und kleine Unternehmen gilt eine Ausnahme von der Bußgeldpflicht bei Verstoß gegen die 24-Stunden-Meldefrist. Und für Open-Source-Software-Stewards gilt eine vollständige Befreiung von Geldbußen – dazu gleich mehr.

Open Source und der CRA: Ein differenziertes Bild

Die Frage, wie der CRA mit Open-Source-Software umgeht, hat während des gesamten Gesetzgebungsprozesses für intensive Debatten gesorgt. Organisationen wie die Eclipse Foundation, die Open Source Initiative und The Document Foundation hatten in einem offenen Brief an die EU-Kommission vor unbeabsichtigten negativen Folgen für das Open-Source-Ökosystem gewarnt. Das Ergebnis ist ein differenzierter Ansatz, der zwischen verschiedenen Akteuren und Nutzungsszenarien unterscheidet.

Der Grundsatz lautet: Freie und Open-Source-Software, die nicht monetarisiert wird, fällt grundsätzlich nicht unter den CRA. Erwägungsgrund 18 der Verordnung stellt klar, dass Software, die „offen geteilt und frei zugänglich, nutzbar, veränderbar und weiterverteilbar“ ist und kostenlos ohne kommerzielle Aktivität bereitgestellt wird, vom Geltungsbereich ausgenommen bleibt.

Das bedeutet konkret: Wer als Einzelperson ein Open-Source-Projekt auf GitHub pflegt, Spenden über GitHub Sponsors annimmt und das Projekt nicht aktiv monetarisiert, ist in der Regel nicht betroffen. Der CRA stellt ausdrücklich klar, dass die Annahme von Spenden ohne Gewinnerzielungsabsicht keine kommerzielle Tätigkeit darstellt.

Aber Vorsicht: Sobald jemand die Software kommerziell vermarktet – etwa durch den Verkauf einer Enterprise-Version oder kostenpflichtigen Support – wird diese Person oder Organisation zum Hersteller im Sinne des CRA und unterliegt den vollen Pflichten. Die Herstellerpflichten gelten dann allerdings nur für die monetarisierte Version. Eine parallel existierende kostenlose Community-Version bleibt außen vor, sofern der Entwickler eine Einzelperson ist.

Open-Source-Software-Steward: Die neue Rolle im CRA

Eine der bemerkenswertesten Neuerungen des CRA ist die Einführung einer völlig neuen Kategorie von Akteuren: des Open-Source-Software-Stewards. Diese Rolle wurde während des Gesetzgebungsprozesses als Reaktion auf das Feedback der Open-Source-Community geschaffen und hat kein Vorbild in bisherigen EU-Verordnungen.

Artikel 3 Absatz 14 des CRA definiert einen Open-Source-Software-Steward als eine juristische Person (nicht eine natürliche Person), die – anders als ein Hersteller – systematisch und dauerhaft die Entwicklung bestimmter Open-Source-Produkte unterstützt, die für kommerzielle Aktivitäten bestimmt sind, und deren Lebensfähigkeit sicherstellt. Typische Beispiele sind Foundations wie die Apache Software Foundation, die Eclipse Foundation oder die Linux Foundation, aber auch Unternehmen, die Open-Source-Software in einem geschäftlichen Kontext entwickeln und veröffentlichen, ohne sie direkt zu monetarisieren.

Der entscheidende Unterschied zum Hersteller: Stewards stellen die Software selbst nicht auf dem Markt bereit, sondern unterstützen deren Entwicklung. Die Pflichten nach Artikel 24 sind dementsprechend deutlich leichter – ein „Light-Touch“-Ansatz, wie es im Gesetzgebungsprozess genannt wurde. Stewards müssen eine dokumentierte Cybersicherheitsrichtlinie einführen, die eine sichere Entwicklung fördert. Sie müssen mit Marktaufsichtsbehörden kooperieren. Und sie müssen aktiv ausgenutzte Schwachstellen melden, sofern sie in die Entwicklung des Produkts involviert sind.

Dieser letzte Punkt ist wichtig: Wenn ein Steward nur finanzielle oder organisatorische Unterstützung leistet, aber nicht an der Entwicklung beteiligt ist, greift die Meldepflicht nicht. In der Praxis ist das die typische Konstellation bei vielen Foundations, die Infrastruktur und Governance bereitstellen, aber die Entwicklungsentscheidungen den Projektteams überlassen.

Und der vielleicht wichtigste Aspekt: Gemäß Artikel 64 Absatz 10 des CRA sind Open-Source-Software-Stewards vollständig von Geldbußen befreit – für sämtliche Verstöße gegen die Verordnung. Die anderen Pflichten bestehen zwar weiterhin, aber es drohen keine finanziellen Sanktionen bei Nicht-Einhaltung.

Was in der Praxis unklar bleibt

Trotz des grundsätzlich differenzierten Ansatzes gibt es erhebliche Grauzonen, die in der Community für Verunsicherung sorgen. Ein zentrales Problem hat die Open Regulatory Compliance Working Group (ORC WG) in ihrem Whitepaper identifiziert: Der CRA geht von einem Modell aus, in dem der Steward dem Projekt Richtlinien auferlegt. In der Realität entwickeln viele Open-Source-Projekte ihre eigenen Sicherheitsrichtlinien eigenständig, während Stewards eher Koordination und Infrastruktur bereitstellen als Anweisungen zu geben.

Weitere offene Fragen betreffen Linux-Distributionen und Paketmanager. Ob diese als Stewards einzustufen sind, ist bislang nicht abschließend geklärt. Die Umsetzungsleitlinien der EU-Kommission, deren Entwurf im März 2026 zur Konsultation veröffentlicht wurde, sollen hier für mehr Klarheit sorgen – aber bis diese finalisiert sind, operieren viele Akteure in einem Zustand der Unsicherheit.

Besonders heikel ist die Abgrenzung zwischen Steward und Hersteller. Ein Solo-Maintainer, der eine GmbH gründet und über diese das Projekt betreut, könnte als Steward eingestuft werden – monetarisiert die Firma die Software aber, wird sie zum Hersteller mit vollen Pflichten. Die ORC WG FAQ stellt klar: Natürliche Personen können keine Stewards sein, da ein Steward per Definition eine juristische Person sein muss. Einzelentwickler, die nicht monetarisieren, fallen komplett aus dem Geltungsbereich.

Linux Foundation Report: Alarmierende Wissenslücken

Wie ernst die Lage ist, zeigt der Bericht „Unaware and Uncertain: The Stark Realities of Cyber Resilience Act Readiness in Open Source“, den die Linux Foundation in Zusammenarbeit mit der OpenSSF und Linux Foundation Europe veröffentlicht hat.

Die Ergebnisse sind ernüchternd: 62 Prozent der befragten Open-Source-Akteure gaben an, mit dem CRA gar nicht oder nur oberflächlich vertraut zu sein. Nur ein Viertel der Befragten mit gewisser CRA-Kenntnis konnte das Jahr der vollständigen Anwendbarkeit (2027) korrekt benennen. Über die Hälfte der nicht-kommerziellen Open-Source-Entwickler war unsicher, ob sie überhaupt betroffen sind. Und auf der Herstellerseite zeigte sich, dass viele Unternehmen passiv auf Sicherheitsfixes aus dem Upstream-Bereich warten, statt selbst aktiv Schwachstellen zu managen. Nur ein kleiner Teil der befragten Hersteller produziert bereits SBOMs.

Bei den Stewards offenbarten sich massive Ressourcenengpässe: 50 Prozent nannten fehlende finanzielle Unterstützung als größte Hürde, 47 Prozent fehlende rechtliche Beratung und 44 Prozent fehlende technische Ressourcen.

Der Report empfiehlt unter anderem eine aktivere Rolle der Hersteller bei der Cybersicherheit, mehr Finanzierung und rechtliche Unterstützung für Open-Source-Projekte sowie die Entwicklung von Leitfäden und Best Practices, um unbeabsichtigte negative Auswirkungen auf die Entwicklung zu vermeiden.

Ein zweiter Report der Linux Foundation – „Pathways to Cybersecurity Best Practices in Open Source“ – untersucht am Beispiel von drei konkreten Projekten (Civil Infrastructure Platform, Yocto Project und Zephyr Project), wie Open-Source-Projekte die CRA-Anforderungen praktisch umsetzen können. Dieser Report zeigt, dass Compliance durchaus machbar ist – aber eben vorausschauende Planung und strukturiertes Vorgehen erfordert.

Was bedeutet der CRA für Maker und Hobbyentwickler?

Für die Maker- und Hobbyentwickler-Community ergibt sich ein differenziertes Bild. Wer privat ein Open-Source-Projekt entwickelt, den Code auf GitHub stellt und dafür kein Geld nimmt, fällt nicht unter den CRA. Punkt. Auch wer über Plattformen wie GitHub Sponsors Spenden erhält, ist in der Regel nicht betroffen – solange keine systematische kommerzielle Unterstützung vorliegt.

Aber sobald ein Maker-Projekt kommerziell wird – zum Beispiel ein selbst entwickeltes IoT-Gerät, das über Tindie oder einen eigenen Shop verkauft wird – greifen die vollen Herstellerpflichten. Das umfasst die SBOM-Erstellung, das kontinuierliche Schwachstellenmanagement, die Meldepflichten ab September 2026 und perspektivisch die CE-Kennzeichnung nach CRA-Standards ab Dezember 2027.

Auch wer als Maker ein Produkt entwickelt und die Firmware als Open Source veröffentlicht, aber das physische Produkt verkauft, ist Hersteller im Sinne des CRA. Die Open-Source-Veröffentlichung der Firmware ändert nichts an der Herstellereigenschaft für das Gesamtprodukt.

Allerdings gibt es für Kleinstunternehmen und KMU einige Erleichterungen: Microenterprises und kleine Unternehmen sind von Bußgeldern bei Verstoß gegen die 24-Stunden-Meldefrist befreit. Und bei der Bemessung von Sanktionen müssen die Behörden die Größe des Unternehmens berücksichtigen.

Ressourcen und nächste Schritte

Die Open-Source-Community hat bereits eine Reihe von Ressourcen entwickelt, die bei der Orientierung helfen:

Die Open Regulatory Compliance Working Group (ORC WG) hat einen umfassenden Leitfaden zum CRA erstellt, inklusive FAQ für Maintainer, Stewards und Hersteller. Das zugehörige Whitepaper zu den Steward-Pflichten ist offen für Community-Feedback.

Die OpenSSF bietet mit dem kostenlosen Kurs „Understanding the EU Cyber Resilience Act“ (LFEL1001) einen 90-minütigen, selbstgesteuerten Online-Kurs an, der die wesentlichen CRA-Konzepte vermittelt. Der Kurs verzeichnete in der ersten Woche fast 2.000 Anmeldungen – ein Indikator für den enormen Informationsbedarf.

Die OpenSSF stellt zudem einen Brief Guide for OSS Developers bereit, der auf wenigen Seiten die wichtigsten Fragen für Open-Source-Entwickler beantwortet.

Das BSI als zuständige Marktaufsichtsbehörde in Deutschland veröffentlicht mit der Technischen Richtlinie TR-03183 praxisnahe Interpretationen der CRA-Anforderungen, unterteilt in allgemeine Anforderungen, SBOM-Spezifikationen und den Umgang mit Schwachstellenmeldungen.

Die EU-Kommission selbst listet auf ihrer CRA-Seite für Open Source weitere Community-Ressourcen und verlinkt auf relevante Initiativen.

Fazit: Handeln statt abwarten

Der EU Cyber Resilience Act markiert einen der bedeutendsten regulatorischen Einschnitte für die Softwarebranche in Europa. Erstmals wird Cybersicherheit zur nicht verhandelbaren Marktzugangsvoraussetzung – vergleichbar mit den Sicherheitsanforderungen für elektrische Geräte oder Spielzeug.

Die gute Nachricht für die Open-Source-Community: Der Gesetzgeber hat die besondere Natur von Open-Source-Entwicklung anerkannt. Die Einführung der Steward-Kategorie mit Light-Touch-Pflichten und der vollständigen Bußgeldbefreiung zeigt, dass das Feedback der Community Wirkung gezeigt hat. Individuelle, nicht-kommerzielle Entwickler sind explizit ausgenommen.

Die schlechte Nachricht: Die Wissenslücken sind enorm, die Zeit ist knapp, und viele offene Fragen sind noch ungeklärt. Für Hersteller – auch kleine, auch Maker, die Produkte verkaufen – tickt die Uhr. September 2026 kommt schneller, als viele denken.

Wer Open-Source-Software entwickelt oder nutzt, sollte jetzt drei Dinge tun: Erstens, die eigene Rolle klären – bin ich Hersteller, Steward oder falle ich gar nicht unter den CRA? Zweitens, sich informieren, etwa über den kostenlosen OpenSSF-Kurs oder die ORC-WG-Ressourcen. Und drittens, wenn betroffen, sofort mit der Gap-Analyse beginnen – denn in weniger als fünf Monaten greift die erste Meldepflicht, und bis dahin müssen Prozesse, Verantwortlichkeiten und SBOMs stehen.

Die Zeit des Abwartens ist vorbei.

Quellen:

EU Cyber Resilience Act und die Open-Source-Community – Der Countdown läuft