Technik verstehen / Erklärung

24 Stunden sind keine Reparaturfrist

Seit September müssen Hersteller bestimmte Cybervorfälle früh melden. Die Frist setzt eine Behördenmeldung in Gang, aber keinen allgemeinen Countdown bis zum fertigen Sicherheitsupdate.

Redaktionelles Datum:
5 Min. Lesezeit

In diesem Text
ABB. 01[ MELDUNG UND ABHILFE ]Industrieller Netzwerkcontroller zwischen einem Berichtsbogen mit Uhr und einem getrennten Ersatzmodul mit Handwerkzeug.
ABB. 01 Meldung und technische Abhilfe gehören zusammen, folgen aber eigenen Zeitpunkten. Redaktionelle Konzeptillustration.

Ein Hersteller vernetzter Steuerungen bekommt am Montagmorgen einen glaubwürdigen Hinweis: Eine Schwachstelle in einer ausgelieferten Geräteversion wird offenbar angegriffen. Jetzt laufen zwei Aufgaben nebeneinander. Das Team muss herausfinden, was betroffen ist und wie sich das Risiko begrenzen lässt. Zugleich muss der Hersteller prüfen, ob eine gesetzliche Meldepflicht greift und welche Frist gilt.

Seit dem 11. September 2026 verlangt der Cyber Resilience Act (CRA) von betroffenen Herstellern, aktiv ausgenutzte Schwachstellen und schwere Sicherheitsvorfälle zu melden. Die 24 Stunden aus der Schlagzeile beziehen sich auf eine frühe Behördenmeldung. Sie bedeuten nicht, dass innerhalb eines Tages ein fertiger Patch bereitstehen muss. Meldung, Abhilfe und Schlussbericht haben unterschiedliche Startpunkte.

Wer muss die Meldung abgeben?

Die Meldepflicht nach Artikel 14 richtet sich an den Hersteller eines Produkts mit digitalen Elementen. Gemeint ist grundsätzlich das Unternehmen, das ein Produkt entwickelt oder entwickeln lässt und es unter eigenem Namen oder eigener Marke auf dem EU-Markt anbietet. Ein Unternehmen, das die Maschine lediglich betreibt oder kauft, wird dadurch nicht zum Hersteller. Für Importeure, Händler und Open-Source-Software-Stewards gelten eigene Regeln.

Ob ein konkretes Produkt unter den CRA fällt, hängt unter anderem davon ab, ob es auf dem EU-Markt bereitgestellt wird und eine direkte oder indirekte Datenverbindung hat. Es gibt Ausnahmen und Überschneidungen mit besonderen Produktregeln. Bei einem Grenzfall müssen Rolle, Produkt und Rechtsgrundlage einzeln geprüft werden. Für die Meldepflicht ist außerdem wichtig: Auch ein Produkt, das schon vor dem 11. Dezember 2027 auf den Markt gekommen ist, kann erfasst sein. Artikel 69 Absatz 3 zieht die Meldepflicht für CRA-Produkte vor.

Nicht jeder Fehler ist ein meldepflichtiger Vorfall

Artikel 14 nennt zwei Auslöser. Eine aktiv ausgenutzte Schwachstelle liegt vor, wenn verlässliche Hinweise zeigen, dass jemand sie böswillig ausnutzt. Ein schwerer Sicherheitsvorfall muss erhebliche Auswirkungen auf die Sicherheit des Produkts haben. Ein gewöhnlicher Programmfehler, ein theoretischer Angriff oder ein unbestätigter Alarm erfüllt diese Beschreibung nicht automatisch.

Das heißt nicht, dass ein Team mit der Prüfung warten sollte, bis jeder technische Zusammenhang geklärt ist. Ein glaubwürdiger Hinweis braucht eine schnelle, dokumentierte Einordnung: Welche Produktversion ist betroffen? Was ist bekannt, was noch offen? Ab wann wusste der Hersteller, dass ein meldepflichtiges Ereignis vorliegt? Dieser Zeitpunkt ist für die ersten beiden Fristen entscheidend. Ein Käufer oder Betreiber kann Hinweise an den Hersteller geben; die Pflicht zur Meldung nach Artikel 14 liegt beim Hersteller.

Vier Fristen, zwei verschiedene Schlussberichte

