Countdown 11.9.: CRA-Meldepflicht 24h/72h/14 Tage – ENISA-SRP wird scharf

Freitagabend, 19:47 Uhr. Im Ticket-System blinkt eine Zeile, die niemand bestellt hat: zuverlässige Hinweise, dass eine Schwachstelle in Ihrem Produkt mit digitalen Elementen aktiv ausgenutzt wird. Das Wochenende steht vor der Tür. Die Frage ist nicht mehr, ob Sie reagieren – sondern wer den Knopf im ENISA Single Reporting Platform (SRP) drückt, bevor die 24-Stunden-Uhr abläuft.

Willkommen im Countdown. Ab dem 11.9. gelten die Meldepflichten des Cyber Resilience Act (CRA) für Hersteller. Frühwarnung binnen 24 Stunden, Vollmeldung binnen 72 Stunden, Final Report später – und das alles über ein Portal, das unter portal.cra-srp.enisa.europa.eu erreichbar sein soll. Spoiler: Wer bis dahin keine Assigned Representatives, kein EU Login mit MFA und keinen klaren CSIRT-Pfad hat, spielt Freitagabend russisches Roulette mit Fristen.

Das Pikante daran: Es reicht nicht, „irgendwen aus Security“ anzurufen. Die Meldung läuft einmal über die SRP an das CSIRT der Hauptniederlassung und – außer bei Particularly Exceptional Circumstances (PEC) – parallel an ENISA. Doppelmeldungen an zehn Behörden? Abgesagt. Eine Meldung, viele Empfänger. Der Clou sitzt in der Organisation, nicht im Formular.

Was am 11.9. scharf wird: CRA-Meldepflicht nach Artikel 14

Laut der Europäischen Kommission müssen Hersteller ab dem 11. September 2026 aktiv ausgenutzte Schwachstellen (Actively Exploited Vulnerabilities, AEV) und schwere Sicherheitsvorfälle (Severe Incidents, SI) mit Auswirkungen auf die Sicherheit ihrer Produkte mit digitalen Elementen melden. Die Rechtsgrundlage steckt in den Artikeln 14 bis 17 CRA; die Plattform selbst ist in Artikel 16 verankert. Details finden Sie auf der Seite der Kommission zu den CRA-Reporting-Verpflichtungen.

Wichtig für den Kalender: Am Starttag ist nur die Pflichtmeldung nach Artikel 14 verpflichtend. Freiwillige Meldungen nach Artikel 15 kommen später. Open-Source-Software-Stewards nach Artikel 24 Absatz 3 starten erst am 11. Dezember 2027. Wer also freitags glaubt, „alles CRA“ sei auf einmal live, verwechselt Launch-Scope mit Marketingfolie.

Wenig überraschend bleibt die Verantwortung beim Hersteller: Eine AEV oder ein SI – eine Meldung. Auch wenn Tochtergesellschaften in fünf Mitgliedstaaten sitzen und die Konzernzentrale außerhalb der EU liegt. Intern koordinieren, extern einmal submitten. Brisant wird es, wenn niemand weiß, wer „aware“ im Sinne der Frist ist – und die Uhr schon läuft.

Die Uhr tickt: 24 Stunden, 72 Stunden, Final Report

Die Fristen sind kein Soft-Target. Sie beginnen, sobald der Hersteller Kenntnis von der AEV oder dem schweren Vorfall hat. „Ohne unangemessene Verzögerung“ und in jedem Fall innerhalb der genannten Fenster. Wer die Early Warning verschläft, hat nicht nur ein Compliance-Problem – sondern einen dokumentierten Startpunkt für Aufsicht und Audit.

Plot Twist: Die Plattform zeigt für die 72-Stunden-Meldung derzeit einen Zähler, der 48 Stunden nach Abgabe der Early Warning als Fälligkeit anzeigt. In Einzelfällen wirkt eine Meldung also „überfällig“, bevor die gesetzlichen 72 Stunden seit Kenntnis abgelaufen sind. ENISA weist darauf hin, dass die Logik später auf das Feld „Date/Time when you became aware“ umgestellt werden soll. Bis dahin: Zähler beobachten, aber die gesetzliche Frist nicht mit dem UI-Timer verwechseln.

