Verkaufen Sie Software oder Geräte? Ab 11. September gilt eine Meldepflicht

Kurz erklärt

Ab dem 11. September 2026 müssen Hersteller erfasster Software und Geräte aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle melden. Nicht jede Website und nicht jeder Fehler ist betroffen. Klären Sie zuerst die Betroffenheit; bereiten Sie dann Zuständigkeiten und Meldewege vor. Die ersten Fristen laufen ab Kenntnis des meldepflichtigen Ereignisses.

Auf dieser Seite:

• Wer ist betroffen?
• Was muss gemeldet werden?
• Fristen und Meldestufen
• Meldeplattform und Zuständigkeit
• Vorbereitung
• Quellen

Verkaufen oder liefern Sie etwas, das beim Kunden läuft? Eine App, ein Plugin, ein Programm zum Installieren, die Software in einem Gerät, ein vernetztes Gerät selbst? Dann sollten Sie die neue Meldepflicht prüfen. Betreiben Sie nur eine Website oder einen reinen Onlinedienst, dann eher nicht.

Ab dem 11. September 2026 müssen Hersteller von erfassten Produkten zwei Arten von Ereignissen melden: aktiv ausgenutzte Schwachstellen in ihrem Produkt und schwerwiegende Sicherheitsvorfälle mit Auswirkungen auf dessen Sicherheit. Die erste Warnung muss unverzüglich, spätestens binnen 24 Stunden nach Kenntniserlangung, erfolgen. Das gilt auch für Produkte, die längst verkauft sind. CRA, Artikel 14, 69 Absatz 3 und 71 Absatz 2.

Dieser Beitrag erklärt die Meldepflicht und die Vorbereitung darauf. Er ist keine vollständige Anleitung zur Produktkonformität ab Dezember 2027 und keine Rechtsberatung. Bei einem regulierten Produkt sollten Sie die Einordnung mit qualifizierter Rechtsberatung klären.

Wen es wahrscheinlich nicht betrifft

Eine Website, die Ihr Unternehmen und Ihre Leistungen vorstellt, ist kein Produkt in diesem Sinne. Dasselbe gilt für reine Onlinedienste, die Kunden ausschließlich im Browser aufrufen. Eine installierte App oder Browser-Erweiterung kann dagegen erfasst sein. Unterstützt ein Onlinedienst eine notwendige Funktion eines solchen Produkts, muss er gesondert geprüft werden. Kommissionsleitlinien, Randnummern 20–21 und 194–195.

Wer ausschließlich für den eigenen Betrieb entwickelt und nichts an Dritte abgibt, bringt dadurch kein Produkt auf den Markt. Für reine Dienste können andere Vorschriften relevant sein, etwa NIS-2; deren Anwendungsbereich ist separat zu prüfen. Kommissions-FAQ, Abschnitte 1.2 und 1.5.

Bei freier, quelloffener Software genügt „kostenlos“ als Begründung für eine Ausnahme nicht. Entscheidend sind die kommerzielle Bereitstellung und das Geschäftsmodell. Auch indirekte Monetarisierung kann zählen. Die Leitlinien unterscheiden unter anderem Supportleistungen, Spenden und gemeinnützige Organisationen; diese Fälle sollte man nicht über einen Kamm scheren. Kommissionsleitlinien, Abschnitt 3.2.

Organisationen, die bestimmte quelloffene Software dauerhaft unterstützen, können die besondere Rolle eines „Verwalters quelloffener Software“ haben. Welche Pflichten damit verbunden sind, hängt von ihrer Beteiligung an Entwicklung und Infrastruktur ab. Die entsprechenden Meldepflichten nach Artikel 24 Absatz 3 gelten ab dem 11. Dezember 2027. CRA, Artikel 3 Nummer 14 und Artikel 24, Kommissions-FAQ, Abschnitt 5.5.

Außerdem bestehen gesetzliche Ausnahmen, etwa für bestimmte Medizinprodukte, Fahrzeuge, zertifizierte Luftfahrtprodukte und Schiffsausrüstung sowie bestimmte identische Ersatzteile. In solchen Branchen ist Artikel 2 der erste Prüfschritt. CRA, Artikel 2.

Wen es betrifft

Gemeint sind Hersteller von „Produkten mit digitalen Elementen“: Software oder Hardware, die im Rahmen einer Geschäftstätigkeit auf dem EU-Markt bereitgestellt wird. Zur vorgesehenen oder vernünftigerweise vorhersehbaren Nutzung muss eine direkte oder indirekte Datenverbindung zu einem Gerät oder Netzwerk gehören. Eine Internetverbindung ist dafür nicht zwingend nötig. Die kommerzielle Bereitstellung kann auch kostenlos erfolgen. CRA, Artikel 2 Absatz 1 und Artikel 3 Nummern 1 und 22.

Konkret geht es beispielsweise um:

• Software zum Installieren auf einem Rechner oder Server
• eine App, ein Plugin oder eine Browser-Erweiterung
• die fest eingebaute Software eines Geräts, oft Firmware genannt
• ein vernetztes Gerät, vom Sensor bis zur Maschinensteuerung

Wer ein solches Produkt entwickelt oder entwickeln lässt und unter eigenem Namen oder eigener Marke vermarktet, ist grundsätzlich Hersteller. Der bloße Weiterverkauf einer fremden Marke macht einen Händler noch nicht dazu. CRA, Artikel 3 Nummer 13.

Zwei Fälle übersieht man leicht.

Der erste ist Auftragssoftware. Eine maßgeschneiderte Lösung für einen einzigen Geschäftskunden kann ebenfalls erfasst sein. Wer Hersteller ist, hängt dabei auch davon ab, unter wessen Namen sie vermarktet wird. Der Auftragnehmer ist nicht automatisch der Hersteller. Kommissions-FAQ, Abschnitt 4.2.5, CRA, Artikel 3 Nummer 13.

Der zweite ist der Server hinter der App. Kann die App ohne eine bestimmte Datenfernverarbeitung eine ihrer Funktionen nicht erfüllen und wurde die dafür nötige Software vom Hersteller oder unter seiner Verantwortung entwickelt, gehört diese Lösung zum Produkt. Ein selbst entwickeltes Backend bleibt auch dann erfasst, wenn es auf fremder Cloud-Infrastruktur läuft. Ein bloß eingekaufter Standarddienst erfüllt die Definition dagegen nicht allein deshalb, weil die App ihn nutzt. CRA, Artikel 3 Nummer 2, Kommissionsleitlinien, Randnummern 195–196.

Was gemeldet werden muss, und was nicht

Der erste Auslöser ist eine aktiv ausgenutzte Schwachstelle. Dafür müssen verlässliche Nachweise vorliegen, dass ein böswilliger Akteur die Lücke in einem System ohne Zustimmung des Systemeigners ausgenutzt hat. Ein Angriffsversuch allein ist damit nicht gleichzusetzen. CRA, Artikel 3 Nummer 42 und Artikel 14 Absatz 1.

Ein Fund durch Sicherheitsforscher oder ein Bug-Bounty-Programm löst für sich genommen keine Pflichtmeldung aus. Auch eine Lücke ohne verfügbares Update ist nicht automatisch ein Meldefall. Zeigt der Fund zugleich Belege einer böswilligen Ausnutzung, muss er entsprechend bewertet werden. Kommissions-FAQ, Abschnitt 5.2.

Der zweite Auslöser ist ein schwerwiegender Sicherheitsvorfall. Das ist ein Vorfall, der den Schutz sensibler oder wichtiger Daten oder Funktionen beeinträchtigt oder beeinträchtigen kann. Erfasst ist auch die tatsächliche oder mögliche Einschleusung oder Ausführung von Schadcode im Produkt oder in Systemen seiner Nutzer. Ein kompromittierter Updateweg ist ein naheliegender Fall. Es muss also nicht erst ein nachgewiesener Kundenschaden eintreten. CRA, Artikel 14 Absätze 3 und 5.

Steckt die Lücke in einer eingekauften oder quelloffenen Komponente, kann sie trotzdem Ihr Meldefall sein. Nach den Leitlinien entfällt die Pflichtmeldung für Sie, wenn die Lücke in Ihrem Produkt nicht ausnutzbar ist oder dort nicht ausgenutzt wurde. Die technische Betroffenheit muss deshalb geprüft werden. Den Komponentenhersteller zu informieren und angemessene Gegenmaßnahmen zu prüfen, bleibt sinnvoll; die allgemeinen CRA-Pflichten dazu gelten grundsätzlich ab Dezember 2027. Kommissionsleitlinien, Randnummer 218, CRA, Artikel 13 Absatz 6, Anhang I Teil II und Artikel 71.

Für bereits vor dem 11. September 2026 bekannte aktive Ausnutzung verlangen die Leitlinien keine rückwirkende Meldung. War zuvor nur die Lücke bekannt und erfahren Sie ab dem Stichtag erstmals von ihrer aktiven Ausnutzung, greift die Pflicht dagegen. Kommissionsleitlinien, Randnummer 217.

Wann die Uhr startet

Die Frist beginnt mit Ihrer Kenntnis. Die Kommission versteht darunter eine hinreichende Sicherheit nach einer ersten Bewertung, dass eine aktive Ausnutzung oder ein schwerwiegender Vorfall vorliegt. Diese Bewertung muss unverzüglich erfolgen. Sie dürfen die Uhr nicht durch eine liegen gelassene Meldung oder das Warten auf eine vollständige Untersuchung verschieben. Kommissionsleitlinien, Randnummern 212–215.

Praktisch heißt das: Hinweis, erste Bewertung und Zeitpunkt der Kenntniserlangung dokumentieren. Legen Sie fest, wer das auch am Wochenende übernimmt und wer die Vertretung ist.

Drei Stufen

Stufe	Frist	Inhalt in Kurzform
Frühwarnung	Unverzüglich, spätestens 24 Stunden nach Kenntnis	Erste Angaben zum Fall und gegebenenfalls zu betroffenen Mitgliedstaaten; bei Vorfällen auch, ob eine rechtswidrige oder böswillige Handlung vermutet wird
Ergänzende Meldung	Unverzüglich, spätestens 72 Stunden nach Kenntnis	Verfügbare Angaben zu Produkt, Ausnutzung oder Vorfall, erste Bewertung und Gegenmaßnahmen
Abschlussbericht zur Schwachstelle	Spätestens 14 Tage nach Verfügbarkeit einer Korrektur oder Risikominderung	Schwere, Auswirkungen und Abhilfe; verfügbare Angaben zum Angreifer
Abschlussbericht zum Vorfall	Innerhalb eines Monats nach der ergänzenden Vorfallsmeldung	Schwere, Auswirkungen, wahrscheinliche Ursache und ergriffene oder laufende Gegenmaßnahmen

Die 72 Stunden beginnen ebenfalls mit der Kenntnis, nicht erst mit der Frühwarnung. Eine noch laufende Behebung hebt die Monatsfrist für den Vorfallsbericht nicht auf; er enthält dann auch die laufenden Maßnahmen. Die Meldestelle kann Zwischenberichte anfordern. CRA, Artikel 14 Absätze 2, 4 und 6.

Parallel müssen Sie betroffene Nutzer informieren und, soweit erforderlich, erläutern, was sie selbst tun können. Gegebenenfalls sind alle Nutzer einzubeziehen. Die Leitlinien unterscheiden diese rechtzeitige Information von einer sofortigen Veröffentlichung sensibler technischer Details. CRA, Artikel 14 Absatz 8, Kommissionsleitlinien, Randnummern 219–221.

Wohin die Meldung geht

CRA-Pflichtmeldungen werden über die europäische Single Reporting Platform der ENISA eingereicht. Dabei wählen Sie das zuständige nationale Reaktionsteam für IT-Sicherheitsvorfälle, das CSIRT. Für Deutschland ist dies das BSI. Grundsätzlich erhalten das zuständige CSIRT und ENISA die Meldung; das CSIRT verteilt sie an weitere betroffene Mitgliedstaaten. Für besonders sensible Informationen gibt es eng begrenzte Ausnahmen bei der Weitergabe. CRA, Artikel 14 Absatz 7 und Artikel 16, ENISA, Liste der zuständigen CSIRTs.

Welches Land zuständig ist, richtet sich vorrangig danach, wo die Entscheidungen zur Produktsicherheit überwiegend getroffen werden. Ist das nicht bestimmbar, zählt die EU-Niederlassung mit den meisten Beschäftigten. Für Hersteller ohne EU-Hauptniederlassung legt Artikel 14 Absatz 7 eine weitere Reihenfolge fest. Sie müssen das richtige CSIRT selbst bestimmen; eine falsche Auswahl kann laut ENISA eine erneute Einreichung nötig machen. ENISA-FAQ, Frage 18.

Der angekündigte Zugang ab 11. September 2026 ist das CRA-Meldeportal. Nach dem ENISA-Stand vom 10. September startet es auf Englisch, ohne Programmierschnittstelle und zunächst nur für Pflichtmeldungen. Ein persönliches EU-Login-Konto mit Mehrfaktoranmeldung können die vorgesehenen Meldepersonen schon vorbereiten. ENISA empfiehlt die eigentliche Registrierung des Herstellers im Portal erst bei einer anstehenden Meldung. Die Prüfung der Zuordnung zum Hersteller läuft parallel und blockiert die ersten Meldungen nicht. ENISA-FAQ, Fragen 4, 9, 15, 24 und 28.

Die aktuelle FAQ nennt außerdem eine Unschärfe im Fristenzähler: Das Portal zeigt die 72-Stunden-Frist zunächst als 48 Stunden nach der Frühwarnung an. Maßgeblich bleibt die gesetzliche Frist ab Kenntnis. Führen Sie die Fristen daher selbst mit. Bei einem Ausfall soll die Meldung nach Wiederverfügbarkeit eingereicht werden; bei dringendem Kommunikationsbedarf empfiehlt ENISA zusätzlich den direkten Kontakt zum zuständigen CSIRT. ENISA-FAQ, Fragen 25–26.

Eine CRA-Meldung erledigt nicht automatisch andere Meldepflichten, etwa nach NIS-2 oder bei Datenschutzverletzungen. Diese sind getrennt zu prüfen. CRA, Erwägungsgrund 12, Kommissions-FAQ, Abschnitt 2.8.

Was vorbereitet sein sollte

Beginnen Sie mit einer Liste Ihrer Produkte und der verantwortlichen Hersteller. Halten Sie je Produkt fest, wer Sicherheitshinweise bewertet, welche Versionen betroffen sein können und wie Kunden erreichbar sind. Das ist eine praktische Empfehlung für die Umsetzung der Meldepflicht.

Vier weitere Vorkehrungen werden als allgemeine CRA-Pflichten grundsätzlich ab dem 11. Dezember 2027 relevant. Für die Meldung und Reaktion helfen sie schon vorher:

• eine auffindbare Kontaktadresse für Schwachstellenmeldungen
• eine veröffentlichte Regel zum Umgang mit solchen Hinweisen
• ein Verzeichnis der verbauten Softwarekomponenten
• ein verlässlicher Weg, Sicherheitsupdates auszuliefern

Die rechtliche Grundlage für diese späteren Pflichten sind Anhang I Teil II, Anhang II Nummer 2 und Artikel 71 CRA.

Proben Sie den Ablauf mit einem erfundenen Fall: Am Freitagabend kommt ein verlässlicher Hinweis auf die Ausnutzung einer Lücke in Ihrer App. Wer prüft ihn? Wer dokumentiert die Kenntnis? Wer meldet, falls die zuständige Person ausfällt? Welche Angaben braucht die erste Meldung? Nutzen Sie dafür die ENISA-Ausfüllhilfe mit Pflichtfeldern je Meldestufe. Reichen Sie einen Übungsfall nicht als echte Meldung ein.

Fünf Sätze, die im Umlauf sind

„Die Regel gilt doch erst ab Dezember 2027.“ Die meisten CRA-Pflichten gelten ab dem 11. Dezember 2027. Artikel 14 gilt schon ab dem 11. September 2026. CRA, Artikel 71.

„Das betrifft nur neue Produkte.“ Die Meldepflicht gilt auch für erfasste Bestandsprodukte. Nach den Leitlinien sogar dann, wenn der Support bereits beendet ist. CRA, Artikel 69 Absatz 3, Kommissionsleitlinien, Randnummer 210.

„Jede Schwachstelle muss gemeldet werden.“ Eine Pflichtmeldung setzt aktive Ausnutzung oder einen schwerwiegenden Vorfall voraus. Freiwillige Meldungen sind davon zu unterscheiden und werden zum Start noch nicht im Portal unterstützt. CRA, Artikel 14–15, ENISA-FAQ, Fragen 4 und 30.

„Die 24 Stunden laufen ab dem Angriff.“ Sie laufen ab Kenntnis. CRA, Artikel 14 Absatz 2 Buchstabe a und Absatz 4 Buchstabe a.

„Eine Meldung im NIS-2-Portal genügt.“ Für die CRA-Pflichtmeldung ist die Single Reporting Platform vorgesehen. CRA, Artikel 14 Absatz 7.

Was ein Versäumnis kosten kann

Der CRA sieht für Verstöße gegen zentrale Herstellerpflichten einschließlich Artikel 14 bis zu 15 Millionen Euro vor, bei Unternehmen alternativ bis zu 2,5 Prozent des weltweiten Jahresumsatzes des vorherigen Geschäftsjahrs, je nachdem, welcher Betrag höher ist. Größe und Marktanteil fließen in die Bemessung ein. Artikel 64 gehört jedoch zu den Vorschriften, die grundsätzlich erst ab dem 11. Dezember 2027 gelten. Meldebeginn und Anwendung des Bußgeldrahmens sind deshalb auseinanderzuhalten. CRA, Artikel 64 Absätze 2 und 5 sowie Artikel 71.

Für Hersteller, die als Kleinstunternehmen oder kleine Unternehmen gelten, nimmt Artikel 64 Absatz 10 das Verpassen der 24-Stunden-Frist von diesen Geldbußen aus. Die Meldepflicht selbst bleibt bestehen. Die Ausnahme erfasst weder pauschal alle Mittelständler noch die 72-Stunden-Meldung oder den Abschlussbericht. Maßgeblich ist die EU-Unternehmensdefinition einschließlich verbundener Unternehmen. Die Berichtigung vom 2. Juli 2025 hat den Verweis in Artikel 64 Absatz 10 korrigiert; der unberichtigte Ursprungstext ist hier unvollständig. CRA, Artikel 64 Absatz 10 und Erwägungsgrund 5.

In Deutschland sieht der Gesetzentwurf das BSI als Marktüberwachungsbehörde vor. Das parlamentarische Verfahren steht am 10. September 2026 weiterhin auf „Überwiesen“. Die Meldepflicht ab 11. September folgt unmittelbar aus der EU-Verordnung. Gesetzentwurf, BT-Drucksache 21/6134, aktueller DIP-Verfahrensstand.

Ein Werkzeug für die erste Einordnung

Die Einstiegsfragen dieses Beitrags stecken in unserem CRA-Meldepflicht-Check. Er fragt nach Ihrem Angebot, der Abgabe an Dritte, der Marke, quelloffener Software, notwendigen Serverdiensten, der zuständigen Niederlassung und der Unternehmensgröße. „Weiß nicht“ ist als Antwort möglich.

Das Werkzeug bietet eine erste Einordnung mit Fundstellen, einen Fristenrechner und eine Vorbereitungsliste. Prüfen Sie vor einer echten Meldung den aktuellen Rechts- und Plattformstand anhand der Quellen unten. Ob Ihre Verträge Sie zum Hersteller machen oder Ihr Betrieb den Ablauf beherrscht, entscheidet ein Fragebogen nicht.

Wenn Sie unsicher sind

Wir können mit Ihnen Ihr Angebot und den vorgesehenen Meldeablauf durchgehen. Eine rechtliche Einzelfallprüfung durch qualifizierte Rechtsberatung ersetzt dieses Gespräch nicht.

Kostenloses Erstgespräch vereinbaren

Quellen und Stand dieser Aktualisierung

Quellenstand: 10. September 2026.

1. Verordnung (EU) 2024/2847, verbindlicher Amtsblatttext und konsolidierte Lesefassung, Konsolidierungsdatum 20. November 2024. Fundstellen: Artikel 2 und 3 (Anwendungsbereich und Rollen), Artikel 14–16 (Meldungen), Artikel 24 Absatz 3 (Open Source), Artikel 64 (Bußgelder), Artikel 69 und 71 (Fristen), Anhang I Teil II und Anhang II Nummer 2 (Vorbereitung). Die Konsolidierung dient als Lesehilfe; maßgeblich sind die Amtsblattakte einschließlich Berichtigungen.
2. Berichtigung vom 2. Juli 2025, ABl. L 2025/90555. Fundstelle: Artikel 64 Absatz 10, Korrektur des Verweises auf „Absätze 2 bis 9“.
3. Kommissionsleitlinien C(2026) 5252 vom 27. Juli 2026, Dokumentseite, Volltext als PDF. Fundstellen: Randnummern 20–21, Abschnitt 3.2, Randnummern 194–196 und 209–221. Nicht bindende Auslegungshilfe.
4. FAQ der Kommissionsdienststellen zur CRA-Umsetzung, Dokumentseite, Markdown-Fassung, PDF. Version 1.4 vom 4. September 2026; Abschnitte 1.1–1.5, 2.8, 4.2.5 und 5.1–5.5. Laufend aktualisiertes Arbeitspapier, nach eigener Aussage keine verbindliche Position der Kommission.
5. EU-Kommission: CRA-Meldepflichten, Stand 31. Juli 2026. Überblick über Fristen und Weitergabe.
6. ENISA: FAQ zur Single Reporting Platform, Stand 10. September 2026. Fragen 4, 9, 15, 18 und 24–30 zu Start, Anmeldung, Zuständigkeit, Ausfall und Fristenzähler. Beschreibt den Plattformbetrieb, ersetzt nicht den Gesetzestext.
7. ENISA: zuständige CSIRTs sowie Ausfüllhilfe „Glossary“. CSIRT-Liste vom 4. September 2026, Glossary Version 1.1 vom 5. September 2026; abgerufen am 10. September 2026.
8. BSI: Cyber Resilience Act. Deutsche Behördeninformation zur Abgrenzung und Vorbereitung, abgerufen am 10. September 2026.
9. Bundestag: Gesetzentwurf 21/6134 und DIP-Vorgang 334566. Verfahrensstand am 10. September 2026: „Überwiesen“.
10. DATENMASSIV: CRA-Meldepflicht-Check, eigene Angebotsquelle, Stand 10. September 2026. Angaben zum Funktionsumfang des Checks.

Seit der vorherigen Fassung wurden insbesondere Anwendungsbereich, Open-Source-Abgrenzung, Kenntniszeitpunkt, Abschlussbericht, Bußgeldbeginn und Plattformhinweise präzisiert. Neu hinzugekommen sind direkte Quellenlinks und die ENISA-Hinweise vom 10. September zum angekündigten Plattformstart am 11. September 2026.

Dieser Beitrag unterstützt die Einordnung, ist aber keine Rechtsberatung. Lassen Sie die Anwendung auf Ihr konkretes Produkt fachkundig prüfen.

Kontakt

Mithilfe von KI erstellt. Redaktionelle Verantwortung: DATENMASSIV. Allgemeine Information, keine individuelle Rechtsberatung.