Cyber Resilience Act: 24/72-Stunden-Meldeprozess ab September 2026

Alle Abbildungen in diesem Beitrag sind KI-generierte Symbolbilder. Sie zeigen keine reale Kundenimplementierung.

Stand: 25. August 2026. Dieser Beitrag ordnet die technische und betriebliche Vorbereitung ein. Er ersetzt weder eine rechtliche Prüfung des konkreten Produkts noch Rechtsberatung.

Kurze Antwort

Ab dem 11. September 2026 müssen Hersteller aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle melden, die ein Produkt mit digitalen Elementen betreffen. Die erste Warnung muss innerhalb von 24 Stunden nach Bekanntwerden, die vollständige Meldung innerhalb von 72 Stunden über die zentrale CRA Single Reporting Platform (SRP) erfolgen.

Der gesamte Cyber Resilience Act gilt damit noch nicht. Die meisten Produkt-, Konformitäts- und Dokumentationsanforderungen werden erst am 11. Dezember 2027 vollständig anwendbar. Die Meldepflicht kommt früher — und sie gilt nach der Zusammenfassung der Europäischen Kommission auch für relevante Produkte, die bereits vor diesem Datum auf dem EU-Markt bereitgestellt wurden.

Das macht den September-Termin vor allem zu einer Betriebsfrage: Erkennt das Team einen relevanten Fall rechtzeitig? Kann es Produkt, Versionen und betroffene Nutzer bestimmen? Sind Evidence, Entscheidung und Kommunikation nachvollziehbar? Und lässt sich eine Abhilfe kontrolliert ausrollen?

Die Fristen im Überblick

Hersteller melden einmal über die SRP. Die Meldung wird an das koordinierende CSIRT am Ort der Hauptniederlassung adressiert; die Plattform übernimmt den geregelten Informationsfluss zu ENISA und gegebenenfalls weiteren CSIRTs. Für Unternehmen mit deutscher Hauptniederlassung sollten die aktuellen Hinweise von ENISA und BSI vor dem Stichtag geprüft werden.

Die 24 Stunden sind keine „Arbeitsstunden“. Wochenenden, Feiertage und Abwesenheiten müssen im Prozess mitgedacht werden.

Vier Abgrenzungen, bevor Sie einen Prozess bauen

Nicht jede Schwachstelle ist sofort meldepflichtig

Artikel 14 unterscheidet zwei Auslöser:

1. eine aktiv ausgenutzte Schwachstelle im betroffenen Produkt; oder
2. einen schwerwiegenden Vorfall, der die Sicherheit des Produkts beeinträchtigt.

Eine bekannte, aber nach aktuellem Stand nicht aktiv ausgenutzte Schwachstelle gehört weiterhin in das reguläre Vulnerability- und Patch-Management. Ein schwerwiegender Sicherheitsvorfall kann dagegen auch ohne bereits bestätigte, aktiv ausgenutzte Produktlücke meldepflichtig sein. Ein Runbook, das nur nach „Exploit ja oder nein?“ fragt, ist deshalb unvollständig.

SaaS ist nicht pauschal ein- oder ausgeschlossen

Der CRA erfasst Produkte mit digitalen Elementen und bestimmte Remote Data Processing Solutions. Entscheidend ist unter anderem, ob die entfernte Verarbeitung vom Hersteller oder unter seiner Verantwortung entwickelt wurde und ob das Produkt ohne sie eine Funktion nicht ausführen könnte. Eine Cloud-Funktion, die zu einem vernetzten Produkt gehört, kann damit erfasst sein; eine unabhängige Website oder ein beliebiger externer Cloud-Dienst nicht automatisch.

Für ein reines SaaS-Angebot sollte der konkrete Scope anhand der aktuellen CRA-Leitlinien der Kommission rechtlich geprüft werden. Der technische Meldeprozess bleibt trotzdem sinnvoll: Kunden, Verträge und andere Regelwerke verlangen oft dieselben Fähigkeiten.

Open Source verschiebt die Produktverantwortung nicht einfach nach oben

Steckt die Lücke in einer integrierten Open-Source- oder Drittkomponente, muss der Hersteller prüfen, ob die Schwachstelle das eigene Produkt tatsächlich betrifft und aktiv ausgenutzt wird beziehungsweise einen schweren Vorfall verursacht hat. Nur „die Bibliothek steht in unserem Lockfile“ reicht für diese Schlussfolgerung nicht.

