--- title: "Cyber Resilience Act: Operativer Meldeleitfaden für 24 und 72 Stunden" canonical: https://wavect.io/de/blog/cyber-resilience-act-reporting-playbook-2026/ language: de description: "CRA-Meldungen im Betrieb: 24/72-Stunden-Fristen, getrennte Abschlussberichte für Schwachstellen und schwere Vorfälle, Verantwortung und Nachweise." image: "https://wavect.io/img/blog/headers/header_cyber-resilience-act-reporting-playbook-2026.png" author: ["Kevin Riedl"] published: "2026-08-24" updated: "2026-10-05" reviewed: "2026-10-05" --- # Cyber Resilience Act: Operativer Meldeleitfaden für 24 und 72 Stunden [**Zurück**](/de/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/de/team/kevin-riedl/) [Kevin Riedl](/de/team/kevin-riedl/) https://linkedin.com/in/wsdt 9 Min Lesezeit · 24. August 2026 Zuletzt geprüft 5. Oktober 2026 [**Weiter**](/de/blog/eu-battery-passport-software-architecture-2027/) TL;DR Stand 5. Oktober 2026 gelten die CRA-Meldepflichten für Hersteller bereits. Aktiv ausgenutzte Schwachstellen und schwerwiegende Vorfälle erfordern eine Frühwarnung binnen 24 Stunden und eine Meldung binnen 72 Stunden ab Kenntniserlangung. Der Abschlussbericht folgt bei Schwachstellen spätestens 14 Tage nach Verfügbarkeit einer Korrekturmaßnahme, bei schwerwiegenden Vorfällen binnen eines Monats nach der 72-Stunden-Meldung. **Stand 5. Oktober 2026 gelten die CRA-Meldepflichten für Hersteller bereits. Aktiv ausgenutzte Schwachstellen und schwerwiegende Vorfälle erfordern eine Frühwarnung binnen 24 Stunden und eine Meldung binnen 72 Stunden ab Kenntniserlangung. Der Abschlussbericht folgt bei Schwachstellen spätestens 14 Tage nach Verfügbarkeit einer Korrekturmaßnahme, bei schwerwiegenden Vorfällen binnen eines Monats nach der 72-Stunden-Meldung.** Die Meldepflichten für Hersteller gelten seit 11. September 2026. Dieser technische Leitfaden macht daraus einen laufenden Prozess statt eines künftigen Vorbereitungsprojekts. Er ist keine Rechtsberatung: Produktumfang, Wirtschaftsakteursrolle und Meldetatbestand müssen fachkundig geprüft werden. Die nachfolgenden Umsetzungsempfehlungen sind keine zusätzlichen gesetzlichen Pflichten. ## Welche Frist gehört zu welcher Meldung? | Schritt | Auslöser und Frist | Operativer Nachweis | | --- | --- | --- | | **Frühwarnung: beide Kategorien** | Binnen 24 Stunden ab Kenntniserlangung | Kenntniszeitpunkt, Kategorie, erste Fakten und Eingangsbestätigung sichern. | | **Meldung: beide Kategorien** | Binnen 72 Stunden ab Kenntniserlangung, nicht 72 Stunden nach der Frühwarnung | Betroffene Produkte, Bewertung und verfügbare Maßnahmen ergänzen. | | **Abschluss: aktiv ausgenutzte Schwachstelle** | Spätestens 14 Tage nach Verfügbarkeit einer Korrekturmaßnahme | Verfügbarkeitszeitpunkt, Behebung und Abschlussübermittlung dokumentieren. | | **Abschluss: schwerwiegender Vorfall** | Binnen eines Monats nach der 72-Stunden-Meldung | Meldezeitpunkt, Kalendermonatsfrist und abschließende Vorfallsbewertung sichern. | ## Wer verantwortet Kenntniserlangung und Eskalation? Benenne eine verantwortliche Incident-Leitung und eine erreichbare Vertretung. Die Kenntniserlangung darf nicht künstlich bis zur Freigabe eines Tickets oder zur Veröffentlichung einer CVE verschoben werden. Dokumentiere, wer wann was wusste, und eskaliere unklare Meldetatbestände ohne auf vollständige Zuordnung zu warten. - Meldungen von Forschenden, Kunden, Lieferanten, CSIRTs und Monitoring in einen Aufnahmeprozess führen. - Erstbeobachtung, Kenntniserlangung im Unternehmen, interne Eskalation und externe Übermittlungen unterscheiden. UTC-Zeitstempel mit Nachweisen speichern. - Anwendungsbereich und Auslöser getrennt bewerten: Ein Scanner-Fund ist nicht automatisch eine aktiv ausgenutzte Schwachstelle oder ein schwerwiegender Vorfall. Entscheidung und Verantwortung dokumentieren. ## Was gehört in die Vorfallsakte? Nutze eine dauerhafte Incident-ID über alle Meldestufen. Trenne bestätigte Fakten von Annahmen und weise wesentlichen offenen Punkten Verantwortliche zu. Das folgende Schema ist eine technische Empfehlung, keine Behauptung, dass jedes Feld im externen Formular verpflichtend ist. - Produkt und betroffene Version, Herstellerrolle, Länder, Kategorie, Ausnutzungs- oder Schweregradnachweise, Kenntniszeitpunkt und die beiden ersten Fristen erfassen. - Bei Schwachstellen die Verfügbarkeit der Korrekturmaßnahme speichern, bei schwerwiegenden Vorfällen den Zeitpunkt der 72-Stunden-Meldung. Daraus die jeweils eigene Abschlussfrist berechnen. - Belege, Bewertungsänderungen, Verantwortliche, Maßnahmen- und Rolloutentscheidungen, Kommunikation, übermittelte Inhalte und Eingangsbestätigungen aufbewahren. - Sensible Exploit-Details und personenbezogene Daten beschränken. Zugriffe, angemessene Aufbewahrung und eine bereinigte Ansicht für die Zusammenarbeit festlegen. ## Wo wird gemeldet und wie wird geübt? Die Single Reporting Platform von ENISA ist seit 11. September 2026 in Betrieb. Nutze die offiziellen Zugangs- und Nutzungshinweise statt eine öffentliche Melde-API vorauszusetzen. Richte autorisierte Zugänge und Vertretungen jetzt ein; halte die interne Vorfallsakte unabhängig vom externen Formular. - Zugang, Zuständigkeiten und passenden CSIRT-Meldeweg anhand der offiziellen Plattformhinweise prüfen. - Zwei interne Übungen durchführen: eine ausgenutzte Schwachstelle und einen schwerwiegenden Vorfall. Keine erfundenen Übungsvorfälle in den produktiven Meldekanal einsenden. - Wochenenden, Abwesenheiten, verlorenen Plattformzugang, verzögerte Lieferantenmeldungen und Sicherung der Eingangsbestätigungen testen. ## Operative Prüfungen, die jetzt erforderlich sind 1. Betroffene Produkte, Herstellerverantwortung, Incident-Leitung und Vertretung festlegen. 2. Offiziellen Plattformzugang prüfen und aktuelle Meldeanleitungen im Incident-Handbuch pflegen. 3. Kenntniszeitpunkte sowie getrennte 24-Stunden-, 72-Stunden- und kategoriespezifische Abschlussfristen abbilden. 4. Meldungseingang mit Produkt-, Release- und Behebungsdaten verbinden; Zugriffsschutz und Abruf der Nachweise testen. 5. Beide Kategorien üben, erkannte Lücken schließen und regelmäßige Übungen festlegen. Ein Verbesserungsprojekt setzt keine Meldefrist aus. ## Häufige Fragen zur CRA-Meldung ### Gelten die Meldepflichten für Hersteller schon? Ja, seit 11. September 2026. Diese Seite wurde am 5. Oktober 2026 geprüft und ist kein Vorbereitungsleitfaden für einen noch bevorstehenden Start. ### Laufen die 24- und 72-Stunden-Fristen nacheinander? Nein. Beide beginnen mit der Kenntniserlangung. Die Meldung ist binnen 72 Stunden ab diesem Zeitpunkt fällig, nicht 72 Stunden nach der Frühwarnung. ### Ist jeder Abschlussbericht binnen 14 Tagen fällig? Nein. Diese Regel gilt für aktiv ausgenutzte Schwachstellen und beginnt mit der Verfügbarkeit einer Korrekturmaßnahme. Bei schwerwiegenden Vorfällen gilt ein Monat nach der 72-Stunden-Meldung. ### Gilt für Open-Source-Software-Stewards derselbe Starttermin? Nein. Für deren Pflichten nach Artikel 24 Absatz 3 nennt die Kommission den 11. Dezember 2027. Ein Hersteller wird nicht allein dadurch zum Steward, dass sein Produkt Open-Source-Software enthält. ### Braucht die Frühwarnung eine abgeschlossene Ursachenanalyse? Nein. Verfügbare Fakten sichern, Unsicherheiten kennzeichnen und die Meldung in den späteren Stufen ergänzen. Die Suche nach vollständigen Belegen darf eine rechtzeitige Eskalation nicht verhindern. ### Ist dieser Leitfaden eine rechtliche Compliance-Bestätigung? Nein. Er beschreibt die technische Umsetzung. Anwendungsbereich, Rolle, Vorfallskategorie und konkrete Pflichten benötigen weiterhin eine geeignete rechtliche Bewertung. ## Fazit Jetzt zählt verlässliche Ausführung: eine Vorfallsakte, klare Verantwortung mit Vertretung und getrennte Abschlussfristen für die beiden Kategorien. Meldung, Behebung und Kundenkommunikation müssen verbunden bleiben, ohne auf eine perfekte Ursachenanalyse zu warten. ## Primärquellen 1. [Europäische Kommission: CRA-Meldepflichten](https://digital-strategy.ec.europa.eu/en/policies/cra-reporting). Termine für Hersteller und Stewards sowie beide Meldekategorien und Fristen 2. [ENISA: Single Reporting Platform](https://www.enisa.europa.eu/topics/product-security/vulnerability-services/eu-incident-response-and-cyber-crisis-management/single-reporting-platform-srp). Offizieller Zugang, Nutzungshinweise und Meldematerialien 3. [Europäische Kommission: CRA-Anwendungsleitlinien](https://digital-strategy.ec.europa.eu/en/library/commission-publishes-new-guidance-support-timely-cyber-resilience-act-implementation). Anwendungsbereich und Umsetzung; aktuellen Abschnitt zur Meldung beachten ## Das könnte dich auch interessieren.. [**Benchmark für Software-Wartungskosten** Plane Kapazität für Security-Fixes, Dependencies, Observability und Support.](/de/blog/software-maintenance-cost-benchmark-dach-saas/) [**Wavect vs. Entwicklungsagenturen** Vergleiche Delivery-Modelle für compliance-kritische Software.](/de/compare/wavect-vs-dev-agencies/) AI-Governance und Regulierung ## Weiterlesen Security, Richtlinien, Compliance und Betriebskontrollen für verantwortungsvolle AI-Nutzung. [Hier starten**EU AI Act Kosten für Startups: Scope vor Budget**](/de/blog/eu-ai-act-compliance-cost-startup/) - [Anthropics Warnung vor selbstreplizierender KI: Was lokale KI gewinnt](/de/blog/anthropic-self-replicating-ai-local-inference/) - [EU-Produkthaftung: Evidenz-Checkliste für Software](/de/blog/eu-product-liability-software-evidence-2026/) - [AI Bill of Materials: CycloneDX vs. SPDX](/de/blog/ai-bill-of-materials-cyclonedx-spdx-2026/) - [Pseudonymisierungs-Gateway für LLMs: Verlässt der Prompt den DSGVO-Bereich?](/de/blog/llm-pseudonymization-gateway-gdpr-2026/) - [Semantica im Test 2026: Erklärt es jede Entscheidung eines KI-Agenten?](/de/blog/semantica-ai-agent-decision-provenance/) [Vorheriger Artikel**Anthropics Warnung vor selbstreplizierender KI: Was lokale KI gewinnt**](/de/blog/anthropic-self-replicating-ai-local-inference/) [Nächster Artikel**EU-Produkthaftung: Evidenz-Checkliste für Software**](/de/blog/eu-product-liability-software-evidence-2026/) [**Zurück**](/de/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/de/team/kevin-riedl/) [Kevin Riedl](/de/team/kevin-riedl/) https://linkedin.com/in/wsdt 9 Min Lesezeit · 24. August 2026 Zuletzt geprüft 5. Oktober 2026 [**Weiter**](/de/blog/eu-battery-passport-software-architecture-2027/)