Most GRC teams filed the Cyber Resilience Act under two words: "product" and "2027."
Beides ist falsch.
Die Meldepflicht nach Artikel 14 gilt ab 11. September 2026. Nicht Dezember 2027. Das ist das Datum, das alle im Kopf haben, und es ist das falsche.
Drei Wochen.
Und es geht nicht nur um das, was Sie nächstes Jahr ausliefern. Es geht um das, was Sie bereits ausgeliefert haben. Ein Produkt, das 2018 auf dem EU-Markt bereitgestellt wurde und heute noch erhältlich ist, fällt ab dem Tag in den Anwendungsbereich der Meldepflicht, an dem diese in Kraft tritt.
Wenn Ihre Organisation irgendetwas mit digitalen Elementen in die EU verkauft, ist das Ihr Incident-Prozess, nicht der Papierkram des Produktteams.
Was Artikel 14 tatsächlich verlangt
Zwei Auslöser, drei Uhren, ein Kanal.
Die Auslöser:
- eine aktiv ausgenutzte Schwachstelle in Ihrem Produkt
- ein schwerwiegender Vorfall mit Auswirkungen auf die Sicherheit Ihres Produkts
Die Uhren:
- 24 Stunden: Frühwarnung, ab dem Moment, in dem Sie Kenntnis erlangen
- 72 Stunden: vollständige Meldung, einschließlich ergriffener Korrektur- oder Minderungsmaßnahmen
- 14 Tage: Abschlussbericht, sobald eine Korrekturmaßnahme für eine aktiv ausgenutzte Schwachstelle verfügbar ist
- ein Monat: Abschlussbericht für einen schwerwiegenden Vorfall, sobald dieser behoben ist
Der Kanal:
Eine Meldung über die Single Reporting Platform von ENISA, adressiert an das CSIRT am Hauptsitz, gleichzeitig ENISA zugänglich gemacht.
Beachten Sie, was nicht in there. This is not "report every CVE." The trigger is active exploitation in the wild, or a severe incident. That distinction is the difference between a workable process and a team that drowns in week two.
Schauen wir uns an, was Sie richtig machen müssen.
1. Das Datum ist 2026. Das, das Sie sich gemerkt haben, ist 2027.
Der CRA (Verordnung (EU) 2024/2847) trat am 10. Dezember 2024 in Kraft. Der Großteil der Pflichten (Security by Design, technische Dokumentation, Konformitätsbewertung, CE-Kennzeichnung) gilt ab 11. Dezember 2027.
Artikel 71(2) nimmt die Meldepflichten aus und zieht sie um fünfzehn Monate vor.
Dann schließt Artikel 69(3) den Ausweg. Die Übergangsregelungen, die es ermöglichen, bestehende Produkte bis Dezember 2027 ohne vollständige Konformität auf dem Markt zu belassen, erstrecken sich nicht auf die Meldepflichten.
Die am 11. September meldepflichtigen Produkte sind also nicht Ihre Roadmap für 2027. Es ist Ihre gesamte installierte Basis.
Hinweis: Wenn Ihr Produktinventar nur auflistet, was sich in aktiver Entwicklung befindet, haben Sie kein Produktinventar. Sie haben ein Backlog.
2. The Clock Starts on "Aware." Nobody Has Defined That.
Hier entscheidet sich alles, und das ist keine Rechtsfrage.
Vierundzwanzig Stunden sind keine lange Zeit. Es ist ein Arbeitstag oder ein Samstagabend. Die Uhr beginnt nicht, wenn Ihr Rechtsteam sich einig ist, dass ein Problem besteht. Sie beginnt, wenn die Organisation Kenntnis erlangt.
So who is "the organisation"?
- ein Support-Ingenieur, der um 19:00 Uhr ein seltsames Ticket sieht
- ein Forscher, der eine E-Mail an Ihre allgemeine security@-Adresse schickt
- ein Threat-Intelligence-Feed, der Ihren Produktnamen markiert
- ein Kunden-SOC, das Ihren Account Manager anruft
Jede dieser Situationen kann der Moment der Kenntniserlangung sein. Wenn niemand weiß, was als Nächstes zu tun ist, läuft Ihre 24-Stunden-Frist, während eine E-Mail ungelesen bleibt.
Sie müssen drei Dinge schriftlich festhalten, bevor der September kommt:
- welches Ereignis Kenntniserlangung darstellt, in klarer Sprache
- wer befugt ist, sie festzustellen, mit einer namentlich genannten Vertretung
- wo der Startzeitpunkt der Uhr dokumentiert wird, damit Sie nachweisen können, wann sie startete
That last one matters more than people expect. If a regulator asks why the early warning landed at hour 31, "we became aware later than you think" is only an answer if you can show it.
Anmerkung: Wir alle haben das bei GDPR erlebt. Eine Datenpanne wird drei Wochen zu spät gemeldet, nicht weil jemand etwas verbergen wollte. Der Support hat sie als Bug protokolliert. Die IT nannte es ein Konfigurationsproblem. Niemand in der Kette hatte sich je darauf geeinigt, was tatsächlich als Verletzung personenbezogener Daten gilt, also startete die Uhr nie. Die Rechtsabteilung erfuhr davon, als ein Kunde eine Frage stellte.
Dieselbe Mechanik gilt unter dem CRA, mit einem engeren Zeitfenster. Definitionen sind der langweilige Teil. Sie sind auch der Teil, der darüber entscheidet, ob Sie zu spät waren.
3. Der CRA verlangt von Ihnen zu melden, bevor er verlangt, dass Sie zuhören
Hier ist das Reihenfolge-Problem, das niemand anspricht, und es ist das, das sorgfältige Teams erwischen wird.
Artikel 13(8) verpflichtet Hersteller, Richtlinien und Verfahren zu haben, einschließlich der in Anhang I, Teil II, Punkt (5) festgelegten koordinierten Offenlegungsrichtlinie für Schwachstellen, um aus internen oder externen Quellen gemeldete Schwachstellen zu bearbeiten und zu beheben.
Dort finden sich tatsächlich drei rechtlich eigenständige Pflichten, und in den meisten Unternehmen bedient ein einziger Posteingang alle drei:
- eine CVD-Richtlinie, schriftlich, veröffentlicht und durchgesetzt
- eine Kontaktadresse für die Meldung von Schwachstellen in Ihren Produkten und in den von Ihnen ausgelieferten Drittanbieterkomponenten
- eine zentrale Anlaufstelle, über die Nutzer direkt einen Menschen erreichen können
Nun zum Timing. Diese Pflichten stehen in Anhang I, Teil II. Anhang I wird am 11. Dezember 2027 rechtsverbindlich. Die Meldepflicht nach Artikel 14 wird am 11. September 2026 verbindlich.
Lesen Sie das noch einmal. Fünfzehn Monate lang verpflichtet das Gesetz Sie, aktiv ausgenutzte Schwachstellen in Ihren Produkten zu melden, ohne gleichzeitig zu verlangen, dass Sie den Kanal betreiben, über den Sie davon erfahren würden.
A team that follows the dates literally will spend those fifteen months on a 24-hour clock with no reliable way to learn the clock has started. Because the honest answer to "how do most manufacturers discover active exploitation of their own product?" is: someone tells them.
Es gibt einen zweiten Grund, das jetzt zu tun. Von allem im CRA sind die CVD-Richtlinie und die Kontaktadresse die zwei Dinge, die von außerhalb Ihrer Organisation sichtbar sind. Eine Marktüberwachungsbehörde, die sich einen ersten Eindruck von Ihrer Sicherheitslage verschafft, wird Ihre Website besuchen, bevor sie Sie jemals um ein Dokument bittet.
Was gut aussieht:
- Richtlinie unter einer stabilen, öffentlichen URL, nicht vergraben in einer rechtlichen Unterseite
- eine security.txt-Datei auf Ihrer Domain
- ein überwachter Posteingang mit einem namentlich genannten Verantwortlichen und einer Vertretung, kein Alias, den niemand liest
- angegebener Geltungsbereich, erwartete Reaktionszeiten, was im und außerhalb des Test-Umfangs liegt, wie Sie mit Credits und Veröffentlichung umgehen
- jede Meldung protokolliert, denn die Durchsetzung der Richtlinie ist selbst die Pflicht
Hinweis: Sie müssen das nicht neu erfinden. ISO/IEC 29147 und ISO/IEC 30111 sind die Referenzstandards für Offenlegung und Bearbeitung, und das NCSC Vulnerability Disclosure Toolkit ist ein solider kostenloser Ausgangspunkt. Etwas Funktionierendes in drei Wochen zu veröffentlichen ist besser als etwas Perfektes im Dezember 2027.
4. Sie können nicht melden, was Sie nicht benennen können
Die 72-Stunden-Stufe verlangt Produkttyp und -klassifizierung. Das bedeutet, Sie brauchen vor einem Vorfall, nicht während eines solchen:
- die Liste der Produkte mit digitalen Elementen, die Sie auf dem EU-Markt bereitstellen
- für jedes einzelne, ob es als Standard, als wichtig (Anhang III, Klasse I oder II) oder als kritisch (Anhang IV) eingestuft ist
- eine SBOM in einem gängigen, maschinenlesbaren Format
Die Klassifizierung folgt der Kernfunktion des Produkts; wo mehr als eine Klasse passt, gilt die strengere.
Die SBOM ist der Teil, den Teams unterschätzen. Artikel 14 verlangt, dass Sie eine Schwachstelle in Ihrem Produkt melden. Wenn Ihr Produkt ein nicht inventarisiertes End-of-Life-Framework enthält, werden Sie aus Ihrer eigenen Telemetrie nicht erfahren, dass es ausgenutzt wird. Sie werden es von einem Kunden erfahren oder aus den Nachrichten, was ein sehr teurer Weg ist, eine 24-Stunden-Frist zu starten.
Hinweis: Führen Sie die Übung rückwärts durch. Wählen Sie eine Komponente, von der Sie wissen, dass sie in drei Ihrer Produkte enthalten ist. Können Sie diese Liste in weniger als einer Stunde erstellen, heute, ohne Engineering zu fragen? Wenn nicht, ist das Ihre erste Lücke.
5. Die Plattform ist noch nicht live. Registrieren Sie sich trotzdem.
Das ist der Teil, der daraus eine Geschichte macht und kein Compliance-Memo.
Die unter Artikel 16 eingerichtete und von ENISA betriebene Single Reporting Platform soll am 11. September 2026 in Betrieb gehen. Nicht früher. Mitte August war die öffentliche Zugangs-URL noch nicht veröffentlicht. Kurze Videos und ein Webinar sind zwei Wochen vor dem Start angekündigt.
Die Pflicht ist unveränderlich. Das Werkzeug ist es nicht. Diese Lücke liegt bei Ihnen, nicht bei der Aufsichtsbehörde.
Drei Dinge hängen nicht davon ab, dass die Plattform existiert:
Erstellen Sie die EU-Login-Konten jetzt. Die Registrierung erfolgt über EU Login unter ecas.ec.europa.eu. Sie können das Konto heute anlegen. Es mitten in einem Vorfall zu tun, mit laufender 24-Stunden-Frist, ist eine selbst verursachte Verzögerung.
Richten Sie zwei Zugänge ein, nicht einen. Es gibt einen Primary Assigned Representative, der sich registriert, indem er die Rolle auswählt, das koordinierende CSIRT benennt, der Vereinbarung zustimmt und die Herstellerdaten eingibt. Die Vertretung, der Secondary AR, wird per E-Mail eingeladen, und diese Einladung verfällt nach sieben Tagen. Versenden Sie sie und bestätigen Sie die Annahme. Eine nicht akzeptierte Einladung ist keine Vertretung.
Warten Sie nicht auf die CSIRT-Validierung. Die Validierung des AR durch das koordinierende CSIRT erfolgt nach der Registrierung. Sie läuft parallel und blockiert Sie nicht bei der Meldung. Teams, die davon ausgehen, dass sie ein grünes Licht brauchen, bevor sie eine Meldung abgeben können, werden Stunden verlieren, die sie nicht haben.
Die Leitlinien von ENISA wurden diesen Monat bereits zweimal aktualisiert. Die Leitfäden zur Registrierung und Meldung wurden mit dem 3. August neu datiert, der Leitfaden zur Benutzeroberfläche erschien am 14. August. Alles ist als vorläufig gekennzeichnet. Bauen Sie Ihren internen Prozess anhand der Pflichtfelder auf, nicht anhand der Screenshots.
6. Es gibt noch keine harmonisierten Normen
Am 13. August 2026 stellte ETSI 17 finale Entwürfe von CRA-Produktnormen zur öffentlichen Konsultation bereit. Keine davon ist eine harmonisierte Norm. Die Kommentarfrist endet Mitte September, mit Genehmigungsverfahren bis in den November je nach Branche.
Notifizierte Stellen kommen im Dezember 2026.
Die ehrliche Beurteilung lautet daher: Die Konformitätsinfrastruktur des CRA wird noch aufgebaut, und die Meldepflicht tritt ohnehin zuerst in Kraft.
If your plan was "we will start once the standards are published," you have already lost the reporting window. Standards tell you how to prove your product meets the essential requirements. They do not tell you who files the early warning on a Sunday.
7. Ihre NIS2- und DORA-Meldungen decken das nicht ab
Diese Annahme begegnet mir ständig, und sie ist gefährlich, weil sie fast stimmt.
Sie verfügen vielleicht bereits über eine 24/72-Stunden-Routine aus NIS2 oder DORA. Gut. Es ist nicht dieselbe Pflicht.
| NIS2 / DORA | CRA Artikel 14 | |
|---|---|---|
| Auslöser | Vorfall, der Ihre Dienste betrifft | Schwachstelle oder Vorfall, der Ihr Produkt betrifft, in den Händen Ihrer Kunden |
| Wer meldet | Sie als Einrichtung | Sie als Hersteller |
| Empfänger | Ihre nationale Behörde | Ihr CSIRT am Hauptsitz, über die SRP, mit ENISA |
| Kenntniserlangung | Ihr eigener Betrieb | häufig die Umgebung eines anderen |
Ein Ereignis kann beide Pflichten auslösen. Ein schwerwiegender Vorfall bei einem Produkt, das Sie herstellen und selbst betreiben, bedeutet zwei Meldungen, zwei Empfänger, zwei Nachweispfade.
Das Reflexmuster, das Sie jetzt aufbauen müssen, ist kein neuer Prozess. Es ist ein Entscheidungspunkt an der Spitze Ihres bestehenden: Welche Regelwerke berührt dieses Ereignis? Beantworten Sie das in Minute fünf, nicht in Stunde zwanzig.
Anmerkung: Ich will ehrlich mit Ihnen über den Zustand des Markts sein. Fast keiner meiner Kunden fragt gerade nach dem CRA, weil sie NIS2 noch nicht ernst genug nehmen, um so weit zu kommen. Drei Wochen noch. Das ist das ehrliche Bild.
Das Beispiel, das ich Ihnen geben kann, ist also mein eigenes. Bei Mobilexpense, wo ich als CISO tätig bin, bauen wir genau das: einen einzigen Incident-Prozess mit zwei Verzweigungen. Gleiche Aufnahme, gleiche ersten Fragen, und dann eine Gabelung an dem Punkt, an dem Sie entscheiden, ob das Ereignis eine Sache der Einrichtung, des Produkts oder beides ist. Die Gabelung ist jetzt günstig zu entwerfen. Sie ist sehr teuer zu improvisieren in Stunde drei.
8. Was Sie tatsächlich vor dem 11. September abschließen können
Drei Wochen reichen nicht aus, um ein Programm aufzubauen. Sie reichen aus, um den Teil aufzubauen, der als Erstes auslöst.
Woche eins:
- EU-Login-Konten anlegen, primär und als Vertretung
- die Einladung für den Secondary AR versenden und die Annahme vor Ablauf bestätigen
- Ihr koordinierendes CSIRT identifizieren
- die CVD-Richtlinie zur rechtlichen Prüfung einreichen, denn das ist der kritische Pfad
Woche zwei:
- CVD-Richtlinie, Kontaktadresse und security.txt veröffentlichen
- die Liste der meldepflichtigen Produkte einfrieren, einschließlich Legacy-Produkte
- jedem Produkt eine Klassifizierung zuweisen
- write the definition of "aware" and name the two people who can declare it
Woche drei:
- die 24-Stunden-Frühwarnung als kurzes internes Formular aufbauen, das den Pflichtfeldern entspricht
- die Frage zur Regime-Zuordnung an den Anfang Ihres Incident-Prozesses setzen
- auf dem Papier proben. Ein Szenario, ein Samstagabend, eine Stoppuhr
Dieser letzte Schritt ist der, den alle überspringen, und der einzige, der zeigt, ob die anderen elf funktioniert haben.
Abschließender Gedanke
Die unbequeme Wahrheit des 11. September ist, dass die Aufsichtsbehörde früher da ist als ihre eigenen Werkzeuge, und das ändert nichts an Ihrer Lage.
Sie können keine Frühwarnung mit einem ISO 27001-Zertifikat abgeben. Sie können ein Produkt nicht mit einer Richtlinie klassifizieren. Und Sie können keine 24-Stunden-Frist mit einem Prozess starten, der nur in einem Dokument existiert, das niemand je durchgespielt hat.
Die Hersteller, die das im September gut meistern, werden nicht diejenigen mit der besten CRA-Lückenanalyse sein. Es werden diejenigen sein, die, wenn das Ticket um 19:00 Uhr an einem Samstag eingeht, einen namentlich bekannten Menschen haben, der weiß, dass er den Knopf drücken darf.
Alles andere ist Vorbereitung auf diesen einen Moment.
Sanktionen bei Verstößen gegen die wesentlichen Anforderungen und Herstellerpflichten belaufen sich auf 15 Millionen Euro oder 2,5 % des gesamten weltweiten Jahresumsatzes, je nachdem, welcher Betrag höher ist. Aber das Bußgeld ist nicht das Risiko. Das Risiko ist, am Tag selbst festzustellen, dass die Kenntniserlangung niemandes Aufgabe war.
Wenn Sie die 24/72-Stunden-Routine solide aufbauen möchten, mit Auslösern, Eskalation, Nachweisen und der regulatorischen Zuordnung, die entscheidet, welche Regelwerke ein Ereignis berührt, ist das genau das, was wir im ISO/IEC 27035 Lead Incident Manager vermitteln. Fünf Tage, abgestimmt auf DORA, NIS2 und jetzt auf CRA Artikel 14. Zertifiziert oder erstattet.