Ist das Produkt betroffen, bleibt die eigene Melde- und Abhilfefähigkeit relevant. Der CRA verlangt zudem, identifizierte Komponenten-Schwachstellen angemessen an Hersteller oder Maintainer der Komponente zurückzuspielen. Genau deshalb gehören Versionsbezug, Abhängigkeitsgraph und Komponenten-Owner in den Betrieb.

CRA und NIS2 beantworten unterschiedliche Fragen

Vereinfacht richtet sich der CRA an die Sicherheit von Produkten mit digitalen Elementen und deren Hersteller, während NIS2 die Cybersicherheits- und Meldepflichten bestimmter Einrichtungen regelt. Ein Unternehmen kann von einem, von beiden oder von keinem der beiden Regelwerke erfasst sein. Auch Meldeanlass, Empfänger, Fristen und Inhalt dürfen nicht aus einem NIS2-Runbook in den CRA-Prozess kopiert werden. Die organisatorische Perspektive haben wir separat in NIS2 aus Engineering-Sicht eingeordnet.

1. Produkt- und Verantwortungsinventar anlegen

Der Meldeprozess beginnt nicht mit einem Formular, sondern mit einer belastbaren Liste. Für jedes potenziell erfasste Produkt sollten mindestens dokumentiert sein:

• Produkt, Varianten und noch unterstützte Versionen;
• technische und rechtliche Herstellerrolle;
• technische Owner und Vertretung;
• Hauptniederlassung und zuständiger Meldeweg;
• EU-Mitgliedstaaten, in denen das Produkt bereitgestellt wurde;
• erreichbare Nutzer- und Kundenverteiler;
• Deployment-Modell: SaaS, App, On-Premise, Embedded oder SDK;
• kritische Drittkomponenten und deren Supportstatus.

Bei SaaS gibt es häufig nur eine produktive Version. Bei On-Premise-Produkten können mehrere Stände gleichzeitig im Feld sein. Ohne Installations- oder Entitlement-Daten ist dann weder die Betroffenheit noch die Nutzerinformation schnell bestimmbar.

2. „Bekanntwerden“ operativ behandeln — nicht umdefinieren

Die Frist knüpft an das Bekanntwerden an. Ein Unternehmen kann den rechtlichen Zeitpunkt nicht durch eine interne Regel beliebig nach hinten verschieben. Es kann aber definieren, wie Hinweise unverzüglich aufgenommen, verifiziert, eskaliert und dokumentiert werden.

Typische Eingangssignale sind:

• eine Meldung über security@ oder eine Vulnerability-Disclosure-Seite;
• ein Alert aus SIEM, Runtime Monitoring oder Error Tracking;
• ein Kundenbericht über verdächtiges Verhalten;
• ein Advisory zu einer tatsächlich eingesetzten Komponente;
• Hinweise auf unbefugten Zugriff, manipulierte Builds oder kompromittierte Signaturschlüssel.

Nicht jeder rohe Alert ist bereits hinreichend belastbare Kenntnis eines meldepflichtigen Ereignisses. Umgekehrt schützt ein ungelesenes Postfach nicht vor Fristbeginn. Praktisch wichtig ist daher eine dokumentierte Triage ohne vermeidbare Wartezeit: Wann ging der Hinweis ein? Wann lagen ausreichend verlässliche Informationen vor? Wer entschied mit welcher Begründung?

Die Frühwarnung ist bewusst nicht der fertige Forensikbericht. Fehlende Details können in den späteren Stufen ergänzt werden. Unsicherheit sollte deshalb dokumentiert und nicht als Grund genutzt werden, die erste Bewertung aufzuschieben.

3. Die ersten 72 Stunden als Runbook abbilden

Die folgenden Zeitfenster sind ein internes Arbeitsmodell, keine zusätzlichen gesetzlichen Fristen:

Stunde 0–2: Signal sichern und triagieren

• Eingang und Originalbeleg sichern;
• Incident- und Evidence-Owner benennen;
• Produkt, Herstellerrolle und mögliche Auswirkungen prüfen;
• zwischen aktiv ausgenutzter Schwachstelle und schwerem Sicherheitsvorfall unterscheiden;
• juristische und fachliche Eskalation auslösen, wenn der Scope unklar ist.

Stunde 2–8: Umfang und Sofortmaßnahme bestimmen

• betroffene Releases, Umgebungen und Nutzergruppen eingrenzen;
• Logs, Artefakte, Hashes und relevante Konfigurationen erhalten;
• verfügbare Mitigation prüfen: Feature Flag, Schlüsselrotation, Konfigurationsänderung, WAF-Regel oder kontrollierte Abschaltung;
• Kommunikations- und Meldeverantwortliche aktivieren.

