Cyber Resilience Act 2026: Der 24/72-Stunden-Meldeworkflow für Produkte mit digitalen Elementen
Transparenzhinweis
Dieser Beitrag wurde automatisiert mit KI erstellt. Die verlinkten Primärquellen der Europäischen Kommission, ENISA und EUR-Lex wurden am 19. August 2026 im Erstellungsprozess geprüft; vor der Veröffentlichung fand keine inhaltliche menschliche Redaktion statt. Der Beitrag enthält keine Kundenfälle oder gemessenen Projektergebnisse und bietet betriebliche Orientierung, aber keine Rechtsberatung.
Viele Unternehmen verbinden den Cyber Resilience Act mit dem 11. Dezember 2027. Für Meldungen ist das zu spät: Bereits ab 11. September 2026 müssen Hersteller aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle melden, wenn sie die Sicherheit von Produkten mit digitalen Elementen betreffen.
Damit beginnt im Ernstfall sofort ein getakteter Prozess. Ab Kenntnisnahme bleiben höchstens 24 Stunden für die Frühwarnung und 72 Stunden für die erweiterte Meldung. Wer erst dann Produktdaten, Zuständigkeiten und Nachweise zusammensucht, macht aus einem Sicherheitsereignis zusätzlich ein Fristenproblem.
Die gute Nachricht: Die Meldung ist bewusst gestuft. Innerhalb von 24 Stunden muss nicht die gesamte Untersuchung abgeschlossen sein. Entscheidend ist ein Workflow, der das Ereignis sauber erfasst, rechtzeitig eskaliert, die jeweils nötigen Felder vorbereitet und jede Einreichung nachweisbar macht.
Kurz zusammengefasst
- Der frühe Termin ist entscheidend: Artikel 14 gilt ab 11. September 2026, während die meisten übrigen CRA-Pflichten später greifen.
- T0 muss belastbar sein: Der Zeitpunkt der Kenntnisnahme startet die Fristen und darf nur durch eine dokumentierte, auditierbare Neubewertung geändert werden.
- Technik und Meldung laufen parallel: Eindämmung und Analyse gehen weiter, während die Meldestufen vorbereitet werden.
- Intern automatisieren, extern kontrollieren: ENISA stellt derzeit keine API für die Einreichung bereit; die SRP-Übergabe bleibt ein menschlicher Prüfschritt.
- Ein Dossier statt verteilter Dateien: Produktdaten, Entscheidungen, Entwürfe und Einreichungsbelege gehören in dieselbe Fallakte.
Wen dieser Leitfaden betrifft
Scope vor Workflow
Dieser Leitfaden behandelt ausschließlich den operativen Meldeprozess nach Artikel 14 CRA. Er richtet sich an Hersteller von Produkten mit digitalen Elementen; Open-Source-Software-Stewards sind nur in dem Umfang einbezogen, in dem sie gemäß Artikel 24 Absatz 3 beteiligt sind. Nicht jedes KMU ist Hersteller, nicht jede Schwachstelle ist aktiv ausgenutzt und nicht jeder Sicherheitsvorfall ist im Sinne des CRA schwerwiegend. Produkt, Unternehmensrolle und Ereignis müssen separat rechtlich und technisch geprüft werden.
Die Fristen auf einen Blick
| Stufe | Frist | Prozessziel |
|---|---|---|
| T0 – Kenntnisnahme | Sofort protokollieren | Rohsignal, zuerst gesetzten T0, Quelle, Produkt und Belege revisionssicher speichern; jede Neubewertung versionieren |
| Frühwarnung | Unverzüglich, spätestens 24 Stunden | Mindestangaben über die Single Reporting Platform übermitteln |
| Hauptmeldung | Unverzüglich, spätestens 72 Stunden | Allgemeine Informationen, erste Bewertung und Maßnahmen ergänzen |
| Abschluss: Schwachstelle | Spätestens 14 Tage nach verfügbarer Korrektur- oder Minderungsmaßnahme | Beschreibung, Schweregrad, Auswirkung und Abhilfe abschließen |
| Abschluss: Vorfall | Innerhalb eines Monats nach der 72-Stunden-Meldung | Ursache, Auswirkung und laufende Maßnahmen dokumentieren |
Die SRP ist der einheitliche Meldeweg. Sie leitet die Meldung an den zuständigen CSIRT-Koordinator und grundsätzlich gleichzeitig an ENISA weiter. Intern sollte trotzdem jede übermittelte Fassung mit Zeitpunkt und Referenz am Fall gesichert werden.
Der interne Meldeworkflow in sieben Schritten
- 1. Signal zentral erfassen: Monitoring, Support, Entwicklung, externe Forschende und Lieferanten brauchen einen eindeutigen Eingangskanal. Jedes Signal erzeugt einen Fall, nicht nur eine weitere E-Mail.
- 2. T0 nachvollziehbar festhalten: Speichern Sie Rohsignal und zuerst gesetzten T0 revisionssicher. Falls sich der Kenntniszeitpunkt nach fachlicher Prüfung ändert, müssen alter und neuer Stand samt Begründung auditierbar bleiben.
- 3. Technische Reaktion und Meldeprüfung parallel starten: Eindämmung, Analyse und Patch-Arbeit laufen weiter; zugleich prüft die CRA-Koordination, ob aktive Ausnutzung oder ein schwerwiegender produktbezogener Vorfall vorliegt. Die Automation verteilt Aufgaben, trifft aber nicht die rechtliche Einordnung.
- 4. Produktstammdaten anreichern: Herstellername, Produkt, Produkttyp, Kategorie und betroffene Mitgliedstaaten fließen aus einem gepflegten Produktregister in den Fall – nicht aus dem Gedächtnis des Incident-Teams.
- 5. 24-Stunden-Paket erstellen und kontrolliert einreichen: Der Workflow prüft Mindestfelder, markiert Lücken und erstellt eine klare Übergabe. Eine benannte Person kontrolliert Inhalt und Identität, überträgt die Meldung in die SRP und legt den Einreichungsnachweis ab.
- 6. Untersuchung für die 72-Stunden-Meldung fortführen: Technische Teams ergänzen Art, Auswirkung, erste Bewertung sowie umgesetzte und für Nutzer verfügbare Maßnahmen. Änderungen gegenüber der Frühwarnung bleiben nachvollziehbar.
- 7. Abschlussbericht und Fallabschluss steuern: Die Fristlogik unterscheidet Schwachstelle und schwerwiegenden Vorfall. Der Fall endet erst, wenn der Abschlussbericht eingereicht, der Beleg archiviert und offene Korrekturmaßnahmen in den normalen Produktprozess übergeben sind.
Der Ablauf verbindet Product Security, Entwicklung und Compliance. Wie daraus ein wartbarer Gesamtprozess wird, zeigt auch der Lyron-Leitfaden zur Prozessautomatisierung für KMU.
Feld- und Rollenmatrix für das eigene Runbook
Die Rollenbezeichnungen sind betriebliche Empfehlungen, keine vom CRA vorgeschriebene Organisationsstruktur. Die Feldgruppen orientieren sich an der ENISA-FAQ Q16; vor der ersten echten Meldung muss der dann aktuelle SRP-Dialog erneut geprüft werden.
| Feldgruppe | 24 Stunden | 72 Stunden / Abschluss | Empfohlene Verantwortung |
|---|---|---|---|
| Stammdaten | Meldungstyp und -stufe, Hersteller oder Steward, Produkt und Titel; Produkttyp und -kategorie optional, verfügbare Marktangaben ergänzen | Angaben bestätigen oder aktualisieren | CRA-Koordination + Product Owner |
| Aktiv ausgenutzte Schwachstelle | CVE, EUVD und erste Details, soweit vorhanden | 72h: Art der Schwachstelle und Ausnutzung, ergriffene Korrektur- oder Minderungsmaßnahmen und Schritte für Nutzer. Abschluss: vollständige Beschreibung, Schweregrad, Auswirkung sowie Datum und Details der verfügbaren Korrekturmaßnahme | Product Security + Entwicklung |
| Schwerwiegender Vorfall | Verdacht auf rechtswidrige oder böswillige Handlung kennzeichnen | 72h: Art, Erkennungs- und Eintrittszeitpunkt, erste Bewertung, ergriffene Maßnahmen und Schritte für Nutzer. Abschluss: detaillierte Beschreibung, Schweregrad, Auswirkung, wahrscheinliche Ursache oder Bedrohungsart und laufende Minderung | Incident Lead + Entwicklung |
| Sensibilität | Interne Kennzeichnung, soweit erkennbar | Bei 72h angeben, wenn verfügbar; im Abschluss prüfen und fortschreiben | Security + CRA-Koordination |
| Einreichungsnachweis | Übermittelte Fassung, Uhrzeit, SRP-Referenz | Jeweils neue und finale Fassung, Uhrzeit, Referenz | Benannter Submitter + Stellvertretung |
Was sich ohne API sinnvoll automatisieren lässt
ENISA zieht eine klare Grenze: Organisationen können ihre internen Meldeabläufe automatisieren und Anforderungen in Systeme und Datenbanken integrieren; in diesem Stadium wird jedoch keine API für die Einreichung bereitgestellt. Das bedeutet nicht „keine Automation“, sondern eine kontrollierte menschliche Übergabe.
Sinnvoll automatisieren
- Fall aus Monitoring-, Support- oder Entwicklungs-Signalen erzeugen
- T0 sichern und Folgefristen berechnen
- Produkt- und Kontaktstammdaten anreichern
- Pflichtfelder prüfen, Aufgaben verteilen und eskalieren
- Entwürfe versionieren und Einreichungsbelege zentral ablegen
Bewusst menschlich lassen
- Meldepflicht fachlich und rechtlich einordnen
- Sensible Angaben bewerten und Wortlaut freigeben
- Identität, Fall und Fassung vor der SRP-Eingabe prüfen
- In der SRP anmelden und absenden
- Erfolgreiche Übermittlung und Referenz bestätigen
Die richtige Systemgrenze
Eine fragile Browser-Automation rund um Login und Absenden ist kein Ersatz für eine API. Der belastbare Prozess endet an einer klaren Übergabestelle: intern vollständig vorbereitet, extern von einer verantwortlichen Person geprüft und eingereicht.
Drei Wochen bis zur Betriebsbereitschaft
Woche 1: Scope und Eigentümer
Produkte und Rollen erfassen, Entscheidungspfad fachlich prüfen, CRA-Koordination, technische Leitung, Submitter und Stellvertretung benennen. Einen zentralen Eingang und die T0-Regel festlegen.
Woche 2: Fallmodell und Automation
ENISA-Feldgruppen abbilden, Checklisten erzeugen, Fristen und Eskalationen umsetzen, Versionierung sowie Vier-Augen-Übergabe mit Belegablage testen.
Woche 3: Zwei Szenarien proben
Eine aktiv ausgenutzte Schwachstelle und einen schwerwiegenden Vorfall als Tischübung durchspielen – einschließlich Abwesenheit und Eingang außerhalb der Kernarbeitszeit. Fehlende Felder verbessern, Runbook freigeben.
Prüfen Sie den aktuellen ENISA-Stand und den echten SRP-Dialog erneut, sobald die Plattform öffentlich verfügbar ist. Die Übung ist kein Kundenfall und liefert keine Marketingkennzahl; sie soll den eigenen Ablauf vor einem realen Ereignis belastbar machen.
Vier Kennzahlen, die den Prozess steuerbar machen
- T0-Latenz: Zeit vom ersten belastbaren Signal bis zum dokumentierten Startpunkt.
- Feldvollständigkeit: Anteil der je Stufe erforderlichen Angaben vor dem internen Prüftermin.
- Fristrisiko: Offene Aufgaben und drohende Überschreitungen je Fall.
- Nachweisquote: Einreichungen mit vollständig archivierter Fassung, Referenz und Zeitstempel.
Diese Kennzahlen messen den eigenen Ablauf. Sie beweisen keine Rechtskonformität und werden hier bewusst ohne erfundene Benchmarks oder Kundenergebnisse genannt. Für den späteren Betrieb helfen zusätzlich die Prüf- und Eskalationsprinzipien aus dem Guide KI-Workflows überwachen.
Fazit: Fristen automatisieren, Verantwortung sichtbar halten
Der CRA-Meldeprozess ist weder nur ein Security-Ticket noch nur ein Compliance-Formular. Er verbindet Produktwissen, technische Analyse, Fristen, Freigaben und belastbare Nachweise. Genau diese Übergaben sollten betroffene KMU vor dem 11. September gestalten.
Der entscheidende Architekturpunkt ist die Grenze der Automation: Daten, Aufgaben, Fristen und Entwürfe laufen strukturiert zusammen; Einordnung, Freigabe und SRP-Einreichung bleiben nachvollziehbar bei verantwortlichen Menschen. So entsteht ein Workflow, der im Ernstfall arbeitsfähig ist, statt erst dann erfunden zu werden.
Quellen und Bildnachweis
Stand und Prüfung: 19. August 2026.
- Europäische Kommission: CRA-Meldepflichten – aktualisiert am 31. Juli 2026; Starttermin, Meldestufen, Abschlussfristen und Status der Single Reporting Platform.
- ENISA: FAQ zur Single Reporting Platform – aktualisiert am 3. August 2026; insbesondere Fristen, derzeit fehlende API und Feldgruppen in Q7, Q15 und Q16.
- Europäische Kommission: neue CRA-Leitlinie – veröffentlicht am 27. Juli 2026; Scope, Risikobewertung und Meldepflichten mit besonderem KMU-Fokus.
- EUR-Lex: Verordnung (EU) 2024/2847 – verbindlicher Rechtstext, insbesondere Artikel 14, 16 und 24.
- ENISA: aktuelle SRP-Oberflächenfunktionen – aktualisiert am 14. August 2026; Rollen, Dashboard und Meldestatus.
- Foto: Jakub Pabis auf Unsplash, Unsplash-Lizenz; kommerzielle Nutzung und Bearbeitung erlaubt. Die Quellseite nennt eine Sony ILCE-7M4 und zeigt eine reale Leiterplatte ohne Personen oder erkennbare Markenlogos.
Im Ernstfall darf der Workflow nicht erst erfunden werden.
Lyron strukturiert Sicherheits-, Produkt- und Compliance-Informationen zu einem nachvollziehbaren Meldeworkflow mit Fristlogik, Pflichtfeldprüfung, Eskalation und kontrollierter SRP-Übergabe. Die rechtliche Einordnung bleibt bei Ihnen und Ihren qualifizierten Beratern; wir bauen den Prozess, der die richtigen Informationen rechtzeitig dorthin bringt.
CRA-Workflow besprechenArtikel teilen: