Inhaltsverzeichnis
- 1.Was der Cyber Resilience Act regelt — und warum er auch reine Software trifft
- 2.Der Zeitstrahl: Welche Frist wann scharf wird
- 3.Die 24/72/14-Kaskade: Was genau gemeldet werden muss
- 4.Was jetzt in den SDLC muss: Sechs konkrete Bausteine
- 5.CRA neben NIS2, DORA und dem AI Act: die Regulierungsmatrix
- 6.Sanktionen und die nächsten 90 Tage
Was der Cyber Resilience Act regelt — und warum er auch reine Software trifft
Der Cyber Resilience Act (Verordnung (EU) 2024/2847) ist das erste EU-weite Gesetz, das verbindliche Cybersicherheitsanforderungen an "Produkte mit digitalen Elementen" über deren gesamten Lebenszyklus stellt. Anders als NIS2, das Betreiber kritischer und wichtiger Einrichtungen reguliert, adressiert der CRA die Hersteller selbst: Wer Hardware oder Software mit einer direkten oder indirekten Datenverbindung auf dem EU-Markt bereitstellt, muss künftig nachweisen, dass das Produkt "secure by design" entwickelt, mit Sicherheitsupdates versorgt und über einen definierten Support-Zeitraum gepflegt wird. Die Verordnung trat am 10. Dezember 2024 in Kraft (siehe https://eur-lex.europa.eu/eli/reg/2024/2847/oj).
Entscheidend für Delivery-Organisationen ist der weite Geltungsbereich: Der CRA erfasst ausdrücklich auch reine Software — Betriebssysteme, Bibliotheken, Anwendungen, Firmware. Die EU-Kommission stellt klar, dass jedes Produkt mit digitalen Elementen, das kommerziell auf dem Markt bereitgestellt wird, in den Anwendungsbereich fällt, sofern es nicht durch sektorspezifische Regeln (Medizinprodukte, Kraftfahrzeuge, Luftfahrt) bereits abgedeckt ist (siehe https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act). Reine Software-as-a-Service-Angebote fallen grundsätzlich nicht darunter — wohl aber die Software-Artefakte, die ausgeliefert oder eingebettet werden.
Damit verschiebt der CRA eine Grundannahme der Produktentwicklung: Cybersicherheit ist nicht länger ein nachgelagertes Qualitätsmerkmal, sondern eine regulatorische Markteintrittsvoraussetzung mit CE-Kennzeichnung. Für Engineering-Leads heißt das, dass Sicherheitsanforderungen, Schwachstellen-Handling und Update-Fähigkeit zu Pflichtbestandteilen der Definition of Done werden — überprüfbar, dokumentiert und auditierbar.
Der CRA macht aus Cybersicherheit eine Produkteigenschaft mit CE-Pflicht. Für Software-Hersteller heißt das: Security-by-Design, Schwachstellen-Handling und ein definierter Support-Zeitraum sind keine Kür mehr, sondern Marktzugangsbedingung.
Der Zeitstrahl: Welche Frist wann scharf wird
Der CRA wird gestaffelt anwendbar, und genau diese Staffelung ist die häufigste Planungsfalle. Drei Stichtage sind für Delivery-Roadmaps relevant: Ab dem 11. Juni 2026 gelten die Vorschriften zur Notifizierung von Konformitätsbewertungsstellen. Ab dem 11. September 2026 greifen die Meldepflichten für aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle. Und ab dem 11. Dezember 2027 ist der CRA in vollem Umfang anwendbar — inklusive aller wesentlichen Anforderungen und der CE-Kennzeichnungspflicht (siehe https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act).
Die Reihenfolge ist kontraintuitiv: Die operativ anspruchsvollste Pflicht — das fristgebundene Melden von Vorfällen an die Behörden — gilt fünfzehn Monate vor der vollen Anwendbarkeit. Wer bis Dezember 2027 wartet, um sich mit dem CRA zu beschäftigen, hat die Meldepflicht bereits über ein Jahr lang verletzt. Genau dieses Muster — eine vorgezogene Berichtspflicht vor der materiellen Vollanwendung — kennen Organisationen bereits aus NIS2 und DORA; der CRA wiederholt es.
Für die Planung bedeutet das eine klare Priorisierung: Der Meldeprozess muss vor dem 11. September 2026 stehen, unabhängig davon, ob die vollständige Konformitätsdokumentation schon fertig ist. Die wesentlichen technischen Anforderungen aus Anhang I haben mit Dezember 2027 mehr Vorlauf, dürfen aber nicht erst dann angegangen werden, weil Security-by-Design-Eigenschaften nicht nachträglich in ausgelieferte Produkte zurückgebaut werden können.
| Stichtag | Pflicht | Was Delivery-Teams bis dahin brauchen |
|---|---|---|
| 11. Juni 2026 | Notifizierung von Konformitätsbewertungsstellen | Klärung, ob das Produkt als "wichtig" (Anhang III) oder "kritisch" (Anhang IV) eingestuft ist und welcher Konformitätsweg gilt |
| 11. September 2026 | Meldepflichten (Art. 14): 24h / 72h / 14 Tage | Funktionierender Incident- und Schwachstellen-Meldeprozess an CSIRT + ENISA, inkl. Rollen, Eskalation und Vorlagen |
| 11. Dezember 2027 | Volle Anwendbarkeit, CE-Kennzeichnung | Anhang-I-Anforderungen erfüllt, technische Dokumentation, SBOM, Update-Mechanismus, Support-Zeitraum dokumentiert |
Die 24/72/14-Kaskade: Was genau gemeldet werden muss
Der Kern der ab September 2026 geltenden Pflicht ist eine dreistufige Meldekaskade nach Artikel 14 der Verordnung. Sie greift bei zwei Auslösern: einer aktiv ausgenutzten Schwachstelle im Produkt und einem schwerwiegenden Sicherheitsvorfall, der die Sicherheit des Produkts beeinträchtigt. In beiden Fällen läuft dieselbe Frist-Logik (siehe https://eur-lex.europa.eu/eli/reg/2024/2847/oj).
Stufe eins ist die Frühwarnung: Innerhalb von 24 Stunden, nachdem der Hersteller Kenntnis erlangt hat, muss eine erste Meldung erfolgen — knapp, aber unverzüglich. Stufe zwei ist die eigentliche Vorfallsmeldung innerhalb von 72 Stunden, mit den verfügbaren Details zu Art, Auswirkung und ergriffenen Korrekturmaßnahmen. Stufe drei ist der Abschlussbericht: bei Schwachstellen innerhalb von 14 Tagen, nachdem eine Korrektur- oder Abhilfemaßnahme verfügbar ist, bei schwerwiegenden Vorfällen innerhalb eines Monats nach der 72-Stunden-Meldung.
Adressat ist nicht eine einzelne Behörde, sondern das als Koordinator benannte CSIRT des Mitgliedstaats zusammen mit der EU-Agentur für Cybersicherheit ENISA, technisch abgewickelt über eine zentrale Meldeplattform, die ENISA bereitstellt (siehe https://www.hoganlovells.com/en/publications/eu-cyber-resilience-act-getting-ready-for-cra-compliance-in-2026). Für Delivery-Organisationen ist die 24-Stunden-Frühwarnung der schärfste Hebel: Sie ist nur einhaltbar, wenn die Erkennung, die Entscheidung "ist das meldepflichtig?" und die Meldung selbst vorab als Prozess definiert und geprobt sind. Ein Ticket-Workflow, der erst im Ernstfall improvisiert wird, scheitert an dieser Frist.
Die drei Meldestufen im Überblick
Frühwarnung (24 Stunden ab Kenntnis): erste Benachrichtigung über die aktiv ausgenutzte Schwachstelle oder den schwerwiegenden Vorfall. Vorfallsmeldung (72 Stunden): inhaltliche Meldung mit Bewertung, Betroffenheit und ersten Gegenmaßnahmen. Abschlussbericht (14 Tage bei Schwachstellen nach Verfügbarkeit der Abhilfe / 1 Monat bei Vorfällen): Ursachenanalyse, getroffene Maßnahmen, Lessons Learned.
Praktisch heißt das: Die Organisation braucht eine klare Zuständigkeit (wer entscheidet über die Meldung?), eine 24/7-erreichbare Eskalationskette und vorbereitete Meldevorlagen. Die Frist beginnt mit der Kenntniserlangung — nicht mit der internen Bestätigung, nicht mit dem Fix.
Was jetzt in den SDLC muss: Sechs konkrete Bausteine
Der CRA lässt sich nicht durch ein einmaliges Compliance-Projekt erledigen, weil seine Anforderungen über den gesamten Lebenszyklus laufen. Sechs Bausteine gehören in die Delivery-Pipeline, nicht in eine separate Compliance-Ablage.
Erstens eine Software Bill of Materials (SBOM): Der CRA verlangt, dass Hersteller die in ihren Produkten enthaltenen Komponenten kennen und dokumentieren. Eine maschinenlesbare SBOM (CycloneDX oder SPDX) aus dem Build-Prozess heraus ist die Grundlage, um bei einer neu bekannt gewordenen Schwachstelle innerhalb von Stunden zu beantworten, ob das eigene Produkt betroffen ist. Zweitens ein koordinierter Vulnerability-Disclosure-Prozess mit einer öffentlichen Kontaktstelle und einer Security-Policy. Drittens ein Update-Mechanismus, der Sicherheitsupdates zeitnah und möglichst automatisch ausliefert.
Viertens die technische Dokumentation und der Konformitätsnachweis, die für die CE-Kennzeichnung ab Dezember 2027 nötig sind — diese Artefakte entstehen am günstigsten kontinuierlich, nicht in einem Schlussspurt. Fünftens der definierte Support-Zeitraum: Der CRA erwartet, dass Hersteller einen Zeitraum festlegen und kommunizieren, in dem sie Sicherheitsupdates bereitstellen; die EU-Kommission nennt fünf Jahre als Orientierung, sofern die erwartete Nutzungsdauer nicht kürzer ist (siehe https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act). Sechstens der geprobte Meldeprozess für die 24/72/14-Kaskade als Teil des Incident-Runbooks.
Der gemeinsame Nenner dieser sechs Bausteine: Sie sind allesamt automatisierbar und gehören in die CI/CD-Pipeline. Eine Organisation, die SBOM-Erzeugung, Dependency-Scanning und Update-Auslieferung als Pipeline-Stufen behandelt, erfüllt die CRA-Substanz als Nebenprodukt guter Engineering-Praxis — statt sie als regulatorische Sonderlast zu tragen.
CRA neben NIS2, DORA und dem AI Act: die Regulierungsmatrix
Der häufigste Fehler in der Praxis ist, den CRA isoliert zu betrachten. Tatsächlich überlappt er mit den anderen großen EU-Rahmenwerken an genau den Stellen, an denen Delivery-Governance ohnehin ansetzt. NIS2 reguliert die Betreiber wichtiger und kritischer Einrichtungen und ihre Meldepflichten an das BSI; der CRA reguliert die Produkte, die diese Betreiber einsetzen. Eine Organisation, die zugleich Software herstellt und kritische Dienste betreibt, fällt unter beide — mit zwei parallelen, aber unterschiedlichen Meldewegen (BSI für NIS2-Vorfälle, CSIRT/ENISA für CRA-Produktvorfälle).
DORA wiederum verlangt von Finanzunternehmen ein striktes Management ihrer IKT-Drittanbieter samt Informationsregister — und CRA-konforme Produkte werden zu einem prüfbaren Qualitätsmerkmal in genau diesem Drittanbieter-Management. Der AI Act schließlich greift dort, wo das Produkt mit digitalen Elementen ein KI-System ist; für Hochrisiko-KI verweisen die Cybersicherheitsanforderungen des AI Act auf das CRA-Niveau. Das BSI ordnet den CRA in diesen Gesamtkontext der europäischen Cybersicherheitsgesetzgebung ein (siehe https://www.bsi.bund.de/dok/cyber-resilience-act).
Für die Governance-Praxis folgt daraus eine effizientere Strategie als vier getrennte Compliance-Silos: Ein gemeinsames Schwachstellen- und Vorfalls-Management, das die unterschiedlichen Fristen und Adressaten als Varianten desselben Prozesses behandelt, deckt CRA, NIS2 und DORA mit einem Mechanismus ab. Wer hingegen für jede Verordnung ein eigenes Runbook aufbaut, produziert Reibung und Lücken an den Schnittstellen — und genau diese Schnittstellen sind es, an denen im Ernstfall die 24-Stunden-Frist reißt.
CRA, NIS2, DORA und AI Act sind keine vier Projekte, sondern vier Sichten auf denselben Kern: Schwachstellen kennen, Vorfälle erkennen, fristgerecht melden, nachweisbar handeln. Wer das als einen Prozess baut, spart Aufwand und schließt die gefährlichen Schnittstellen-Lücken.
Sanktionen und die nächsten 90 Tage
Der CRA ist mit spürbaren Sanktionen bewehrt: Bei Verstößen gegen die wesentlichen Cybersicherheitsanforderungen drohen Geldbußen von bis zu 15 Millionen Euro oder 2,5 Prozent des weltweiten Jahresumsatzes, je nachdem, welcher Betrag höher ist (siehe https://eur-lex.europa.eu/eli/reg/2024/2847/oj). Das hebt den CRA auf ein Durchsetzungsniveau, das mit der DSGVO vergleichbar ist, und macht ihn zu einem Vorstandsthema, nicht nur zu einer Engineering-Aufgabe.
Für die nächsten 90 Tage empfiehlt sich ein nüchterner Dreischritt. Erstens: Bestandsaufnahme — welche der eigenen Produkte fallen überhaupt unter den CRA, und sind darunter "wichtige" oder "kritische" gemäß Anhang III und IV? Zweitens: den Meldeprozess für die 24/72/14-Kaskade als Erstes bauen und durchspielen, weil seine Frist im September 2026 als erste scharf wird. Drittens: SBOM-Erzeugung und Dependency-Scanning als Pipeline-Stufen einführen, damit die Frage "sind wir betroffen?" bei der nächsten kritischen Schwachstelle in Minuten statt Tagen beantwortet ist.
Der CRA belohnt Organisationen, die ihre Sicherheitsarbeit bereits als kontinuierlichen Pipeline-Bestandteil betreiben, und bestraft jene, die Security als nachgelagertes Audit verstehen. Damit ist er weniger eine neue Last als ein regulatorischer Anlass, Engineering-Disziplin nachzuholen, die ohnehin überfällig war.
Die wichtigsten Erkenntnisse
- Der Cyber Resilience Act (Verordnung (EU) 2024/2847) reguliert die Hersteller von Produkten mit digitalen Elementen — inklusive reiner Software — und macht Cybersicherheit zur CE-pflichtigen Produkteigenschaft.
- Die Meldepflichten greifen bereits ab 11. September 2026, fünfzehn Monate vor der vollen Anwendbarkeit am 11. Dezember 2027 — wer bis 2027 wartet, verletzt die Meldepflicht über ein Jahr lang.
- Die Meldekaskade nach Artikel 14 ist dreistufig: 24-Stunden-Frühwarnung, 72-Stunden-Vorfallsmeldung, 14-Tage-Abschlussbericht — an das koordinierende CSIRT und ENISA über eine zentrale Plattform.
- Sechs Bausteine gehören in den SDLC: SBOM, koordinierter Vulnerability-Disclosure, Update-Mechanismus, technische Dokumentation, definierter Support-Zeitraum und ein geprobter Meldeprozess.
- CRA, NIS2, DORA und AI Act überlappen — ein gemeinsames Schwachstellen- und Vorfalls-Management deckt alle vier mit einem Prozess ab, statt vier getrennte Compliance-Silos zu bauen.
- Bußgelder von bis zu 15 Mio. Euro oder 2,5 % des weltweiten Jahresumsatzes machen den CRA zum Vorstandsthema.
Passende Assessment-Templates
Häufig gestellte Fragen
Ja. Der CRA erfasst "Produkte mit digitalen Elementen", und die EU-Kommission stellt klar, dass darunter ausdrücklich auch reine Software fällt — Betriebssysteme, Bibliotheken, Anwendungen und Firmware, sofern sie kommerziell auf dem EU-Markt bereitgestellt werden. Ausgenommen sind unter anderem reine Software-as-a-Service-Angebote sowie Produkte, die bereits durch sektorspezifische Rechtsakte (Medizinprodukte, Kraftfahrzeuge, Luftfahrt) abgedeckt sind. Nicht-kommerzielle Open-Source-Software fällt grundsätzlich nicht in den Anwendungsbereich, kommerziell vertriebene Open-Source-Produkte hingegen schon.
Die Meldepflichten für aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle nach Artikel 14 gelten ab dem 11. September 2026. Das ist deutlich früher als die volle Anwendbarkeit der Verordnung am 11. Dezember 2027. Ein dritter Stichtag, der 11. Juni 2026, betrifft die Notifizierung von Konformitätsbewertungsstellen. Die gestaffelte Anwendbarkeit ist die häufigste Planungsfalle: Die operativ anspruchsvollste Pflicht — das fristgebundene Melden — gilt zuerst.
Sie beschreibt die dreistufige Meldekaskade: Innerhalb von 24 Stunden nach Kenntniserlangung ist eine Frühwarnung abzugeben, innerhalb von 72 Stunden die eigentliche Vorfalls- oder Schwachstellenmeldung mit den verfügbaren Details, und ein Abschlussbericht folgt bei Schwachstellen innerhalb von 14 Tagen nach Verfügbarkeit einer Abhilfemaßnahme beziehungsweise bei schwerwiegenden Vorfällen innerhalb eines Monats. Die Fristen beginnen mit der Kenntniserlangung, nicht mit der internen Bestätigung oder dem Fix — deshalb muss der Prozess vorab definiert und geprobt sein.
Nicht primär an das BSI. CRA-Meldungen gehen an das als Koordinator benannte CSIRT des betreffenden Mitgliedstaats zusammen mit der EU-Agentur für Cybersicherheit ENISA, technisch über eine zentrale Meldeplattform, die ENISA bereitstellt. Das ist ein anderer Meldeweg als bei NIS2, wo Vorfälle in Deutschland an das BSI gehen. Organisationen, die sowohl Produkte herstellen als auch kritische Dienste betreiben, müssen deshalb beide Wege parallel bedienen — ein wesentlicher Grund, das Vorfalls-Management als einen Prozess mit mehreren Ausgabevarianten zu bauen.
NIS2 reguliert die Betreiber wichtiger und kritischer Einrichtungen, der CRA die Produkte, die diese Betreiber einsetzen. DORA verlangt von Finanzunternehmen ein striktes IKT-Drittanbieter-Management, in dem CRA-Konformität zu einem prüfbaren Qualitätsmerkmal wird. Der AI Act greift dort, wo das Produkt ein KI-System ist, und verweist für Hochrisiko-KI auf das CRA-Sicherheitsniveau. Die Rahmenwerke überlappen an den Stellen, an denen Delivery-Governance ohnehin ansetzt: Schwachstellen kennen, Vorfälle erkennen, fristgerecht melden. Ein gemeinsamer Mechanismus ist effizienter und sicherer als vier getrennte Silos.
Bei Verstößen gegen die wesentlichen Cybersicherheitsanforderungen sieht der CRA Geldbußen von bis zu 15 Millionen Euro oder 2,5 Prozent des weltweiten Jahresumsatzes vor, je nachdem, welcher Betrag höher ist. Für andere Pflichtverstöße gelten niedrigere, aber ebenfalls erhebliche Obergrenzen. Dieses Sanktionsniveau ist mit der DSGVO vergleichbar und macht den CRA zu einem Thema für die Geschäftsleitung, nicht nur für das Engineering. Die Marktüberwachungsbehörden der Mitgliedstaaten setzen die Verordnung durch.