Cyber Resilience Act: die 24-Stunden-Meldepflicht ab 11. September 2026 – und wen sie wirklich trifft

Am 11. September 2026 beginnt die erste operative Pflicht aus dem Cyber Resilience Act: Wer ein Produkt mit digitalen Elementen in der EU auf den Markt bringt, muss aktiv ausgenutzte Schwachstellen binnen 24 Stunden melden. Die eigentliche Hürde ist nicht die Frist, sondern die Frage davor – nämlich ob man überhaupt gemeint ist. Sehr viele mittelständische Unternehmen beantworten diese Frage mit „wir sind doch kein Hersteller“, und liegen damit falsch. Wie wir bei Softwareprojekten unterstützen, die diese Anforderungen mittragen müssen, steht auf unserer Seite zur individuellen Softwareentwicklung.

Was am 11. September 2026 beginnt

Der Cyber Resilience Act – Verordnung (EU) 2024/2847 – gilt in weiten Teilen erst ab dem 11. Dezember 2027. Die Meldepflichten nach Artikel 14 sind vorgezogen und greifen bereits ab dem 11. September 2026. Gemeldet wird über die zentrale Plattform der EU-Agentur ENISA an das zuständige CSIRT, in Deutschland also im Zusammenspiel mit dem BSI.

Zwei Dinge lösen die Pflicht aus: eine aktiv ausgenutzte Schwachstelle im eigenen Produkt und ein schwerwiegender Sicherheitsvorfall, der die Sicherheit des Produkts beeinträchtigt. Die Meldung läuft dann in Stufen ab:

• 24 Stunden: Frühwarnung, sobald das Unternehmen Kenntnis erlangt. Sie darf knapp sein – entscheidend ist, dass sie überhaupt rechtzeitig herausgeht.
• 72 Stunden: die eigentliche Meldung mit Angaben zur Schwachstelle und zu bereits getroffenen Gegenmaßnahmen.
• 14 Tage bzw. ein Monat: der Abschlussbericht – 14 Tage nach Bereitstellung einer Korrekturmaßnahme bei Schwachstellen, spätestens ein Monat nach der Meldung bei Vorfällen.

Wer schon mit NIS2 zu tun hatte, erkennt die Kaskade wieder. Sie ist bewusst ähnlich gebaut, betrifft aber einen anderen Adressaten: NIS2 richtet sich an Betreiber und deren eigene Netz- und Informationssysteme, der CRA an denjenigen, der ein Produkt in Verkehr bringt. Ein Maschinenbauer kann beides sein – als Betreiber seiner eigenen IT und als Hersteller seiner Maschinen. Was das für die Registrierung beim BSI bedeutet, haben wir im Beitrag zur NIS2-Registrierung beschrieben.

24 Stunden sind keine technische Anforderung, sondern eine organisatorische. Die Frist läuft auch am Freitagabend – und sie setzt voraus, dass jemand im Haus überhaupt bemerkt, dass eine Schwachstelle ausgenutzt wird.

„Wir sind doch kein Hersteller“

Das ist der häufigste Irrtum, und er hält der Definition nicht stand. Als Hersteller gilt im Sinne des CRA, wer ein Produkt mit digitalen Elementen unter eigenem Namen oder eigener Marke in der EU auf den Markt bringt – oder ein bestehendes Produkt wesentlich verändert. Daraus folgt eine Reihe von Fällen, die im Mittelstand regelmäßig übersehen werden:

• Maschinen- und Anlagenbau. Sobald Steuerung, Bedienpanel oder Fernwartung Software enthalten, ist die Maschine ein Produkt mit digitalen Elementen. Das trifft praktisch jede moderne Anlage.
• Reine Softwareprodukte. Das BSI nennt hier ausdrücklich auch Buchhaltungssoftware und mobile Apps. Wer eine App kommerziell anbietet, ist Hersteller.
• Zugekaufte Entwicklung unter eigenem Namen. Wenn Sie Software extern entwickeln lassen und unter Ihrer Marke vertreiben, sind Sie der Hersteller – nicht das Entwicklungshaus. Diese Zuordnung überrascht in Projekten regelmäßig.
• Wesentliche Veränderung. Wer ein fremdes Produkt so umbaut, dass sich sein Risikoprofil ändert, tritt in die Herstellerpflichten ein.