Die Frühwarnung und die anschließende Hauptmeldung beziehen sich auf denselben Kenntniszeitpunkt. Für den Schlussbericht beginnt die Uhr dagegen jeweils bei einem anderen Ereignis.

Meldung Frist und Startpunkt
Frühwarnung Unverzüglich, spätestens 24 Stunden ab Kenntnis des Herstellers vom meldepflichtigen Ereignis.
Hauptmeldung Unverzüglich, spätestens 72 Stunden ab demselben Kenntniszeitpunkt.
Schlussbericht bei aktiv ausgenutzter Schwachstelle Spätestens 14 Tage, nachdem eine Korrektur- oder Abhilfemaßnahme verfügbar wird.
Schlussbericht bei schwerem Sicherheitsvorfall Innerhalb eines Monats ab Einreichung der 72-Stunden-Meldung.

Die Tabelle beschreibt Meldezeitpunkte, keine allgemeine Reparaturzusage. Eine Abhilfe kann parallel zur Meldung vorbereitet werden. Der CRA setzt für den Schlussbericht zur Schwachstelle einen eigenen Zeitpunkt, sobald eine Maßnahme verfügbar ist. Beim schweren Sicherheitsvorfall knüpft der Schlussbericht an die 72-Stunden-Meldung an. Wer alle Fristen als einen einzigen Countdown behandelt, kann den falschen Moment überwachen.

Die Plattform vereinfacht den Weg, nicht die Fristen

Hersteller reichen ihre Meldungen über die Single Reporting Platform (SRP) der EU-Agentur ENISA ein. Sie wählen dabei den zuständigen CSIRT-Koordinator, in der Regel im Mitgliedstaat ihrer Hauptniederlassung. Die Meldung wird an diese Stelle geleitet und an weitere zuständige Stellen verteilt. Die Plattform ersetzt weder die interne technische Reaktion noch die Verantwortung des Herstellers, seine Zeitpunkte und nächsten Schritte festzuhalten.

Ein Detail verdient besondere Aufmerksamkeit: In der von ENISA am 15. Oktober 2026 beschriebenen SRP-Version setzt der 72-Stunden-Zähler seine Erinnerungsfrist auf 48 Stunden nach Einreichung der Frühwarnung. Dadurch kann die Oberfläche eine Meldung als überfällig anzeigen, obwohl seit der Kenntnis des Herstellers noch keine 72 Stunden vergangen sind. ENISA beschreibt den Zähler als Orientierung für Erinnerungen, nicht als Ersatz für die gesetzliche Frist. Hersteller sollten deshalb den eigenen Kenntniszeitpunkt und ihre Fristen unabhängig dokumentieren. Oberflächen und Abläufe der SRP können sich ändern.

Meldung heute, weitere Produktpflichten später

Die Staffelung ist leicht zu verwechseln. Die Meldepflicht aus Artikel 14 gilt seit dem 11. September 2026. Die meisten übrigen CRA-Anforderungen, darunter die umfassenderen Pflichten zur Schwachstellenbehandlung, zu Sicherheitsupdates und zu Unterstützungszeiträumen, gelten ab dem 11. Dezember 2027. Für die erfassten Produkte ist grundsätzlich ein Supportzeitraum von mindestens fünf Jahren vorgesehen, außer die erwartete Nutzungsdauer des Produkts liegt darunter.

Der Meldebeginn verschiebt diese späteren Anforderungen nicht nach vorne. Umgekehrt bedeutet die spätere volle Anwendung nicht, dass bis Ende 2027 mit einer Meldung gewartet werden darf. Das sind zwei verschiedene Teile derselben Verordnung mit eigenen Anwendungsdaten.

SCHEMA / FRISTEN MIT VERSCHIEDENEM STARTPUNKT

AUSLÖSERDer Hersteller erkennt einen meldepflichtigen Fall
01 / FRÜHWARNUNG

Ab Kenntnis. Unverzüglich, spätestens nach 24 Stunden.

02 / HAUPTMELDUNG

Ab demselben Kenntniszeitpunkt. Unverzüglich, spätestens nach 72 Stunden.

AKTIV AUSGENUTZTE SCHWACHSTELLESchlussbericht spätestens 14 Tage, nachdem eine Abhilfe verfügbar wird.
SCHWERER SICHERHEITSVORFALLSchlussbericht innerhalb eines Monats ab der 72-Stunden-Meldung.
Die Fristen für Frühwarnung und Hauptmeldung beginnen mit der Kenntnis des Herstellers. Die beiden Schlussberichte knüpfen an andere Ereignisse an. Redaktionelles Schema.

