Leitfaden

Cyber Resilience Act: die Meldepflicht für Software- und SaaS-Hersteller

Von Lucas Weber, CyberSec42 · Stand 28.10.2026

Seit dem 11. September 2026 müssen Hersteller von Produkten mit digitalen Elementen nach Artikel 14 des Cyber Resilience Act (CRA) aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle melden: eine Frühwarnung binnen 24 Stunden, eine Meldung binnen 72 Stunden und danach einen Abschlussbericht. Gemeldet wird über die Single Reporting Platform der ENISA, gleichzeitig an die ENISA und an das koordinierende CSIRT des Landes der Hauptniederlassung, in Deutschland das CERT-Bund im BSI. Die Pflicht gilt auch für Produkte, die schon auf dem Markt sind. Die übrigen Pflichten des CRA greifen ab dem 11. Dezember 2027.

Der Zeitplan bis Dezember 2027

Der Cyber Resilience Act ist die Verordnung (EU) 2024/2847. Er gilt unmittelbar in allen Mitgliedstaaten und tritt in Stufen in Anwendung.

Wichtig für Bestandsprodukte: Produkte, die vor dem 11. Dezember 2027 in Verkehr gebracht wurden, unterliegen den übrigen Anforderungen nur, wenn sie danach wesentlich geändert werden (Artikel 69 Absatz 2). Die Meldepflicht aus Artikel 14 gilt für sie trotzdem (Artikel 69 Absatz 3), nach der Leitlinie der Kommission auch nach Ende des Unterstützungszeitraums. Rückwirkend melden müssen Sie nicht. Erfahren Sie aber erst nach dem 11. September 2026 von einer Ausnutzung, auch bei einer älteren Schwachstelle, greift die Pflicht.

Wer Hersteller im Sinne des CRA ist

Hersteller ist nach Artikel 3 Nummer 13, wer Produkte mit digitalen Elementen entwickelt oder herstellt oder entwickeln oder herstellen lässt und sie unter eigenem Namen oder eigener Marke vermarktet, gegen Bezahlung, zur Monetarisierung oder kostenlos. Ein Produkt mit digitalen Elementen ist ein Software- oder Hardwareprodukt samt seiner Lösungen zur Datenfernverarbeitung, einschließlich separat in Verkehr gebrachter Komponenten (Artikel 3 Nummer 1).

Erfasst sind solche Produkte, wenn ihr bestimmungsgemäßer Zweck oder ihre vernünftigerweise vorhersehbare Verwendung eine direkte oder indirekte Datenverbindung zu einem Gerät oder Netz einschließt (Artikel 2 Absatz 1). Bei Software können das Apps, Desktop-Programme, Agenten, Kommandozeilenwerkzeuge, Bibliotheken und SDKs sein, die Sie geschäftlich bereitstellen.

Ausgenommen sind unter anderem Medizinprodukte, bestimmte Fahrzeug-, Luftfahrt- und Schiffsausrüstung sowie Produkte ausschließlich für nationale Sicherheit oder Verteidigung (Artikel 2). Für freie und quelloffene Software gelten Sonderregeln, die wir hier ausklammern.

Fällt SaaS unter den CRA?

Die kurze Antwort: Eine reine SaaS-Anwendung, die Ihre Kunden ausschließlich im Browser nutzen, ist für sich genommen kein Produkt mit digitalen Elementen. Sie kann aber Teil eines Produkts sein, und viele SaaS-Anbieter liefern zusätzlich Software aus.

Grundlage ist der Begriff der Datenfernverarbeitung (remote data processing) in Artikel 3 Nummer 2: Datenverarbeitung aus der Ferne, deren Software vom Hersteller oder unter seiner Verantwortung konzipiert und entwickelt wurde und ohne die das Produkt eine seiner Funktionen nicht erfüllen könnte. Erwägungsgrund 12 stellt klar, dass Cloud-Lösungen nur dann erfasst sind, wenn sie diese Definition erfüllen, und dass für Cloud-Dienste wie SaaS, PaaS und IaaS die NIS2-Richtlinie gilt.

