Der umfassende Leitfaden zum EU Cyber Resilience Act (CRA)

Der Cyber Resilience Act (Verordnung (EU) 2024/2847) ist das Cybersicherheitsgesetz der EU für Produkte mit digitalen Elementen. Er ist am 10. Dezember 2024 in Kraft getreten und adressiert zwei zentrale Probleme: das niedrige Grundniveau an Sicherheit vernetzter Produkte und den Mangel an Informationen, die Nutzer benötigen, um diese Produkte sicher auszuwählen und zu betreiben. Ausgangspunkt ist die Annahme, dass jedes vernetzte Produkt zum Einfallstor für Angreifer werden kann. Deshalb gelten die Mindestanforderungen breit und nicht nur für eine eng gefasste Liste kritischer Software.

Entscheidend ist: Jede Organisation, die Hardware oder Software im Rahmen einer Geschäftstätigkeit auf dem EU-Markt in Verkehr bringt, fällt in den Anwendungsbereich, auch wenn sie ihren Sitz außerhalb der EU hat. Ausgenommen sind bestimmte Bereiche, etwa reine SaaS-Angebote, Medizinprodukte, Zivilluftfahrt, Schiffsausrüstung und nicht kommerzielle Open Source. Zudem übernehmen Einführer und Händler die Pflichten des Herstellers, wenn sie ein Produkt unter eigenem Namen oder eigener Marke vertreiben oder es wesentlich ändern (oder Open Source in ein kommerzielles Produkt integrieren). Auch für Verwalter quelloffener Software gelten bestimmte Pflichten aus dem CRA.

Die ersten Pflichten für Hersteller gelten seit dem 11. September 2026. Sie betreffen die Meldeverfahren für aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle. Die zweite Gruppe von Anforderungen, darunter Verfahren zur Behandlung von Schwachstellen, SBOMs, Security by Default und weitere, gilt ab dem 11. Dezember 2027. Produkte, die ab diesem Datum auf dem EU-Markt in Verkehr gebracht werden, müssen die Konformitätsanforderungen des CRA erfüllen und die CE-Kennzeichnung tragen.

Der CRA wird über drei Jahre schrittweise wirksam. Die Meldepflicht gilt bereits; die übrigen Anforderungen folgen im Dezember 2027.

Artikel 14 des CRA, der seit dem 11. September 2026 gilt, enthält die Pflichten zur Meldung von Schwachstellen und Sicherheitsvorfällen. Organisationen müssen aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle nun innerhalb von 24 Stunden an die ENISA melden, innerhalb von 72 Stunden weitere Angaben nachreichen und in den folgenden Wochen einen Abschlussbericht vorlegen. Falls noch nicht geschehen, benennen Sie auf der Plattform der ENISA einen primären und bis zu 20 sekundäre „Assigned Representatives“, die das Meldeverfahren in Ihrem Namen abwickeln. Richten Sie außerdem einen Ablauf für die Reaktion auf Sicherheitsvorfälle ein, der die drei vom CRA geforderten Meldungen liefern kann.

Während Sie die Einhaltung von Artikel 14 sicherstellen, sollten Sie sich bereits auf die nächsten Anforderungen des CRA vorbereiten, die ab dem 11. Dezember 2027 gelten. Dazu gehören sichere Voreinstellungen nach dem Prinzip Security by Design, automatisiert erzeugte, maschinenlesbare SBOMs, ein festgelegter Unterstützungszeitraum und Sicherheitsupdates, die getrennt von Funktionsupdates bereitgestellt werden.

Weiterlesen: Zeitplan für die Compliance mit dem EU-CRA

Jedes vom CRA erfasste Produkt muss dieselben Anforderungen nach Anhang I erfüllen. Je nach Klasse unterscheidet sich das Konformitätsbewertungsverfahren, das sich aus der Produktklasse ergibt.

Die Klassifizierung ergibt sich aus vier Fragen, die der Reihe nach beantwortet werden:

1. Fällt das Produkt in den Anwendungsbereich? Ein Produkt mit digitalen Elementen, das im Rahmen einer Geschäftstätigkeit auf dem EU-Markt in Verkehr gebracht wird und nicht durch sektorale Vorschriften ausgenommen ist. (Anders formuliert: Hardware- oder Softwareprodukte, die mit anderer Hardware oder Software kommunizieren können, sofern sie nicht ausdrücklich ausgenommen sind.)
2. Entspricht seine Kernfunktion einer Kategorie aus Anhang IV? → Kritisch.
3. Entspricht seine Kernfunktion einer Kategorie aus Anhang III? → Wichtig, in der Klasse, die der Anhang zuweist.
4. Andernfalls → Standardkategorie.

Weiterlesen: Die Produktklassifizierung nach dem CRA erklärt

