Cyber Resilience Act – Übersicht und Auswirkungen

Der Cyber Resilience Act (CRA) ist eine EU-Verordnung (EU) 2024/2847, die verbindliche Cybersicherheitsanforderungen für alle Produkte mit digitalen Elementen einführt. Ziel ist es, Sicherheitsrisiken zu reduzieren, Schwachstellen schneller zu beseitigen und Transparenz zu schaffen. Dies erfolgt über verpflichtende Konformitätsbewertungen und die Vergabe einer CE-Kennzeichnung, mit der Hersteller erklären, dass ihre Produkte die im CRA definierten Cybersicherheitsanforderungen erfüllen. Das Ganze ist mit etablierten CE-Kennzeichen in anderen Produktbereichen vergleichbar.

{{< centered-image src="/posts/2025-12-15-cra/ce-stemp.png" width="100%" alt="Illustration bzgl. des CE Kennzeichens für Software">}}

Der CRA wurde am 10. Dezember 2024 wirksam und gilt als EU-Verordnung ohne nationale Umsetzung direkt in allen Mitgliedstaaten, also auch in Deutschland. Dabei sind insbesondere die folgenden rechtlich relevanten Meilensteine zu beachten:

Ab dem 11.06.2026 dürfen notifizierte Prüfstellen Zertifizierungen durchführen
Ab dem 11.09.2026 müssen alle Softwarehersteller aktiv ausgenutzte Schwachstellen innerhalb von 24 Stunden und Sicherheitsvorfälle innerhalb von 72 Stunden an CERT/ENISA melden
Ab dem 11.12.2027 sind alle CRA-Anforderungen verbindlich anzuwenden. Jede in der EU vertriebene Software benötigt ab diesem Tag verpflichtend eine CE‑Kennzeichnung

Anforderungen des CRA für Software Hersteller

Das CRA definiert verschiedenste Hauptanforderungen, die von allen Herstellern umgesetzt werden müssen um in Zukunft weiterhin legal Software in der EU vertreiben zu dürfen. Analog zu anderen Produkten wird Software, welche den Anforderungen genügt, mit einem CE-Kennzeichen versehen, nachdem diese eine Prüfung durch eine benannte Stelle erfolgreich durchlaufen hat. Die verschiedenen Anforderungen sind hier einmal auf eine sehr vereinfachte Übersicht heruntergebrochen:

Security by Design & Default, wodurch Cybersecurity bereits in Softwarearchitektur, Code und Konfigurationsstandards verankert sein muss.
Verpflichtende Sicherheitsdokumentationen, durch die Nutzende alle sicherheitsrelevante Funktionen nachvollziehen können.
Schwachstellenmanagement und Incident Reporting, wodurch eine kontinuierlich Überwachung der Software auf Schwachstellen und eine konkrete Meldepflicht definiert wird.
Verpflichtende Software Bill of Materials (SBOM), die alle technischen Informationen der Software (inklusive aller transitiven Abhängigkeiten) beinhalten, gegen Schwachstellen-Datenbanken abgeglichen und mindestens 10 Jahre bzw. über die Supportdauer des Produkts aufbewahrt werden muss.
Kostenlose Sicherheitsupdates, die mindestens über den definierten Supportzeitraum der Software – in der Regel mindestens fünf Jahre, häufig jedoch bis zu zehn Jahre – bereitgestellt werden müssen.

{{< centered-image src="/posts/2025-12-15-cra/requirements-de.png" width="100%" alt="Anforderungen an Hersteller">}}

Willst du mehr zu den Anforderungen des CRA wissen? Wir helfen hier gerne und teilen unser Wissen. [Kontaktiere uns]({{< relref "contact" >}}) einfach für weitere Fragen oder [abonniere unseren Newsletter]({{< relref "newsletter" >}}).

Wie kommt nun Open Source ins Spiel?

Zunächst die gute Nachricht: Das Bereitstellen von nicht-kommerzieller OSS ist vom CRA ausdrücklich ausgenommen.

Diese Ausnahme entbindet jedoch nicht die kommerziellen Softwarehersteller von der Verantwortung für die in ihren Produkten eingesetzten Open-Source-Komponenten. Der CRA folgt hier einem klaren Prinzip: Verantwortlich ist immer derjenige, der Software als Produkt in Verkehr bringt – unabhängig davon, ob einzelne Bestandteile selbst entwickelt oder als Open Source eingebunden wurden. Dies gilt ausdrücklich auch für Open-Source-Software, die selbst im Rahmen eines kommerziellen Geschäftsmodells vertrieben wird, etwa in Form von kostenpflichtigen „Pro“- oder Enterprise-Varianten von (F)OSS-Projekten. Genau an dieser Stelle kommen Open-Source-Stewards und CRA-konforme Attestierungen für Open-Source-Software ins Spiel: Sie schaffen die notwendige Grundlage, damit Hersteller ihre Nachweispflichten entlang der Software-Lieferkette erfüllen können.