Für AEV gibt es aktuell keinen Final-Report-Zähler im Portal – logisch, weil die 14 Tage erst mit der verfügbaren Korrekturmaßnahme beginnen. Für SI zeigt der Zähler etwa einen Monat nach der 72-Stunden-Meldung. Erinnerungsmails helfen. Ersetzen tun sie die Verantwortung nicht.

Dieses Bild wurde komplett mit KI generiertProviderhiggsfieldModellflux_2PromptEditorial Symbolbild: digital countdown clock and incident response desk, abstract metaphor for 24 hour early warning and 72 hour notification deadlines, photorealistic cybersecurity magazine style, no text, no logosCountdown-Anzeige und Meldepflicht-Uhr: 24h Early Warning, 72h Notification, Final Report über die ENISA-SRP

AEV oder SI – zwei Labels, zwei Final-Pfade

Eine Actively Exploited Vulnerability liegt vor, wenn zuverlässige Belege zeigen, dass ein böswilliger Akteur die Schwachstelle in einem System ohne Erlaubnis der Systemeigentümer ausgenutzt hat. Das ist die CRA-Definition – knapp, hart, beweisorientiert. „Vielleicht wird ausgenutzt“ reicht nicht. Ein reiner Labor-Nachweis ohne aktive Ausnutzung auch nicht. Es geht um aktive Ausnutzung mit belastbaren Hinweisen.

Ein Severe Incident ist ein Vorfall mit schwerwiegender Auswirkung auf die Sicherheit des Produkts mit digitalen Elementen – etwa auf Verfügbarkeit, Authentizität, Integrität oder Vertraulichkeit von Daten oder Funktionen. Die Schwerekriterien liegen in Artikel 14 Absatz 5 CRA. Wer im SRP den Typ wählt, bekommt angepasste Felder: CVE/EUVD, Exploit-Lage und PEC eher bei AEV; Incident-Charakter, Mitigation und Root Cause eher bei SI.

Überraschung: Nicht jedes Feld ist in jeder Stufe Pflicht. Manches ist in der Early Warning optional und wird in der 72-Stunden-Meldung oder im Final Report verpflichtend. Das SRP-Glossar von ENISA listet Feld für Feld, was wann gilt. Wer Freitagabend improvisiert, tippt in Felder, die Montag morgen in der Audit-Spur hässlich aussehen.

Und ja: Auch Produkte, die vor dem 11. Dezember 2027 in Verkehr gebracht wurden, fallen unter die Meldepflicht ab dem 11.9.2026, sofern sie im CRA-Anwendungsbereich liegen. Rückwirkend melden müssen Sie eine AEV nicht, von der Sie schon vor dem Stichtag wussten. Werden Sie danach aware – auch wenn die Schwachstelle älter ist – läuft die Uhr.

ENISA Single Reporting Platform: einmal melden, CSIRT plus ENISA

Der Sinn der SRP steckt im Namen: Single. Hersteller melden elektronisch einmal, wählen das zuständige CSIRT als Koordinator und lösen damit den Verteiler aus. Die Meldung geht an das CSIRT der Hauptniederlassung und wird – sofern keine PEC greifen – gleichzeitig ENISA bereitgestellt. Das empfangende CSIRT leitet ohne Verzögerung an andere relevante CSIRTs in Mitgliedstaaten weiter, in denen das Produkt verfügbar ist, und teilt Informationen mit Marktüberwachungsbehörden, soweit nötig.

Die aktuelle ENISA-FAQ zur Single Reporting Platform (Stand 8.9.2026) macht den Betriebsmodus klar: ENISA betreibt und sichert die Plattform; CSIRTs bewerten, entscheiden über Verzögerungen und helfen; die Kommission setzt delegierte und Durchführungsrechtsakte; Marktüberwachung vollzieht. Wer glaubt, „Portal ausfüllen = Akte geschlossen“, unterschätzt den zweiten Akt hinter dem Submit-Button.