Die Meldepflichten nach Artikel 14 gelten seit dem 11. September 2026 und reichen in einem entscheidenden Punkt weiter als die Pflichten ab 2027: Sie gelten für jedes Produkt im Anwendungsbereich, das bereits auf dem EU-Markt ist, auch für Produkte, die Jahre vor dem CRA in Verkehr gebracht wurden, und sie bestehen über das Ende des Unterstützungszeitraums hinaus fort. Sie betreffen alle vier Produktklassen.

Die Meldepflicht hat zwei voneinander unabhängige Auslöser: eine aktiv ausgenutzte Schwachstelle (verlässliche Nachweise, dass ein böswilliger Akteur sie ohne Zustimmung des Systemeigners ausgenutzt hat) oder einen schwerwiegenden Sicherheitsvorfall mit Auswirkungen auf die Sicherheit des Produkts. Ein Sicherheitsvorfall kann auch ganz ohne zugrunde liegende Schwachstelle meldepflichtig sein, etwa bei einer kompromittierten Build-Pipeline, einem gestohlenen Signaturschlüssel oder einem gekaperten Update-Server.

Alle Meldungen müssen über die einheitliche Meldeplattform der ENISA erfolgen. E-Mail und nationale Portale erfüllen die Pflicht nicht. Auf der Plattform wählen Sie das als Koordinator benannte CSIRT (nationales Computer-Notfallteam) des Mitgliedstaats Ihrer Hauptniederlassung, also des Mitgliedstaats, in dem die Entscheidungen zur Cybersicherheit überwiegend getroffen werden. Eine Meldung pro Ereignis deckt die gesamte Unternehmensgruppe ab.

Bei der Gestaltung Ihrer Meldeprozesse sind einige wichtige Details zu beachten:

• Meldende Personen müssen registriert sein: „Assigned Representatives“ mit EU Login und MFA (ein primärer, bis zu 20 sekundäre)
• Derzeit gibt es keine API für Einreichungen, daher füllt eine Person das Formular manuell aus
• Artikel 14 Absatz 8 verpflichtet Sie gesondert, betroffene Nutzer zu informieren, idealerweise in einem maschinenlesbaren Format wie VEX.

Weiterlesen: Die Meldepflichten des CRA ab 2026 erfüllen

Der CRA verpflichtet Hersteller, die Komponenten ihrer Produkte zu ermitteln und zu dokumentieren, unter anderem durch eine SBOM „in einem gängigen maschinenlesbaren Format, aus der zumindest die obersten Abhängigkeiten der Produkte hervorgehen“.

Die ungefähre Tiefe der geforderten SBOM ist bekannt, die Einzelheiten der Anforderung wurden aber noch nicht veröffentlicht. So ist etwa offen, ob bestimmte Datenfelder (z. B. Lizenzinformationen, Hashwerte der Komponenten und weitere) verpflichtend werden. Artikel 13 Absatz 24 ermächtigt die Kommission, Format und Elemente der SBOM in Durchführungsrechtsakten festzulegen, und CEN/CENELEC erarbeitet derzeit Normen. Die klarste Orientierung bietet heute die BSI TR-03183 Teil 2 in Version 2.1 (veröffentlicht im März 2025), die jedoch eine Empfehlung und keine Pflicht ist.

Angesichts der derzeitigen Unsicherheit empfiehlt es sich, solide SBOM-Grundlagen zu schaffen, mit denen Sie die Vorgaben der Durchführungsrechtsakte später durch Konfigurationsänderungen statt durch ein neues Projekt erfüllen können. Dazu gehören die Fähigkeit, bei jedem Build eine maschinenlesbare SBOM zu erzeugen, SBOMs einzulesen und die Weitergabe der SBOM an die jeweils relevanten Parteien zu steuern.

Weiterlesen: SBOM-Anforderungen im Cyber Resilience Act der EU

Mehrere führende europäische Hersteller nutzen FOSSA, um SBOMs, Schwachstellen, die automatisierte Lizenz-Compliance und regulatorische Berichte zu verwalten. Die Plattform von FOSSA deckt den operativen Kern der CRA-Reife ab:

Dieser Leitfaden dient der Orientierung bei der Planung und ist keine Rechtsberatung. Für eine verbindliche Beurteilung der Konformität ziehen Sie qualifizierten Rechtsbeistand hinzu. Primärquellen: Verordnung (EU) 2024/2847 (EUR-Lex), die CRA-Seite der Europäischen Kommission und ENISA. Hilfreich ist außerdem das Dokument CRA Compliance Requirements and Checklist des OpenChain-Projekts, das die Pflichten unter anderem nach Rolle (z. B. Hersteller, Einführer) und Geltungsbeginn gliedert.