Die Kommission hat am 27. Juli 2026 eine Leitlinie zur Anwendung des CRA veröffentlicht (C(2026) 5252). Sie ist nicht bindend, gibt aber die Lesart der Kommission wieder: Software, die aus der Ferne ausgeführt und vom Nutzer nur aufgerufen wird, ist allein deshalb kein Produkt mit digitalen Elementen. Das gilt typischerweise für Web-Anwendungen und Progressive Web Apps, die ausschließlich im Browser genutzt werden. Ein lokal installierter Client dagegen ist ein Produkt. Stützt sich dieser Client auf ein Backend, das die Definition der Datenfernverarbeitung erfüllt, gehört das Backend zum Produkt.

Die zwei Prüffragen für Ihr Backend

Nach der Leitlinie ist ein Backend nur dann Datenfernverarbeitung im Sinne des CRA, wenn beide Fragen mit Ja beantwortet werden:

• Würde ohne diese Verarbeitung eine Funktion des Produkts ausfallen? Nicht nur Kernfunktionen zählen. Die Leitlinie nennt etwa Dateisynchronisation, Konfiguration, Update-Verteilung sowie Identitäts- und Zugriffsverwaltung. Reine Statistik-Telemetrie zählt nicht.
• Wurde die Software von Ihnen oder unter Ihrer Verantwortung entwickelt? Eigen- oder Auftragsentwicklung nach Ihren Vorgaben: ja. Ein fremder, nur lizenzierter SaaS-Dienst: nein. Ihn behandeln Sie wie eine Komponente, mit Risikobewertung und Sorgfaltsprüfung.

Die Einordnung ist eine Einzelfallprüfung; halten Sie das Ergebnis je Produkt mit Begründung fest. Grenzfälle gehören zu Ihrer Rechtsberatung, verbindlich auslegen kann den CRA nur der Europäische Gerichtshof.

Was gemeldet werden muss

Aktiv ausgenutzte Schwachstellen

Eine Schwachstelle gilt als aktiv ausgenutzt, wenn es verlässliche Belege dafür gibt, dass ein böswilliger Akteur sie ohne Erlaubnis des Systeminhabers ausgenutzt hat (Artikel 3 Nummer 42). Nach den Hinweisen des BSI reichen ein veröffentlichter Exploit, Proof-of-Concept-Code oder Portscans nicht aus. Eine ausnutzbare, aber nicht ausgenutzte Schwachstelle ist nicht meldepflichtig.

Für Schwachstellen in fremden Komponenten gilt laut Leitlinie: Wird die Schwachstelle in Ihrem Produkt aktiv ausgenutzt, melden Sie. Ist der verwundbare Code in Ihrem Produkt nicht erreichbar oder dort nicht ausgenutzt worden, besteht keine Meldepflicht. Sie können aber freiwillig melden (Artikel 15) und müssen die Schwachstelle an den Hersteller oder Betreuer der Komponente weitergeben (Artikel 13 Absatz 6).

Schwerwiegende Sicherheitsvorfälle

Ein Vorfall mit Auswirkungen auf die Sicherheit des Produkts ist nach Artikel 14 Absatz 5 schwerwiegend, wenn er

• die Fähigkeit des Produkts beeinträchtigt oder beeinträchtigen kann, die Verfügbarkeit, Authentizität, Integrität oder Vertraulichkeit sensibler oder wichtiger Daten oder Funktionen zu schützen, oder
• zur Einschleusung oder Ausführung von Schadcode im Produkt oder in den Systemen eines Nutzers geführt hat oder führen kann.

Ein Beispiel ist eine kompromittierte Build- oder Update-Infrastruktur. Ein Ransomware-Angriff auf Ihre Büro-IT ist nach Hinweis des BSI nicht automatisch ein schwerwiegender Vorfall im Sinne des CRA. Entscheidend ist, ob die Sicherheit des Produkts betroffen ist.

Wann die Uhr läuft

Die Fristen beginnen, sobald Sie Kenntnis erlangt haben. Laut Leitlinie der Kommission ist das der Fall, wenn Sie nach einer unverzüglichen ersten Prüfung hinreichend sicher sind, dass eine aktive Ausnutzung oder ein schwerwiegender Vorfall vorliegt. Die erste Prüfung darf also nicht liegen bleiben.

