Die 24-Stunden-Uhr: Die Meldepflicht der Cyberresilienz-Verordnung gilt bereits

Am 11. September 2026 hat die ENISA ihre einheitliche Meldeplattform (Single Reporting Platform, SRP) unter portal.cra-srp.enisa.europa.eu (opens in new tab) freigeschaltet, und seitdem gilt Artikel 14 der Cyberresilienz-Verordnung (CRA) (Hogan Lovells, September 2026 (opens in new tab)). Seit jenem Morgen hat jeder Hersteller eines erfassten Produkts 24 Stunden Zeit, eine Frühwarnung abzusetzen, sobald er Kenntnis von einer aktiv ausgenutzten Schwachstelle in diesem Produkt erlangt. Das gilt auch für Produkte, die schon vor Jahren in Verkehr gebracht wurden.

Die meisten Engineering-Verantwortlichen, mit denen wir sprechen, haben den CRA noch unter „Dezember 2027“ abgelegt. Das ist der Termin für Konformitätsbewertung, CE-Kennzeichnung und die grundlegenden Anforderungen. Die Meldepflicht hat nicht so lange gewartet. Die KMU-Umfrage der ENISA aus Februar und März 2026 ergab, dass zwei Drittel der Befragten vom CRA gehört haben, aber nur 35 % eine Software Bill of Materials (SBOM) einsetzen. Und die ENISA warnt selbst, dass ihre freiwillige Stichprobe den Reifegrad vermutlich zu optimistisch abbildet (Zusammenfassung des ENISA SME CRA Survey Report auf der Digital Skills and Jobs Platform (opens in new tab)).

Unsere These: Das Formular auszufüllen ist der leichte Teil. Schwer sind Erkennung und Triage. Kommt Ihre Organisation verlässlich an den Punkt, an dem sie „Kenntnis“ hat, hält sie genau fest, wann das war, und schafft sie es, eine qualifizierte Person vor Ablauf der Frist auf die Meldeplattform zu bringen? Um 3 Uhr nachts an einem Sonntag, für ein Produkt, das seit 2022 niemand mehr angefasst hat? Und vor alledem müssen Sie wissen, welche Ihrer Produkte überhaupt erfasst sind. Ein reines Web-SaaS ist es meist nicht. Ihre Mobile App, Ihr Desktop-Agent, Ihr On-Prem-Installer oder Ihre Geräte-Firmware ist es, und das Backend, ohne das diese nicht funktionieren, ebenfalls.

Was seit dem 11. September gilt

Der Gesetzestext ist kurz. Artikel 14 der Verordnung (EU) 2024/2847 (opens in new tab) erlegt Herstellern zwei Meldepflichten auf:

• Aktiv ausgenutzte Schwachstellen. Die Verordnung definiert sie als Schwachstellen, für die es zuverlässige Belege gibt, dass ein böswilliger Akteur sie ohne Erlaubnis des Eigentümers in einem System ausgenutzt hat (Art. 3 Nr. 42). Ein Proof of Concept auf GitHub ist das nicht. Ausnutzung in freier Wildbahn schon.
• Schwerwiegende Sicherheitsvorfälle mit Auswirkungen auf die Sicherheit des Produkts. Ein Vorfall gilt als schwerwiegend, wenn er die Fähigkeit des Produkts beeinträchtigt oder beeinträchtigen könnte, die Verfügbarkeit, Authentizität, Integrität oder Vertraulichkeit sensibler oder wichtiger Daten oder Funktionen zu schützen, oder wenn er zur Ausführung von Schadcode im Produkt oder auf den Systemen eines Nutzers geführt hat oder führen könnte (Art. 14 Abs. 5). Ein kompromittierter Update-Server ist das Lehrbuchbeispiel.

