Cyber Resilience Act: Muss mein Unternehmen Sicherheitslücken in Software melden?

Dein Unternehmen kann nach dem Cyber Resilience Act meldepflichtig sein, wenn es Hersteller eines erfassten Softwareprodukts ist. Gemeldet werden müssen dann aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle, erläutert die ENISA. Die bloße Nutzung von Software macht dich laut BSI noch nicht zum meldepflichtigen Hersteller.

Kurz gesagt: Nicht jede Sicherheitslücke muss nach dem CRA gemeldet werden. Prüfe zuerst, ob dein Produkt erfasst ist und dein Unternehmen die Herstellerrolle hat. Kläre mit deinem Entwicklungspartner, wer Sicherheitshinweise untersucht und eine erforderliche Meldung bearbeitet.

Stand: Oktober 2026. Dieser Beitrag dient der Orientierung und ersetzt keine Rechtsberatung. Lass offene Fragen zur Betroffenheit und Meldepflicht anwaltlich oder durch die zuständige Behörde klären.

Der Anlass ist konkret: Laut ENISA-FAQ gelten die ersten CRA-Meldepflichten seit dem 11. September 2026; die gemeinsame EU-Meldeplattform ist seit diesem Tag in Betrieb. Wenn du eigene Softwareprodukte anbietest oder entwickeln lässt, solltest du deshalb jetzt deine Herstellerrolle und die Zuständigkeiten klären.

Wen betrifft die Meldepflicht nach dem Cyber Resilience Act?

Die CRA-Meldepflicht betrifft Hersteller erfasster Produkte mit digitalen Elementen. Auch Softwareprodukte können darunterfallen, wie das BSI zum Cyber Resilience Act erläutert.

Für die Einordnung reicht „Wir haben eine App“ nicht. Beschreibe stattdessen, was dein Unternehmen anbietet und wie die Software genutzt wird. Wer die Anwendung programmiert hat, ist dabei nur ein Teil der Beschreibung.

Ein Beispiel: Du lässt eine Anwendung für deine Mitarbeiter entwickeln, die Angebotsdaten aus Excel übernimmt. Oder du bietest anderen Unternehmen eine Anwendung unter deinem Namen an. Diese Angaben sind für die Prüfung relevant, entscheiden die Rechtsfrage aber noch nicht allein.

Stelle für jedes zu prüfende Produkt diese Informationen zusammen:

• Was macht die Software, und wer nutzt sie?
• Wie erhalten Nutzer die Software oder den Zugang dazu?
• Unter wessen Namen wird sie angeboten?
• Wer übernimmt Entwicklung und Betrieb?

Damit kann eine rechtliche Prüfung an einem konkreten Produkt ansetzen. Ein allgemeines Gespräch über „unsere Digitalisierung“ hilft deutlich weniger.

Ist jede Individualsoftware automatisch betroffen?

Nein, eine pauschale CRA-Meldepflicht für sämtliche Individualsoftware lässt sich aus den BSI-Informationen nicht ableiten. Auch eine Auftragsentwicklung muss anhand des Produkts und der Herstellerrolle eingeordnet werden.

Individualsoftware bedeutet zunächst: Eine Anwendung wurde für bestimmte Anforderungen entwickelt. Daraus ergibt sich noch nicht, wie sie angeboten oder bereitgestellt wird. Auch „nur für unsere Firma gebaut“ ersetzt deshalb keine Beschreibung des tatsächlichen Einsatzes.

Ergänze die Produktbeschreibung um eine einfache Darstellung der technischen Bestandteile. Läuft die Anwendung auf einem Smartphone? Verarbeitet ein Server die Daten? Werden Daten an andere Dienste übertragen?

Bei einem Maklerportal könnte darin stehen: Mitarbeiter laden Unterlagen hoch, die Anwendung liest Objektdaten aus und überträgt sie an ein Immobilienportal. Benenne die beteiligten Systeme. Eine solche Darstellung hilft später auch, einen Sicherheitshinweis der richtigen Komponente zuzuordnen.

Diese Informationen gehören möglichst schon in die schriftlichen Anforderungen. Der Ratgeber zum Lastenheft für eine App zeigt, wie du Funktionen und Zuständigkeiten vor der Entwicklung festhältst. Die rechtliche Einordnung bleibt eine eigene Aufgabe.

Muss jede gefundene Sicherheitslücke gemeldet werden?

Nein, die ENISA-FAQ nennen aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle als meldepflichtige Ereignisse. Ein gefundener Programmfehler oder eine automatische Sicherheitswarnung erfüllt diese Voraussetzungen nicht automatisch.

Eine Schwachstelle ist eine technische Schwäche, die einen Angriff ermöglichen kann. „Aktiv ausgenutzt“ bedeutet, dass sie tatsächlich für Angriffe verwendet wird. Ob das der Fall ist, lässt sich nicht aus jeder Warnmeldung ablesen.

Angenommen, dein Entwickler erhält eine Warnung zu einer Softwarebibliothek. Das ist ein fertiger Programmbaustein, den eure Anwendung verwendet. Zuerst muss er prüfen, ob eure eingesetzte Version betroffen ist und ob die verwundbare Funktion überhaupt genutzt wird.

Danach geht es um Hinweise auf eine Ausnutzung. Eine Warnung über eine mögliche Angriffsmethode ist etwas anderes als ein nachgewiesener Angriff. Welche rechtliche Bewertung daraus folgt, muss anhand des konkreten Ereignisses geklärt werden.

Fehlerbehebung und Meldeprüfung sollten parallel laufen. Der Entwickler untersucht die Schwachstelle und setzt nötige Schutzmaßnahmen um. Gleichzeitig wird geklärt, ob das Ereignis eine Meldepflicht auslöst.

Ein installiertes Update beendet diese Prüfung nicht automatisch. Es beantwortet zunächst die technische Frage, ob die bekannte Schwachstelle behoben wurde.

Können ältere Softwareprodukte betroffen sein?

Ja, auch bereits angebotene Softwareprodukte können von den CRA-Meldepflichten betroffen sein. Laut ENISA-FAQ kann das Produkte einschließen, die vor dem allgemeinen CRA-Anwendungsbeginn am 11. Dezember 2027 auf dem Markt waren.

Beschränke deine Bestandsaufnahme deshalb nicht auf aktuelle Entwicklungsprojekte. Nimm auch Anwendungen auf, die seit Langem laufen und kaum verändert werden. Ihr Alter allein beantwortet die Frage nach der Betroffenheit nicht.

Kläre für diese Anwendungen, wer technische Fragen beantworten kann. Liegt der Quellcode vor, also der lesbare Programmtext? Ist bekannt, welche Softwarekomponenten eingesetzt werden und wer Zugriff auf den Betrieb hat?

Fehlen diese Informationen, wird schon die Untersuchung einer Sicherheitswarnung schwierig. Wie du Zugänge und Dokumentation absicherst, beschreibt der Ratgeber zur Abhängigkeit vom Softwareentwickler.

Wer ist zuständig, wenn eine Agentur die Software entwickelt hat?

Eine externe Entwicklung beantwortet die Frage nach der Herstellerrolle nicht allein. Maßgeblich bleiben das Produkt und die konkrete Rolle deines Unternehmens, wie aus den BSI-Informationen hervorgeht.

Trenne deshalb die rechtliche Verantwortung von der praktischen Arbeit. Wer rechtlich verantwortlich ist, solltest du bei Unklarheiten anwaltlich klären lassen. Wer technische Fakten zusammenträgt oder eine Meldung vorbereitet, kannst du anschließend mit deinem Entwicklungspartner festlegen.

„Die Agentur kümmert sich“ ist zu ungenau. Benenne Ansprechpartner und halte fest, welche Aufgaben sie übernehmen:

• Wer nimmt Sicherheitshinweise entgegen?
• Wer untersucht betroffene Versionen und Hinweise auf Angriffe?
• Wer koordiniert die rechtliche Bewertung?
• Wer bereitet eine erforderliche Meldung vor und übermittelt sie?
• Wer übernimmt bei Urlaub oder Nichterreichbarkeit?

Der Entwickler kennt den Code, aber möglicherweise nicht alle Einsatzbedingungen. Du weißt beispielsweise, welche Unternehmen die Anwendung nutzen. Für die Bewertung müssen diese Informationen zusammenkommen.

Bei mawu halten wir Anforderungen und technische Umsetzung vor der Entwicklung schriftlich fest. Auch die Ergebnisse deiner CRA-Rollenklärung sollten in die Projektunterlagen einfließen, damit technische Aufgaben nicht offenbleiben. Unser Vorgehen von der Konzeption bis zur Wartung beschreibt den Rahmen der Zusammenarbeit, keine rechtliche CRA-Prüfung.

Was solltest du bei einem Sicherheitshinweis tun?

Erfasse den Hinweis, schalte den technischen Ansprechpartner ein und stoße bei möglicher Betroffenheit die Meldeprüfung an. Die folgenden Schritte sind praktische Empfehlungen, kein vollständiger Katalog gesetzlicher Anforderungen.

Den ursprünglichen Hinweis sichern

Bewahre die Nachricht auf und notiere den Eingangszeitpunkt. Halte fest, welche Anwendung und welche Funktion betroffen sein könnten. „Beim Export erscheinen fremde Datensätze“ hilft der Untersuchung mehr als „Die Software ist unsicher“.

Trenne beobachtete Fehler von Vermutungen. Verteile mögliche sensible Daten nicht unnötig per E-Mail oder Messenger weiter.

Die technische Untersuchung koordinieren

Lass den Entwicklungspartner prüfen, welche Versionen betroffen sein könnten und welche Aufzeichnungen verfügbar sind. Protokolle sind technische Aufzeichnungen über Ereignisse in einem System. Sie können etwa zeigen, wann Zugriffe oder Änderungen stattgefunden haben.

Unkoordinierte Änderungen können solche Spuren überschreiben. Benenne deshalb eine Person, die Untersuchung und Schutzmaßnahmen abstimmt. Das darf nötige Maßnahmen gegen einen laufenden Angriff nicht verzögern.

Die Meldeprüfung nicht liegen lassen

Für CRA-Meldungen beschreibt die ENISA die gemeinsame EU-Meldeplattform. Kläre anhand der offiziellen Informationen und bei Bedarf mit rechtlicher Unterstützung, welche Fristen und Angaben im konkreten Fall gelten.

Bereite Zuständigkeiten und nötige Zugänge vor, bevor ein Vorfall eintritt. Eine Meldung sollte nicht daran scheitern, dass niemand weiß, wer sie bearbeiten soll.

Nimm jetzt deine angebotenen Softwareprodukte durch und notiere die offenen Fragen zur Herstellerrolle. Vereinbare mit deinem Entwicklungspartner, wer die technische Beschreibung liefert und wer die rechtliche Einordnung veranlasst.