Welches CSIRT? In der Regel das CSIRT Designated as Coordinator (CDaC) im Mitgliedstaat der Hauptniederlassung – dort, wo Entscheidungen zur Cybersicherheit der Produkte überwiegend getroffen werden. Hilfsweise: Standort mit den meisten Beschäftigten in der EU. Ohne EU-Niederlassung greift eine Kaskade über Bevollmächtigte, Importeure, Händler und Nutzerzahlen. Falsches CDaC wählen kann die Meldung ungültig machen. Dann heißt es: neu einreichen. Freitagabend-Favorit? Eher nicht.

Wer Parallelwelten zu Netz- und Informationssicherheit kennt, merkt den Unterschied: Die NIS2-Richtlinie zielt auf Betreiber und wesentliche/wichtige Einrichtungen. CRA zielt auf Produkte mit digitalen Elementen und deren Hersteller. Zwei Regelkreise, zwei Meldewege, eine gemeinsame Erwartung: Fristen ernst nehmen.

Registrierung vor dem Ernstfall: EU Login, Primary AR, Secondary AR

Zugang nur über EU Login mit Multi-Faktor-Authentifizierung. Konten sind personenbezogen. Assigned Representatives (AR) melden sich mit dem eigenen Login an – nicht mit einem geteilten „Security-Team“-Account aus dem Passwortmanager von 2019. EU Login kann vorab unter dem zentralen Anmeldeportal der Kommission angelegt werden. MFA ist Pflicht, nicht Nice-to-have.

Pro Hersteller gibt es genau eine Primary AR. Dazu bis zu 20 Secondary ARs. Die Primary AR registriert sich direkt, wählt das CDaC, hinterlegt Herstellerdaten und legt die erste Verknüpfung an. Secondary ARs kommen per Einladung und bestätigen die vorausgefüllten Angaben. Die Primary AR verwaltet die Entität, lädt ein, entfernt. Die Zuordnung AR–Hersteller wird vom CDaC validiert – parallel zum Meldegeschehen, nicht als Blockade davor.

Der Clou: Nicht validierte ARs dürfen bis zu 20 Meldungen pro Hersteller absetzen, bevor die Validierung zwingend wird. Das rettet den Freitagabend, an dem die erste AEV eintrifft und das CSIRT noch nicht durch ist. Es ersetzt keine saubere Registrierungsstrategie. ENISA rät ausdrücklich: Registrieren und Validierung anstoßen, wenn Sie tatsächlich melden müssen – und nicht prophylaktisch die Warteschlangen der CSIRTs verstopfen. Sofern EU Login schon steht, dauert die SRP-Registrierung laut FAQ nur wenige Minuten.

Englisch only beim Launch. Kein API. Wer tausende Produkte und automatisierte interne Pipelines hat, automatisiert intern – und tippt oder orchestriert am Ende trotzdem über die Web-Oberfläche. API „irgendwann später“ ist keine Architekturentscheidung für den 11.9.

Was am Launch bewusst fehlt: API, Art. 15, OSS-Stewards

Drei Lücken, die Sie in die Roadmap schreiben sollten – nicht in die Ausrede-Liste. Erstens: Keine Programmierschnittstelle beim Start. Zweitens: Freiwillige Meldungen nach Artikel 15 (Schwachstellen, Bedrohungen, Vorfälle, Near Misses durch natürliche oder juristische Personen) kommen in einer späteren Phase. Drittens: Open-Source-Software-Stewards melden erst ab dem 11.12.2027, soweit sie in den Einsatz von Produkten mit digitalen Elementen eingebunden sind.

