Cyber Resilience Act: Seit 11. September müssen Hersteller Sicherheitsfälle melden

Seit dem 11. September 2026 gelten die CRA-Meldepflichten für betroffene Hersteller. Was deutsche KMU jetzt bei Zuständigkeiten, Fristen und Produkten prüfen sollten.

Die entscheidende Technologie-Nachricht dieser Woche ist für Softwarehäuser und Hersteller vernetzter Produkte kein neues KI-Modell: Ein bereits beschlossener Teil des Cyber Resilience Act wird praktisch verbindlich. Seit dem 11. September 2026 gilt Artikel 14 der Verordnung (EU) 2024/2847. Betroffene Hersteller müssen aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle mit Auswirkungen auf die Sicherheit ihrer Produkte melden. Die weitergehenden Produktanforderungen gelten grundsätzlich erst ab dem 11. Dezember 2027. Diese Termine auseinanderzuhalten ist wichtig: Eine Roadmap für 2027 ersetzt keinen heute funktionsfähigen Meldeprozess.

Quelle: EU-Kommission: Meldepflichten, CRA-Rechtstext, Artikel 71.

Quelle: EU-Kommission: CRA-Übersicht, CRA, Artikel 14 und 69.

1. Warum der Termin für den Mittelstand relevant ist

Der CRA betrifft nicht nur große Plattformanbieter. Sein Anwendungsbereich umfasst auf dem EU-Markt bereitgestellte Produkte mit digitalen Elementen, deren bestimmungsgemäße oder vernünftigerweise vorhersehbare Nutzung eine direkte oder indirekte Datenverbindung zu einem Gerät oder Netzwerk einschließt. Das können Hardware, eigenständig vertriebene Software und separat bereitgestellte Komponenten sein. Das BSI nennt ausdrücklich auch B2B-Software und Industriesysteme. Für die Erstprüfung empfehlen wir deshalb eine Produktliste statt einer Diskussion über die Größe der eigenen IT-Abteilung. Erfasst werden sollten Produktname, Vertriebsmodell, verantwortliche Gesellschaft, Markenname, Versionen und technische Abhängigkeiten. Auch bereits ausgelieferte Produkte gehören in diese Prüfung: Artikel 69 Absatz 3 erstreckt die Pflichten aus Artikel 14 ausdrücklich auf in den Anwendungsbereich fallende Produkte, die vor dem 11. Dezember 2027 in Verkehr gebracht wurden.

Quelle: BSI: Cyber Resilience Act, CRA, Artikel 2 und 69.

Drei Fragen für die erste Einordnung

• Entwickeln oder fertigen wir ein digitales Produkt selbst oder lassen wir es entwickeln und vermarkten es unter unserem Namen?
• Stellen wir es im Rahmen einer kommerziellen Tätigkeit auf dem EU-Markt bereit, und besteht die relevante Geräte- oder Netzwerkverbindung?
• Greifen besondere Ausnahmen oder sektorale Regelungen, die eine gesonderte rechtliche Prüfung verlangen?

Diese Fragen sind eine Arbeitsgrundlage, keine abschließende Rechtsprüfung. Insbesondere bei Eigenmarken, Auftragsentwicklung und Mischformen aus Gerät und Dienstleistung empfehlen wir eine dokumentierte Einordnung je Produkt statt eines pauschalen Urteils für das gesamte Unternehmen.

2. Cloud und KI: Nicht das Schlagwort entscheidet

Der CRA definiert auch zum Produkt gehörende Datenfernverarbeitungslösungen: Die betreffende Software muss vom Hersteller oder unter seiner Verantwortung entwickelt sein; ohne diese Verarbeitung könnte das Produkt eine seiner Funktionen nicht erfüllen. Daraus folgt keine pauschale Erfassung aller Cloud-Dienste. Ebenso wenig befreit das Etikett „Cloud“ ein Produkt automatisch. Bei KI-Produkten sollte die Prüfung daher an Produkt, Bereitstellung und Herstellerrolle ansetzen, nicht an der Frage, welches Modell eingebaut wurde. Die Ausnahme für freie und quelloffene Software außerhalb einer kommerziellen Tätigkeit ist ebenfalls kein allgemeiner Freibrief für jedes kommerzielle Produkt mit Open-Source-Komponenten. Für einen Betrieb, der lediglich einen externen KI-Assistenten verwendet, ergibt sich aus dieser Nutzung allein keine Herstellerrolle nach dem CRA.

Quelle: CRA, Artikel 2 und 3 sowie Erwägungsgründe 11–12 und 18, EU-Kommission: Anwendungsbereich und Begriffe.

Praktische Prüffälle, keine pauschalen Rechtsurteile

• Eigene Branchenanwendung: Prüfen Sie Vermarktung, technische Verbindung und Herstellerrolle, auch wenn die Entwicklung ausgelagert wurde.
• Vernetztes Gerät mit Cloud-Funktion: Dokumentieren Sie, welche Funktionen ohne das Backend ausfallen würden und wer dessen Entwicklung verantwortet.
• Interner KI-Assistent: Trennen Sie die Nutzung eines fremden Dienstes von der Bereitstellung eines eigenen digitalen Produkts.
• Kommerzielles Produkt mit offenen Bibliotheken: Prüfen Sie das Gesamtprodukt; die Lizenz einer einzelnen Bibliothek beantwortet die Herstellerfrage nicht.

3. Was tatsächlich gemeldet werden muss

Zwei Fälle sind zu unterscheiden. Erstens: Eine im Produkt enthaltene Schwachstelle wird aktiv ausgenutzt und der Hersteller erlangt davon Kenntnis. Der CRA verlangt verlässliche Anhaltspunkte für eine Ausnutzung durch einen böswilligen Akteur ohne Erlaubnis des Systemeigentümers. Ein Scannerfund oder eine Meldung aus einem autorisierten Test ist deshalb nicht automatisch eine Pflichtmeldung. Zweitens: Ein schwerwiegender Vorfall wirkt sich auf die Produktsicherheit aus. Artikel 14 Absatz 5 erfasst unter anderem Vorfälle, die den Schutz sensibler oder wichtiger Daten beziehungsweise Funktionen beeinträchtigen oder beeinträchtigen können. Auch die mögliche Einschleusung oder Ausführung schädlichen Codes gehört zu den Kriterien. Für diesen zweiten Meldegrund muss nicht zusätzlich auf einen vollständig belegten Angriff auf eine einzelne Schwachstelle gewartet werden.

Quelle: CRA, Artikel 3 und 14, Brightsight: Einordnung zum Meldebeginn vom 11. September.

Unsere Empfehlung für die technische Triage

• Produkt und betroffene Versionen identifizieren, ohne den Eingangshinweis vorschnell als irrelevant abzulegen.
• Belege für tatsächliche Ausnutzung von Vermutungen, Testbefunden und allgemeinen Warnungen trennen.
• Den eigenständigen Tatbestand eines schwerwiegenden Vorfalls gesondert prüfen.
• Zeitpunkt der Kenntnis, Entscheidungsgrundlage, offene Fragen und nächste Neubewertung festhalten.
• Einen Nicht-Meldeentscheid begründen und bei neuen Erkenntnissen erneut bewerten.

4. Die Fristen: Drei Stufen, zwei unterschiedliche Abschlüsse

Die ersten beiden Fristen laufen jeweils ab Kenntnis des Herstellers, nicht nacheinander. Die Frühwarnung ist unverzüglich und spätestens binnen 24 Stunden abzugeben; die weitergehende Meldung folgt ebenfalls unverzüglich und spätestens binnen 72 Stunden ab Kenntnis, soweit die Informationen nicht bereits übermittelt wurden. Für Schwachstellen ist der Abschlussbericht spätestens 14 Tage nach Verfügbarkeit einer Korrektur- oder Abhilfemaßnahme vorgesehen. Bei schwerwiegenden Vorfällen ist er innerhalb eines Monats nach Übermittlung der Vorfallsmeldung der zweiten Stufe einzureichen. Eine interne Freigaberunde sollte deshalb nicht darauf angelegt sein, erst eine vollständige Ursachenanalyse abzuwarten. Die gestufte Meldung erlaubt ausdrücklich, zunächst mit den verfügbaren Informationen zu arbeiten.

Quelle: CRA, Artikel 14 Absätze 2 und 4, EU-Kommission: Meldefristen.

5. Meldeweg und Kundeninformation zusammen vorbereiten

Der vorgesehene gemeinsame Meldeweg ist die von ENISA eingerichtete Single Reporting Platform, kurz SRP. Die Meldungen richten sich an das zuständige koordinierende CSIRT und ENISA; Artikel 14 regelt die Zuordnung anhand der Hauptniederlassung und weitere Fälle. ENISA veröffentlicht Anleitungen für Registrierung, Rollen sowie Übermittlung und Aktualisierung von Meldungen. Zusätzlich verpflichtet Artikel 14 Absatz 8 den Hersteller zur Information betroffener und gegebenenfalls aller Nutzer über die Schwachstelle oder den Vorfall sowie erforderlichenfalls über geeignete Maßnahmen. Die Behördenmeldung ist daher nicht mit einer vollständigen Kundenkommunikation gleichzusetzen. Dieser Beitrag bestätigt keinen eigenen Test des geschützten Meldeportals; für den tatsächlichen Zugang sind die jeweils aktuellen offiziellen Anleitungen maßgeblich.

