Ab dem 11. September 2026 müssen Hersteller aktiv ausgenutzte Schwachstellen und schwerwiegende Vorfälle EU-weit melden — Frühwarnung binnen 24 Stunden, über die neue Single Reporting Platform (SRP) der ENISA. Wir machen Sie meldefähig, bevor die Uhr zum ersten Mal läuft.
Der Cyber Resilience Act gilt vollständig erst ab Dezember 2027 — doch die Meldepflichten nach Artikel 14 starten 15 Monate früher. Ab dem 11. September 2026 müssen Hersteller von Produkten mit digitalen Elementen zwei Ereignisarten melden: aktiv ausgenutzte Schwachstellen in ihren Produkten und schwerwiegende Vorfälle mit Auswirkungen auf die Produktsicherheit. Die Pflicht gilt produktbezogen — also auch für Produkte, die längst im Markt sind. Einen Bestandsschutz gibt es bei der Meldepflicht nicht.
Gemeldet wird über die Single Reporting Platform (SRP): eine zentrale, von der ENISA betriebene Meldeplattform, die jede Meldung automatisch an das zuständige nationale CSIRT, an die CSIRTs aller Mitgliedstaaten, in denen das Produkt bereitgestellt wird, und an die ENISA selbst verteilt — einmal melden statt bis zu 27-mal. Die Plattform geht am 11. September 2026 in Betrieb; die begleitenden Unterlagen (Factsheet, FAQ und User-Guides) hat die ENISA am 31. Juli 2026 veröffentlicht.
Alle Fristen laufen ab Kenntnis („becoming aware“) — nicht ab Behebung. Wochenenden zählen mit.
Innerhalb von 24 Stunden nach Kenntnis: Kurzmeldung an das koordinierende CSIRT und die ENISA — damit Warnungen andere Betreiber erreichen, bevor die Ausnutzungswelle rollt.
Innerhalb von 72 Stunden: allgemeine Informationen und eine erste Einschätzung — Schweregrad, Auswirkungen und, soweit bereits verfügbar, ergriffene Korrektur- oder Abhilfemaßnahmen.
Bei Schwachstellen spätestens 14 Tage nach Verfügbarkeit einer Korrekturmaßnahme, bei Vorfällen einen Monat nach der 72-Stunden-Meldung: Ursachen, Verlauf und Gegenmaßnahmen.
Zwei Meldetatbestände, ein Meldeweg: die Single Reporting Platform der ENISA.
Es liegen verlässliche Belege vor, dass ein Angreifer eine Schwachstelle in Ihrem Produkt ausgenutzt hat — unabhängig davon, ob der Versuch erfolgreich war. Belege können eigene Telemetrie, Hinweise von CSIRTs, Kunden oder Sicherheitsforschern sowie Einträge in Exploit-Katalogen sein.
Schwerwiegend ist ein Vorfall, wenn er die Fähigkeit des Produkts beeinträchtigt — oder beeinträchtigen kann —, sensible Daten und Funktionen zu schützen, oder wenn er zur Einschleusung bzw. Ausführung von Schadcode geführt hat oder führen kann. Das Potenzial genügt: kompromittierte Build-Server und Update-Kanäle sind der Paradefall.
Die SRP leitet Ihre Meldung an das als Koordinator benannte CSIRT, informiert gleichzeitig die ENISA und verteilt unverzüglich an die CSIRTs aller Mitgliedstaaten, in denen das Produkt bereitgestellt wird. Marktüberwachungsbehörden erhalten ausgewählte Informationen für ihre Aufsicht.
Die Plattform ist auf Vertraulichkeit ausgelegt. Eine Verzögerung der Weiterverteilung ist nur in begründeten Ausnahmen möglich — etwa bei unmittelbar bevorstehendem Patch — und liegt im Ermessen des CSIRT (Art. 16 Abs. 2 CRA, Delegierte Verordnung (EU) 2026/881). Ein Opt-out für Hersteller ist nicht vorgesehen.
Die Plattform selbst ist bewusst schlank gehalten — die eigentliche Vorbereitung liegt bei Ihnen.
Der Zugang zur SRP erfolgt mit einem EU-Login-Konto. Legen Sie Konten für mindestens zwei Personen an und regeln Sie Vertretungen — der Ernstfall hält sich nicht an Urlaubspläne.
Nach dem ersten Zugang validiert Ihr CSIRT die benannten Vertreter — laut ENISA-FAQ parallel zum Meldeprozess. Die Abgabe der Meldung wird dadurch nicht aufgehalten.
Nach ENISA-FAQ stellt die SRP zum Start keine Programmierschnittstelle bereit: Jede Meldung wird manuell im Webformular erfasst — in drei Stufen mit gemeinsamen sowie schwachstellen- bzw. vorfallspezifischen Feldern. Vorbereitete Textbausteine und ein Feld-Mapping sind Ihr Tempo-Hebel.
Nach einem Vorfall oder einer ausgenutzten Schwachstelle müssen Sie auch die betroffenen Nutzer unverzüglich informieren — einschließlich Risiko- und Abhilfeinformationen. Versäumen Sie das, kann das CSIRT Ihre Nutzer selbst informieren.
Die ENISA plant vor dem Start eine Testphase sowie ein Onboarding-Webinar rund zwei Wochen vor Inbetriebnahme. Nutzen Sie beides — mit vorbereiteten Meldepaketen wird der 11. September zum normalen Werktag.
CRA und NIS2 melden verschiedene Dinge an verschiedene Stellen. Ein Ereignis kann mehrere Meldepflichten zugleich auslösen.
Der Hersteller meldet aktiv ausgenutzte Schwachstellen und schwerwiegende Vorfälle, die das Produkt betreffen — über die SRP an CSIRT und ENISA, im Takt 24 h / 72 h / 14 Tage bzw. 1 Monat.
Betreiber wesentlicher und wichtiger Einrichtungen melden erhebliche Sicherheitsvorfälle ihrer Organisation über die nationalen Meldewege (in Deutschland: BSI) — im Takt 24 h / 72 h / 1 Monat.
Ransomware beim Software-Hersteller mit betroffenem Update-Server kann CRA-, NIS2- und DSGVO-Meldung zugleich auslösen — im Finanzsektor zusätzlich DORA. Die SRP nimmt Ihnen nur die CRA-Meldung ab: Bauen Sie eine Meldelandkarte mit einem gemeinsamen Prozess.
Sechs Schritte, mit denen die 24-Stunden-Frist zuverlässig haltbar wird.
Produktliste erstellen und die CRA-Betroffenheit je Produkt bewerten — Bestandsprodukte einbeziehen, denn die Meldepflicht kennt keinen Bestandsschutz.
Zuständiges CSIRT über die Hauptniederlassung herleiten (Art. 14 Abs. 7), EU-Login-Konten für mindestens zwei Personen anlegen und Vertretungsregeln festlegen.
Intern festlegen, wann „Kenntnis“ vorliegt, wer sie feststellt und wie der Zeitpunkt dokumentiert wird — er ist der Anker aller Fristen. Erreichbarkeit auch am Wochenende regeln.
Formularfelder der SRP auf interne Datenquellen mappen, Textbausteine für die 24-h- und 72-h-Meldung vorbereiten und Freigaben vorab einholen — keine Gremienschleifen im Ernstfall.
Tabletop-Übung mit realistischem Szenario gegen die Uhr — inklusive Nutzerkommunikation nach Art. 14 Abs. 8 und dem unbequemen Freitagabend-Fall.
Komponenten-Monitoring aufsetzen (u. a. EU-Schwachstellendatenbank EUVD, CISA KEV), die SBOM aktuell halten und Informationspflichten der Zulieferer vertraglich sichern.
Kompakte Antworten — auf Ihre konkreten Produkte gehen wir im Erstgespräch ein.
Ja. Die Meldepflicht nach Art. 14 gilt ab dem 11. September 2026 produktbezogen — also auch für Produkte, die bereits im Markt sind. Die übrigen CRA-Pflichten, etwa die CE-Kennzeichnung, greifen ab dem 11. Dezember 2027.
Mit Kenntnis („becoming aware“): sobald Ihr Unternehmen von der aktiven Ausnutzung oder dem schwerwiegenden Vorfall erfährt. Nicht erst mit der Behebung und nicht erst nach interner Freigabe — deshalb gehören Kenntnis-Trigger und Meldeprozess vorab definiert und dokumentiert.
Es liegen verlässliche Belege vor, dass ein Angreifer die Schwachstelle ohne Zustimmung des Systemeigentümers ausgenutzt hat oder es versucht hat — der Erfolg des Angriffs ist unerheblich (Art. 3 Nr. 42 CRA). Auch ein belastbarer Hinweis von außen, etwa durch ein CSIRT oder einen Kunden, kann die Frist auslösen.
Bei schwerwiegenden Vorfällen genügt bereits das Potenzial: Auch wenn der Vorfall die Schutzfähigkeit des Produkts nur beeinträchtigen kann oder die Ausführung von Schadcode möglich ist, liegt ein Meldefall vor (Art. 14 Abs. 5). Im Zweifel gilt: melden — eine Meldung ist kein Schuldeingeständnis.
Zum Start nicht. Laut ENISA-FAQ wird die SRP zunächst ohne Programmierschnittstelle betrieben — Meldungen werden manuell im Webformular erfasst. Umso wichtiger sind vorbereitete Textbausteine, ein Feld-Mapping auf Ihre internen Daten und geübte Abläufe.
Grundsätzlich das CSIRT des Mitgliedstaats, in dem Ihre Hauptniederlassung liegt — dort, wo die wesentlichen Cybersicherheitsentscheidungen für Ihre Produkte fallen (Art. 14 Abs. 7). Ohne EU-Niederlassung greift die Kaskade über Bevollmächtigten, Einführer und Händler. In Deutschland ist das BSI die zentrale Anlaufstelle; die offizielle CSIRT-Liste veröffentlicht die ENISA.
Bußgelder bis 15 Mio. Euro oder 2,5 % des weltweiten Jahresumsatzes — je nachdem, welcher Betrag höher ist — sowie marktaufsichtliche Maßnahmen bis hin zum Rückruf. Und: Informieren Sie betroffene Nutzer nicht selbst, kann das CSIRT dies übernehmen — dann ohne Ihre Tonalität.
Vom Readiness-Check bis zur geprobten 24-Stunden-Meldung — pragmatisch, produktnah, auditfest.
Produktportfolio, Betroffenheit und Lücken kompakt bewertet: Scope, Meldefähigkeit und Schwachstellenmanagement — mit priorisiertem Maßnahmenplan bis zum 11. September.
Kenntnis-Trigger, Rollen und Eskalationswege definieren, EU-Login-Zugänge und CSIRT-Zuordnung vorbereiten, Feld-Mapping und Textbausteine für 24-h- und 72-h-Meldungen erstellen.
Aufbau oder Schärfung Ihres Product-Security-Incident-Response-Teams: CVD-Richtlinie, Kontaktstelle für Meldungen, SBOM-Pflege und Exploit-Monitoring als belastbare Kenntnisquelle.
Wir proben den Ernstfall gegen die Uhr — inklusive 72-Stunden-Einschätzung, Abschlussbericht und Nutzerkommunikation nach Art. 14 Abs. 8. Danach kennt jede Rolle ihren Part.
Wenn es passiert: Unterstützung bei Bewertung, Eindämmung und fristgerechter Meldung — technisch und regulatorisch aus einer Hand.
Meldepflicht heute, Anhang-I-Anforderungen und Konformitätsbewertung morgen: Wir begleiten Sie durchgängig bis zur CE-Kennzeichnung — als Projekt oder als GRC as a Service.
Im unverbindlichen Erstgespräch klären wir, wo Ihr Portfolio steht, welche Lücken die 24-Stunden-Frist gefährden und wie Ihr Fahrplan bis zum 11. September aussieht.