ENISA stellt Factsheet, FAQ, Glossar bereit; User Manual und Tutorial-Videos sollen zum Launch folgen. Helpdesk-Adresse für offene Fälle: cra-srp-helpdesk@enisa.europa.eu – besonders relevant für kleinere Hersteller, die keine Compliance-Abteilung mit Nachtschicht haben.

Plot Twist für die Betriebsorganisation: Wenn die SRP vorübergehend down ist, warten Sie und reichen danach trotzdem über die SRP nach. Direkter CSIRT-Kontakt ist möglich, wenn sofortige Kommunikation nötig scheint – ersetzt die SRP-Einreichung aber nicht. Artikel 14 Absatz 7 bleibt der Anker. „Wir haben angerufen“ ist kein Submit.

Dieses Bild wurde komplett mit KI generiertProviderhiggsfieldModellflux_2PromptEditorial Symbolbild: digital countdown clock and incident response desk, abstract metaphor for 24 hour early warning and 72 hour notification deadlines, photorealistic cybersecurity magazine style, no text, no logos

PEC und verzögerte Weitergabe: wann ENISA nur Teilinfos sieht

Dieses Bild wurde komplett mit KI generiertProviderhiggsfieldModellflux_2PromptEditorial Symbolbild: professional at laptop preparing regulatory security report submission, EU digital infrastructure atmosphere, photorealistic magazine photo, no text, no logos, no readable screens

Particularly Exceptional Circumstances erlauben es dem empfangenden CSIRT, die Weitergabe an andere Mitgliedstaaten zu verzögern oder zurückzuhalten – auch auf Antrag des Herstellers. Die Kommission hat am 11. Dezember 2025 einen delegierten Rechtsakt zu den Gründen und Bedingungen für solche Verzögerungen angenommen. Das ist kein Freifahrtschein für Geheimniskrämerei, sondern ein eng gefasstes Sicherheitsventil.

PEC prüfen Sie in dem 72-Stunden-Fenster, wo die Felder im Formular auftauchen. Voraussetzung: mindestens eine der Bedingungen aus Artikel 16 Absatz 2 CRA. Markiert der Hersteller PEC aktiv, erhält ENISA zunächst nur Teilinformationen, bis das empfangende CSIRT die vollständige Meldung freigibt. Das Pikante daran: Wer PEC aus Bequemlichkeit anklickt, riskiert Verzögerungen und Nachfragen – und erklärt später, warum die Ausnahme greifen sollte.

Brisant für Konzerne mit sensiblen Lieferketten: Die Weitergabe an andere CSIRTs und Marktüberwachung ist der Normalfall. Verzögerung ist die Ausnahme mit Begründung. Wer PEC in der Playbook-Checkliste hat, braucht vorab juristische und security-seitige Kriterien – nicht erst, wenn die 72 Stunden halb vorbei sind.

Zur Einordnung mit angrenzenden Schockwellen in der Lieferkette lohnt der Blick auf Fälle, in denen Alarmketten Institutionen treffen – etwa im Kontext von CERT-Alarm und Supply-Chain-Vorfällen. CRA-Produktmeldung und klassische Incident-Kommunikation sind verwandt, aber nicht deckungsgleich.

Checkliste vor Freitag: Rollen, Playbooks, CSIRT, MFA

Wer den 11.9. als „noch Zeit“ verbucht, unterschätzt Onboarding-Reibung. Konkret lohnt sich vor dem Stichtag:

• Primary AR und Vertretung (Secondary ARs) benennen – mit Klarheit, wer nachts submitten darf.
• EU Login persönlich anlegen, MFA erzwingen, Geräte und Backup-Faktoren testen.
• Hauptniederlassung und zuständiges CDaC dokumentieren; Fallback-Logik für Grenzfälle schriftlich festhalten.
• Playbook AEV vs. SI: Wer entscheidet „aware“? Wer liefert Produktversion, CVE/EUVD, Mitigationstexte?
• Feldmapping Early Warning / 72h / Final gegen interne Ticketsysteme legen – ohne API heißt das: Copy-Paste-fähig und auditierbar.
• PEC-Kriterien mit Legal vorbereiten; Default ist „keine PEC“.
• Escalation, wenn SRP down: CSIRT-Kontaktliste, aber Pflicht zur späteren SRP-Nachreichung.
• Sprachregelung Englisch für Formularfelder üben – Launch-Sprache ist Englisch.