Für beide gilt dieselbe Abfolge. Eine Frühwarnung innerhalb von 24 Stunden nach Kenntniserlangung. Eine ausführlichere Meldung innerhalb von 72 Stunden, die Art des Problems und etwaige Abhilfemaßnahmen beschreibt, einschließlich dessen, was Nutzer selbst tun können. Dann ein Abschlussbericht: bei Schwachstellen spätestens 14 Tage, nachdem eine Korrektur- oder Abhilfemaßnahme verfügbar ist; bei Vorfällen innerhalb eines Monats nach der 72-Stunden-Meldung. Die Meldungen laufen über die einheitliche Meldeplattform an das CSIRT, das im Mitgliedstaat Ihrer Hauptniederlassung als Koordinator benannt ist, und gleichzeitig an die ENISA (Art. 14 Abs. 1 bis 4 und 7). Nach Art. 14 Abs. 7 ist die Hauptniederlassung dort, wo die Entscheidungen über die Cybersicherheit Ihrer Produkte überwiegend getroffen werden. Für einen deutschen Hersteller ist das koordinierende CSIRT CERT-Bund beim BSI (opens in new tab).

Drei Details werden regelmäßig übersehen:

1. Bestandsprodukte sind erfasst. Nach Artikel 69 Abs. 3 gilt Artikel 14 für jedes erfasste Produkt, das vor dem 11. Dezember 2027 in Verkehr gebracht wurde, nicht nur für neue. Die Leitlinien der Kommission ergänzen, dass die Pflicht auch nach dem Ende des Unterstützungszeitraums eines Produkts fortbesteht (Hogan Lovells zu den finalen Leitlinien, Juli 2026 (opens in new tab)).
2. Auch die Nutzer müssen informiert werden. Artikel 14 Abs. 8 verpflichtet Sie, die betroffenen Nutzer und gegebenenfalls alle Nutzer zu informieren, zusammen mit den Abhilfemaßnahmen, die sie ergreifen können, „gegebenenfalls in einem strukturierten, maschinenlesbaren Format“. Wenn Sie schweigen, kann das CSIRT Ihre Nutzer selbst benachrichtigen.
3. Die Bußgelder. Verstöße gegen Artikel 14 können mit Geldbußen von bis zu 15 Mio. Euro oder 2,5 % des weltweiten Jahresumsatzes geahndet werden, je nachdem, welcher Betrag höher ist (Art. 64 Abs. 2). Kleinst- und Kleinunternehmen sind von Geldbußen speziell für die versäumte 24-Stunden-Frühwarnung ausgenommen (Art. 64 Abs. 10 Buchst. a). Ein typischer mittelständischer Hersteller ist mittelgroß oder größer, für ihn greift diese Ausnahme also nicht. Und die Pflicht selbst hebt sie ohnehin nicht auf.

Reines SaaS ist meist draußen. Ihre App, Ihr Agent und Ihre Firmware nicht.

Beim Anwendungsbereich liegen Teams in beide Richtungen falsch: Die einen halten den CRA für ein Hardware-Gesetz, die anderen glauben, jedes Cloud-Produkt sei erfasst.

Die Verordnung definiert ein Produkt mit digitalen Elementen als Software- oder Hardwareprodukt und dessen Datenfernverarbeitungslösungen (Art. 3 Nr. 1). Datenfernverarbeitung ist eine Verarbeitung aus der Ferne mit Software, die vom Hersteller oder unter seiner Verantwortung konzipiert und entwickelt wurde und ohne die das Produkt eine seiner Funktionen nicht erfüllen könnte (Art. 3 Nr. 2). Erwägungsgrund 12 stellt klar, dass Cloud-Dienste wie SaaS, PaaS und IaaS grundsätzlich unter NIS2 fallen und nicht unter den CRA, und dass Cloud-Dienste, die außerhalb der Verantwortung des Herstellers entwickelt wurden, nicht erfasst sind.

Die finalen Leitlinien der Kommission (opens in new tab) vom 27. Juli 2026 ziehen die Grenze schärfer. Wie Hogan Lovells (opens in new tab) zusammenfasst: Software, die entfernt läuft und auf die der Nutzer nur zugreift, typischerweise eine Webanwendung, die ausschließlich über den Browser genutzt wird, ist allein deshalb noch kein Produkt mit digitalen Elementen. Software, die dem Nutzer bereitgestellt und auf seiner Seite ausgeführt wird, dagegen schon: installierte Anwendungen, Browser-Erweiterungen und Apps, die mit Webtechnologien gebaut, aber zur lokalen Ausführung ausgeliefert werden.

