Cyber Resilience Act: Seit 11. September 2026 gilt die Meldepflicht. Was heißt das für deine Software?

Seit dem 11. September 2026 müssen Hersteller von Software und vernetzten Produkten in der EU aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle melden. Grundlage ist der Cyber Resilience Act (CRA, Verordnung (EU) 2024/2847). Die Meldungen laufen über eine zentrale Plattform der ENISA, die Fristen sind kurz. Wer Software für andere herstellt, braucht deshalb jetzt einen Prozess, der eine Schwachstelle in Stunden erkennt, bewertet und meldet.

Dieser Artikel ordnet ein, was gilt, wer betroffen sein kann und welche Schritte du jetzt vorbereiten solltest. Er ersetzt keine Rechtsberatung.

Was verlangt der Cyber Resilience Act seit September 2026?

Der CRA tritt in Stufen in Kraft. Die erste wichtige Stufe ist seit dem 11. September 2026 wirksam: die Meldepflichten. Am selben Tag hat die ENISA ihre Single Reporting Platform gestartet.

Gemeldet werden müssen:

• aktiv ausgenutzte Schwachstellen in einem Produkt und
• schwerwiegende Sicherheitsvorfälle, die das Produkt betreffen.

Die Meldung geht über die Plattform an das CSIRT im Land des Hauptsitzes und an die ENISA. In Deutschland ist laut Bitkom das BSI zuständig.

Die volle Anwendung des CRA folgt am 11. Dezember 2027. Ab dann gelten auch die übrigen Anforderungen an Produkte, etwa an die sichere Entwicklung und die Versorgung mit Sicherheitsupdates.

Welche Fristen gelten?

Laut einer Einordnung der Kanzlei Hogan Lovells gilt ein dreistufiges Verfahren:

Schritt	Frist
Frühwarnung	innerhalb von 24 Stunden
Meldung	innerhalb von 72 Stunden
Abschlussbericht	14 Tage nach verfügbarer Korrektur (Schwachstelle) bzw. 1 Monat nach der Meldung (Vorfall)

Ebenfalls laut Hogan Lovells gelten die Pflichten auch für Produkte, die schon vor dem 11. September 2026 auf dem Markt waren. Rückwirkende Meldungen für frühere Ereignisse sind nicht nötig.

24 Stunden sind kurz. Wer erst nach einer Lücke anfängt zu überlegen, wer zuständig ist und wo man meldet, schafft das nicht.

Bin ich Hersteller im Sinne des CRA?

Hersteller ist, wer ein Produkt mit digitalen Elementen in der EU in Verkehr bringt. Das betrifft klar zum Beispiel Software, die du verkaufst oder lizenzierst, und vernetzte Geräte mit Software.

Schwieriger ist die Einordnung bei Individualentwicklung für einen einzelnen Kunden und bei reinen SaaS-Angeboten. Hier kann die Bewertung je nach Fall anders ausfallen. Diese Frage solltest du im Einzelfall juristisch prüfen lassen. Wir sind keine Kanzlei und geben hier bewusst keine pauschale Antwort.

Unabhängig von der rechtlichen Einordnung gilt: Die Fähigkeiten, die der CRA verlangt, sind gute Praxis für jede Software im Einsatz. Wer sie hat, ist auch ohne Meldepflicht besser geschützt.

Wie gut sind Unternehmen vorbereitet?

Laut einer Bitkom-Umfrage vom September 2026 unter 1.003 Unternehmen wissen nur 29 Prozent, was der CRA für sie bedeutet. 28 Prozent kennen ihn gar nicht.

Gleichzeitig steigt der Druck. Laut BSI-Lagebericht 2025 kamen durchschnittlich 119 neue Schwachstellen pro Tag hinzu, rund 24 Prozent mehr als im Vorjahr. Von 950 angezeigten Ransomware-Angriffen richteten sich laut BSI 80 Prozent gegen kleine und mittlere Unternehmen. Das BSI fordert, das Management der eigenen Web-Angriffsfläche so selbstverständlich zu machen wie Virenschutz.