Allerdings ist zwar das Bereitstellen von OSS im CRA ausgenommen, eine Einbettung von Open-Source-Komponenten in kommerzielle Software befreit die Hersteller dieser Produkte in keinerlei Hinsicht von der Anforderungen und Nachweispflichten der intern verwendeten Open-Source-Software. Dies bedeutet, dass jeder Anbieter von kommerzieller Software nun für die im Produkt genutzten Open-Source-Komponenten offiziell verantwortlich ist und bei Problemen zur Rechenschaft gezogen werden kann. Schaut man sich an, dass nach aktuellen Schätzungen über 75-80% moderner Softwareprodukte aus Open-Source-Komponenten besteht und nur maximal 25% eines kommerziellen Produktes selbsterstellter Code ist, erkennt man schnell die Herausforderung, vor der kommerzielle Softwareanbieter in Zukunft stehen werden: Während sie bisher den größten Teil ihrer Produktes kostenlos durch Open-Source Komponenten erhalten konnten, müssen sie nun für diese Rechenschaft abliefern. Die folgenden Pflichten ergeben sich nicht für Open Source selbst, sondern für den Hersteller des kommerziellen Gesamtprodukts:

Bewertung der Qualität aller OSS‑Bibliotheken
Überwachung von CVEs
Patchen von OSS Komponenten innerhalb enger Zeitfenster
Dokumentation durch SBOM
Meldung aktiv genutzter Schwachstellen an Behörden inklusive festgesetzter Deadlines

{{< centered-image src="/posts/2025-12-15-cra/duties-de.png" width="100%" alt="Pflichten für Hersteller">}}

In der Praxis ist es für einzelne Hersteller kaum realistisch, diese Pflichten für jede eingesetzte Open-Source-Komponente eigenständig vollständig zu erfüllen. Hier übernehmen Open-Source-Stewards eine Schlüsselrolle, indem sie Pflege, Sicherheitsprozesse und perspektivisch auch CRA-konforme Attestierungen für von ihnen betreute Projekte bereitstellen– und damit kommerziellen Herstellern ermöglichen, ihre gesetzlichen Nachweispflichten verlässlich zu erfüllen.

Open-Source-Stewards als Retter des Kapitalismus

Sicherlich ist allen klar, dass es keine Lösung sein kann, dass Hersteller nun alle Open-Source-Komponenten gegen neue und selbstgeschriebene Bausteine ersetzen.

Dies wäre aus wirtschaftlicher und sicherheitstechnischer Sicht schlicht unverantwortlich und unrealistisch. Die Lösung ist hierbei vielmehr, dass Open-Source-Stewards, die bereits heute die Pflege und Weiterentwicklung von Open-Source-Software übernehmen, sinnvolle und nachhaltige Unterstützung für Softwarehersteller anbieten. Bekannte Beispiele für Open-Source-Stewards sind gemeinnützige Organisationen wie die Eclipse Foundation oder die Linux Foundation, Firmen wie Red Hat oder Open Elements sowie staatliche Einrichtungen wie die Sovereign Tech Agency (STA) oder ZenDis. Alle diese Entitäten beschäftigen sich bereits heute damit, die Anforderungen des CRA für die von ihnen verwaltete OSS umzusetzen. Hierdurch entstehen Multiplikatoren, die allen Softwareanbietern helfen. Um als kommerzieller Softwarehersteller den Anforderungen des CRA gerecht zu werden, reicht es aber nicht, einfach auf die Open-Source-Stewards und deren Arbeit zu verweisen. Um hier einen sicheren Workflow zu ermöglichen, gibt es aktuell Diskussionen darüber, dass Open-Source-Stewards in Zukunft CRA-konforme Attestierungen für von ihnen betreute Open-Source-Projekte anbieten können. Diese können von kommerziellen Herstellern zum Erhalt eines CE-Kennzeichens genutzt werden. Vor allem darüber, wie und zu welchen Preisen bzw. Konditionen solche Attestierungen in Zukunft angeboten werden, gibt es aktuell eine aktive Diskussion.

