Cyber Resilience Act: BSI wird zuständige Behörde – was Softwarehersteller jetzt klären müssen

Wer für Kunden Software entwickelt – eine Buchhaltungslösung, ein Lagerverwaltungssystem, eine App für den Außendienst – fällt nach aktueller Rechtslage unter eine EU-Verordnung, die viele Geschäftsführer im Mittelstand noch nicht auf dem Schirm haben: den Cyber Resilience Act. Am 15. Oktober 2026 hat der Bundestag laut BSI-Pressemitteilung (öffnet in neuem Tab) das deutsche Durchführungsgesetz dazu verabschiedet und damit geklärt, wer hierzulande für die Durchsetzung zuständig ist: das Bundesamt für Sicherheit in der Informationstechnik (BSI). Für Unternehmen, die Software als Produkt verkaufen oder bereitstellen, ist das kein Randthema mehr, sondern der Moment, an dem aus einer abstrakten EU-Verordnung eine konkrete nationale Behörde mit Prüf- und Sanktionsbefugnis wird.

Was der CRA ist – und für wen er gilt

Der Cyber Resilience Act (öffnet in neuem Tab) (Verordnung (EU) 2024/2847) legt laut BSI erstmals EU-weit verbindliche Mindestanforderungen an die Cybersicherheit von „Produkten mit digitalen Elementen" fest. Das BSI nennt dabei ausdrücklich zwei Kategorien, die über klassische IoT-Hardware hinausgehen: vernetzte Hardwareprodukte wie Smartphones oder Smart-Meter-Gateways – und reine Softwareprodukte, als Beispiele führt das BSI explizit Buchhaltungssoftware, Computerspiele und mobile Apps an. Nicht-kommerzielle Open-Source-Software ist laut BSI ausgenommen; alles andere, was ein Unternehmen als Produkt in Verkehr bringt, grundsätzlich nicht.

Das deckt sich mit der Formulierung der EU-Verordnung selbst (öffnet in neuem Tab): Erfasst ist, was direkt oder indirekt mit einem Gerät oder Netzwerk verbunden werden kann – eine Definition, die praktisch jede B2B-Software trifft, die über das Internet kommuniziert, Updates nachlädt oder eine Cloud-Komponente besitzt. Wer dagegen nur eine eigene Website betreibt oder Software ausschließlich intern nutzt, ohne sie an Dritte zu vertreiben, fällt nach dieser Definition nicht automatisch darunter.

Die Fristen: zwei Daten, die bereits gelten, eine dritte, die ansteht

Der CRA wird laut BSI in Etappen bis Ende 2027 umgesetzt. Drei Termine sind für Unternehmen bereits relevant oder stehen unmittelbar bevor:

• Seit 11. September 2026 gilt die Meldepflicht für aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle. Hersteller müssen diese über eine zentrale ENISA-Plattform melden, mit gestaffelten Fristen von 24 Stunden für die Frühwarnung bis zu 14 Tagen für den Abschlussbericht.
• 15. Oktober 2026: Der Bundestag hat laut BSI das CRA-Durchführungsgesetz verabschiedet, das die Zuständigkeiten in Deutschland regelt. Laut Recherche von CRA Evidence (öffnet in neuem Tab) stand das Gesetz zum 6. November 2026 noch zur Befassung im Bundesrat – geplant für die Plenarsitzung am 20. November 2026 – und war zu diesem Zeitpunkt noch nicht im Bundesgesetzblatt verkündet. Unternehmen sollten sich also auf die Rolle des BSI einstellen, die formale Verkündung aber vor einer rechtsverbindlichen Einordnung noch abwarten.
• 11. Dezember 2027 greifen laut BSI alle übrigen CRA-Anforderungen vollständig: Konformitätsbewertung, CE-Kennzeichnung, vollständige technische Dokumentation.

Wer das mit der Übergangsfrist des EU AI Acts verwechselt, verwechselt zwei unterschiedliche Verordnungen mit unterschiedlichen Zeitplänen – ein Fehler, der in der Praxis vorkommt, weil beide Regelwerke zeitlich ineinandergreifen und beide „KI" beziehungsweise „digitale Produkte" adressieren. Der CRA betrifft die Cybersicherheit von Produkten, unabhängig davon, ob KI zum Einsatz kommt.

Was das BSI künftig konkret tut

Mit dem Durchführungsgesetz bekommt das BSI laut eigener Pressemitteilung fünf neue Aufgaben zugewiesen:

• Marktüberwachung: stichprobenartige oder gezielte Prüfung von Produkten, mit der Befugnis, Nachbesserungen zu verlangen, Sanktionen und Bußgelder zu verhängen und nicht konforme Produkte vom Markt zu nehmen.
• Notifizierende Behörde: Das BSI bestätigt die Kompetenz von Konformitätsbewertungsstellen, bei denen sich Hersteller prüfen lassen können, wenn ihr Produkt in eine höhere Risikoklasse fällt. Laut BSI-Verfahrensseite (öffnet in neuem Tab) läuft das Verfahren in der Regel über eine Akkreditierung durch die Deutsche Akkreditierungsstelle (DAkkS), die das BSI anschließend als notifizierende Stelle bestätigt.
• Zuständiges CSIRT: Seit dem 11. September 2026 koordiniert das BSI bereits die CRA-Meldungen für Deutschland.
• Beschwerdestelle für Verbraucherinnen und Verbraucher bei Verstößen gegen den CRA.
• Unterstützung für KMU: Das BSI kündigt ausdrücklich an, kleine und mittlere Unternehmen bei der Erfüllung der CRA-Anforderungen zu begleiten.

Diesen letzten Punkt nimmt das BSI bereits in die Praxis: Laut IHK Dresden (öffnet in neuem Tab) läuft noch bis zum 19. November 2026 eine anonyme Umfrage des BSI, mit der die Behörde ermitteln will, wo Unternehmen bei der CRA-Umsetzung Unterstützung brauchen.

Was auf dem Spiel steht

Verstöße gegen die grundlegenden Cybersicherheitsanforderungen (Anhang I der Verordnung) oder gegen die Pflichten aus den Artikeln 13 und 14 können laut EU-Verordnung (öffnet in neuem Tab) mit Bußgeldern von bis zu 15 Millionen Euro oder bis zu 2,5 Prozent des weltweiten Jahresumsatzes des vorangegangenen Geschäftsjahres geahndet werden – je nachdem, welcher Betrag höher ist. Für Verstöße gegen weitere Pflichten, etwa aus den Artikeln zur Meldepflicht oder Dokumentation, sieht die Verordnung bis zu 10 Millionen Euro oder 2 Prozent des Jahresumsatzes vor. Bei der Bemessung der Geldbuße muss die Behörde laut Verordnung die Größe des Unternehmens berücksichtigen, ausdrücklich auch Kleinst-, kleine und mittlere Unternehmen – das heißt aber nicht, dass KMU von der Pflicht selbst ausgenommen sind, nur dass die Bußgeldhöhe im Einzelfall anders bemessen werden kann.

Was für B2B-Softwarehersteller im Mittelstand praktisch zu tun ist

Die meisten Produkte, für die der CRA überhaupt relevant ist, fallen laut BSI in die Kategorie „Standardprodukte" – dafür reicht eine Selbstbewertung durch den Hersteller, keine externe Prüfstelle. Nur eine kleinere Gruppe „wichtiger" oder „kritischer" Produkte, etwa Passwortmanager oder Firewalls, braucht eine Drittstellenbewertung. Für die Mehrheit der Mittelständler, die eigene Fachsoftware entwickeln oder vertreiben, heißt das konkret:

1. Produktbestand klären. Welche selbst entwickelten oder vertriebenen Produkte haben eine Netzwerkverbindung oder Cloud-Komponente – und fallen damit unter den CRA-Anwendungsbereich? Diese Bestandsaufnahme ist die Grundlage für alles Weitere und sollte nicht erst beim ersten Prüfanruf des BSI entstehen.
2. Schwachstellen-Prozess benennen. Wer erkennt im Unternehmen eine aktiv ausgenutzte Schwachstelle im eigenen Produkt, wer ist für die Meldung über die ENISA-Plattform innerhalb von 24 Stunden verantwortlich? Diese Meldepflicht gilt bereits seit September 2026, unabhängig davon, wann das deutsche Durchführungsgesetz in Kraft tritt.
3. SBOM einplanen. Der CRA verlangt laut BSI eine Software Bill of Materials – ein Verzeichnis aller verwendeten Komponenten einschließlich Open-Source-Bibliotheken. Sie muss nicht veröffentlicht werden, aber vorliegen und aktuell gehalten werden.
4. Secure-by-Design und Secure-by-Default von der Entwicklung an mitdenken: verschlüsselte Datenübertragung, keine schwachen Standardpasswörter, automatische Sicherheitsupdates als Standardeinstellung.
5. Supportzeitraum definieren und kommunizieren. Der CRA verlangt kostenlose Sicherheitsupdates über die gesamte erwartete Produktlebensdauer, in der Regel fünf Jahre – dieser Zeitraum muss gegenüber den Kunden benannt werden.

Wer heute schon ein n8n-gestütztes Monitoring für Sicherheitsupdates betreibt oder Schwachstellen-Scans automatisiert, hat einen Teil der organisatorischen Vorarbeit bereits erledigt. Was fehlt, ist meist nicht die Technik, sondern die benannte Zuständigkeit: eine Person, die im Ernstfall weiß, dass die 24-Stunden-Uhr läuft, und die den Meldeweg kennt, bevor er gebraucht wird.

Ein naheliegender erster Schritt, der sich von der eigentlichen CRA-Meldepflicht unterscheidet, aber in dieselbe Richtung zielt: eine security.txt-Datei auf der eigenen Website, über die Sicherheitsforscher und CERTs überhaupt erst einen Kontakt finden. Die freiwillige Maßnahme ersetzt die CRA-Meldepflicht nicht, schafft aber einen Kanal, bevor eine Lücke öffentlich wird – wie dieser Beitrag im Detail beschreibt.

Wie sich der CRA zur NIS2-Richtlinie abgrenzt

Beide Regelwerke tauchen in Unternehmensgesprächen oft in einem Atemzug auf, regeln aber Unterschiedliches. Die NIS2-Richtlinie, in Deutschland über das BSI-Gesetz umgesetzt, verpflichtet laut BSI rund 29.500 als „besonders wichtig" oder „wichtig" eingestufte Einrichtungen zu Risikomanagementmaßnahmen für die eigene IT-Infrastruktur – sie betrifft also den Betrieb eines Unternehmens als Ganzes. Der CRA dagegen betrifft das Produkt: Wer Software oder vernetzte Hardware an Dritte verkauft oder bereitstellt, muss die Cybersicherheitsanforderungen dieses Produkts erfüllen, unabhängig davon, ob das eigene Unternehmen unter NIS2 fällt. Ein mittelständischer Softwarehersteller kann deshalb vom CRA betroffen sein, ohne eine NIS2-Einrichtung zu sein – und umgekehrt.

Fazit: Zuständigkeit ist geklärt, Vorlauf bleibt nötig

Mit dem Durchführungsgesetz ist die institutionelle Unklarheit beseitigt, die den CRA in Deutschland bislang begleitet hat – das BSI ist eine zentrale Anlaufstelle für Marktüberwachung, Notifizierung und Meldungen in einer Person, anders als etwa beim Datenschutz mit seinen Landesbehörden. Das reduziert laut mehreren Fachquellen den Interpretationsspielraum. Was es nicht ändert: Die Meldepflicht für Schwachstellen läuft bereits seit September 2026, und bis Dezember 2027 bleibt für die vollständige Konformitätsbewertung Vorlaufzeit, die sich am besten jetzt nutzen lässt – solange Prüfkapazitäten noch nicht knapp sind und der erste Ernstfall noch nicht eingetreten ist.