Was seit 11. September 2026 bereits gilt
Der Cyber Resilience Act – kurz CRA – ist nicht erst ein Thema für 2027. Zwar werden viele der umfassenden Produktanforderungen erst später vollständig anwendbar, die Meldepflichten für aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle gelten jedoch bereits seit dem 11. September 2026.
Die Europäische Kommission nennt dafür klare Fristen: Eine Frühwarnung muss grundsätzlich innerhalb von 24 Stunden nach Kenntnis erfolgen, eine ausführlichere Meldung innerhalb von 72 Stunden. Für aktiv ausgenutzte Schwachstellen ist anschließend ein Abschlussbericht spätestens 14 Tage nach Verfügbarkeit einer Korrektur- oder Minderungsmaßnahme vorgesehen; bei schwerwiegenden Vorfällen folgt der Abschlussbericht innerhalb eines Monats nach der 72-Stunden-Meldung.
Wer ist vom Cyber Resilience Act betroffen?
Im Mittelpunkt stehen Hersteller von Produkten mit digitalen Elementen, die solche Produkte auf dem EU-Markt bereitstellen. Das kann klassische Hardware betreffen, aber auch Software und vernetzte Produkte. Entscheidend ist nicht die Unternehmensgröße allein, sondern Rolle, Produkt und Bereitstellung im Markt.
Für viele mittelständische Unternehmen ist deshalb zunächst zu klären: Entwickeln oder vertreiben wir eigene Software? Integrieren wir Software in Maschinen oder Geräte? Bringen wir Produkte unter eigenem Namen auf den Markt? Welche externen Komponenten und Open-Source-Bestandteile stecken darin? Diese Rollenklärung ist Voraussetzung für jede weitere CRA-Planung.
Open-Source-Software-Stewards haben einen eigenen Zeitplan; deren entsprechende Berichtspflichten greifen nach den EU-Hinweisen ab dem 11. Dezember 2027. Die konkrete Einordnung eines Unternehmens oder Produkts sollte bei rechtlichen Zweifelsfragen mit geeigneter Rechtsberatung abgestimmt werden.
24 Stunden, 72 Stunden, Abschlussbericht: Die Fristen im Überblick
Frühwarnung innerhalb von 24 Stunden
Wird eine aktiv ausgenutzte Schwachstelle oder ein schwerwiegender Vorfall bekannt, beginnt die Uhr. Die Frühwarnung soll schnell informieren und muss noch nicht jede technische Einzelheit enthalten.
Vollständigerer Bericht innerhalb von 72 Stunden
Innerhalb von 72 Stunden werden zusätzliche Informationen erwartet – etwa zum betroffenen Produkt, zur Art der Schwachstelle beziehungsweise des Vorfalls und zu bereits ergriffenen Korrektur- oder Minderungsmaßnahmen.
Abschlussbericht
Bei aktiv ausgenutzten Schwachstellen ist der Abschlussbericht spätestens 14 Tage nach Verfügbarkeit einer Korrektur- oder Minderungsmaßnahme fällig. Bei schweren Sicherheitsvorfällen gilt ein Monatszeitraum nach der 72-Stunden-Meldung.
Die offiziellen Regeln und Fristen sind auf der Seite der EU-Kommission zu den CRA-Meldepflichten zusammengefasst.
Meldung über die ENISA Single Reporting Platform
Für die Meldungen wurde eine zentrale Single Reporting Platform (SRP) eingerichtet. Sie wird von ENISA betrieben und soll verhindern, dass Hersteller denselben Vorgang separat an zahlreiche Stellen melden müssen. Die Plattform ist seit 11. September 2026 für die verpflichtenden CRA-Meldungen in Betrieb.
Für Unternehmen ist wichtig, den Zugang nicht erst während eines laufenden Vorfalls zu organisieren. Verantwortliche Personen, EU-Login, Rollen, Stellvertretungen und interne Freigaben sollten vorher festgelegt und getestet werden. Informationen zur Nutzung stellt ENISA auf der Single Reporting Platform bereit.
Was der CRA in der IT-Praxis verändert
Die kurzen Fristen verändern vor allem die interne Geschwindigkeit. Ein Sicherheitshinweis darf nicht tagelang in einem persönlichen Postfach liegen. Ein Ticket darf nicht zwischen Entwicklung, IT und Geschäftsführung wandern, ohne dass klar ist, ob eine Meldepflicht geprüft wurde.
- Monitoring: Schwachstellen und Vorfälle müssen zuverlässig erkannt werden.
- Produktinventar: Das Unternehmen muss wissen, welche Versionen, Komponenten und Abhängigkeiten betroffen sein können.
- Bewertung: Technische Teams brauchen Kriterien, wann eine Schwachstelle als aktiv ausgenutzt beziehungsweise ein Vorfall als schwerwiegend betrachtet werden muss.
- Eskalation: Security, Entwicklung, Management und gegebenenfalls Recht/Compliance müssen definierte Wege haben.
- Kundenkommunikation: Korrekturmaßnahmen und Updates müssen schnell in eine verständliche Form gebracht werden.
Diese internen Prozesse sollten jetzt stehen
1. Verantwortlichkeit benennen
Eine Person oder Funktion sollte den CRA-Meldeprozess steuern. Dazu gehört eine Stellvertretung, damit Urlaub oder Krankheit keine Frist gefährdet.
2. Technische Erstbewertung definieren
Welche Informationen benötigt das Security- oder Entwicklungsteam in den ersten zwei Stunden? Produktversion, betroffene Komponente, bekannte Ausnutzung, erreichbare Systeme und mögliche Auswirkungen sollten schnell zusammengetragen werden können.
3. 24-Stunden-Prozess testen
Ein Tabletop-Test mit einem fiktiven Vorfall zeigt sehr schnell, ob Kontakte, Zuständigkeiten und Freigaben realistisch funktionieren.
4. Beweise und Entscheidungen dokumentieren
Nicht nur die Meldung selbst, sondern auch Zeitpunkte, technische Erkenntnisse, Risikobewertung und getroffene Maßnahmen sollten nachvollziehbar dokumentiert werden.
Software-Lieferkette und Abhängigkeiten werden wichtiger
Moderne Produkte bestehen selten ausschließlich aus eigenem Code. Bibliotheken, Firmware, Open-Source-Komponenten, Cloud-Dienste und Zuliefermodule können Teil des Produkts sein. Wird eine kritische Schwachstelle in einer Komponente bekannt, muss ein Hersteller schnell beantworten können, welche eigenen Produkte und Versionen betroffen sind.
Deshalb gewinnen Software-Stücklisten, Versionsinventare, Herstellerkontakte und automatisierte Schwachstelleninformationen an Bedeutung. Eine gute Lieferkettenübersicht verkürzt die Zeit zwischen „neue CVE bekannt“ und „wir wissen, ob wir betroffen sind“ erheblich.
Typische Fehler bei der CRA-Vorbereitung
- „Das betrifft nur große Hersteller“: Die Einordnung richtet sich nach Rolle und Produkt, nicht nur nach Mitarbeiterzahl.
- Nur eine juristische Richtlinie schreiben: Ohne technische Erkennung und operative Abläufe hilft das Dokument im Ernstfall wenig.
- Kein vollständiges Produktinventar: Wer Komponenten und Versionen nicht kennt, kann Betroffenheit nur langsam beurteilen.
- Meldezugang nicht testen: Konten, Rollen und Stellvertretungen gehören vor einem Vorfall geprüft.
- Lieferanten nicht einbinden: Zulieferer müssen Sicherheitsinformationen schnell und strukturiert bereitstellen können.
CRA-Schnellcheck für Unternehmen
- Ist geklärt, ob und für welche Produkte Ihr Unternehmen als Hersteller gilt?
- Existiert ein aktuelles Produkt-, Versions- und Komponentenverzeichnis?
- Ist definiert, wer eine mögliche Meldepflicht technisch und organisatorisch bewertet?
- Kann innerhalb von 24 Stunden eine belastbare Erstmeldung organisiert werden?
- Sind ENISA-SRP-Zugang, Stellvertretung und Freigabewege vorbereitet?
- Gibt es einen Prozess für Security Advisories, Updates und Kundeninformation?
- Wurde der Ablauf bereits mit einem realistischen Szenario getestet?
Fazit: CRA-Compliance beginnt bei funktionierenden IT- und Security-Prozessen
Seit 11. September 2026 ist der Cyber Resilience Act für betroffene Hersteller praktisch angekommen. Die Meldefristen zeigen, dass Schwachstellenmanagement, Incident Response, Produktinventar und Dokumentation enger zusammenarbeiten müssen.
büKOM Systemhaus GmbH unterstützt Unternehmen bei IT-Security, Schwachstellenmanagement, Monitoring, technischen Melde- und Eskalationsprozessen sowie der organisatorischen Vorbereitung. Die rechtliche Einordnung ersetzt das nicht – sie schafft aber die technische Basis, damit Vorgaben im Ernstfall überhaupt umgesetzt werden können.