Cyber Resilience Act: Seit dem 11. September läuft die 24-Stunden-Uhr

Am 11. September 2026 hat sich für Softwarehersteller in der EU etwas geändert, das viele noch nicht gemerkt haben: Seit diesem Tag gilt Artikel 14 des Cyber Resilience Act. Wer von einer aktiv ausgenutzten Schwachstelle in seinem Produkt erfährt, muss innerhalb von 24 Stunden eine Frühwarnung abgeben, innerhalb von 72 Stunden eine Meldung, und am Ende einen Abschlussbericht. Nicht ab Dezember 2027, wenn der Rest der Verordnung greift. Jetzt. Und nicht nur für neue Produkte, sondern für alles, was heute schon auf dem Markt ist.

Die Frist ist nicht das Problem. Das Problem ist, dass die meisten Betriebe eine aktiv ausgenutzte Schwachstelle in ihrem Produkt gar nicht innerhalb von 24 Stunden bemerken würden. Die Meldepflicht ist eine Architekturfrage, keine Formularfrage.

Vorweg, weil es in diesem Beitrag um eine Verordnung geht: Ich bin Architektin und Security Engineer, keine Juristin. Was hier steht, ist die technische Lesart der Verordnung (EU) 2024/2847 und dessen, was ENISA und die Fachpresse seit September dazu veröffentlicht haben. Ob und wie Ihr konkretes Produkt darunter fällt, gehört in eine Kanzlei. Was dieser Beitrag leisten kann: Ihnen zu zeigen, was technisch und organisatorisch stehen muss, damit Sie die Frist überhaupt einhalten können, falls sie Sie trifft.

Eine Frage vorab, die von der juristischen Einordnung unabhängig ist: Wissen Sie heute, welche Versionen Ihrer Software bei welchen Kunden laufen, welche Bibliotheken darin stecken und wen Sie am Wochenende erreichen müssen, wenn eine davon aktiv angegriffen wird? Wenn eine der drei Antworten „nicht sicher“ lautet, geht es im Rest dieses Beitrags genau darum.

Was seit dem 11. September gilt

Der Cyber Resilience Act ist am 10. Dezember 2024 in Kraft getreten und gilt in seiner Gesamtheit ab dem 11. Dezember 2027. Zwei Teile sind vorgezogen: Die Regeln für Konformitätsbewertungsstellen seit dem 11. Juni 2026, und die Meldepflichten der Hersteller nach Artikel 14 seit dem 11. September 2026. Und der entscheidende Satz steht in den Übergangsbestimmungen: Die Pflichten aus Artikel 14 gelten für alle Produkte im Anwendungsbereich, die vor dem 11. Dezember 2027 in Verkehr gebracht wurden. Eine wesentliche Änderung ist dafür nicht nötig. Auch ein Bestandsprodukt von 2019 kann seit September unter die Meldepflicht fallen, sofern es in den Anwendungsbereich des CRA fällt.

Gemeldet werden müssen zwei Arten von Ereignissen:

• Aktiv ausgenutzte Schwachstellen. Eine Schwachstelle, zu der verlässliche Nachweise vorliegen, dass ein böswilliger Akteur sie ohne Zustimmung des Systemeigners in einem System ausgenutzt hat. Nicht jede gefundene Lücke, nicht jeder Patch. Die Lücke, die jemand wirklich benutzt.
• Schwerwiegende Sicherheitsvorfälle mit Auswirkungen auf die Sicherheit des Produkts, also auf Verfügbarkeit, Authentizität, Integrität oder Vertraulichkeit. Was „schwerwiegend“ heißt, definiert Artikel 14 Absatz 5.

Gemeldet wird einmal, über die einheitliche Meldeplattform, die ENISA am 11. September in Betrieb genommen hat. Der Hersteller wählt dort das koordinierende CSIRT des Mitgliedstaats seiner Hauptniederlassung, für Betriebe mit Sitz in Deutschland das BSI. Von dort geht die Meldung an die CSIRTs der anderen Länder, in denen das Produkt erhältlich ist, und gleichzeitig an ENISA. Die Anmeldung läuft über ein EU-Login-Konto mit zweitem Faktor, pro Hersteller gibt es einen benannten Hauptvertreter und bis zu zwanzig weitere. Die erste Version der Plattform hat keine Schnittstelle, Meldungen werden im Browser eingetragen, auf Englisch, unter portal.cra-srp.enisa.europa.eu.

