Cyber Resilience Act: Was dem Mittelstand jetzt noch fehlt
Was der Cyber Resilience Act eigentlich regelt
Der Cyber Resilience Act, kurz CRA, ist eine EU-Verordnung, die erstmals verbindliche Cybersicherheitsanforderungen an Produkte mit digitalen Elementen stellt. Gemeint sind damit nicht nur klassische Software-Produkte, sondern alles, was Code enthält und mit einem Netzwerk oder einem anderen Gerät kommunizieren kann. Das reicht von der smarten Steuerung in der Produktionsanlage über vernetzte Sensoren bis hin zu Software, die ein Unternehmen selbst entwickelt und verkauft oder in eigene Produkte einbaut.
Der Grundgedanke dahinter ist einfach: Sicherheit soll nicht erst nachträglich draufgesetzt werden, wenn ein Produkt schon auf dem Markt ist, sondern von Anfang an mitgedacht werden, über den gesamten Lebenszyklus hinweg. Das betrifft die Entwicklung, die Auslieferung und vor allem die Zeit danach, wenn Sicherheitslücken auftauchen und Updates bereitgestellt werden müssen. Genau hier liegt für viele Unternehmen der wunde Punkt, denn ein Produkt einmal zu bauen ist etwas anderes, als es über Jahre hinweg sicher zu pflegen.
Die Verordnung ist bereits in Kraft, die vollständige Anwendung beginnt aber erst im Dezember 2027. Das klingt nach viel Zeit, ist es aber nicht, wenn man bedenkt, wie lange interne Prozesse, Dokumentationen und Lieferketten-Abstimmungen in der Praxis brauchen, bis sie wirklich funktionieren.
Warum Ende 2027 näher ist, als es wirkt
Ein häufiger Denkfehler ist, eine Frist in eineinhalb Jahren als komfortablen Puffer zu betrachten. In der Realität verschwindet dieser Puffer schnell, sobald man anfängt, die eigenen Prozesse ehrlich durchzugehen. Wer heute noch nicht genau weiß, welche Softwarekomponenten in den eigenen Produkten stecken, wer für Updates zuständig ist und wie im Ernstfall eine Sicherheitslücke gemeldet wird, steht am Anfang eines Prozesses, der typischerweise Monate dauert, nicht Wochen.
Hinzu kommt, dass viele Anforderungen des CRA nicht isoliert erfüllt werden können, sondern von Zulieferern, Dienstleistern und Software-Bibliotheken abhängen, die man selbst gar nicht komplett unter Kontrolle hat. Wer Software von Drittanbietern einbindet, muss auch deren Sicherheitszustand kennen und im Zweifel nachfragen, ob und wie lange diese Komponenten noch mit Updates versorgt werden. Diese Abstimmung mit der eigenen Lieferkette kostet Zeit, gerade wenn mehrere Zulieferer involviert sind und nicht alle gleich kooperativ oder gleich weit sind.
Wer erst kurz vor der Frist beginnt, riskiert, dass die eigene Vorbereitung an genau diesen externen Abhängigkeiten hängen bleibt, ohne dass man das noch kurzfristig lösen kann.
Meldepflichten: Der Teil, der viele überrascht
Ein zentraler Baustein des Cyber Resilience Act sind neue Meldepflichten. Werden aktiv ausgenutzte Sicherheitslücken oder schwerwiegende Sicherheitsvorfälle bei einem betroffenen Produkt bekannt, muss das an die zuständigen Behörden gemeldet werden, und zwar innerhalb enger zeitlicher Vorgaben. Das ist ein deutlicher Unterschied zur bisherigen Praxis, bei der viele Unternehmen Sicherheitsprobleme intern lösten, ohne dass es eine formale Meldepflicht nach außen gab.
Für ein Unternehmen bedeutet das zunächst eine organisatorische Frage: Wer im Betrieb erkennt überhaupt, dass eine gemeldete oder entdeckte Schwachstelle in einem eigenen Produkt relevant ist? Wer entscheidet, ob eine Meldepflicht ausgelöst wird? Und wer setzt diese Meldung dann fristgerecht um? In vielen kleineren und mittleren Unternehmen gibt es dafür bislang schlicht keinen definierten Prozess, weil das Thema Cybersicherheit oft bei einer einzelnen IT-Fachkraft oder einem externen Dienstleister nebenbei mitläuft.
Genau das ist der Punkt, an dem viele Betriebe aktuell noch Nachholbedarf haben. Es reicht nicht, im Ernstfall irgendwie zu reagieren, sondern es braucht vorher festgelegte Zuständigkeiten und Abläufe, damit die Frist überhaupt eingehalten werden kann. Ein durchdachtes Konzept für IT-Sicherheit sollte solche Meldewege deshalb von vornherein mitdenken, statt sie erst dann zu entwerfen, wenn der erste Vorfall schon passiert ist.
SBOM: Die Software-Stückliste als neue Pflichtübung
Der zweite große Stolperstein ist die sogenannte Software Bill of Materials, kurz SBOM. Man kann sich das wie eine Stückliste vorstellen, wie sie in der Produktion für physische Bauteile längst Standard ist, nur eben für Software. Eine SBOM listet auf, aus welchen Komponenten, Bibliotheken und Modulen ein Softwareprodukt tatsächlich besteht, inklusive der verwendeten Versionen.
Das klingt zunächst nach einer reinen Dokumentationsaufgabe, hat aber erhebliche praktische Konsequenzen. Wird beispielsweise in einer weit verbreiteten Programmbibliothek eine neue Sicherheitslücke bekannt, muss ein Unternehmen sehr schnell feststellen können, ob und wo diese Komponente in den eigenen Produkten steckt. Ohne eine gepflegte SBOM bedeutet das oft eine aufwendige manuelle Suche durch den gesamten Code, unter Zeitdruck, während die Lücke bereits öffentlich bekannt ist.
Viele Unternehmen, gerade wenn sie über Jahre gewachsene Software im Einsatz haben, kennen ihre eigene Codebasis in dieser Detailtiefe schlicht nicht mehr vollständig. Software wurde oft von wechselnden Entwicklern, externen Dienstleistern oder im Rahmen von Projekten mit Zeitdruck zusammengebaut, ohne dass jemand systematisch dokumentiert hat, welche Fremdkomponenten dabei verwendet wurden. Das jetzt nachträglich aufzuarbeiten ist möglich, aber es ist Arbeit, die Zeit braucht und am besten nicht erst unter dem Druck der auslaufenden Frist begonnen wird.
Wo der deutsche Mittelstand aktuell steht
Die aktuelle Lage lässt sich so zusammenfassen: Das Thema Cyber Resilience Act ist in vielen Unternehmen zwar grundsätzlich bekannt, aber die konkrete Umsetzung hinkt hinterher. Das betrifft insbesondere die beiden gerade beschriebenen Bereiche, Meldepflichten und SBOM, weil beide nicht mit einer einmaligen technischen Maßnahme erledigt sind, sondern dauerhafte Prozesse erfordern.
Das ist nachvollziehbar. Viele mittelständische Betriebe haben in den vergangenen Jahren bereits mit der NIS2-Richtlinie zu tun gehabt oder tun es noch, und der Cyber Resilience Act wirkt für sie wie ein weiteres Regelwerk, das obendrauf kommt. Tatsächlich überschneiden sich beide Themen in einigen Punkten, etwa bei der grundsätzlichen Frage nach Meldewegen und Risikomanagement, sodass sich Vorarbeiten aus dem einen Bereich oft auch für den anderen nutzen lassen. Wer sich bereits mit NIS2 & IT-Sicherheit beschäftigt hat, hat also keine doppelte Arbeit vor sich, sondern kann auf bestehenden Strukturen aufbauen.
Wichtig ist dabei, den Cyber Resilience Act nicht als reines Software-Thema für Hersteller zu betrachten. Auch Unternehmen, die eigene Anwendungen, Konfiguratoren, Kundenportale oder vernetzte Zusatzprodukte anbieten, obwohl das nicht ihr Kerngeschäft ist, können unter die Verordnung fallen. Wer beispielsweise eine eigene IoT-Komponente in seine Maschinen einbaut oder eine Software-Lösung als Zusatzprodukt verkauft, sollte frühzeitig prüfen, ob und in welchem Umfang der CRA für das eigene Geschäft relevant wird.
Was das für den Mittelstand bedeutet
Die gute Nachricht ist: Wer jetzt anfängt, hat noch genug Zeit, das sauber und ohne Hektik umzusetzen. Wer wartet, riskiert, kurz vor Dezember 2027 unter erheblichem Zeitdruck zu stehen, während gleichzeitig auch andere Unternehmen versuchen, dieselben knappen Ressourcen an Beratern und Dienstleistern zu binden. Ein paar konkrete Schritte helfen dabei, das Thema strukturiert anzugehen.
Zunächst lohnt sich eine ehrliche Bestandsaufnahme: Welche eigenen Produkte, Anwendungen oder vernetzten Komponenten enthalten Software, und wer im Unternehmen kennt deren technischen Aufbau tatsächlich im Detail? Diese Übersicht ist die Grundlage für alles Weitere und deckt oft schon erste blinde Flecken auf.
Darauf aufbauend sollte ein Unternehmen beginnen, für seine zentralen Softwareprodukte eine SBOM aufzubauen, auch wenn das zunächst nur für die wichtigsten Anwendungen geschieht. Es muss nicht sofort perfekt und vollständig sein, aber ein Anfang mit den kritischsten Systemen schafft schon einen erheblichen Vorsprung gegenüber dem Nichtstun.
Parallel dazu braucht es klare interne Zuständigkeiten für den Ernstfall: Wer erkennt eine relevante Sicherheitslücke, wer bewertet sie, und wer meldet sie fristgerecht an die richtige Stelle? Diese Rollen sollten nicht erst in der Krise verteilt werden, sondern vorher schriftlich festgelegt sein, idealerweise mit einer klaren Eskalationskette und Vertretungsregelung.
Auch der Blick auf die eigene Lieferkette gehört dazu. Wer Software oder Komponenten von Drittanbietern einsetzt, sollte frühzeitig klären, wie diese Anbieter selbst mit dem Thema umgehen und ob sie ihrerseits die notwendigen Informationen liefern können. Ein CRA-Gespräch mit den wichtigsten Lieferanten jetzt zu führen ist deutlich entspannter als eine Nachfrage kurz vor Ablauf der Frist.
Ergänzend kann ein unabhängiger Blick von außen helfen, die eigene Ausgangslage realistisch einzuschätzen. Ein Website-Audit deckt zum Beispiel auf, wie es um Sicherheit, Aktualität und technische Sauberkeit der eigenen digitalen Auftritte bestellt ist, und liefert damit oft auch erste Hinweise darauf, wo im Unternehmen grundsätzlicher Nachholbedarf bei Software-Pflege und Update-Prozessen besteht. Wer zudem eigene Anwendungen oder Kundenportale nicht selbst betreiben möchte, kann durch Managed Hosting sicherstellen, dass Updates, Patches und die laufende Absicherung der Infrastruktur professionell und dokumentiert erfolgen, was sich später auch bei den CRA-Nachweispflichten auszahlt.
Am Ende geht es beim Cyber Resilience Act nicht darum, in Panik zu verfallen, sondern darum, ein Thema, das ohnehin auf jeden zukommt, rechtzeitig und in überschaubaren Schritten anzugehen. Wer jetzt beginnt, verteilt den Aufwand über anderthalb Jahre statt ihn in den letzten Wochen vor der Frist zu bündeln.
Häufige Fragen
Ab wann gilt der Cyber Resilience Act verbindlich?
Die vollständige Anwendung der Verordnung beginnt im Dezember 2027. Einzelne Pflichten, etwa zu Meldewegen, können aber schon vorher relevant werden, weshalb sich eine frühzeitige Vorbereitung lohnt.
Betrifft der Cyber Resilience Act auch kleinere Mittelständler?
Ja, sofern ein Unternehmen Produkte mit digitalen Elementen entwickelt, verkauft oder in eigene Produkte integriert. Das kann auch für Betriebe gelten, deren Kerngeschäft eigentlich nicht die Softwareentwicklung ist, etwa wenn eine vernetzte Zusatzkomponente oder eine eigene Anwendung im Angebot ist.
Was genau ist eine SBOM?
Eine SBOM, also Software Bill of Materials, ist eine Art Stückliste für Software. Sie listet auf, aus welchen Komponenten und Versionen ein Softwareprodukt besteht, damit im Fall einer bekannt werdenden Sicherheitslücke schnell geprüft werden kann, ob die eigenen Produkte betroffen sind.
Was passiert, wenn eine Sicherheitslücke nicht rechtzeitig gemeldet wird?
Der Cyber Resilience Act sieht enge zeitliche Vorgaben für die Meldung aktiv ausgenutzter Schwachstellen und schwerwiegender Vorfälle vor. Wird diese Frist versäumt, drohen Konsequenzen im Rahmen der Verordnung, weshalb klare interne Zuständigkeiten für die Erkennung und Meldung solcher Fälle wichtig sind.
Wie hängen Cyber Resilience Act und NIS2 zusammen?
Beide Regelwerke betreffen Cybersicherheit, richten sich aber an unterschiedliche Bereiche. NIS2 betrifft vor allem den Betrieb kritischer und wichtiger Einrichtungen, während der CRA auf die Sicherheit von Produkten mit digitalen Elementen abzielt. In der Praxis überschneiden sich aber Themen wie Meldewege und Risikomanagement, sodass Vorarbeiten aus dem einen Bereich oft für den anderen genutzt werden können.
Wo sollte ein Unternehmen jetzt konkret anfangen?
Am Anfang steht eine ehrliche Bestandsaufnahme der eigenen Softwareprodukte und ihrer Komponenten. Darauf aufbauend sollten interne Zuständigkeiten für Meldepflichten festgelegt und der Aufbau einer SBOM für die wichtigsten Systeme begonnen werden, ergänzt durch Gespräche mit zentralen Software-Zulieferern.