Spätestens Stunde 24: Frühwarnung über die SRP

Die Frühwarnung enthält den zu diesem Zeitpunkt bekannten Sachstand. Ein klarer Marker „bestätigt / wahrscheinlich / noch unklar“ verhindert, dass Annahmen später wie Tatsachen gelesen werden.

Spätestens Stunde 72: vollständige Meldung

Bis dahin sollten Produktkontext, Art und Auswirkung, Bewertung, bekannte Angriffsindikatoren sowie ergriffene und geplante Korrektur- oder Abhilfemaßnahmen konsistent beschrieben sein. Die Nutzerkommunikation muss denselben Sachstand verwenden — ohne vertrauliche Angriffsdetails unnötig offenzulegen.

4. Vier Funktionen verbindlich besetzen

Auch ein kleines Team braucht vier Funktionen. Mehrere Funktionen dürfen bei einer Person liegen, aber jede benötigt einen Namen, eine Vertretung und erreichbare Kontaktdaten.

Ein Freigabemodell, das nachts zwingend auf eine einzelne nicht erreichbare Person wartet, ist kein Notfallprozess. Definieren Sie vorab, welche Maßnahmen innerhalb welcher Grenzen ohne Vorstandssitzung freigegeben werden dürfen.

5. SBOM, Release-Bezug und Komponenten-Owner verbinden

Eine SBOM ist nicht automatisch ein CRA-Meldeprozess. Sie wird wertvoll, wenn sie beantwortet: Welche konkrete ausgelieferte Version enthält welche Komponente?

Der CRA sieht für die ab Dezember 2027 geltenden Vulnerability-Handling-Anforderungen eine maschinenlesbare Software Bill of Materials vor, mindestens mit den direkten Abhängigkeiten. Das BSI konkretisiert das Thema in Teil 2 der Technischen Richtlinie TR-03183. Diese Richtlinie ist eine hilfreiche technische Referenz, ersetzt aber keine Prüfung der verbindlichen Anforderungen und künftigen Standards.

Ein einfacher Startpunkt in der CI kann beispielsweise so aussehen:

syft dir:. -o cyclonedx-json=sbom-$(git rev-parse --short HEAD).json

Entscheidend ist die Kette danach:

1. SBOM pro Build oder Release erzeugen;
2. unveränderbar mit Commit, Image-Digest und Release-ID archivieren;
3. gegen aktuelle Advisories auswerten;
4. Treffer gegen tatsächlich ausgelieferte Artefakte prüfen;
5. kritische Komponenten einem Owner und Supportstatus zuordnen.

Der Lieferkettenvorfall ChainDrop im August 2026 zeigte, wie Publish-Tokens, Entwicklungsumgebungen und voneinander abhängige Pakete einen Vorfall vervielfachen können. Für den eigenen Betrieb folgt daraus nicht „keine Open-Source-Pakete mehr“, sondern: Lockfiles, eingeschränkte Tokens, überprüfbare Builds, minimale Installationsrechte und eine nachvollziehbare Release-Herkunft.

6. Evidence muss den Geschäfts- und Releasezustand erklären

Ein Ordner mit Screenshots reicht selten. Der Abschlussbericht und die interne Nachbereitung brauchen eine belastbare Ereigniskette:

• initiales Signal und Zeitpunkt;
• bestätigte versus vermutete Fakten;
• betroffene Produktversionen und Umgebungen;
• sicherheitsrelevante Logs mit dokumentierter Zeitzone;
• Build-, Deployment- und Konfigurationsänderungen;
• Entscheidungen, Freigaben und verworfene Alternativen;
• versendete Meldungs- und Kommunikationsstände;
• Zeitpunkt, zu dem eine Korrektur- oder Abhilfemaßnahme verfügbar wurde.

Log-Retention, Zeitsynchronisierung und Zugriffsrechte sind dabei ebenso wichtig wie das Incident-Dokument. Werden relevante Logs während der Analyse rotiert oder überschrieben, lässt sich die Timeline später nicht zuverlässig rekonstruieren.

7. Patch, Mitigation und Rollback vor dem Ernstfall üben

Der CRA schreibt kein internes Zwei-Stunden-Deploymentziel vor. Ein Team sollte dennoch ein eigenes, risikobasiertes Ziel definieren und testen. Für manche Systeme ist eine Konfigurationsänderung in Minuten realistisch, für andere braucht ein sicherer Patch deutlich länger.