Ein Detail aus dieser ersten Version, das man kennen sollte: Die Plattform zeigt für die 72-Stunden-Meldung einen Zähler, der 48 Stunden nach dem Absenden der Frühwarnung abläuft, nicht 72 Stunden nach Kenntnisnahme. Wer die Frühwarnung spät in den ersten 24 Stunden abschickt, sieht die Meldung also als überfällig markiert, während die gesetzliche Frist noch läuft. ENISA schreibt in den FAQ zur Plattform, dass die Zähler nur der Übersicht dienen und die Fristen aus Artikel 14 nicht ersetzen, und dass eine spätere Version ab dem eingetragenen Zeitpunkt der Kenntnisnahme rechnen wird. Maßgeblich ist die Verordnung, nicht der Zähler. Aber wer sich nach dem Zähler richtet, ist auf der sicheren Seite.

Dazu kommt eine Pflicht, die in den Zusammenfassungen oft untergeht: Nach Artikel 14 Absatz 8 muss der Hersteller die betroffenen Nutzer über die Schwachstelle oder den Vorfall und über mögliche Gegenmaßnahmen informieren. Tut er das nicht, kann das CSIRT die Information selbst veröffentlichen. Das heißt: Sie brauchen nicht nur einen Weg zur Behörde, sondern auch einen Weg zu Ihren Kunden, und Sie müssen wissen, wer Ihre Kunden sind.

Wer Hersteller ist, und warum das mehr Betriebe trifft als gedacht

Die Verordnung gilt für Produkte mit digitalen Elementen, die auf dem Markt bereitgestellt werden und deren Verwendung eine direkte oder indirekte Datenverbindung umfasst. Software ist ein Produkt mit digitalen Elementen. „Bereitstellung auf dem Markt“ ist die entgeltliche oder unentgeltliche Abgabe zur Nutzung im Rahmen einer Geschäftstätigkeit. Hersteller ist, wer ein solches Produkt entwickelt oder entwickeln lässt und unter eigenem Namen oder eigener Marke vermarktet.

Daraus folgen drei Dinge, die in meinen Gesprächen regelmäßig überraschen:

• Die Stückzahl spielt keine Rolle. Die Verordnung kennt keine Schwelle, ab der etwas ein Produkt wird. Eine Branchensoftware mit dreißig Installationen ist genauso ein Produkt wie eine mit dreißigtausend.
• Auftragsentwicklung ist eine Grauzone, keine Freizone. Ob eine für einen einzelnen Kunden entwickelte Anwendung unter die Verordnung fällt, hängt daran, wer sie unter wessen Namen bereitstellt und ob sie Dritten zugänglich gemacht wird. Wer eine Anwendung entwickelt, die der Kunde dann unter seinem eigenen Namen an seine Kunden abgibt, hat die Herstellerfrage beim Kunden liegen, nicht gelöst. Das ist die Frage, die in die Kanzlei gehört, und zwar vor dem Ernstfall.
• Reine Cloud-Dienste sind draußen, ihre Produktteile nicht. Software, die ausschließlich als Dienst über das Internet genutzt wird, fällt als Dienstleistung nicht unter den CRA, sondern unter NIS2 und verwandte Regeln. Aber eine App, ein installierbarer Client oder ein Gerät, das ohne das zugehörige Backend eine seiner Funktionen nicht erfüllen kann, ist ein Produkt, und die Datenfernverarbeitung gehört dann zum Produkt dazu.

Für Verwalter quelloffener Software gilt ein leichteres Regime: Sie müssen melden, soweit sie an der Entwicklung beteiligt sind, Bußgelder treffen sie nicht. Und für Kleinst- und Kleinunternehmen gibt es eine einzige Erleichterung, die man kennen sollte, ohne sich darauf auszuruhen: Das Bußgeld für die Verletzung der 24-Stunden-Frist gilt für sie nicht. Die Pflicht gilt trotzdem, die 72-Stunden-Frist und der Abschlussbericht sind voll bußgeldbewehrt, und die Bußgelder für Verstöße gegen Artikel 13 und 14 reichen bis 15 Millionen Euro oder 2,5 Prozent des weltweiten Jahresumsatzes, je nachdem, was höher ist.

Die Uhr läuft ab Kenntnisnahme. Das ist der eigentliche Punkt.

Alle Fristen beginnen in dem Moment, in dem der Hersteller Kenntnis erlangt. Das klingt wie eine Erleichterung: Was man nicht weiß, muss man nicht melden. In der Praxis ist es das Gegenteil, aus zwei Gründen.

Erstens ist „Kenntnis“ keine Frage des Geschäftsführers, sondern der Organisation. Wenn ein Kunde am Freitagnachmittag an den Support schreibt, dass in seiner Installation fremde Daten aufgetaucht sind, und der Support das Ticket am Montag öffnet, dann ist die Frage, wann die Uhr angefangen hat zu laufen, keine, die Sie gewinnen wollen. Zweitens entsteht die Kenntnis bei einer aktiv ausgenutzten Schwachstelle fast nie dort, wo die Meldung herkommt. Sie entsteht in einem Log, in einem Crash-Report, in einer Mail eines Sicherheitsforschers, in einem Tweet, in einer Mitteilung eines Bibliotheksherstellers. Wer diese Kanäle nicht hat oder nicht liest, erfährt es von der Behörde oder aus der Presse, und dann ist die Frist nicht mehr das Thema.

Deshalb ist die Meldepflicht in erster Linie eine Frage an die Architektur und den Betrieb. Fünf Dinge müssen existieren, bevor die erste Meldung je nötig wird:

1. Ein Eingang für Schwachstellen

Eine Adresse, an die Sicherheitsforscher, Kunden und Partner eine Schwachstelle melden können, veröffentlicht und tatsächlich gelesen. Technisch ist das eine security.txt auf der Domain und eine Richtlinie zur koordinierten Offenlegung, die sagt, was mit einer Meldung passiert. Die Verordnung verlangt das ab Dezember 2027 ohnehin als Teil der Schwachstellenbehandlung. Für die Meldepflicht ist es die Voraussetzung, um überhaupt Kenntnis zu erlangen, bevor es jemand anders tut.

2. Wissen, was im Produkt steckt

Aktiv ausgenutzte Schwachstellen können auch in eingebundenen Bibliotheken und Komponenten stecken, nicht nur im eigenen Code. Wer nicht weiß, welche Version welcher Bibliothek in welchem ausgelieferten Stand steckt, kann die Mitteilung „Lücke in Komponente X wird aktiv ausgenutzt“ nicht in 24 Stunden in die Frage übersetzen, ob das eigene Produkt betroffen ist. Eine Stückliste der Software, eine SBOM, ist ab 2027 Pflicht. Für die Frist ist sie seit September nützlich, und sie muss pro ausgelieferter Version existieren, nicht nur für den aktuellen Hauptzweig. Eine SBOM kann schnell zeigen, ob eine betroffene Komponente enthalten ist. Sie beantwortet aber nicht automatisch, ob der verwundbare Codepfad erreichbar ist oder ob die Schwachstelle im konkreten Produkt ausnutzbar ist. Diese Bewertung braucht jemanden, der den Code und die Einsatzumgebung kennt, und der muss in den 24 Stunden erreichbar sein.

3. Logging, das die Frage beantwortet

Ob eine Schwachstelle im eigenen Produkt ausgenutzt wurde, lässt sich häufig erst durch die Kombination aus Logs, Telemetrie, Kundenmeldungen und externen Sicherheitsinformationen beurteilen. Ob die Ausnutzung „schwerwiegend“ war, beantworten dieselben Quellen. Welche Mitgliedstaaten betroffen sind, beantworten sie zusammen mit der Kundenliste. Alles, was im Beitrag über Forensic Readiness steht, gilt hier mit einer zusätzlichen Schärfe: Dort ging es darum, einen Vorfall überhaupt aufklären zu können. Hier geht es darum, ihn innerhalb von drei Tagen so weit aufgeklärt zu haben, dass eine erste Bewertung belastbar ist.

4. Eine Entscheidungskette mit Namen