Ausgenommen ist nicht-kommerziell bereitgestellte Open-Source-Software; für „Open-Source-Verwalter“ gelten abgemilderte Pflichten. Die Ausnahme greift allerdings nicht mehr, sobald Open-Source-Komponenten Teil eines kommerziell vertriebenen Produkts werden – dann verantwortet der Hersteller das Gesamtprodukt.

Was bis Mitte September realistisch machbar ist

Fünf Wochen reichen nicht für Konformität – sie müssen auch nicht dafür reichen, denn die inhaltlichen Anforderungen kommen erst Ende 2027. Bis September geht es allein um Meldefähigkeit. Realistisch sind vier Schritte.

Zuerst braucht es ein Inventar: Welche Produkte bringen wir mit digitalen Elementen in Verkehr, und welche Software steckt darin? Ohne diese Liste lässt sich keine der folgenden Fragen beantworten. Dann die Zuständigkeit – eine benannte Person mit Vertretung, denn eine 24-Stunden-Frist ohne Rufbereitschaft ist eine Fiktion. Drittens der Meldeweg: Zugang zur ENISA-Plattform klären und intern festhalten, wer meldet und wer entscheidet. Und schließlich die Erkennung: Es nützt kein Prozess, wenn niemand mitbekommt, dass eine Schwachstelle ausgenutzt wird. Dazu gehören ein erreichbarer Kanal für Sicherheitshinweise von außen und ein Blick darauf, welche Fremdkomponenten in den eigenen Produkten stecken.

Der eigentliche Termin ist Dezember 2027

Ab dem 11. Dezember 2027 dürfen nur noch Produkte in Verkehr gebracht werden, die die Sicherheitsanforderungen des CRA erfüllen – mit Konformitätsbewertung, technischer Dokumentation und CE-Kennzeichnung. Dazu kommt die Pflicht, Schwachstellen über einen Unterstützungszeitraum von mindestens fünf Jahren zu behandeln, oder über die gesamte Produktlebensdauer, wenn diese kürzer ist. Für Maschinen, die zehn Jahre und länger im Feld stehen, ist das eine neue Planungslogik: Sicherheitsupdates werden zur kalkulierten Betriebspflicht, nicht zur Kulanz.

Der Bußgeldrahmen unterstreicht das – bei Verstößen gegen die wesentlichen Anforderungen und die zentralen Hersteller- und Meldepflichten bis zu 15 Millionen Euro oder 2,5 Prozent des weltweiten Jahresumsatzes, je nachdem, was höher ist.

Praktisch heißt das: Was heute an Software entsteht, steht 2027 unter diesen Anforderungen. Nachweisbare Herkunft der Komponenten, Protokollierung, ein Update-Weg für ausgelieferte Geräte und dokumentierte Sicherheitsentscheidungen lassen sich schwer nachrüsten, wenn Architektur und Auslieferung darauf nicht ausgelegt sind. Wer jetzt entwickelt oder entwickeln lässt, trifft diese Entscheidungen bereits – bewusst oder nicht.

Fazit

Der 11. September 2026 ist kein Zertifizierungstermin, sondern ein Organisationstermin. Er verlangt keine konforme Produktpalette, sondern die Fähigkeit, innerhalb eines Tages zu reagieren und zu melden. Die dafür nötige Vorarbeit – wissen, welche Produkte man in Verkehr bringt, und wissen, wer nachts erreichbar ist – ist in fünf Wochen zu leisten. Die inhaltliche Arbeit für Dezember 2027 nicht, und deshalb sollte sie parallel beginnen. Wenn Sie einordnen wollen, ob Ihre Produkte unter den CRA fallen und was das für laufende Entwicklungsprojekte bedeutet, sprechen Sie uns an.

Weiterführende Quellen

• BSI – Cyber Resilience Act: Fristen, Pflichten, betroffene Produkte
• EUR-Lex – Verordnung (EU) 2024/2847 (Cyber Resilience Act)

Hinweis: Dieser Beitrag gibt den Stand vom 6. August 2026 wieder und dient der allgemeinen Information. Er ersetzt keine Rechtsberatung; ob und wie Ihr Unternehmen betroffen ist, sollte im Einzelfall geprüft werden.