Für IoT- und Gerätehersteller, die ohnehin Triage-Disziplin brauchen, schließt sich der Kreis zur praktischen Priorisierung – thematisch verwandt mit Ansätzen aus dem NIST-Triage für IoT-Sicherheit: erst Klassifikation, dann Aktion, dann Dokumentation. CRA verlangt dasselbe Tempo, nur mit Behördenempfänger.

Spoiler aus der Praxis: Die größte Lücke sitzt selten im Portal. Sie sitzt zwischen Vulnerability Management, Product Security und Legal, wenn um 19:47 niemand weiß, ob die Zeile im Ticket eine AEV ist – oder nur ein lautes Gerücht.

NIS2, DSGVO und CRA: drei Uhren, ein Freitagabend

CRA-Produktmeldepflicht ersetzt weder NIS2-Pflichten betroffener Einrichtungen noch datenschutzrechtliche Meldungen. Sie ergänzt. Ein schwerer Vorfall am Produkt kann parallel DSGVO-Meldewege auslösen, wenn personenbezogene Daten betroffen sind, und gleichzeitig NIS2-Relevant sein, wenn Ihre Organisation unter die Richtlinie fällt. Drei Fristenrahmen, drei Adressatenkreise – und die SRP ist nur einer davon.

Wer KMU im Gesundheits- oder Energiesektor durch die NIS2-Transponierung begleitet hat, kennt das Muster: Zuständigkeit klären, Rollen fixieren, Templates vorhalten. Genau das verlangt jetzt auch die CRA-Meldepflicht – nur eben produktbezogen und über ENISA. Der Text zur NIS2-Transponierung für KMU in Gesundheit und Energie zeigt, wie schnell Sektorregeln operative Last erzeugen. CRA macht aus Produktteams Meldeorganisationen.

Wenig überraschend fordern Aufsicht und Markt das Gleiche: nachvollziehbare Kenntniszeitpunkte, belastbare Schwerebewertung, keine Show-Meldungen. Wer intern „wir schauen Montag“ als Default setzt, baut systematisch Fristbruch.

Betriebsrealität nach dem Submit: Zähler, Felder, Helpdesk

Nach der Early Warning erwartet die Plattform die 72-Stunden-Notification mit mehr Substanz: allgemeine Informationen, erste Bewertung, Angaben zu Korrektur- und Nutzermitigationen, wo erforderlich. Im Final Report werden Schwere und Impact ausführlich – bei AEV inklusive Datum der verfügbaren Maßnahme; bei SI inklusive angewandter Mitigationen und wahrscheinlicher Ursache.

ENISA betont: Die Zähler dienen der Sichtbarkeit und Erinnerung. Sie ersetzen nicht die Pflicht, ohne unangemessene Verzögerung und innerhalb der gesetzlichen Fenster zu melden. Wer nur dem UI-Grün hinterherläuft, kann trotzdem zu spät sein – oder unnötig panisch, wenn der 72h-Zähler früher warnt als das Gesetz.

Drittkomponenten: Eine aktiv ausgenutzte Schwachstelle in einer Zulieferkomponente entbindet den Hersteller nicht pauschal. Die Kommissions-FAQ zur CRA-Umsetzung (Abschnitt zu Drittkomponenten) ist Pflichtlektüre für Product Security. Lieferantenklauseln ohne Meldewege sind Dekoration.

Und wenn Sie kein Hersteller sind? Die aktuelle SRP-Version nimmt Pflichtmeldungen von Herstellern nach Artikel 14 entgegen. Andere Personen wenden sich an das nationale CSIRT; eine SRP-Einreichung kann als ungültig markiert werden. Klartext statt Wunschdenken.