{{< centered-image src="/posts/2025-12-15-cra/steward.png" width="100%" alt="Open Elements als Open Source Steward">}}

Ein Großteil dieser und weiterer Diskussionen zum Cyber Resilience Act erfolgt aktuell über die Open Regulatory Compliance Working Group in der Open Elements, zu den 20 Gründungsmitgliedern, neben Großen wie Siemens oder dem OpenForum Europe, gehört. Nach der Gründung im Jahr 2024 ist die Arbeitsgruppe mittlerweile stark gewachsen und Firmen wie Microsoft, Google oder Mercedes-Benz haben sich angeschlossen, um als Softwarehersteller bereits heute über die kommenden Anforderungen des CRA informiert zu sein.

Warum Unternehmen bereits jetzt in OSS investieren müssen

Auch wenn die hier beschriebene Lösung sehr vielversprechend klingt, dürfen Softwarehersteller nicht bis Ende nächsten Jahres warten, bevor sie sich mit dem Thema auseinandersetzen. Viele kritische Open-Source-Projekte erfüllen heute bei weitem noch nicht die vom CRA definierten Pflichten. Das Apache Maven(TM)-Projekt, welches von Open Elements durch eine staatliche Förderung zur Pflege von kritischer Infrastruktur aktuell weiterentwickelt und gepflegt wird, hatte, bevor wir mit der Pflege begonnen haben, eine Median-Patchzeit von bis zu 150 Tagen. Dies überschreitet bei Weitem die Fristen des CRA. Diese Probleme werden sich nicht von einem auf den anderen Tag ändern lassen. Für Apache Maven kommt auch noch hinzu, dass die aktuelle Investition in das Projekt aller Voraussicht nach in der ersten Jahreshälfte 2026 auslaufen wird. Für andere Projekte sind die Probleme sogar noch größer. So liegt das Patchdelay in NPM durchschnittlich bei 4–11 Monaten. Diese Zahlen und Fakten zeigen, dass vor allem große Projekte mit einer komplizierten Supply Chain und vielen Abhängigkeiten hier bereits heute aktiv werden müssen.

Empfehlungen für Unternehmen

Wir empfehlen jedem Unternehmen bereits heute, die eigene Software auf den CRA vorzubereiten. Hierbei sind aus unserer Sicht vor allem die folgenden Punkte essenziell wichtig:

SBOM-Management aufbauen
Risikoanalyse aller Abhängigkeiten durchführen
OSS‑Projekte aktiv unterstützen (Funding, Contributions, Stewardship)

{{< centered-image src="/posts/2025-12-15-cra/recommendations-de.png" width="100%" alt="Empfehlungen für Unternehmen">}}

Gerne unterstützen wir dich bei der Analyse deiner OSS Abhängigkeiten. [Kontaktiere uns]({{< relref "contact" >}}) einfach für weitere Fragen oder [abonniere unseren Newsletter]({{< relref "newsletter" >}}).

Welche Risiken drohen bei Nicht-Einhaltung?

Der CRA ist kein unverbindlicher Leitfaden, sondern ein durchsetzbares Marktregulierungsinstrument.
Bei Verstößen drohen Bußgelder von bis zu 15 Millionen Euro oder 2,5 % des weltweiten Jahresumsatzes. Zusätzlich können Produkte vom EU-Markt genommen oder deren Vertrieb untersagt werden.

Fazit

Der Cyber Resilience Act verändert Software-Lieferketten tiefgreifend. Auch wenn es initial wie ein kompliziertes Problem klingt, birgt der CRA sehr viele Chancen. Wir leben in einer Welt, in der es minütlich zu gefährlichen Cyberangriffen kommt, indem Schwachstellen von Software aktiv ausgenutzt werden. Durch unsere immer weiter digitalisierte und vernetzte Welt entsteht durch diese Angriffe ein immer größeres Sicherheitsrisiko. Der CRA hilft dabei, dies in den Griff zu bekommen, indem die Verordnung Verantwortungen klar definiert. Hierdurch wird sich vor allem für Anbieter von kommerzieller Software etwas ändern:

Open Source ist kein kostenloser Rohstoff mehr, sondern kritische Infrastruktur.
Wer ihn nutzt, trägt Verantwortung – und muss bereit sein, in dessen Nachhaltigkeit und Sicherheit zu investieren.

Eine Investition in Open Source ist keine Option mehr, sondern eine Voraussetzung für die Marktfähigkeit ab 2027.