Cyber Resilience Act: Antworten zitieren nun den Artikel

Am 11. September 2026 trat die Meldepflicht nach Artikel 14 des Cyber Resilience Act in Kraft. Ab diesem Zeitpunkt ist ein Hersteller eines Produkts mit digitalen Elementen, der von einer aktiv ausgenutzten Schwachstelle in diesem Produkt erfährt, zu einer Frühwarnung innerhalb von 24 Stunden, einer vollständigeren Meldung innerhalb von 72 Stunden und einem abschließenden Bericht verpflichtet: 14 Tage für eine Schwachstelle, sobald eine Korrekturmaßnahme verfügbar ist, und einen Monat für einen schweren Vorfall (Verordnung (EU) 2024/2847, Artikel 14 und 71).

Eine Pflicht mit einer 24-Stunden-Frist verwandelt eine ungefähr richtige Antwort in eine Haftungsfrage. Die Fragen, die nach Inkrafttreten der Frist eingehen, sind spezifisch, nicht thematisch. Zählt das Produkt überhaupt als Produkt mit digitalen Elementen? In welche Klasse fällt es, und welcher Konformitätsweg ergibt sich daraus? Wer ist die koordinierende CSIRT, und wohin muss die Meldung gehen? Eine plausible klingende Antwort, die die Vorschrift falsch wiedergibt, ist schlimmer als gar keine Antwort, weil darauf gehandelt wird.

Der Cyber Resilience Act ist genau der Bereich, in dem ein allgemeiner Assistent am schlechtesten abschneidet. Die Verordnung trat am 10. Dezember 2024 in Kraft – so neu, dass das Modellwissen zu ihrem Text dünn ist – und ihre Anwendung ist in Artikel 71 gestaffelt, sodass selbst Fachleute in diesem Bereich an das falsche Datum denken: das Hauptanwendungsdatum 11. Dezember 2027, an dem die wesentlichen Anforderungen, die Konformitätsbewertung und die CE-Kennzeichnung beginnen, ist das Datum, das die meisten Roadmaps nennen und das mehr als ein Jahr nach der Meldepflicht liegt, die Hersteller bereits bindet.

Vorher und jetzt

Bis zu diesem Update war der Cyber Resilience Act nicht Teil der kuratierten Rahmenwerke des Assistenten. Eine Frage zum CRA wurde über denselben allgemeinen Pfad beantwortet wie jede andere Frage: Modellwissen, ohne artikelgenaue Zitate als Grundlage. Für die DSGVO, DORA, UK GDPR und CCPA/CPRA hatten wir dieses Problem bereits mit Rahmenwerken gelöst, die den Absatz und den Punkt zitieren. Der CRA war die Lücke – und diese Lücke saß genau auf der Uhr, die bereits tickte.

Was im September 2026 ausgeliefert wurde, ist ein kuratiertes Wissensrahmenwerk für die Verordnung (EU) 2024/2847, das gegen den offiziellen Text verifiziert wurde und alle 71 Artikel auf Artikelebene abdeckt, mit unterteilten Punkten, wo die Empfehlung davon abhängt:

• Artikel 13: Herstellerpflichten – Supportzeitraum und Sicherheitsupdate-Verpflichtungen, ein zentraler Ansprechpartner, eine koordinierte Offenlegungsrichtlinie für Schwachstellen.
• Artikel 14: Die Meldekaskade und ihre Fristen, inklusive der Definition eines schweren Vorfalls.
• Artikel 15 bis 17: Freiwillige Meldungen und die ENISA-Einzelmeldungsplattform.
• Artikel 18 bis 26: Einführer, Händler, wesentliche Änderungen und Verwalter von Open-Source-Software.
• Artikel 27 bis 34: Die Konformitätswege und die Zuordnung zwischen Klasse I, Klasse II und kritischen Produkten.
• Artikel 64: Die Strafrahmen, die bei schweren Verstößen bis zu 15 Millionen Euro oder 2,5 % des weltweiten Jahresumsatzes erreichen können.
• Anhang-Abdeckung: Anhang I – Wesentliche Anforderungen und Pflichten zur Schwachstellenbehandlung, Anhang II – Benutzerinformationen, Anhang III – Produktklassen und Anhang IV – Liste kritischer Produkte, sowie Anhang VII – Technische Dokumentation.

Jede Zeile enthält den Akteur, für den sie gilt, entsprechend der Taxonomie der Verordnung: Hersteller, Einführer, Händler, Verwalter von Open-Source-Software, Bevollmächtigter, Benannte Stelle, Marktüberwachungsbehörde, CSIRT, ENISA. Ein Einführer, der fragt, ob eine Pflicht ihn betrifft, erhält eine Antwort, die den Artikel nennt und angibt, wessen Pflicht es ist – statt eine Zusammenfassung aus Herstellersicht.

Wann "CRA" nicht auslöst

Eine Detail aus derselben Woche zeigt, wie das Rahmenwerk in der Praxis funktioniert. CRA ist kein sicheres Akronym: Es steht auch für Credit Rating Agency (Ratingagentur), den US Community Reinvestment Act und die Canada Revenue Agency. Der Assistent lädt das EU-Rahmenwerk nicht bei einer bloßen Nennung von CRA; die Frage selbst muss einen klaren EU-Produkt-Hinweis enthalten. Eine Bank, die Fragen zu ihren Eigenkapitalquoten stellt, oder eine Steuerfrage zur Canada Revenue Agency erhält daher kein europäisches Produktsicherheitsrahmenwerk in die Antwort injiziert. Dieser Kollisionsschutz wurde in derselben Woche wie das Rahmenwerk selbst eingeführt.

Für wen ist das gedacht?

Hersteller von Produkten mit digitalen Elementen, die in der EU verkauft werden, Einführer und Händler, die diese Produkte vertreiben, sowie Verwalter von Open-Source-Software, die prüfen müssen, ob die Verordnung für sie gilt. Auch GRC-Verantwortliche und Berater, die solche Fragen beantworten – darunter Teams, deren ISO-27001-Umfang bisher keine Produkthaftung berührte und die nun eine Meldepflicht im Kalender vorfinden. Das Rahmenwerk ist in der geteilten Rahmenwerksregistrierung verfügbar, sodass dieselben Verweise über die API und in Embeddings zurückgegeben werden. Auch heyGRC beantwortet CRA-Fragen damit.

Zwei Grenzen bleiben bestehen: Dies ist Referenzwissen zur Orientierung, kein Rechtsgutachten, und die Antworten zitieren die zugrundeliegenden Vorschriften. Und dieser Beitrag ist nicht die Referenz selbst: Das strategische Argument, warum die Frist 2026 die 2027er-Daten in Ihrer Planung übertrumpft, findet sich in „Der Cyber Resilience Act ist ein 2026-Problem, nicht eines von 2027“. Die vollständigen Pflichten und der Zeitplan, inklusive der Fristen nach Artikel 71 und der Melde-Tabelle nach Artikel 14, sind im Leitfaden zu Pflichten und Zeitplan des Cyber Resilience Act zu finden. Die Frage „Betrifft uns das überhaupt?“ beantwortet der CRA-Anwendbarkeitschecker.