Der Haken: Entfernt laufende Software gerät als Datenfernverarbeitungslösung (Remote Data Processing Solution, RDPS) wieder in den Anwendungsbereich, wenn ein anderes erfasstes Produkt sie zum Funktionieren braucht. Erwägungsgrund 11 nennt fast wörtlich das Beispiel, das auf die meisten mittelständischen Softwareanbieter zutrifft: eine Mobile App, die auf eine API oder Datenbank angewiesen ist, die von einem vom Hersteller entwickelten Dienst bereitgestellt wird. Dann ist dieser Dienst Teil des Produkts. Laut den Leitlinien umfasst das mindestens die Module, die für die Funktionalität des Produkts zuständig sind, und die Schnittstellen, die sie nutzen. Backend-Systeme für die nachgelagerte Verarbeitung, mit denen das Produkt nicht direkt kommuniziert, gehören nicht dazu.

In der Praxis ordnen sich die Produkte, die wir in mittelständischen Portfolios sehen, ungefähr so ein:

Produktform	Unsere Lesart
Reine Browser-Web-App, keine Client-Software	Grundsätzlich nicht vom CRA erfasst; als Anbieter kann für Sie NIS2 gelten
Mobile App (iOS/Android) plus eigene API	Erfasst; die API, von der sie abhängt, ist eine RDPS
Desktop-App, Electron-App oder „Sync-Agent“	Erfasst, dazu jedes Backend, das sie benötigt
On-Prem-Installer oder Docker-Image, das Sie an Kunden ausliefern	Erfasst
Firmware auf einem Gerät plus deren Cloud-Control-Plane	Erfasst, beides
Browser-Erweiterung als Begleiter Ihres SaaS	Erfasst, und sie kann einen Teil des SaaS mit hineinziehen

Die letzte Zeile ist die Falle. Viele SaaS-Unternehmen liefern eine kleine Client-Komponente aus: eine Companion-App, ein Outlook-Add-in, einen Scanner-Agenten, eine Druckerbrücke für ein Kassensystem. Diese Komponente ist ein Produkt, und das Backend, auf das sie angewiesen ist, kann zu ihrer Datenfernverarbeitungslösung werden. „Wir sind ein SaaS-Unternehmen“ ist keine Antwort auf die Frage nach dem Anwendungsbereich; eine schriftliche Einordnung Produkt für Produkt schon.

Schwer ist die „Kenntnis“, nicht das Formular

Jede Frist in Artikel 14 beginnt mit dem Zeitpunkt, zu dem der Hersteller Kenntnis erlangt. Wie Hogan Lovells (opens in new tab) zusammenfasst, liegt Kenntnis nach Lesart der Kommission vor, sobald der Hersteller mit hinreichender Sicherheit weiß, dass eine Schwachstelle in seinem Produkt aktiv ausgenutzt wird oder dass ein schwerwiegender Sicherheitsvorfall die Sicherheit des Produkts beeinträchtigt hat. Diese Lesart ist hilfreich und gefährlich zugleich.

Hilfreich, weil die Uhr nicht bei jedem Scanner-Alarm und jeder unverifizierten E-Mail an security@ zu laufen beginnt. Eine CVE in einer Bibliothek, die Sie ausliefern, ist für sich genommen noch kein Fall für Artikel 14. Die Leitlinien stellen klar, dass Sie bei Drittkomponenten nur melden müssen, wenn die Schwachstelle in Ihrem Produkt aktiv ausgenutzt wird. Ist der verwundbare Code nicht erreichbar oder hat ihn niemand ausgenutzt, ist keine Meldung nach Artikel 14 fällig, Ihr reguläres Schwachstellenmanagement gilt aber weiterhin (Rn. 217 bis 218 der Leitlinien, laut derselben Zusammenfassung). Außerdem bestätigen sie, dass Ausnutzungen, von denen Sie schon vor dem 11. September 2026 wussten, nicht rückwirkend gemeldet werden müssen.

