Seit dem 11. September 2026 gilt für Hersteller von Produkten mit digitalen Elementen eine neue operative Pflicht: Aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle müssen nach dem europäischen Cyber Resilience Act gemeldet werden. Die Fristen beginnen nicht erst nach einer vollständigen technischen Untersuchung, sondern bereits mit der Kenntnis des relevanten Ereignisses. Die erste Frühwarnung ist innerhalb von 24 Stunden vorgesehen, die ausführlichere Meldung innerhalb von 72 Stunden. Gerade kleine Softwarehäuser, App-Anbieter, Hardwareentwickler und spezialisierte Technologieunternehmen müssen deshalb ihre internen Abläufe jetzt auf kurze Entscheidungswege ausrichten.
Die Meldepflicht ist der erste unmittelbar praxiswirksame Teil des Cyber Resilience Act. Die meisten materiellen Produktanforderungen gelten erst ab dem 11. Dezember 2027, doch das darf nicht mit einer allgemeinen Schonfrist verwechselt werden. Wer bereits heute digitale Produkte auf dem EU-Binnenmarkt bereitstellt und als Hersteller unter die Verordnung fällt, benötigt einen funktionierenden Prozess für Eingang, Bewertung und Meldung von Schwachstellen und Vorfällen. Das betrifft nicht jedes selbstständige Unternehmen, kann aber auch kleine Anbieter erfassen, sobald sie Software oder vernetzte Hardware unter eigenem Namen vermarkten.
Der folgende Überblick dient der allgemeinen Information und ersetzt keine individuelle Rechtsberatung. Bei unklarer Rollenverteilung, komplexen Lieferketten oder einem laufenden Sicherheitsvorfall ist eine spezialisierte rechtliche und technische Prüfung erforderlich.
Was hat sich am 11. September 2026 geändert?
Der Cyber Resilience Act ist die Verordnung (EU) 2024/2847. Er schafft EU-weit einheitliche Anforderungen an die Cybersicherheit von Produkten mit digitalen Elementen. Nach der amtlichen Fassung bei EUR-Lex gilt die Verordnung grundsätzlich ab dem 11. Dezember 2027. Zwei Teile wurden jedoch vorgezogen: Vorschriften zu Konformitätsbewertungsstellen gelten seit dem 11. Juni 2026, die Meldepflichten für aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle seit dem 11. September 2026.
Das Bundesamt für Sicherheit in der Informationstechnik bestätigte den Start der Meldepflicht am 11. September 2026. Meldungen erfolgen über die von der EU-Agentur ENISA betriebene Single Reporting Platform. In Deutschland fungiert CERT-Bund im BSI als koordinierendes Computer Security Incident Response Team. Eine einzige Meldung kann über die Plattform an die zuständigen Stellen der betroffenen Mitgliedstaaten und an ENISA verteilt werden.
Welche Selbstständigen und kleinen Unternehmen können betroffen sein?
Die Pflichten knüpfen nicht an die Unternehmensgröße, sondern an Rolle und Produkt an. Zentral ist der Hersteller eines Produkts mit digitalen Elementen, das im Rahmen einer geschäftlichen Tätigkeit auf dem EU-Markt bereitgestellt wird. Dazu können vernetzte Geräte, IoT-Produkte, Softwareanwendungen, Betriebssysteme, Sicherheitsprogramme, Plugins, mobile Apps oder digitale Komponenten gehören. Auch eine natürliche Person kann Hersteller sein, wenn sie ein solches Produkt entwickelt oder entwickeln lässt und unter eigenem Namen oder eigener Marke vermarktet.
Freiberufliche Entwicklung im Kundenauftrag
Eine freiberufliche Entwicklerin, die lediglich an der internen Software eines Kunden mitarbeitet, ist nicht automatisch Herstellerin des fertigen Produkts. Entscheidend sind Vertragsgestaltung, tatsächliche Kontrolle, Vermarktung und die Frage, unter wessen Namen das Produkt bereitgestellt wird. Wird dagegen eine eigene App oder ein eigenes Softwareprodukt angeboten, rückt die Herstellerrolle deutlich näher. Die Abgrenzung sollte dokumentiert und mit Verträgen sowie Verantwortlichkeiten in der Lieferkette abgeglichen werden.
Open-Source-Software und Software-Stewards
Nicht jede unentgeltliche Open-Source-Veröffentlichung fällt wie ein kommerzielles Produkt unter die Herstellerpflichten. Der CRA enthält besondere Regeln für freie und quelloffene Software sowie für sogenannte Open-Source-Software-Stewards. Nach den aktuellen ENISA-Hinweisen müssen solche Stewards relevante Ereignisse melden, soweit sie an der Entwicklung von Produkten mit digitalen Elementen beteiligt sind. Ob eine Tätigkeit kommerziell ist oder welche Sonderregel greift, muss anhand des konkreten Modells geprüft werden.
Importeure und Händler
Importeure und Händler haben nach dem CRA eigene Pflichten. Die seit September laufende Meldung über die Single Reporting Platform richtet sich in erster Linie an Hersteller und in bestimmten Fällen an Open-Source-Stewards. Ein Händler kann allerdings zum Hersteller werden, wenn ein Produkt unter eigenem Namen oder eigener Marke angeboten oder wesentlich verändert wird. Diese Rollenfrage gehört deshalb in jede Produkt- und Lieferkettenprüfung.
Die bereits vorhandene Übersicht zur Individual- und Branchensoftware für Gründer verdeutlicht, wie unterschiedlich Entwicklung, Lizenzierung und betrieblicher Einsatz organisiert sein können. Für den CRA reicht die allgemeine Bezeichnung „Softwareanbieter“ nicht aus; maßgeblich ist die konkrete Rolle beim Inverkehrbringen.
Welche Ereignisse müssen gemeldet werden?
Die neue Pflicht erfasst nicht jede theoretische Schwachstelle und nicht jede gewöhnliche Betriebsstörung. Gemeldet werden müssen aktiv ausgenutzte Schwachstellen sowie schwerwiegende Sicherheitsvorfälle mit Auswirkungen auf die Sicherheit eines Produkts mit digitalen Elementen. Die Begriffe sind in der Verordnung definiert und müssen im Einzelfall anhand der tatsächlichen Erkenntnisse bewertet werden.
Aktiv ausgenutzte Schwachstelle
Eine Schwachstelle ist aktiv ausgenutzt, wenn bekannt ist, dass ein böswilliger Akteur sie verwendet. Ein bloßer theoretischer Fehler ohne Anzeichen einer Ausnutzung löst daher nicht automatisch dieselbe Meldung aus. Kenntnis kann beispielsweise durch Sicherheitsforschende, Kundschaft, Integratoren, Behörden, Threat-Intelligence-Dienste oder eigene Telemetrie entstehen. Unternehmen benötigen einen zentralen Eingang für solche Hinweise, damit eine Nachricht nicht in einem allgemeinen Supportpostfach liegen bleibt.
Schwerwiegender Sicherheitsvorfall
Ein schwerwiegender Vorfall wirkt sich erheblich auf die Sicherheit des Produkts aus. Das kann Verfügbarkeit, Authentizität, Integrität oder Vertraulichkeit betreffen. Der BSI-Flyer nennt als mögliche Beispiele eine kompromittierte Entwicklungsumgebung, einen manipulierten Update-Server, abgeflossenen Quellcode oder gestohlene Code-Signing-Schlüssel. Nicht jeder Vorfall erreicht automatisch die gesetzliche Schwelle; dennoch muss die Bewertung so früh erfolgen, dass die 24-Stunden-Frist eingehalten werden kann.
Welche Fristen gelten für die Meldung?
Der Meldeprozess ist dreistufig. Nach dem aktuellen ENISA-Faktenblatt zur CRA-Plattform beginnt er in dem Moment, in dem ein Hersteller von der aktiven Ausnutzung oder dem schwerwiegenden Vorfall Kenntnis erlangt. Innerhalb von 24 Stunden ist eine Frühwarnung mit Grundinformationen vorgesehen. Innerhalb von 72 Stunden folgt die ausführlichere Meldung mit allgemeinen Informationen und einer ersten Bewertung.
Bei einer aktiv ausgenutzten Schwachstelle ist der Abschlussbericht spätestens 14 Tage nach Bereitstellung einer Korrekturmaßnahme, etwa eines Patches, fällig. Bei einem schwerwiegenden Sicherheitsvorfall muss der Abschlussbericht innerhalb eines Monats nach der 72-Stunden-Meldung eingereicht werden. Er enthält insbesondere Erkenntnisse zu Schweregrad, Auswirkungen, Ursache und Abhilfemaßnahmen.
Die 24-Stunden-Frist macht deutlich, dass die erste Meldung keine abschließende Ursachenanalyse sein kann. Sie soll den zuständigen Stellen frühzeitig Kenntnis geben. Ein interner Prozess darf die Meldung daher nicht davon abhängig machen, dass Entwicklung, Geschäftsleitung und externe Beratung bereits jedes technische Detail abschließend geklärt haben.
Wie funktioniert die Single Reporting Platform?
Die CRA Single Reporting Platform ist der EU-weit einheitliche elektronische Meldekanal. Sie wird von ENISA entwickelt, betrieben und gepflegt. Nach Angaben von BSI und ENISA ist keine vorherige Registrierung erforderlich. Ein Unternehmen kann bei Bedarf ein Konto anlegen und eine Meldung kurzfristig einreichen. Das ist praktisch, ersetzt aber nicht die Vorbereitung der erforderlichen Informationen und Zuständigkeiten.
Das koordinierende CSIRT richtet sich bei einem Hersteller mit Hauptniederlassung in der EU grundsätzlich nach dem Mitgliedstaat, in dem die wesentlichen Entscheidungen zur Cybersicherheit der Produkte getroffen werden. Für Unternehmen mit entsprechender Hauptniederlassung in Deutschland ist CERT-Bund im BSI die zentrale Stelle. Bei Unternehmen ohne Hauptniederlassung in der EU gelten weitere Kriterien, etwa der Sitz einer bevollmächtigten Vertretung, eines Importeurs oder Händlers.
Was kleine Unternehmen jetzt organisatorisch vorbereiten sollten
Die kurzen Fristen lassen sich nur mit vorbereiteten Zuständigkeiten und belastbaren Informationen einhalten. Für kleine Unternehmen ist dabei kein überdimensioniertes Meldesystem erforderlich, wohl aber ein dokumentierter Ablauf, der vom ersten Hinweis bis zur Freigabe einer Meldung funktioniert.
Produktportfolio und Rollen erfassen
Der erste Schritt ist ein belastbares Verzeichnis aller digitalen Produkte, Versionen, Marken und verantwortlichen Gesellschaften oder Personen. Dazu gehören integrierte Drittkomponenten und gegebenenfalls verbundene Dienste zur Fernverarbeitung von Daten. Für jedes Produkt sollte feststehen, wer als Hersteller auftritt, wer Sicherheitsentscheidungen trifft und welche Märkte beliefert werden. Ohne diese Übersicht lässt sich im Ernstfall kaum bestimmen, ob und wohin gemeldet werden muss.
Einen Meldeweg für Schwachstellen schaffen
Sicherheitsforschende, Kunden und Dienstleister benötigen eine erreichbare Kontaktstelle. Eingehende Hinweise müssen protokolliert, priorisiert und an eine entscheidungsfähige Person weitergeleitet werden. Ein Postfach ohne Vertretung am Wochenende reicht bei einer 24-Stunden-Frist nicht aus. Die Anleitung zur IT-Sicherheit für Freiberufler bietet ergänzende Grundlagen für Geräte, Zugänge und Datensicherung.
Entscheidungsbefugnisse und Vertretung festlegen
Es muss schriftlich feststehen, wer eine Frühwarnung freigibt, wer technische Angaben liefert und wer bei Abwesenheit übernimmt. Kleine Betriebe können externe IT-Sicherheits- oder Rechtsberatung einbinden, dürfen die Verantwortung aber nicht vollständig auslagern. Verträge sollten Reaktionszeiten, Informationspflichten und den Zugang zu Protokollen regeln. Allgemeine Grundsätze einer rechtssicheren Compliance-Organisation helfen dabei, Zuständigkeiten und Nachweise nachvollziehbar aufzubauen.
Vorlage und Testlauf vorbereiten
Eine interne Vorlage sollte mindestens Produkt, betroffene Version, Zeitpunkt der Kenntnis, Art des Ereignisses, bekannte Auswirkungen, betroffene Mitgliedstaaten, Sofortmaßnahmen und verantwortliche Kontaktperson erfassen. Ein kurzer Probelauf zeigt, ob die notwendigen Daten innerhalb weniger Stunden verfügbar sind. Die Übung sollte auch außerhalb normaler Bürozeiten funktionieren und die Übergabe zwischen Support, Entwicklung und Geschäftsleitung abbilden.
Lieferketten und Dienstleister richtig einbinden
Digitale Produkte bestehen häufig aus Bibliotheken, Cloud-Komponenten, zugekaufter Firmware und extern entwickelten Modulen. Ein Hersteller kann seine gesetzliche Verantwortung nicht dadurch erfüllen, dass er lediglich auf einen Zulieferer verweist. Verträge sollten deshalb festlegen, welche Sicherheitsinformationen in welcher Zeit übermittelt werden, wer Patches vorbereitet und wie gemeinsame Vorfälle bewertet werden.
Gleichzeitig darf nicht jede Schwachstellenmeldung ungeprüft als eigener CRA-Fall behandelt werden. Es muss festgestellt werden, ob die Komponente im betroffenen Produkt eingesetzt wird, ob eine aktive Ausnutzung bekannt ist und welche Auswirkungen auf das Produkt bestehen. Die Dokumentation dieser Bewertung schützt nicht nur technisch, sondern zeigt später auch, dass Hinweise systematisch bearbeitet wurden.
Datenschutz, CRA und weitere Meldepflichten
Ein Sicherheitsvorfall kann gleichzeitig mehrere Rechtsbereiche berühren. Sind personenbezogene Daten betroffen, kann zusätzlich eine Meldung nach der Datenschutz-Grundverordnung erforderlich sein. Für bestimmte Unternehmen kommen Pflichten nach NIS 2 oder sektorspezifischen Vorschriften hinzu. Die Systeme verfolgen unterschiedliche Zwecke, Fristen und Empfänger. Eine CRA-Meldung ersetzt daher nicht automatisch eine Datenschutzmeldung oder andere gesetzliche Anzeige.
Der Beitrag zum Datenschutz für Selbstständige erläutert die grundlegenden Verantwortlichkeiten beim Umgang mit personenbezogenen Daten. Für den Notfallplan ist eine gemeinsame Entscheidungsmatrix sinnvoll, die technische Fakten einmal erfasst und anschließend getrennt prüft, welche gesetzlichen Meldungen ausgelöst werden.
Typische Fehler bei der Umsetzung
Ein besonders riskanter Fehler ist die Annahme, kleine Unternehmen seien grundsätzlich ausgenommen. Die Herstellerrolle hängt nicht allein von Umsatz oder Beschäftigtenzahl ab. Ebenso problematisch ist das Warten auf eine vollständige forensische Analyse. Die Frühwarnung muss gerade dann funktionieren, wenn viele Details noch offen sind.
Weitere Fehler sind unklare Vertretungen, unüberwachte Sicherheitsadressen, fehlende Versionslisten und Verträge ohne schnelle Informationspflichten. Auch eine vorschnelle Einstufung jedes Softwarefehlers als meldepflichtiger Vorfall ist nicht sinnvoll. Sie bindet Ressourcen und kann vertrauliche Informationen unnötig verbreiten. Erforderlich ist ein dokumentierter, fachkundiger Prozess, der die gesetzlichen Begriffe zügig auf den konkreten Sachverhalt anwendet.
Häufige Fragen zum Cyber Resilience Act
Die wichtigsten praktischen Punkte lassen sich anhand von sechs Fragen zusammenfassen.
Gilt die CRA-Meldepflicht bereits jetzt?
Ja. Die Meldepflicht für aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle gilt seit dem 11. September 2026. Die meisten übrigen Anforderungen des CRA gelten ab dem 11. Dezember 2027.
Sind Solo-Selbstständige ausgenommen?
Eine pauschale Ausnahme allein wegen der Unternehmensgröße besteht nicht. Entscheidend ist insbesondere, ob eine Person als Hersteller ein Produkt mit digitalen Elementen im Rahmen einer geschäftlichen Tätigkeit auf dem EU-Markt bereitstellt.
Muss jede entdeckte Schwachstelle gemeldet werden?
Nein. Die aktuelle Pflicht betrifft aktiv ausgenutzte Schwachstellen. Eine theoretisch vorhandene, aber nachweislich nicht aktiv ausgenutzte Schwachstelle fällt nicht automatisch unter denselben Meldetatbestand. Andere Pflichten zur Behandlung und Dokumentation können dennoch bestehen.
Wo wird die Meldung eingereicht?
Die Meldung erfolgt über die CRA Single Reporting Platform von ENISA. Für Hersteller mit maßgeblicher Niederlassung und Cybersecurity-Entscheidung in Deutschland ist grundsätzlich CERT-Bund im BSI das koordinierende CSIRT.
Welche Frist ist zuerst einzuhalten?
Innerhalb von 24 Stunden nach Kenntnis ist eine Frühwarnung vorgesehen. Innerhalb von 72 Stunden folgt die ausführlichere Meldung mit erster Bewertung. Später ist je nach Ereignis ein Abschlussbericht erforderlich.
Ersetzt die CRA-Meldung eine DSGVO-Meldung?
Nein. Wenn personenbezogene Daten betroffen sind, können zusätzlich die Melde- und Benachrichtigungspflichten der DSGVO greifen. Auch NIS-2- oder sektorspezifische Pflichten müssen gesondert geprüft werden.
Fazit
Mit dem 11. September 2026 ist der Cyber Resilience Act für Hersteller digitaler Produkte praktisch relevant geworden. Die kurzen Fristen von 24 und 72 Stunden verlangen keine perfekte Sofortanalyse, wohl aber klare Zuständigkeiten, erreichbare Meldewege und eine belastbare Produktübersicht. Selbstständige und kleine Unternehmen sollten deshalb zuerst ihre Rolle als Hersteller, Händler, Importeur oder Dienstleister klären und anschließend einen dokumentierten Reaktionsprozess einrichten. Wer erst im Sicherheitsvorfall mit der Rollen- und Zuständigkeitsprüfung beginnt, verliert genau die Zeit, die der CRA nicht mehr gewährt. Die Vorbereitung ist zugleich eine sinnvolle Grundlage für die umfassenderen Produktpflichten, die ab Dezember 2027 gelten.
Bildnachweis: Beitragsbild von Jakub Zerdzicki über Pexels (Foto-ID 36496927); Bild im Artikel von Christina Morillo über Pexels (Foto-ID 1181320). Nutzung gemäß Pexels-Lizenz.