Ein belastbarer Notfallpfad umfasst:

• reproduzierbaren Build aus einem verifizierten Repository;
• minimale Tests der betroffenen und geschäftskritischen Pfade;
• kontrollierte Freigaberechte;
• Canary-, gestuftes oder segmentiertes Rollout, wo sinnvoll;
• Rollback oder Forward-Fix inklusive Datenbankänderungen;
• Schlüssel- und Credential-Rotation;
• klare Entscheidungskriterien für Abschaltung oder Feature-Deaktivierung.

Ein ungeprüfter „Emergency Deploy“-Shortcut, der Audit-Trail und Tests abschaltet, tauscht ein Sicherheitsproblem gegen ein zweites. Der Ausnahmeweg sollte schneller sein, aber nicht unsichtbar.

8. Nutzerinformation als eigenen Produktfluss vorbereiten

Nach Artikel 14 müssen betroffene Nutzer und, wo angemessen, weitere Nutzer über die Schwachstelle oder den Vorfall informiert werden; falls erforderlich auch über Maßnahmen, mit denen sie Auswirkungen mindern können. Die Behördenmeldung ersetzt diese Kommunikation nicht.

Bereiten Sie Vorlagen und Versandwege vor, ohne den späteren Inhalt vorzutäuschen. Eine gute Nutzerinformation trennt:

• was bestätigt ist;
• wer nach aktuellem Stand betroffen ist;
• welche Maßnahme der Hersteller bereits umgesetzt hat;
• was Nutzer jetzt selbst tun müssen;
• wann das nächste Update folgt;
• wo Rückfragen sicher gestellt werden können.

Für On-Premise-Produkte ist die Kontaktfähigkeit besonders kritisch. Der Hersteller kann den Patch nicht selbst ausrollen und muss deshalb wissen, welche Organisation welche Version betreibt und wer dort Sicherheitsupdates empfangen darf.

Wenn das ursprüngliche Entwicklungsteam nicht mehr da ist

Bei übernommener oder lange nicht gepflegter Software ist die Meldebereitschaft zuerst eine Frage der Kontrolle. Die sinnvolle Reihenfolge lautet:

1. Ownership verifizieren: Repository, Cloud, Domains, CI/CD, Secrets, Signaturschlüssel und Billing müssen unter kontrolliertem Zugriff stehen.
2. Produktzustand erfassen: laufende Versionen, Umgebungen, Abhängigkeiten, Datenflüsse und Kundeninstallationen dokumentieren.
3. Release und Recovery beweisen: selbst einen kleinen, reversiblen Release sowie Restore oder Rollback durchführen.
4. Monitoring und Eingangskanäle schließen: technische Signale und externe Meldungen müssen einen tatsächlich besetzten Prozess erreichen.
5. Erst dann Reaktionszusagen machen: ein SLA ohne verifizierten Zugriff und Releasepfad ist keine belastbare Zusage.

Eine erste Readiness-Baseline lässt sich schrittweise aufbauen. Wie lange das dauert, hängt weniger von der Zahl der Codezeilen als von Zugriffs-, Versions- und Betriebsunklarheiten ab.

Praktische Readiness-Checkliste

Vor dem 11. September 2026

• Produktliste, Herstellerrolle und möglicher CRA-Scope dokumentiert
• zuständiger SRP-/CSIRT-Meldeweg anhand aktueller ENISA- und BSI-Hinweise geprüft
• Primary und Secondary Representative für die SRP organisatorisch festgelegt
• security@ oder CVD-Kanal überwacht; Eskalation außerhalb der Geschäftszeiten getestet
• Triage-Kriterien für aktiv ausgenutzte Schwachstelle und schweren Vorfall getrennt
• Rollen, Vertretungen und Notfall-Freigaben benannt
• Nutzer- und Kundenverteiler je Produkt und Version verfügbar
• Incident-Timeline und Evidence-Ablage vorbereitet
• Notfall-Mitigation, Release und Rollback mindestens einmal geübt
• Vorlagen für Frühwarnung, Folgemeldung und Nutzerinformation vorbereitet

Als Brücke zu Dezember 2027

• SBOM pro Release erzeugt und mit Artefakten verknüpft
• direkte und kritische transitive Abhängigkeiten einem Owner zugeordnet
• End-of-Life-Komponenten mit Migrations- oder Ersatzentscheidung versehen
• Supportzeitraum je Produkt nachvollziehbar bestimmt
• koordinierte Vulnerability-Disclosure-Policy veröffentlicht
• Sicherheitsupdates technisch getrennt und ohne unnötige Verzögerung auslieferbar