Wer entscheidet, ob ein Ereignis meldepflichtig ist? Wer gibt die Frühwarnung ab, wer hat das EU-Login, wer ist der benannte Vertreter auf der Plattform, wer vertritt ihn im Urlaub? Diese Fragen klingen banal und sind es im Ernstfall nicht. Eine 24-Stunden-Frist über ein Wochenende hält nur, wenn die Antworten vorher aufgeschrieben sind und die Personen erreichbar. Die Registrierung auf der Plattform war vor dem 11. September nicht möglich. Wer sie noch nicht gemacht hat, sollte sie nicht am Tag der ersten Meldung beginnen.

5. Ein Weg zu den Nutzern

Artikel 14 Absatz 8 verlangt, dass betroffene Nutzer informiert werden. Das setzt voraus, dass Sie wissen, wer Ihr Produkt in welcher Version einsetzt, und dass Sie sie erreichen können, ohne drei Tage lang Adressen zusammenzusuchen. Für Hersteller mit Direktkunden ist das eine Liste. Für Hersteller mit Händlern und Integratoren ist es ein Vertrag, der regelt, wer wen informiert.

Die Triage: Was ist meldepflichtig, was nicht

Nicht jeder Fund ist eine Meldung. Die Verordnung meint die aktiv ausgenutzte Schwachstelle und den schwerwiegenden Vorfall, nicht die Lücke aus dem Scanner und nicht den Fehler, den ein Kunde gefunden hat, ohne ihn auszunutzen. Trotzdem braucht die Triage eine Regel, die vorher feststeht, weil die Entscheidung unter Zeitdruck und mit unvollständigen Informationen fällt. Was sich in meiner Praxis bewährt:

• Im Zweifel die Frühwarnung, aber der Zweifel braucht einen Anhaltspunkt. Bei konkreten Anhaltspunkten für eine Ausnutzung, etwa Logeinträgen, die zu einer bekannten Lücke passen, einer Kundenmeldung mit Spuren oder einer Warnung zu einer Komponente, die Sie ausliefern, wird sofort intern eskaliert und geprüft. Das ist die Regel für den Betrieb. Wann die gesetzliche Frist beginnt, richtet sich nach den Voraussetzungen des Artikels 14, also nach der Kenntnis von einem meldepflichtigen Ereignis, und diese Einordnung ist im Zweifel Sache der Kanzlei. Ein vager Verdacht ohne Anhaltspunkt löst keine Meldung aus, sondern eine Prüfung, und die muss schnell sein. Ist das Ereignis meldepflichtig, gilt: Die 24-Stunden-Meldung ist bewusst knapp gehalten: Es wird angegeben, dass es ein Ereignis gibt und welche Länder betroffen sind. Eine Frühwarnung, die sich in der 72-Stunden-Meldung als weniger schlimm herausstellt, kostet wenig. Eine verpasste Frist kostet mehr.
• Nachweis der Ausnutzung festhalten. Die Definition verlangt verlässliche Nachweise, dass ein böswilliger Akteur die Lücke ausgenutzt hat. Der Nachweis ist meist ein Logauszug, ein Ticket, ein Bericht eines Dritten. Er gehört in die Akte, mit Zeitstempel, denn er bestimmt den Beginn der Frist.
• Die Komponentenfrage trennen. Wenn die ausgenutzte Lücke in einer Bibliothek steckt, meldet deren Hersteller seine Ausnutzung. Ob Sie Ihr Produkt melden müssen, hängt daran, ob die Ausnutzung Ihr Produkt betrifft. Eine SBOM zeigt schnell, ob die betroffene Komponente enthalten ist. Ob die Schwachstelle im konkreten Produkt ausnutzbar ist, muss anschließend technisch bewertet werden.

Was das für Ihr Unternehmen bedeutet

Wenn Sie Software herstellen, egal ob Sie sich so nennen, ist die erste Aufgabe die Klärung, welche Ihrer Produkte unter die Verordnung fallen. Das ist Juristenarbeit, aber sie braucht eine technische Grundlage: eine Liste aller Produkte, Apps, Clients, Geräte und ihrer Backends, mit der Angabe, was ohne was nicht funktioniert. Die zweite Aufgabe ist die Registrierung auf der Meldeplattform und die Benennung der Personen. Die dritte sind die fünf Dinge oben, in der Reihenfolge Eingang, Stückliste, Logs, Entscheidungskette, Nutzerweg. Die meisten davon sind keine CRA-Projekte, sondern Dinge, die ein gepflegter Betrieb ohnehin braucht. Der CRA ist nur der Termin, der sie nach oben holt.