Ein Bereitschaftsplan, bevor es klingelt

Ein Betrieb kann den Ernstfall nicht vollständig planen. Er kann aber verhindern, dass die erste Stunde mit der Suche nach Zuständigkeiten vergeht. Eine knappe Vorbereitung beginnt bei der Produktliste und führt bis zu einer belastbaren Zeitmarke.

  1. Rolle und Produkte klären: Festhalten, welche juristische Person das Produkt unter eigener Marke anbietet und welche Versionen noch im Markt sind.
  2. Hinweise zustellen: Eine erreichbare Kontaktadresse für Schwachstellen festlegen und Meldungen an eine Person weiterleiten, die eine technische Ersteinschätzung veranlassen kann.
  3. Kenntnis dokumentieren: Erfassen, wer wann welche belastbaren Informationen erhalten hat und wann die Herstellerorganisation ein meldepflichtiges Ereignis erkannt hat.
  4. Vertretung vorbereiten: Verantwortliche Personen für die SRP benennen, eine Vertretung einrichten und den passenden CSIRT-Koordinator vorab ermitteln.
  5. Fortschritt trennen: Frühwarnung, Hauptmeldung, technische Maßnahme, Nutzerinformation und Schlussbericht als eigene Aufgaben mit zuständiger Person nachhalten.

Damit wird ein Bericht nicht automatisch vollständig und ein Produkt nicht automatisch sicher. Es entsteht aber ein nachvollziehbarer Weg vom ersten belastbaren Hinweis bis zur Abhilfe. Die entscheidende Frage am Montagmorgen lautet dann nicht nur: „Wie schnell können wir patchen?“ Sondern auch: „Wer muss jetzt was wissen, welcher Zeitpunkt gilt und wer hält den nächsten Schritt fest?“

Quellen und Hinweise

Verordnung (EU) 2024/2847, insbesondere Artikel 13, 14, 16, 69 und 71 sowie Anhang I. Amtlicher Verordnungstext auf EUR-Lex.

Europäische Kommission, „Cyber Resilience Act – Reporting obligations“ und „Cyber Resilience Act – Summary of the legislative text“, abgerufen am 26. Oktober 2026. Europäische Kommission, FAQs zur Umsetzung des Cyber Resilience Act, Version 1.4 vom 4. September 2026. Europäische Kommission, Leitlinien zur Anwendung des Cyber Resilience Act, 27. Juli 2026, insbesondere Abschnitt 9.1; nicht verbindliche Auslegungshilfe.

ENISA, Informationen und häufig gestellte Fragen zur Single Reporting Platform, Stand 15. Oktober 2026; Plattform-Update Version 1.2.1 vom 20. Oktober 2026. Bundesamt für Sicherheit in der Informationstechnik (BSI), Überblick zum Cyber Resilience Act.

Rechtlicher Hinweis / Haftungsausschluss: Die Beiträge, Fallberichte, Interviews und Erläuterungen auf FreieTech dienen ausschließlich Informations-, Diskussions- und Bildungszwecken. Sie stellen keine individuelle Rechts-, Steuer-, Anlage-, Sicherheits- oder Unternehmensberatung dar und begründen kein vertragliches Beratungsverhältnis. FreieTech steht in keiner geschäftlichen oder gesellschaftsrechtlichen Verbindung zu den im Kontext genannten Unternehmen, Marken oder Behörden. Konkrete betriebliche Umsetzungen, Sicherheitsprüfungen und technische Nachrüstungen erfordern stets eine fachkundige Prüfung des jeweiligen Einzelfalls vor Ort.

Zum Autor

Dr. Jan-Frederik Menzel

Geboren 1982 in Aachen. Nach dem Diplomstudium der Informatik an der RWTH Aachen promovierte er im Bereich verteilte Automatisierungssysteme und industrielle Feldbusse. Er arbeitete über sieben Jahre als Systemarchitekt und technischer Berater für Sensor-Retrofit, Edge-Computing und OPC-UA-Integration im Sondermaschinenbau. Für FreieTech seziert er technische Versprechen, erklärt Softwarearchitekturen, Schnittstellen, Datensouveränität und Datensicherheitskonzepte verständlich, präzise und frei von Marketingjargon.

Zeichnung im Detail