.svg)
Das Wichtigste in Kürze
- Der Cyber Resilience Act, Verordnung (EU) 2024/2847, ist am 10. Dezember 2024 in Kraft getreten. Die Meldepflichten nach Artikel 14 gelten ab dem 11. September 2026, alle übrigen Anforderungen ab dem 11. Dezember 2027.
- Eine aktiv ausgenutzte Schwachstelle löst eine dreistufige Frist aus: Frühwarnung an das nationale CSIRT und an ENISA innerhalb von 24 Stunden, vollständige Meldung innerhalb von 72 Stunden, Abschlussbericht innerhalb von 14 Tagen nach Verfügbarkeit einer Korrekturmaßnahme.
- Jedes Produkt mit digitalen Elementen braucht einen festgelegten Unterstützungszeitraum von mindestens fünf Jahren, sofern die erwartete Lebensdauer nicht kürzer ist, mit kostenlosen Sicherheitsupdates über den gesamten Zeitraum.
- Anhang I Teil II enthält acht Anforderungen an den Umgang mit Schwachstellen. Eine davon ist eine Software-Stückliste (SBOM) in einem gängigen maschinenlesbaren Format, die mindestens die Abhängigkeiten der obersten Ebene abdeckt.
- Bußgelder erreichen 15 Millionen Euro oder 2,5 Prozent des weltweiten Jahresumsatzes, je nachdem, welcher Betrag höher ist, bei Verstößen gegen die wesentlichen Anforderungen oder gegen die Herstellerpflichten aus Artikel 13 und 14.
Der Cyber Resilience Act im Überblick
Der Cyber Resilience Act ist das erste EU-Gesetz, das die Cybersicherheit von Produkten reguliert und nicht die Sicherheit von Organisationen. Wenn Sie Hardware oder Software mit digitalen Elementen auf dem EU-Markt in Verkehr bringen, gilt er für Sie, und er gilt noch Jahre nach dem Verkauf, nicht nur zum Zeitpunkt der Auslieferung. Alle Zahlen in diesem Beitrag stammen aus der Verordnung selbst oder aus der offiziellen Zusammenfassung des Gesetzestexts.
Ein verbreiteter Irrtum: der CRA sei ein Thema für 2027. Das ist er nicht. Die Meldepflichten nach Artikel 14 gelten ab dem 11. September 2026, und sie gelten auch für Produkte, die bereits im Markt sind, einschließlich solcher, die Sie vor Jahren ausgeliefert haben. Der Termin 2027 regelt Konformität und CE-Kennzeichnung. Der Termin 2026 regelt, was passiert, wenn das nächste Mal jemand eine Schwachstelle in Ihrem Code ausnutzt.
1. Security by Design wird zur rechtlichen Produkteigenschaft
Nach Artikel 13 müssen Hersteller Produkte mit digitalen Elementen so konzipieren, entwickeln und herstellen, dass sie die wesentlichen Cybersicherheitsanforderungen aus Anhang I Teil I erfüllen. Dazu gehören eine sichere Standardkonfiguration, keine bekannten ausnutzbaren Schwachstellen zum Zeitpunkt des Inverkehrbringens und der Schutz von Vertraulichkeit und Integrität der Daten, die das Produkt verarbeitet.
Der praktische Unterschied liegt darin, wo Sicherheit in Ihrem Prozess sitzt. Anhang I Teil I wird zum Zeitpunkt des Inverkehrbringens bewertet. Der Nachweis muss also vor der Auslieferung existieren, nicht danach. Sie brauchen eine dokumentierte Cybersicherheits-Risikobewertung für das Produkt, und sie gehört zu der technischen Dokumentation, die Sie zehn Jahre nach dem Inverkehrbringen oder für die Dauer des Unterstützungszeitraums aufbewahren müssen, je nachdem, was länger ist.
Wenn Sie ohnehin ein nach ISO 27001 zertifiziertes Informationssicherheits-Managementsystem betreiben, steht ein guter Teil der organisatorischen Grundlage bereits. Was meist fehlt, ist der Nachweis auf Produktebene. Ein ISMS belegt, dass Ihr Unternehmen Sicherheit steuert. Der CRA verlangt den Nachweis, dass eine bestimmte Version eines bestimmten Produkts es tut.
2. Schwachstellenmanagement läuft über den gesamten Unterstützungszeitraum
Anhang I Teil II enthält acht Anforderungen an den Umgang mit Schwachstellen, die so lange gelten, wie Sie das Produkt unterstützen. Sie umfassen das Identifizieren und Dokumentieren von Schwachstellen und Komponenten, die unverzügliche Behebung, regelmäßige Sicherheitstests, die öffentliche Information über behobene Schwachstellen, eine Richtlinie zur koordinierten Offenlegung von Schwachstellen, eine öffentliche Kontaktadresse für Meldungen, die sichere Verteilung von Updates sowie Sicherheitsupdates, die kostenlos und getrennt von Funktionsupdates ausgeliefert werden.
Die Anforderung mit dem größten Einfluss auf die Entwicklungspraxis ist die erste. Sie verlangt eine Software-Stückliste in einem gängigen maschinenlesbaren Format, die mindestens die Abhängigkeiten der obersten Ebene abdeckt. "Mindestens" ist die Untergrenze. Da die SBOM das Produkt über den gesamten Unterstützungszeitraum abbilden muss, ist es das falsche Modell, sie als Dokument zu behandeln, das man einmal pro Release erstellt. Sie gehört in die Build-Pipeline und wird mit jedem Build neu erzeugt.
Dann der Unterstützungszeitraum selbst. Artikel 13 verlangt, dass Sie ihn festlegen, sein Enddatum dem Käufer beim Kauf mitteilen und ihn auf mindestens fünf Jahre setzen, sofern die erwartete Produktlebensdauer nicht tatsächlich kürzer ist. Fünf Jahre kostenlose Sicherheitsupdates sind ebenso eine kaufmännische wie eine technische Entscheidung, und in vielen Produkt-Roadmaps ist sie nicht eingepreist.
3. Meldungen laufen ab September 2026 auf einer 24-, 72- und 14-Tage-Frist
Artikel 14 verpflichtet Hersteller, aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle gleichzeitig an das von ihrem Mitgliedstaat benannte CSIRT und an ENISA zu melden, über die zentrale Meldeplattform des CRA. Der Ablauf hat drei Stufen.
Der Fehler, den die meisten Teams hier machen: Sie lesen die 24 Stunden als Frist, ein gelöstes Problem zu melden. Das ist sie nicht. Es ist eine Frühwarnpflicht, die mit der Kenntnisnahme beginnt, praktisch also in dem Moment, in dem die E-Mail eines Sicherheitsforschers eintrifft oder Ihr Monitoring eine Ausnutzung im Feld meldet. Niemand hat in 24 Stunden einen Fix. Was Sie in 24 Stunden brauchen, ist eine benannte verantwortliche Person, ein Zugang zur Meldeplattform und die Befugnis, ohne vorherige juristische Prüfung zu melden.
Kleinstunternehmen und kleine Unternehmen sind von Bußgeldern speziell für die Versäumung der 24-Stunden-Frist ausgenommen, und Verwalter von Open-Source-Software fallen nicht unter das Sanktionsregime. Keine der beiden Ausnahmen hebt die Pflicht selbst auf. Wenn Sie bereits Meldeprozesse nach den NIS2-Anforderungen betreiben, wird Ihnen das Fristenmuster bekannt vorkommen. Der Auslöser ist allerdings ein anderer: NIS2 knüpft an Vorfälle an, die Ihre Dienste betreffen, Artikel 14 an Schwachstellen in den Produkten, die Sie verkaufen.
4. Ihre Produktklasse entscheidet, wer prüft
Der CRA folgt einem risikobasierten Ansatz, aber nicht dem, den die früheren Entwürfe beschrieben haben. Die verabschiedete Verordnung kennt drei Stufen oberhalb der Standardkategorie, aufgeführt in den Anhängen III und IV, und die Stufe bestimmt Ihr Konformitätsbewertungsverfahren nach Artikel 32.
Beachten Sie, was in der Tabelle nicht steht. Eine Stufe "hochkritisch" gibt es im verabschiedeten Text nicht, und die Mehrheit der Produkte mit digitalen Elementen fällt in die Standardkategorie, in der Selbstbewertung zulässig ist. Wenn ein Anbieter oder Berater Ihnen erzählt, der CRA zwinge jedes vernetzte Produkt durch eine benannte Stelle, prüfen Sie, welche Fassung des Texts er gelesen hat. Passen mehrere Kategorien auf ein Produkt, gilt die strengere Klasse.
Die Klassifizierung ist außerdem keine einmalige Übung. Ergänzen Sie ein Produkt aus der Standardkategorie um eine VPN-Funktion, wandert die Einordnung mit. Teams, die die Produktklassifizierung als Release-Kriterium behandeln und nicht als einmal erstelltes Rechtsgutachten, bemerken das, bevor eine wesentliche Änderung ihre Pflichten neu auslöst.
5. Fremdkomponenten werden zu Ihrer Nachweispflicht
Artikel 13 verlangt von Herstellern, bei der Integration von Komponenten Dritter Sorgfalt walten zu lassen und sicherzustellen, dass diese Komponenten die Sicherheit des Produkts nicht beeinträchtigen. Ihre Abhängigkeiten sind damit nicht länger das Compliance-Problem eines anderen.
Genau hier hört die SBOM auf, Papierkram zu sein, und wird nützlich. Sie können keine Sorgfaltspflicht für einen Abhängigkeitsbaum erfüllen, den Sie nicht erfasst haben, und Sie können keine Anfrage einer Marktüberwachungsbehörde zu einer Komponente beantworten, von der Sie nicht wussten, dass Sie sie ausliefern. Die Pflicht erstreckt sich auch auf Open-Source-Komponenten, die Sie einbinden. Die Maintainer selbst werden dabei anders behandelt: Verwalter von Open-Source-Software tragen leichtere Pflichten und fallen nicht unter das Sanktionsregime. Die Verantwortung für das, was Sie ausliefern, liegt also bei Ihnen und nicht bei ihnen.
Die Lücke, die Produktteams hier finden, ist eher vertraglich als technisch. Dependency-Scanning ist ein gelöstes Problem. Einen Weg zu einem Fix zu haben, wenn die Komponente eines kommerziellen Lieferanten die Schwachstelle ist, und diesen Weg im Vertrag zu stehen zu haben, bevor Sie ihn brauchen, ist keins. Wenn ein Lieferant sich nicht auf eine Offenlegungsfrist festlegen kann, die in Ihr eigenes 72-Stunden-Fenster passt, ist das eine Einkaufsentscheidung und keine Engineering-Frage.
Warum Dezember 2027 knapper ist, als es aussieht
Das ist der Teil, der in den Zusammenfassungen selten auftaucht. Der Weg über die Selbstbewertung für Produkte der Klasse "wichtig, Klasse I" setzt voraus, dass harmonisierte Normen vollständig angewendet werden, und diese Normen befinden sich noch in der Entwicklung. Benannte Stellen konnten erst ab dem 11. Juni 2026 tätig werden, als Kapitel IV anwendbar wurde. Der günstigste Compliance-Weg für eine ganze Produktstufe hängt damit an Normen, die nicht fertig sind, geprüft von Stellen, die seit wenigen Monaten arbeiten.
Nehmen Sie ein Unternehmen mit 40 Mitarbeitenden, das ein Gerät zur Netzwerküberwachung für industrielle Umgebungen verkauft. Es fällt in die Klasse "wichtig, Klasse I". Sind die harmonisierten Normen für seine Produktkategorie rechtzeitig veröffentlicht und stabil, kann eine interne verantwortliche Person mit etwa halber Kapazität die technische Dokumentation, die SBOM-Pipeline und die Offenlegungsrichtlinie bis zur Konformität tragen. Sind sie es nicht, steht dasselbe Unternehmen 2027 bei einer benannten Stelle in der Warteschlange, zusammen mit allen anderen, die dieselbe Wette eingegangen sind. Die Kapazität benannter Stellen ist begrenzt.
Aus dieser Asymmetrie folgt das Argument, mit den Teilen anzufangen, die von niemandem sonst abhängen. Ihre SBOM-Pipeline, Ihre Richtlinie zur Offenlegung von Schwachstellen, Ihre öffentliche Kontaktadresse und Ihre Entscheidung zum Unterstützungszeitraum liegen vollständig in Ihrer Hand, und keiner dieser Punkte wartet auf eine Norm. Ihr Meldeprozess nach Artikel 14 ist der Punkt mit dem harten Termin 2026. Die Kosten hängen weit stärker davon ab, wie viel davon Sie bei null beginnen müssen, als von irgendeiner Prüfgebühr. Eine Eurozahl für die Prüfung selbst nennen wir bewusst nicht: die Preise benannter Stellen für CRA-Prüfumfänge sind noch nicht so etabliert, dass eine seriöse Angabe möglich wäre.
Keiner dieser Punkte braucht ein fertiges Normungsgremium, eine benannte Stelle oder eine harmonisierte Norm. Es ist außerdem das Muster, das von hier an zu erwarten ist: wie die EU-KI-Verordnung reguliert der CRA, was Sie ausliefern, und nicht, wie Sie arbeiten. Produktteams tragen damit Pflichten, die früher bei einer Compliance-Funktion lagen. Der Termin September 2026 bedeutet für die meisten Teams einige Wochen Vorbereitung und für die, die ihn auslassen, ein echtes Haftungsrisiko. Fangen Sie mit dem Meldeprozess an.
Wo Kertos ansetzt
Kertos ist eine europäische Compliance-Automatisierungsplattform. Für die CRA-Arbeit greifen die Teile, die sich wiederholen: Control-Nachweise, die dauerhaft aktuell bleiben müssen und nicht kurz vor einer Prüfung zusammengesucht werden, Richtlinien mit Versionshistorie und benannter Verantwortung, und die Melde- und Offenlegungsprozesse, die in einer Form existieren müssen, der um drei Uhr nachts jemand folgen kann.
Am meisten bringt in der Praxis die Überschneidung. Die meisten Unternehmen, die der CRA betrifft, tragen bereits ISO 27001, oft zusätzlich NIS2 oder einen SOC-2-Bericht. Die ISO 27001 Controls zu sicherer Entwicklung, Lieferantenbeziehungen und Schwachstellenmanagement leisten echte Arbeit gegen Anhang I, und sie einmal zuzuordnen statt pro Framework ist der Unterschied, der ein kleines Team davor bewahrt, dieselbe Nachweiserhebung viermal zu machen. Dieselbe Logik steht hinter der Harmonisierung eines Multi-Framework-Compliance-Programms.
Kunden von Kertos beschreiben die Verschiebung eher kaufmännisch als in Compliance-Begriffen. Ein Mitgründer formuliert es so, dass Compliance "von einem Risiko zu einem Verkaufsargument geworden" sei. Ungefähr das macht der Cyber Resilience Act mit Produktsicherheit: Er verschiebt die CE-Kennzeichnung an einem vernetzten Produkt von einer Formalität zu etwas, nach dem ein Einkauf fragen wird.
Wenn Sie sehen möchten, wie die Plattform die Nachweis- und Control-Seite abdeckt, buchen Sie eine Demo.
Häufig gestellte Fragen
Wann gilt der Cyber Resilience Act?
Er ist am 10. Dezember 2024 in Kraft getreten. Die Meldepflichten aus Artikel 14 gelten ab dem 11. September 2026, die übrigen Pflichten einschließlich Konformitätsbewertung und CE-Kennzeichnung ab dem 11. Dezember 2027. Produkte, die vor dem 11. Dezember 2027 in Verkehr gebracht wurden, fallen nur bei einer wesentlichen Änderung unter die vollen Anforderungen. Die Meldepflicht nach Artikel 14 erfasst sie in jedem Fall ab September 2026.
Für wen gilt der Cyber Resilience Act?
Für Hersteller, Importeure und Händler, die Produkte mit digitalen Elementen auf dem EU-Markt in Verkehr bringen. Dazu gehört auch Software, die eigenständig verkauft wird, nicht nur vernetzte Hardware. Freie und Open-Source-Software, die außerhalb einer Geschäftstätigkeit bereitgestellt wird, fällt nicht in den Anwendungsbereich, und Verwalter von Open-Source-Software haben leichtere Pflichten und fallen nicht unter das Sanktionsregime.
Welche Strafen drohen bei Verstößen gegen den Cyber Resilience Act?
Artikel 64 sieht als Höchstmaß 15 Millionen Euro oder 2,5 Prozent des weltweiten Jahresumsatzes vor, je nachdem, welcher Betrag höher ist, für Verstöße gegen die wesentlichen Cybersicherheitsanforderungen oder gegen die Herstellerpflichten aus Artikel 13 und 14. Für andere Pflichten liegt die Obergrenze bei 10 Millionen Euro oder 2 Prozent, für falsche oder unvollständige Angaben gegenüber Behörden bei 5 Millionen Euro oder 1 Prozent.
Ist eine SBOM nach dem Cyber Resilience Act Pflicht?
Ja. Anhang I Teil II verlangt eine Software-Stückliste in einem gängigen maschinenlesbaren Format, die mindestens die Abhängigkeiten der obersten Ebene abdeckt, und sie muss über den gesamten Unterstützungszeitraum aktuell bleiben. Eine vollständige Abdeckung aller transitiven Abhängigkeiten ist nicht vorgeschrieben, aber die sicherere Position, da Marktüberwachungsbehörden die vorhandene SBOM anfordern können.
Wie lang ist der Unterstützungszeitraum nach dem Cyber Resilience Act?
Mindestens fünf Jahre, sofern die erwartete Produktlebensdauer nicht kürzer ist. In diesem Fall entspricht der Unterstützungszeitraum dieser Lebensdauer. Sie müssen den Zeitraum festlegen, sein Enddatum mit Monat und Jahr beim Kauf angeben und über den gesamten Zeitraum kostenlose Sicherheitsupdates bereitstellen. Die technische Dokumentation ist zehn Jahre nach dem Inverkehrbringen oder für die Dauer des Unterstützungszeitraums aufzubewahren, je nachdem, was länger ist.