Wie schnell es ernst werden kann, hat der Oktober 2026 gezeigt: Die Lücke PHP2Shell betraf praktisch jede PHP-Installation, das BSI stufte sie als „Orange“ ein, Angriffsversuche gab es schon am Tag des Patches.

Wie hängen CRA und NIS2 zusammen?

Die beiden Regelwerke ergänzen sich. Der CRA regelt Produkte. NIS2 regelt Unternehmen in wichtigen Sektoren und deren eigene IT-Sicherheit.

In Deutschland ist das NIS2-Umsetzungsgesetz seit dem 6. Dezember 2025 in Kraft. Seitdem beaufsichtigt das BSI deutlich mehr Unternehmen. Betroffene Unternehmen müssen sich beim BSI registrieren. Ob dein Unternehmen dazugehört, kannst du mit der Betroffenheitsprüfung des BSI klären.

Ein Unternehmen kann also gleichzeitig unter NIS2 fallen, weil es in einem regulierten Sektor arbeitet, und unter den CRA, weil es Software herstellt.

Was solltest du jetzt vorbereiten?

Diese Schritte sind sinnvoll, egal wie die rechtliche Prüfung ausgeht:

1. Ansprechpartner festlegen. Wer entscheidet, ob eine Schwachstelle gemeldet wird? Wer meldet? Wer vertritt diese Person im Urlaub? Diese Fragen müssen vor dem Ernstfall beantwortet sein.

2. Schwachstellenprozess aufsetzen. Wie erfährst du von Lücken in deiner Software und in den genutzten Komponenten? Wie bewertest du sie? Wie schnell spielst du Korrekturen aus? Ein einfaches, gelebtes Verfahren schlägt ein dickes Handbuch, das niemand kennt.

3. Komponenten kennen (SBOM). Eine Software Bill of Materials listet alle Bibliotheken und Pakete in deiner Software. Ohne sie weißt du bei einer neuen Lücke nicht, ob du betroffen bist. Für npm- und Composer-Projekte lässt sich eine SBOM automatisch im Build erzeugen.

4. Update-Fähigkeit sicherstellen. Eine Korrektur nützt nur, wenn sie schnell bei allen Installationen ankommt. Dazu gehören unterstützte Laufzeitversionen. Software auf Node.js 20 oder bald PHP 8.2 bekommt für neue Lücken in der Laufzeit keine Patches mehr.

5. Lieferkette absichern. Viele aktuelle Angriffe kommen über manipulierte Pakete. Wie du dich dagegen schützt, steht im Artikel zu Supply-Chain-Angriffen über npm und Composer.

6. Rechtlich einordnen lassen. Kläre mit einer Fachkanzlei, ob und wie weit deine Produkte und Leistungen unter den CRA fallen. Mit den Schritten 1 bis 5 hast du dafür schon eine gute Grundlage.

Wie HR CodeLabs dir hilft

Wir sind Softwareentwickler, keine Juristen. Aber wir können dafür sorgen, dass die technische Seite steht, wenn es darauf ankommt:

• Sicherheits-Check: Wir prüfen deine Anwendungen, Server und Abhängigkeiten auf bekannte Lücken und veraltete Versionen und erstellen auf Wunsch eine SBOM.
• Update- & Wartungsservice: Wir spielen Sicherheitsupdates zeitnah ein, überwachen neue Meldungen und dokumentieren, was wann gepatcht wurde.
• Migration alter Versionen: Wir bringen Software auf unterstützte PHP- und Node.js-Versionen, damit Korrekturen überhaupt möglich sind.
• Notfallhilfe nach Angriff: Wenn eine Lücke ausgenutzt wurde, helfen wir beim Eingrenzen und Beheben und liefern die technischen Informationen, die du für eine Meldung brauchst.

Mehr dazu auf der Seite Sicherheit & Wartung. Oder du buchst ein kostenloses Erstgespräch und wir schauen gemeinsam, wo deine Software heute steht.