Die Fristen im Überblick

Auf Anfrage des CSIRT kann ein Zwischenbericht fällig werden (Artikel 14 Absatz 6). Außerdem müssen Sie die betroffenen Nutzer und, wo angemessen, alle Nutzer über die Schwachstelle oder den Vorfall informieren, samt der Maßnahmen, die diese selbst ergreifen können, wo angemessen in einem strukturierten, maschinenlesbaren Format (Artikel 14 Absatz 8).

Verstöße gegen Artikel 13 und 14 können nach Artikel 64 Absatz 2 mit Geldbußen von bis zu 15 Millionen Euro oder bis zu 2,5 Prozent des weltweiten Jahresumsatzes geahndet werden, je nachdem, welcher Betrag höher ist. Kleinst- und Kleinunternehmen können nach Artikel 64 Absatz 10 für eine verpasste 24-Stunden-Frühwarnung nicht mit Geldbußen belegt werden. Die übrigen Fristen gelten auch für sie.

Der Meldeweg: ENISA-Plattform und BSI

Gemeldet wird ausschließlich über die Single Reporting Platform (CRA-SRP), die die ENISA betreibt. Seit dem 11. September 2026 sind Meldungen dort einzureichen. Sie melden einmal, CSIRT und ENISA sehen die Meldung gleichzeitig.

• Zuständiges CSIRT. Maßgeblich ist der Mitgliedstaat Ihrer Hauptniederlassung, also dort, wo Cybersicherheitsentscheidungen zu Ihren Produkten überwiegend fallen, hilfsweise die Niederlassung mit den meisten Beschäftigten (Artikel 14 Absatz 7). Für Hersteller ohne EU-Niederlassung gilt eine feste Rangfolge.
• Deutschland. Das koordinierende CSIRT ist das CERT-Bund im BSI. Mitte Oktober 2026 hat der Bundestag das CRA-Durchführungsgesetz verabschiedet, das das BSI laut BSI auch zur Marktüberwachungsbehörde macht.
• Zugang. Eine Vorab-Registrierung ist laut BSI nicht vorgeschrieben, nötig ist ein EU-Login-Konto. Gemeldet wird durch eine benannte Vertretungsperson (Assigned Representative), primär und sekundär.
• Sprache. Das BSI bittet darum, Meldungen auf Englisch zu verfassen.

Die bloße Meldung führt nicht zu einer erhöhten Haftung (Artikel 17 Absatz 4). Ist eine Schwachstelle besonders sensibel, etwa weil noch kein Update existiert, können Sie das angeben, und das CSIRT kann die Weitergabe für die unbedingt notwendige Zeit zurückstellen (Artikel 16 Absatz 2). Für kleine und mittlere Unternehmen bieten die CSIRTs Unterstützung zu den Meldepflichten an (Artikel 17 Absatz 6).

Verhältnis zu NIS2

NIS2 und CRA haben unterschiedliche Gegenstände. NIS2 regelt die Cybersicherheit von Einrichtungen, also Ihre Organisation und deren Netz- und Informationssysteme. Darunter fallen auch Anbieter von Cloud-Diensten ab mittlerer Unternehmensgröße. Der CRA regelt die Sicherheit von Produkten. Ob Sie von NIS2 betroffen sind, haben wir in einem eigenen Beitrag beschrieben.

Beides kann gleichzeitig zutreffen, etwa bei einem Softwarehersteller, der als Einrichtung unter NIS2 fällt und dessen Produkt von einem Vorfall betroffen ist. Nach Hinweis des BSI ist ein solcher Vorfall dann zweimal zu melden: nach NIS2 über das BSI-Portal und nach dem CRA über die CRA-SRP. Ein Verweis auf die jeweils andere Meldung ist möglich; eine Vereinfachung über den sogenannten Digital Omnibus ist bisher nur ein Vorschlag. Die Fristen ähneln sich, die Auslöser nicht: erheblicher Sicherheitsvorfall bei NIS2, aktiv ausgenutzte Schwachstelle oder schwerwiegender Produktvorfall beim CRA.

Was Sie jetzt vorbereiten sollten