Was Security-Leads jetzt schriftlich festhalten sollten

Drei Sätze ins Führungshandbuch, bevor der Countdown bei null ist. Erstens: Wer darf „aware“ feststellen und die Frist starten? Zweitens: Wer ist Primary AR, wer Secondary, wer hat MFA und Gerätezugriff am Wochenende? Drittens: Welches CDaC ist gewählt, und wo liegt die dokumentierte Begründung der Hauptniederlassung?

Ergänzend: Mapping der SRP-Felder auf Ihr Incident-/Vulnerability-Tool; Englisch-Templates für Summary und Mitigation; PEC-Entscheidungsbaum; Kontakt cra-srp-helpdesk@enisa.europa.eu für Plattformfragen; Eskalation Legal/PR, falls Marktüberwachung oder Öffentlichkeit ins Spiel kommt.

Überraschung für Boards: Die SRP ist kein PR-Kanal. Sie ist ein behördlicher Meldeweg mit Weitergabe an CSIRTs und potenziell Marktüberwachung. Interne Kommunikationspläne müssen das einkalkulieren – inklusive der Tatsache, dass verzögerte Dissemination Ausnahme bleibt.

Wer die kommenden Tage nutzt, um Rollen und Templates zu härten, kauft sich am Freitagabend Zeit. Wer hofft, „wir registrieren dann schon“, kauft sich Stress. Die Plattform soll zum Stichtag stehen; funktionale und Sicherheitstests liefen. Bedienungsfehler bleiben Ihr Problem.

Dokumentationsspuren, die Freitagabend retten

Neben dem Submit zählt die Spur davor. Halten Sie fest, wann welche Person welche Quelle als zuverlässigen Hinweis auf aktive Ausnutzung bewertet hat. Das ist kein Bürokratiefetisch – das ist Ihr Nachweis für den Kenntniszeitpunkt, an dem die 24-Stunden-Frist ansetzt. Ohne Zeitstempel und Entscheidungslogik wird aus einer sauberen Meldung schnell eine Debatte mit Aufsicht und Internem Audit.

Praktisch reicht oft eine kurze Entscheidungsnotiz im Ticket: Quelle, Vertrauensgrad, Produktversion, betroffene Variante, vorläufige Einordnung AEV oder SI, Name der entscheidenden Rolle. Daraus speisen Sie Summary und Felder der Early Warning. Wer das erst im Portal erfindet, verliert Minuten – und bei engem Fenster Stunden.

Abschließend: Testen Sie den Happy Path einmal im Trockenen, sobald das Portal live ist. Login, Rollenwahl, Dummy-Felder in einer internen Übungsumgebung oder anhand des Glossars. Der erste echte Ernstfall ist der schlechteste Moment, um herauszufinden, dass MFA auf dem Diensthandy fehlt.

Schluss: Der Knopf wartet – die Organisation entscheidet

Am 11.9. wird die CRA-Meldepflicht scharf: 24 Stunden Early Warning, 72 Stunden Vollmeldung, Final Report nach 14 Tagen ab Korrekturmaßnahme bei AEV bzw. innerhalb eines Monats nach der 72-Stunden-Meldung bei SI. Einmal melden über die ENISA-SRP an CSIRT und – außer PEC – ENISA. Portal, EU Login, MFA, Primary und Secondary ARs, englische Oberfläche, kein API am Start.

Zurück zum Freitagabend. Das Ticket blinkt. Die Frage „Wer drückt den SRP-Button?“ ist keine rhetorische Fingerübung. Sie ist eine Organisationsfrage mit Uhr. Wenn Sie die Antwort schon kennen – inkl. Login, CDaC und Playbook – ist der Countdown nur noch lästig. Wenn nicht, wird er teuer.

Der Clou zum Abschied: Regulierer und Plattform liefern den Kanal. Die Frist liefert den Druck. Den Submit liefert jemand mit Namen, MFA und Freigabe. Stellen Sie sicher, dass diese Person nicht erst um 19:46 gesucht wird.