Wenn Sie Software einsetzen, ändert sich Ihre Position ebenfalls: Ihre Lieferanten sind seit September verpflichtet, Sie über aktiv ausgenutzte Schwachstellen zu informieren. Das ist ein Anspruch, den Sie in Ihre Verträge und Ihre eigene Vorfallsvorbereitung aufnehmen sollten. Und wenn Sie Software bei einem Dienstleister entwickeln lassen, die Sie dann unter Ihrem Namen an Dritte abgeben, ist die Herstellerrolle möglicherweise bei Ihnen, nicht beim Dienstleister. Diese Frage ist in meinen Projekten seit September die häufigste, und sie wird fast immer zu spät gestellt.

Der Beitrag über die Vorbereitung auf ein Security-Audit beschreibt, was Prüfer sehen wollen. Die Meldepflicht des CRA dreht die Perspektive: Hier gibt es keinen Prüfer, der vorher fragt. Es gibt nur die Uhr, die ab Kenntnisnahme läuft, und die Frage, ob Ihr Betrieb so gebaut ist, dass er Kenntnis erlangt, bevor jemand anders sie hat.

Quellen & weiterführende Belege

• Verordnung (EU) 2024/2847 (Cyber Resilience Act), ABl. L vom 20.11.2024: Artikel 2 (Anwendungsbereich), Artikel 3 (Begriffsbestimmungen, Nr. 42 „aktiv ausgenutzte Schwachstelle“), Artikel 14 (Meldepflichten, Fristen, Absatz 8 Nutzerinformation), Artikel 16 (einheitliche Meldeplattform), Artikel 64 (Geldbußen: Absatz 2 bis 15 Millionen Euro oder 2,5 Prozent für Verstöße gegen Anhang I sowie Artikel 13 und 14, Absatz 3 bis 10 Millionen Euro oder 2 Prozent für die übrigen Pflichten, Absatz 10 Ausnahmen), Artikel 69 Absatz 3 (Geltung von Artikel 14 für Bestandsprodukte), Artikel 71 (Geltungsbeginn 11.09.2026 für Artikel 14, 11.12.2027 gesamt).
• ENISA, CRA Single Reporting Platform (in Betrieb seit 11.09.2026): Factsheet zur einheitlichen Meldeplattform (September 2026) und FAQ unter enisa.europa.eu/cra-srp, Plattform selbst unter portal.cra-srp.enisa.europa.eu; FAQ Nr. 26 zum 72-Stunden-Zähler (Fälligkeit 48 Stunden nach der Frühwarnung, Umstellung auf den Zeitpunkt der Kenntnisnahme für eine spätere Version angekündigt); Anmeldung per EU Login, ein Hauptvertreter und bis zu zwanzig weitere Vertreter je Hersteller, Weiterleitung an koordinierendes CSIRT, weitere CSIRTs und ENISA.
• Delegierte Verordnung (EU) 2026/881: Bedingungen, unter denen die Weitergabe von Meldeinformationen nach Artikel 16 Absatz 2 aufgeschoben werden kann.
• NIS-2-Richtlinie (EU) 2022/2555, Artikel 6 Nr. 6: Definition „Sicherheitsvorfall“, auf die Artikel 3 Nr. 43 CRA verweist. Zum Verhältnis von NIS2-Meldung (Betreiber) und CRA-Meldung (Hersteller) siehe auch den Beitrag über Forensic Readiness.

Die Frage, ob individuell entwickelte Software für einen einzelnen Auftraggeber in den Anwendungsbereich fällt, ist in der Verordnung nicht ausdrücklich geregelt; die Europäische Kommission hat Leitlinien zum Anwendungsbereich in Konsultation gegeben. Beides gehört vor einer Entscheidung in die rechtliche Prüfung.

Carola Schulte

Software-Architektin und Network Security Engineer. Baut Systeme so, dass man im Ernstfall weiß, was los ist, bevor die Frist abläuft.

Beratung anfragen