Die folgenden acht Schritte bauen den Prozess vorher auf. Einige sind ab Dezember 2027 ohnehin Pflicht, helfen aber schon heute, eine Meldepflicht rechtzeitig zu erkennen.

1. Betroffenheit klären. Alle Produkte und Versionen in der EU mit CRA-Einordnung und Begründung auflisten, bei SaaS anhand der zwei Prüffragen. Hauptniederlassung nach Artikel 14 Absatz 7 festhalten.
2. Zuständigkeiten festlegen. Wer entscheidet, ob ein Ereignis meldepflichtig ist? Wer ist primäre und sekundäre Vertretungsperson auf der Plattform? Die Fristen laufen auch am Wochenende, Vertretung und Erreichbarkeit gehören schriftlich geregelt. Das EU-Login-Konto richten Sie vor dem Ernstfall ein.
3. Meldeablauf und Vorlagen. Ein kurzer Entscheidungsbaum und englische Textbausteine für alle drei Meldestufen. Dokumentieren Sie, wann und warum Sie Kenntnis erlangt haben.
4. Richtlinie zur koordinierten Offenlegung. Der CRA verlangt eine Richtlinie zur koordinierten Offenlegung von Schwachstellen (Coordinated Vulnerability Disclosure, Artikel 13 Absatz 8 und Anhang I Teil II Nummer 5). Sie regelt, wie Externe Funde melden, wie Sie antworten und wann veröffentlicht wird. Orientierung bieten ISO/IEC 29147 und 30111.
5. Kontaktstelle für Schwachstellen. Eine leicht auffindbare Kontaktadresse für Meldungen (Anhang I Teil II Nummer 6) und eine zentrale Anlaufstelle, die sich nicht auf automatisierte Werkzeuge beschränken darf (Artikel 13 Absatz 17). Eine security.txt auf Ihrer Website macht die Adresse auch maschinell auffindbar.
6. SBOM. Eine Software-Stückliste in einem gängigen, maschinenlesbaren Format, die mindestens die direkten Abhängigkeiten abdeckt (Anhang I Teil II Nummer 1). Ohne sie können Sie bei einer ausgenutzten Lücke in einer Bibliothek kaum binnen 24 Stunden sagen, ob Ihr Produkt betroffen ist. Die nicht verbindliche Technische Richtlinie TR-03183-2 des BSI beschreibt Anforderungen an SBOMs, mit Zuordnung zu SPDX und CycloneDX.
7. Schwachstellenmanagement und Tests. Schwachstellen ohne Verzögerung beheben, Sicherheitsupdates wo technisch möglich getrennt von Funktionsupdates ausliefern und die Sicherheit des Produkts regelmäßig wirksam testen (Anhang I Teil II Nummern 2, 3 und 7). Ab Dezember 2027 gilt ein Unterstützungszeitraum von in der Regel mindestens fünf Jahren (Artikel 13 Absatz 8).
8. Üben. Den Ablauf einmal mit realistischem Szenario und Stoppuhr durchspielen, vom Verdacht bis zur Nutzerinformation.

Die Checkliste

Wie wir unterstützen können

Die rechtliche Auslegung klären Sie mit Ihrer Rechtsberatung. Bei zwei Bausteinen können wir technisch unterstützen, im schriftlich vereinbarten Umfang.

Mehr dazu: SaaS-Penetrationstest, Compliance-Readiness, NIS2-Readiness, Schwachstellenanalyse und Ablauf eines Penetrationstests.

Häufige Fragen

Quellen

• EUR-Lex: Verordnung (EU) 2024/2847 (Cyber Resilience Act)
• Europäische Kommission: Leitlinie zur Anwendung des CRA, C(2026) 5252, 27.07.2026
• Europäische Kommission: Cyber Resilience Act, Reporting obligations
• Europäische Kommission: Cyber Resilience Act, Summary of the legislative text
• ENISA: CRA Single Reporting Platform
• ENISA: List of CSIRTs designated as coordinators
• BSI: CRA Single Reporting Platform
• BSI: CRA-Durchführungsgesetz verabschiedet
• BSI: TR-03183 Cyber Resilience Requirements for Manufacturers and Products
• EUR-Lex: Richtlinie (EU) 2022/2555 (NIS2)