FAQ

Gilt die Meldepflicht auch für ältere Produkte?

Nach der offiziellen CRA-Zusammenfassung gelten die Berichtspflichten für Produkte mit digitalen Elementen, die auf dem Unionsmarkt bereitgestellt wurden — einschließlich Produkten, die bereits vor dem 11. Dezember 2027 auf dem Markt waren. Ob ein konkretes Altprodukt noch erfasst ist und wer als Hersteller handelt, sollte rechtlich geprüft werden.

Müssen wir an BSI und ENISA zwei getrennte Meldungen senden?

Nein. Die Europäische Kommission beschreibt ausdrücklich eine einmalige Meldung über die CRA Single Reporting Platform. Die Plattform adressiert die Meldung an das koordinierende CSIRT und steuert die weitere Verteilung.

Was ist, wenn wir noch nicht alle Fakten kennen?

Die 24-Stunden-Stufe ist eine Frühwarnung. Ungeklärte Punkte sollten als solche markiert und später aktualisiert werden. Das Team sollte weder Spekulation als Fakt melden noch die Triage bis zur vollständigen Forensik aufschieben.

Gibt es eine Ausnahme für kleine Unternehmen?

Es gibt keine pauschale Befreiung kleiner Hersteller von der Meldepflicht. Die offizielle Zusammenfassung weist allerdings darauf hin, dass Kleinst- und kleine Unternehmen für das Verfehlen der 24-Stunden-Frist nicht mit einer Geldbuße belegt werden sollen; CSIRTs sollen außerdem Helpdesk-Unterstützung anbieten. Das ersetzt weder die Pflicht noch einen funktionsfähigen Prozess und sollte für den konkreten Fall rechtlich eingeordnet werden.

Beginnt der Fünf-Jahres-Support bereits im September 2026?

Die vollständigen Produkt- und Vulnerability-Handling-Anforderungen werden grundsätzlich ab 11. Dezember 2027 anwendbar. Der Supportzeitraum beträgt dann regelmäßig mindestens fünf Jahre, es sei denn, die erwartete Nutzungsdauer des Produkts ist kürzer; bei länger erwarteter Nutzung kann auch ein längerer Zeitraum erforderlich sein. „Fünf Jahre“ ist deshalb kein pauschaler Maximalwert.

Kann ein Dienstleister die Meldung und Reaktion übernehmen?

Operative Aufgaben wie Monitoring, Triage-Unterstützung, Evidence, Release und Vorbereitung der Meldung lassen sich unterstützen oder ausführen. Herstellerrolle und Verantwortung verschwinden dadurch nicht. Zuständigkeit, Freigaben und Informationszugriff müssen im Vertrag und im Runbook eindeutig sein.

Fazit

Die CRA-Meldepflicht verlangt nicht, dass nach 24 Stunden jede technische Frage gelöst ist. Sie verlangt, dass ein Hersteller relevante Signale erkennt, den Sachstand kontrolliert einordnet und fristgerecht melden kann. Dafür braucht es weniger ein neues Compliance-Dashboard als eine verlässliche Verbindung aus Produktinventar, Monitoring, Evidence, Releasefähigkeit und Nutzerkommunikation.

Wenn eine bestehende Plattform diese Grundlagen noch nicht besitzt, ist der beste erste Schritt kein Versprechen, sondern ein kleiner, überprüfbarer Readiness-Test: einen angenommenen Vorfall erkennen, betroffene Releases bestimmen, eine Meldung vorbereiten, einen reversiblen Fix ausrollen und die Timeline anschließend gegen die 24/72-Stunden-Fenster prüfen.

Wir unterstützen Teams dabei, bestehende Software kontrollierbar zu übernehmen und technisch betreibbar zu machen — von Plattform-Support und Wartung über DevOps und Cloud Engineering bis zum Backend- und Architektur-Review. Projekt besprechen →

Quellen

• Verordnung (EU) 2024/2847 — Cyber Resilience Act
• Europäische Kommission: CRA Reporting Obligations
• Europäische Kommission: Zusammenfassung des Cyber Resilience Act
• Europäische Kommission: CRA-Leitlinien vom 27. Juli 2026
• ENISA: CRA Single Reporting Platform
• BSI: Technische Richtlinie TR-03183
• Microsoft Threat Intelligence: ChainDrop supply chain compromise

Dieser Beitrag gibt allgemeine Hinweise zur technischen und betrieblichen Vorbereitung und ersetzt keine Rechtsberatung.