Quelle: ENISA: Single Reporting Platform und Benutzerleitfäden, CRA, Artikel 14 Absätze 7–8 und Artikel 16.

Ein schlankes Rollenmodell als Umsetzungsvorschlag

• Technische Leitung: Bewertet Produktauswirkung, Versionen und Gegenmaßnahmen.
• Meldeverantwortung mit Vertretung: Führt Fristen, pflegt Meldungen und dokumentiert Empfangsnachweise.
• Rechtliche Ansprechperson: Unterstützt bei Grenzfällen und bei der Abgrenzung weiterer Pflichten.
• Kundenkommunikation: Erstellt verständliche Hinweise zu Auswirkungen und Schutzmaßnahmen.
• Geschäftsführung: Gibt den Prozess und erforderliche Ressourcen frei, ohne jede Erstmeldung von einer spontanen Sitzung abhängig zu machen.

6. Ein fiktiver Vorfall als Belastungstest

Stellen Sie sich als Übung ein Softwarehaus vor, dessen Kunde einen unberechtigten Zugriff auf eine ausgelieferte Anwendung meldet. Der Support eröffnet ein Ticket; die Entwicklung bestätigt Hinweise auf die Ausnutzung einer Authentifizierungsschwäche. Unsere Empfehlung ist, bereits beim Eingang eine verantwortliche Person einzubeziehen, die Zeitpunkte zu dokumentieren und die rechtliche Bewertung nicht in einer allgemeinen Fehlerliste verschwinden zu lassen. Sobald die einschlägige Kenntnis vorliegt, werden die gesetzlichen Fristen verfolgt. Parallel sollten betroffene Versionen eingegrenzt, Beweise gesichert und mögliche Schutzmaßnahmen geprüft werden. Der Übungserfolg bemisst sich nicht an einer besonders langen Präsentation, sondern daran, ob das Team eine belastbare Frühwarnung und eine abgestimmte Nutzerinformation rechtzeitig vorbereiten kann.

Prüffragen für die Übung

• Erreicht der Hinweis auch bei Urlaub oder Krankheit eine handlungsfähige Vertretung?
• Ist erkennbar, welche Informationen gesichert und welche lediglich vermutet sind?
• Kann das Team die betroffenen Releases mit Kunden und Komponenten verknüpfen?
• Sind Zugang, Zuständigkeit und Übermittlungsnachweis für den Meldeweg geklärt?
• Werden technische Abhilfe, Behördenmeldung und Kundeninformation gleichzeitig organisiert?

Das Beispiel ist frei konstruiert und beschreibt keinen tatsächlichen Sicherheitsvorfall. Die Ablaufempfehlungen sind unsere betriebliche Einordnung; die gesetzlichen Fristen ergeben sich aus den oben verlinkten Primärquellen.

7. KI sinnvoll einsetzen, Entscheidungen nicht delegieren

Für den eigenen Meldeprozess empfehlen wir einen begrenzten KI-Einsatz: Ein Assistent darf freigegebene Informationen sortieren, einen Entwurf strukturieren oder fehlende Felder markieren. Er sollte aber weder den Kenntniszeitpunkt eigenständig festlegen noch einen Fall ohne menschliche Prüfung als nicht meldepflichtig schließen. Geben Sie ihm keine unkontrollierten Rechte zum Versand an Behörden oder Kunden. Lassen Sie jede Tatsachenangabe im Entwurf auf ein Ticket, ein Protokoll oder eine bestätigte technische Analyse zurückführen. Ungeprüfte Kundendaten und vertrauliche Exploit-Details gehören nicht in beliebige externe Dienste. Das ist ein vorgeschlagenes Kontrollkonzept, keine Behauptung, der CRA schreibe ein bestimmtes KI-Werkzeug oder dieses Rollenmodell vor.

Fazit: Erst Meldefähigkeit herstellen, dann systematisch ausbauen

Für betroffene Hersteller ist der 11. September kein ferner Planungstermin mehr. Unsere Priorität für diese Woche lautet deshalb: Produkte und Rollen einordnen, Zuständigkeiten absichern und die Meldekette üben. Ein größeres Werkzeugprojekt kann folgen, sollte aber die kurzfristige Handlungsfähigkeit nicht blockieren. Trennen Sie in Ihrer Planung die bereits geltenden Meldepflichten von den grundsätzlich ab Dezember 2027 anwendbaren weitergehenden CRA-Anforderungen. Dieser Beitrag bietet eine technische und organisatorische Einordnung, keine Rechtsberatung; insbesondere Anwendungsbereich und Grenzfälle sollten fachkundig rechtlich geprüft werden.

EIST Consulting unterstützt Sie dabei, Produktinventar, technische Sicherheitsprozesse und einen praktikablen Meldeablauf zusammenzubringen.