Gefährlich, weil „Wir haben nie triagiert, also hatten wir nie Kenntnis“ nicht lange tragen wird. Wenn ein Kunde Ihrem Support am Freitag Log-Belege für eine Ausnutzung geschickt hat und das Ticket bis Dienstag liegen blieb, werden Sie kaum argumentieren können, die Kenntnis habe erst am Dienstag begonnen.

Das technische Problem lautet also nicht „das SRP-Formular in unter 24 Stunden ausfüllen“. Es lautet:

1. Jedes Signal, das auf eine Ausnutzung hindeuten könnte, landet an einer einzigen Eingangsstelle.
2. Eine qualifizierte Person sieht es sich innerhalb von Stunden an, nicht von Tagen.
3. Die Entscheidung „Das ist (oder ist nicht) eine Ausnutzung mit hinreichender Sicherheit“ wird mit Zeitstempel und Begründung festgehalten.
4. Wenn ja, geht die Frühwarnung mit dem raus, was bekannt ist, denn die 24-Stunden-Meldung ist bewusst als unvollständig angelegt.

Für die 24-Stunden-Frist verlangt die Verordnung sehr wenig: das Ereignis selbst und die Mitgliedstaaten, in denen das Produkt nach Ihrem Wissen bereitgestellt wird, bei Vorfällen zusätzlich, ob Sie böswillige Handlungen vermuten. Teams, die an der Frühwarnung feilen, reißen die Frist. Schicken Sie sie ab, und bauen Sie danach die 72-Stunden-Meldung.

Das Runbook

Das ist das Minimum, das wir für jedes erfasste Produkt einrichten würden. Nichts davon ist exotisch; das meiste ist liegengebliebene Grundlagenarbeit.

1. Produktinventar mit Scope-Entscheidungen

Jedes Produkt und jede Version, die auf dem EU-Markt in Verkehr gebracht wurde, eingestellte eingeschlossen, mit der rechtlichen Herstellereinheit, dem Support-Status, einer kurzen Begründung zum Anwendungsbereich, den Komponenten der Datenfernverarbeitung und einem verantwortlichen Engineering-Owner. Nach Lesart der Leitlinien können verschiedene Varianten eines Produkts eigenständige Produkte mit jeweils eigenem Datum des Inverkehrbringens sein. Erfassen Sie also Versionen und Varianten, nicht Marketingnamen. Ohne dieses Inventar beginnt Ihr 24-Stunden-Fenster mit einem Meeting darüber, wem eigentlich die Android-App von 2021 gehört.

2. SBOM pro ausgelieferter Version, abfragbar

Eine SBOM ist heute noch kein rechtlich geschuldetes Ergebnis; die Anforderungen aus Anhang I gelten ab Dezember 2027. Trotzdem ist sie der einzige praktikable Weg, die Frage „Liefern wir die Bibliothek aus, die gerade ausgenutzt wird?“ in Minuten zu beantworten. Erzeugen Sie CycloneDX oder SPDX in der CI für jedes Release-Artefakt, Mobile Builds und Firmware-Images eingeschlossen, und speichern Sie sie indiziert nach Produkt und Version. Die TR-03183 des BSI (opens in new tab) beschreibt in Teil 2, was eine gute SBOM enthält. Die Praxis hinkt weit hinterher: Eine Herstellerumfrage unter 505 Engineering-Fachleuten ergab, dass nur 25 % bei jedem Build automatisch SBOMs erzeugen und prüfen (SecurityBrief über Cloudsmith, April 2026 (opens in new tab)). Das ist Herstellerforschung zu Großunternehmen in den USA und Großbritannien, also mit Abschlag zu lesen, deckt sich aber mit dem, was wir sehen.

3. Detection-Feeds, die nach Ausnutzung suchen, nicht nur nach Existenz

Die meisten Tools für Schwachstellenmanagement sagen Ihnen, dass eine CVE existiert. Artikel 14 braucht Signale für Ausnutzung:

• Kataloge bekannter ausgenutzter Schwachstellen wie CISA KEV und die EU Vulnerability Database, automatisch mit Ihrem SBOM-Index abgeglichen.
• Ihre eigene Telemetrie: WAF- und API-Gateway-Logs der RDPS, Crash-Reports und Integritätsfehler aus App oder Firmware, Auffälligkeiten beim Zugriff auf den Update-Server.
• Meldungen von Kunden und Partnern über Support und Wiederverkäufer: der Kanal, der am ehesten echte Belege für eine Ausnutzung transportiert, und der, der am seltensten bei der Security ankommt.
• Eine veröffentlichte security.txt und eine Richtlinie zur koordinierten Offenlegung von Schwachstellen, damit Sicherheitsforscher wissen, wohin sie sich wenden können.

4. Eine Eingangsstelle, Triage mit Zeitstempel

Jedes Signal landet in einer einzigen Queue, die einen unveränderlichen „Eingegangen am“-Zeitstempel festhält. Die Triage ergänzt „Bewertet am“, die Entscheidung (meldepflichtige Ausnutzung, meldepflichtiger Vorfall, nicht meldepflichtig, weitere Daten nötig) und die Begründung, auch bei „nicht meldepflichtig“. Dieser Datensatz ist Ihr Nachweis dafür, wann die Kenntnis begann, und wann nicht.

5. Vorab festgelegte Schweregradkriterien

Übersetzen Sie den abstrakten Artikel 14 Abs. 5 in produktspezifische Auslöser. Für eine Außendienst-App: manipulierte Updates, Remote Code Execution, unberechtigter API-Zugriff auf Kundendaten. Für einen Kassen-Agenten: alles, was Zahlungsdaten berührt oder Code auf der Kasse ausführt. Ein einseitiger Entscheidungsbaum pro Produkt schlägt jede Debatte mitten im Vorfall.

6. On-Call mit jemandem, der entscheiden darf

Ein Engineer, der eine Ausnutzung bestätigen kann, reicht nicht. Die Rotation braucht eine namentlich benannte entscheidungsbefugte Person mit Stellvertretung, die zu jeder Uhrzeit eine Meldung freigeben kann. Zum SRP-Zugang: Die Plattform setzt ein EU-Login-Konto mit Multi-Faktor-Authentifizierung (opens in new tab) voraus, und die ENISA empfiehlt, sich erst dann als Assigned Representative zu registrieren, wenn Sie tatsächlich melden müssen. Die Validierung dieser Zuordnung durch das CSIRT läuft parallel und blockiert Ihre erste Meldung nicht. Legen Sie also jetzt die EU-Login-Konten mit MFA für Ihre primären und stellvertretenden Meldenden an, proben Sie den Registrierungsablauf anhand des ENISA-Benutzerhandbuchs, und halten Sie die Herstellerangaben zum Einfügen bereit.

7. Vorlagen für alle drei Meldestufen

Bereiten Sie Entwürfe für alle drei Stufen vor, abgebildet auf die SRP-Felder aus dem Glossar der ENISA. Füllen Sie vorab aus, was sich nie ändert: Herstelleridentität, Produktkennungen, die Mitgliedstaaten, in denen das jeweilige Produkt verkauft wird (aus den Vertriebsdaten, nicht aus dem Gedächtnis), und die Kontaktrollen. Meldungen bleiben bearbeitbar, bis sie geschlossen sind; nach dem Abschlussbericht sind sie schreibgeschützt. Dieser verdient deshalb eine Prüfung durch Engineering und Rechtsberatung.

8. Nutzerinformation als Release-Artefakt

Artikel 14 Abs. 8 ist die Pflicht, die Teams vergessen und die Nutzer tatsächlich wahrnehmen. Halten Sie pro Produkt eine Vorlage bereit, einen Kanal, den Sie kontrollieren (In-App-Nachricht, Portal, Admin-Verteiler), und idealerweise ein maschinenlesbares Advisory; CSAF ist das naheliegende Format. Die Leitlinien erlauben einen risikobasierten Ansatz: zuerst die betroffenen Nutzer informieren, statt Exploit-Details zu veröffentlichen, die die Lage verschlimmern.

