Wer das lesen sollte: jedes Unternehmen, das Software, ein vernetztes Gerät oder ein Produkt mit Software darin auf den EU-Markt bringt. Wer Technik nur einsetzt statt sie auszuliefern, ist hier nicht gemeint.
Am 11. September 2026 tritt die erste harte Pflicht des Cyber Resilience Act in Kraft. Es ist eine Meldepflicht, sie läuft auf einer 24-Stunden-Uhr, und sie trifft Hersteller, nicht Nutzer.
Was die Pflicht tatsächlich ist
Ab dem 11. September 2026 müssen Hersteller von Produkten mit digitalen Elementen zwei Dinge melden:
- aktiv ausgenutzte Schwachstellen in ihrem Produkt
- schwerwiegende Sicherheitsvorfälle, die die Sicherheit ihres Produkts betreffen
Die Fristen sind kurz und bauen aufeinander auf:
| Stufe | Frist |
|---|---|
| Frühwarnung | 24 Stunden ab Kenntnis |
| Vollständige Meldung | 72 Stunden |
| Abschlussbericht, ausgenutzte Schwachstelle | spätestens 14 Tage nach Verfügbarkeit einer Abhilfemaßnahme |
| Abschlussbericht, schwerwiegender Vorfall | ein Monat |
Meldungen laufen über einen einzigen Kanal, die zentrale Meldeplattform des CRA, an das benannte CSIRT im Mitgliedstaat Ihrer Hauptniederlassung, und werden mit der ENISA geteilt. Dieses CSIRT verteilt anschließend an die übrigen CSIRTs der Länder, in denen das Produkt verfügbar ist. Die Plattform soll zum selben Datum betriebsbereit sein, an dem die Pflicht beginnt.
Der Rest des CRA, die wesentlichen Cybersicherheitsanforderungen, die Konformitätsbewertung und die CE-Kennzeichnung, gilt ab dem 11. Dezember 2027. Das gibt Ihnen fünfzehn Monate für die Produktanforderungen. Für die Meldung gibt es Ihnen keine Zeit.
Warum das Unternehmen überrascht
Drei Gründe, die zu nennen sind, weil jeder eine andere Art Fehler erzeugt.
Es ist eine Produktverordnung, keine Organisationsverordnung. NIS2 fragt, ob Ihr Unternehmen sicher ist. Der CRA fragt nach dem, was Sie anderen verkaufen. Ein Unternehmen kann vollständig außerhalb von NIS2 und mitten im CRA liegen, mit anderen Aufsichtsbehörden, anderen Pflichten und anderen Uhren.
„Produkt mit digitalen Elementen“ ist mehr als Software. Erfasst sind Software, Hardware mit Software darin und integrierte Datenfernverarbeitungslösungen. Ein vernetzter Sensor, eine Industriesteuerung, ein Router, eine eingebettete Firmware, eine als Produktbestandteil ausgelieferte SaaS-Komponente. Viele Unternehmen, die sich nicht als Softwareanbieter sehen, sind nach dieser Definition Hersteller.
Kenntnis startet die Uhr, und Kenntnis kontrollieren Sie nicht. Die 24 Stunden laufen ab dem Moment, in dem Sie Kenntnis erlangen, dass eine Schwachstelle in Ihrem Produkt aktiv ausgenutzt wird. Dieses Wissen kommt häufig von außen: von Forschenden, von Kunden, aus einer CERT-Meldung, aus einer öffentlichen Offenlegung. Beobachtet niemand bei Ihnen die Kanäle, über die es eintrifft, lief die Uhr bereits, als Sie es erfuhren.
Die zwei Dinge, die bis Freitag stehen sollten
Ein Schwachstellenmanagementprogramm bauen Sie nicht in zwei Tagen. Sie können die zwei Dinge einrichten, die aus einer versäumten Frist eine gehaltene machen.
1. Benennen Sie die Person und geben Sie ihr einen Weg. Jemand muss entscheiden dürfen, dass eine Meldung erforderlich ist, und sie einreichen dürfen, ohne auf eine Besprechung zu warten. In einem Unternehmen mit vierzig Beschäftigten ist das eine benannte Person und eine Vertretung. Schreiben Sie auf, wer das ist und wie sie außerhalb der Geschäftszeiten erreichbar sind. Das ist die günstigste Maßnahme auf dieser Seite und die am häufigsten fehlende.
2. Wissen Sie, wie Sie es erfahren würden. Wo kommt die Nachricht an. Eine Sicherheitskontaktadresse auf Ihrer Website, die jemand liest. Beobachtung der CVE-Feeds Ihrer Komponenten. Eine Beziehung zum CERT Ihrer Hauptniederlassung. Ein Weg für Kunden, Ihnen ein Problem zu melden, der nicht in einer allgemeinen Supportschlange eine Woche liegen bleibt.
Beim zweiten Punkt liegt das meiste Risiko, und der Grund gehört klar gesagt. Eine 24-Stunden-Uhr ist nicht schwer zu halten, wenn Sie in Stunde null Bescheid wissen. Sie ist unmöglich zu halten, wenn Sie es am neunten Tag erfahren.
Was in den Monaten danach zu bauen ist
Ist die unmittelbare Lücke geschlossen, ist die Arbeit, die das tragfähig macht, gewöhnlich und vertraut.
Eine Richtlinie zur koordinierten Offenlegung von Schwachstellen. Ein veröffentlichter Weg, auf dem Forschende und Kunden Ihnen melden können, mit einer Reaktionszusage. Das ist auch eine Erwartung unter NIS2, behandelt in dem NIS2 Rahmen zur Offenlegung von Schwachstellen.
Eine Softwarestückliste und die Gewohnheit, sie zu beobachten. Sie können nicht beurteilen, ob eine Schwachstelle Ihr Produkt betrifft, wenn Sie nicht wissen, was darin steckt. Die meisten CRA-relevanten Schwachstellen liegen in Komponenten, die Sie nicht geschrieben haben.
Ein Vorfallprozess, der einen Bericht erzeugt statt einer Diskussion. Die 72-Stunden-Meldung verlangt Konkretes. Während laufender Uhr zu entscheiden, was man sagt, ist die Art, wie Fristen reißen.
Nachweise, die sich ansammeln. Der Abschlussbericht und jede spätere Aufsicht fragen, was Sie wann wussten. Zeitnah erstellte Aufzeichnungen beantworten das. Nachträglich zusammengesuchte nicht, ein Argument aus Nachweise, die sich selbst sammeln.
Verkaufen Sie auch an regulierte Kunden, beachten Sie, dass sich diese Pflichten überlagern statt einander zu ersetzen. Ein Telekommunikationszulieferer kann für sein Produkt im CRA und zugleich in den NIS2 Lieferkettenpflichten seines Kunden stehen, beschrieben in Lieferkettensicherheit unter NIS2. Ein Luftfahrtzulieferer kann im CRA und zugleich in der Part-IS Schnittstellenbewertung seines Kunden stehen, beschrieben in was Part-IS für Zulieferer der Luftfahrt bedeutet. Die effiziente Antwort auf all das ist ein Maßnahmensatz, auf den die Rahmenwerke abgebildet werden, das Argument aus ISO 27001 und NIS2 einmal machen statt zweimal.
Was es nicht ist
Klar zu sagen, denn um dieses Datum ist viel Lärm.
Es ist nicht der vollständige CRA. Konformitätsbewertung, technische Dokumentation und CE-Kennzeichnung sind Themen für Dezember 2027, und dafür bleibt Zeit zur ordentlichen Planung.
Es ist keine Zertifizierung. Am Freitag wird nichts auditiert. Kein Zertifikat, kein Prüfer, kein System zum Beitreten.
Es geht nicht um Ihre interne IT-Sicherheit. Es geht um die Sicherheit dessen, was Sie ausliefern.
Und es gilt nicht für alle. Wer kein Produkt mit digitalen Elementen auf dem EU-Markt bereitstellt, ist nach dieser Verordnung kein Hersteller. Klären Sie, auf welcher Seite dieser Linie Sie stehen, bevor Sie Geld ausgeben, denn eine nennenswerte Zahl von Unternehmen wird den kommenden Monat damit verbringen, sich auf eine Pflicht vorzubereiten, die sie nicht trifft.
Die technische Realität: der Bericht ist die leichte Hälfte
Die Meldepflicht ist verfahrensmäßig. Eine Person benennen, die richtigen Kanäle beobachten, innerhalb des Fensters einreichen. Das ist in einer Woche machbar.
Die schwierigere Frage steht dahinter, und die Verordnung stellt sie nicht. Wenn Sie die 72-Stunden-Meldung einreichen, dass eine Schwachstelle in Ihrem Produkt aktiv ausgenutzt wird, lautet die nächste Frage jedes Kunden, wie lange sie da war und wie viele von ihnen betroffen sind. Das zu beantworten setzt ein Verzeichnis dessen voraus, was in Ihrem Produkt steckt, eine Aufzeichnung, welcher Kunde welche Version betreibt, und eine Möglichkeit zu wissen, was in Ihrer eigenen Umgebung geschehen ist.
Die Verordnung verlangt, zu melden, was Sie wissen. Sie sorgt nicht dafür, dass Sie etwas wissen. Unternehmen, die die Folgefrage beantworten können, haben diese Fähigkeit aus eigenen Gründen aufgebaut, und Unternehmen, die es nicht können, entdecken die Lücke öffentlich bei laufender Uhr. Ein strukturiertes Sicherheitsaudit ist ein vernünftiger Weg, vor Freitag statt nach einem Vorfall herauszufinden, welches von beidem zutrifft.
