In fünf Wochen wird der Cyber Resilience Act erstmals konkret. Ab dem 11. September 2026 gilt Artikel 14 der Verordnung (EU) 2024/2847: Hersteller von Produkten mit digitalen Elementen müssen aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle binnen 24 Stunden melden – über ein Jahr vor der vollständigen Anwendbarkeit des CRA am 11. Dezember 2027. Das Muster kennen wir von NIS2: Ein erheblicher Teil der Betroffenen weiß noch nicht, dass er gemeint ist.
Wer ist „Hersteller“? Breiter gefasst, als viele denken
Der CRA erfasst Produkte mit digitalen Elementen, die auf dem EU-Markt bereitgestellt werden – von der vernetzten Heizungssteuerung über industrielle Steuerungen bis zu reiner Software. Entscheidend sind drei Punkte, die in der Praxis regelmäßig übersehen werden.
Erstens: Die Meldepflicht gilt auch für Bestandsprodukte, die längst beim Kunden im Einsatz sind – nicht nur für Neuware ab dem Stichtag. Zweitens rücken auch Eigenmarkenanbieter und Unternehmen, die ein fremdes Produkt wesentlich verändern, in die Herstellerrolle (Art. 21 und 22 CRA). Wer zugekaufte Hardware unter eigenem Namen vertreibt oder fremde Software substanziell anpasst, trägt die Pflichten des Herstellers. Drittens ist die Grenze zu Diensten feiner, als es scheint: Reine Cloud-Dienste fallen unter NIS2 – Softwareprodukte und Produktkomponenten, auch wenn sie Teil eines SaaS-Angebots sind, können unter den CRA fallen. Ein Maschinenbauer mit Fernwartungsmodul, ein Softwarehaus mit On-Premises-Komponente, ein Systemhaus mit White-Label-Produkt: alle drei sollten ihre Rolle jetzt prüfen.
Was gemeldet werden muss – und was nicht
Die Pflicht ist enger, als die 24-Stunden-Schlagzeile vermuten lässt. Meldepflichtig sind aktiv ausgenutzte Schwachstellen – also solche, die ein Angreifer nachweislich gegen Nutzer eingesetzt hat – sowie schwerwiegende Vorfälle, die die Sicherheit des Produkts beeinträchtigen. Der gewöhnliche Bug, der reguläre Patch, die intern gefundene Schwachstelle ohne Ausnutzung: all das löst keine Meldepflicht nach Artikel 14 aus. Das entlastet – setzt aber voraus, dass ein Unternehmen die Unterscheidung im Ernstfall schnell und dokumentiert treffen kann. Genau dafür braucht es einen funktionierenden Triage-Prozess.
Drei Stufen, zwei Empfänger, eine Plattform
Das Meldeverfahren ist dreistufig: eine Frühwarnung binnen 24 Stunden ab Kenntnis, eine ausführlichere Meldung binnen 72 Stunden, und ein Abschlussbericht – bei Schwachstellen 14 Tage nach Verfügbarkeit einer Korrekturmaßnahme, bei schwerwiegenden Vorfällen spätestens einen Monat nach der 72-Stunden-Meldung. Jede Meldung geht gleichzeitig an das zuständige koordinierende CSIRT und an die ENISA, technisch über die zentrale Single Reporting Platform nach Artikel 16.
Zwei praktische Punkte verdienen Aufmerksamkeit. Die Plattform ist Stand heute noch nicht produktiv; die ENISA kündigt die Betriebsbereitschaft zum Stichtag an, mit einer Testphase davor. Hersteller sollten die Registrierungsmöglichkeit im Blick behalten und sie nutzen, sobald sie öffnet – die 24-Stunden-Uhr wartet nicht auf das Onboarding. Und: Welches CSIRT zuständig ist, richtet sich nach dem Mitgliedstaat, in dem die Cybersicherheitsentscheidungen für die Produkte überwiegend getroffen werden – für die meisten deutschen Hersteller ist das das BSI. Diese Zuordnung lässt sich heute klären, nicht erst im Ernstfall.
Drei Melderegime, ein Vorfall
Für viele Unternehmen kommt der CRA nicht allein. Verarbeitet das betroffene Produkt personenbezogene Daten, läuft parallel die 72-Stunden-Meldung nach Artikel 33 DSGVO an die Datenschutzaufsicht. Ist das Unternehmen selbst Einrichtung im Anwendungsbereich von NIS2, kommt die dortige Meldekette (24 Stunden / 72 Stunden / ein Monat) hinzu. Die Fristen überschneiden sich – Empfänger, Auslöser und Inhalte tun es nicht. Wer die drei Regime in einem einzigen Incident-Prozess mit allen Pflichtfeldern zusammenführt, verhindert, dass im Stress des Vorfalls eine Frist untergeht. Beruhigend immerhin: Artikel 17 Absatz 4 CRA stellt klar, dass die Meldung selbst keine erhöhte Haftung begründet.
Was bei Verstößen droht
Der Bußgeldrahmen für Verstöße gegen die Meldepflichten reicht nach Artikel 64 CRA bis zu 15 Millionen Euro oder 2,5 Prozent des weltweiten Jahresumsatzes. In Deutschland regelt ein Durchführungsgesetz die nationale Zuständigkeit; der Entwurf liegt dem Bundestag vor. Auf die Anwendbarkeit von Artikel 14 hat das keinen Einfluss – die Verordnung gilt unmittelbar.
Was jetzt zu tun ist
- Produktinventar erstellen: Welche Produkte mit digitalen Elementen sind am Markt – einschließlich Bestandsprodukten, Eigenmarken und wesentlich veränderter Fremdprodukte?
- Herstellerrolle klären: Je Produkt dokumentiert festhalten, ob und in welcher Rolle der CRA greift.
- Triage-Prozess aufsetzen: Wer entscheidet binnen Stunden, ob eine Schwachstelle „aktiv ausgenutzt“ ist? Nach welchen Kriterien, mit welcher Dokumentation?
- Meldeschablonen vorbereiten: Die Pflichtinhalte der drei Stufen als ausfüllfertige Vorlagen – im Ernstfall bleibt keine Zeit zum Formulieren.
- CSIRT-Zuordnung festlegen und die Registrierung auf der ENISA-Plattform vornehmen, sobald sie öffnet.
- Melderegime integrieren: CRA, DSGVO und gegebenenfalls NIS2 in einem Incident-Prozess zusammenführen.
- Ins ISMS einbetten: Ein bestehendes ISMS nach ISO 27001 liefert mit Incident Management und Schwachstellenbehandlung das Gerüst – die CRA-Pflichten sind dort Ergänzung, kein Neubau.
Fazit
Der 11. September ist kein Grund zur Hektik, aber ein hartes Datum: Ab dann zählt die Uhr in Stunden, und die Frage, ob man Hersteller im Sinne des CRA ist, sollte niemand erstmals während eines laufenden Angriffs beantworten. Die Vorbereitung ist überschaubar – Inventar, Rollenklärung, Triage, Schablonen – und zahlt vollständig auf die 2027 folgenden Produktanforderungen ein.
Für SaaS- und Softwareanbieter habe ich einen strukturierten CRA-GAP-Fragebogen entwickelt, der Betroffenheit und Handlungsbedarf systematisch erfasst – als Grundlage für eine prüfungsfeste Vorbereitung. Sprechen Sie mich an.