Zielkonflikte, die wir offen benennen

Zu viel melden oder zu wenig. Eine niedrige Schwelle für „Kenntnis“ überschwemmt CERT-Bund und verschleißt Ihre Meldenden. Eine hohe riskiert ein Bußgeld und ein CSIRT, das Ihre Kunden vor Ihnen informiert. Wir tendieren zur Meldung, wenn die Belege für eine Ausnutzung glaubwürdig und spezifisch für Ihr Produkt sind, und andernfalls zur dokumentierten Nichtmeldung. Die schriftliche Begründung zählt mehr als jede einzelne Entscheidung.

Scope minimieren oder die Architektur ehrlich abbilden. Die Leitlinien lassen durchaus Spielraum: Nachgelagerte Verarbeitung, die Ihre App nicht direkt aufruft, ist draußen. Aber eine Grenze, die auf dem Papier gezogen wird statt entlang der tatsächlichen Abhängigkeiten, übersteht keine Nachfrage einer Marktüberwachungsbehörde. Ziehen Sie sie anhand Ihres Architekturdiagramms.

Eine Plattform kaufen oder vorhandene Tools verdrahten. Ein SBOM-Generator in der CI, ein Dienst zur Abhängigkeitsverfolgung, ein KEV-Feed, ein Tracker-Projekt mit Pflichtfeldern für Zeitstempel, eine Pager-Rotation und ein paar Vorlagen decken das meiste ab. Der teure Teil sind Inventar und Verantwortlichkeiten, und die liefert kein Tool.

Was wir nicht behaupten

Wir behaupten nicht, dass jedes SaaS-Unternehmen jetzt ein CRA-Problem hat; ein reines Browser-Produkt ohne ausgelieferten Client liegt grundsätzlich außerhalb. Sie brauchen auch nicht bis nächste Woche Ihr komplettes Programm für Dezember 2027.

Wir behaupten: Wenn Sie irgendetwas ausliefern, das auf der Seite Ihres Kunden läuft, ob App, Agent, Installer oder Firmware, tragen Sie seit dem 11. September eine scharfe 24-Stunden-Pflicht, auch für Ihre alten Releases. Auf die Probe gestellt wird sie, wenn zum ersten Mal jemand eines davon ausnutzt. Das Formular dauert zehn Minuten. Nachweisbar und rechtzeitig zu wissen, dass Sie Kenntnis haben, erfordert das Inventar, die SBOM, die Eingangsstelle und die On-Call-Rotation. Bauen Sie die zuerst.

Weiterführende Literatur

• Verordnung (EU) 2024/2847, die Cyberresilienz-Verordnung (EUR-Lex) (opens in new tab): Artikel 14 zu den Meldepflichten, Erwägungsgründe 11 und 12 sowie Artikel 3 Nr. 1 bis 2 zur Datenfernverarbeitung, Artikel 64 zu Bußgeldern, Artikel 69 Abs. 3 zu Bestandsprodukten.
• Europäische Kommission, Leitlinien zur Anwendung des CRA, C(2026) 5252 (27. Juli 2026) (opens in new tab): Anwendungsbereich, RDPS-Test, Auslegung der Meldepflichten, mit 67 durchgearbeiteten Beispielen.
• ENISA, Leitfaden zur CRA Single Reporting Platform (opens in new tab): Registrierung, Einreichung von Meldungen, die Liste der koordinierenden CSIRTs und das Benutzerhandbuch.
• BSI, Cyber Resilience Act (opens in new tab): die deutsche Sicht, die TR-03183 zu SBOMs und Schwachstellenmanagement sowie Links zur Meldeplattform.
• Hogan Lovells, European Commission publishes final CRA guidance (Juli 2026) (opens in new tab) (auf Englisch): eine klare Zusammenfassung mit Randnummern, was sich gegenüber dem Entwurf geändert hat.
• ENISA SME CRA Survey Report, Zusammenfassung (Juni 2026) (opens in new tab) (auf Englisch): Daten zum Reifegrad, einschließlich der Lücken bei SBOM und Schulung.