Produktverantwortung in der Geschäftsführung: Cyber Resilience Act für Hersteller

Eine Geschäftsführung plant die Markteinführung eines neuen vernetzten Geräts, etwa eines smarten Steuerungsmoduls für die Industrie oder eines IoT-Sensors für den Gebäudebetrieb. Bislang lag die Frage nach Sicherheitslücken meist bei der Entwicklungsabteilung.

Mit dem Cyber Resilience Act verschiebt sich diese Verantwortung spürbar nach oben: Sicherheit wird zur Aufgabe der Unternehmensleitung, nicht mehr nur zur Spezialfrage der Technik. Wer digitale Produkte entwickelt, herstellt oder vertreibt, muss sich künftig mit Nachweispflichten, Fristen und Haftungsfragen auseinandersetzen, die weit über klassische Produktprüfungen hinausgehen. Der folgende Beitrag ordnet ein, was dahintersteckt, wen es betrifft und welche organisatorischen Schritte sich daraus ableiten lassen.

Warum der Cyber Resilience Act zur Chefsache wird

Der Cyber Resilience Act verlangt Sicherheit über den gesamten Lebenszyklus eines digitalen Produkts, von der ersten Entwicklungsphase bis zur Außerbetriebnahme. Das unterscheidet den Ansatz von älteren Regelungen, die meist nur den Zustand eines Produkts bei der Markteinführung betrachteten. Künftig muss ein Hersteller auch nachweisen können, wie er mit neu entdeckten Schwachstellen nach dem Verkauf umgeht, wie lange er Sicherheitsupdates bereitstellt und wie er Vorfälle dokumentiert.

Diese Logik hat eine organisatorische Konsequenz, die viele Unternehmen unterschätzen: Die Verantwortung für die Einhaltung liegt nicht bei einzelnen Entwicklerteams, sondern bei der Unternehmensleitung als Ganzes.

Wer Sicherheitsanforderungen nur als technisches Detailproblem behandelt, läuft Gefahr, Fristen und Dokumentationspflichten zu verpassen, weil niemand die Gesamtverantwortung trägt. Ein Entwicklerteam kann einen Code-Fehler beheben, aber es kann keine unternehmensweite Nachweiskette für Lieferanten, Komponenten und Update-Prozesse aufbauen. Das ist eine Führungsaufgabe, die Ressourcen, Budget und klare Zuständigkeiten braucht.

Fehlt diese Verankerung auf Leitungsebene, entstehen typischerweise zwei Probleme: Zum einen bleiben Zuständigkeiten diffus, sodass niemand den Überblick über alle betroffenen Produktlinien hat. Zum anderen fehlt die Priorisierung gegenüber anderen Projekten, weil Sicherheitsarbeit ohne Rückhalt der Leitung regelmäßig hinter Feature-Entwicklung zurückfällt. Genau deshalb gehört der Cyber Resilience Act in die Geschäftsleitung, nicht in ein isoliertes IT-Ticket.

Welche digitalen Produkte unter den Cyber Resilience Act fallen

Digitale Produkte mit Netzwerk- oder Datenverbindung fallen grundsätzlich in den Geltungsbereich des Cyber Resilience Act. Das betrifft nicht nur klassische Software, sondern auch physische Geräte, die über eine Schnittstelle Daten senden oder empfangen, etwa vernetzte Haushaltsgeräte, industrielle Steuerungskomponenten, Sicherheitskameras oder Firmware, die in größere Systeme eingebettet wird. Ausschlaggebend ist nicht die Branche, sondern die technische Eigenschaft der Konnektivität.

Komplizierter wird es dort, wo sich Zuständigkeiten mit bestehenden Regelwerken überschneiden.

Es bestehen Abgrenzungen zu anderen europäischen Rahmenwerken für Cybersicherheit, die im Einzelfall geprüft werden müssen, etwa wenn ein Produkt bereits unter spezifische sektorale Vorgaben fällt, beispielsweise für medizinische Geräte oder Fahrzeugkomponenten. In solchen Fällen greift häufig eine vorrangige Regelung, während der Cyber Resilience Act ergänzend wirkt. Eine pauschale Aussage, welches Regelwerk vorgeht, lässt sich ohne Blick auf das konkrete Produkt nicht treffen.

Diese Einordnung ist mehr als eine juristische Fleißaufgabe, denn sie entscheidet darüber, welche Nachweis- und Dokumentationspflichten tatsächlich greifen. Ein Hersteller, der ein Produkt falsch einordnet, läuft Gefahr, entweder unnötigen Aufwand zu betreiben oder umgekehrt Pflichten zu übersehen. In der Praxis empfiehlt sich deshalb eine Produktinventur: Welche Produktlinien haben eine Netzwerkanbindung, welche Komponenten stammen von Drittanbietern, und wo bestehen bereits Überschneidungen mit anderen Prüfverfahren. Diese Bestandsaufnahme ist der erste Schritt, bevor überhaupt über konkrete Sicherheitsmaßnahmen im Rahmen des Cyber Resilience Act gesprochen werden kann.

Secure Design Reviews und Penetrationstests: Der Weg zur Konformität mit dem Cyber Resilience Act

Secure Design Reviews und Penetrationstests bilden das praktische Rückgrat beim Nachweis der Konformität mit dem Cyber Resilience Act. Ein Secure Design Review untersucht die Architektur eines Produkts, bevor überhaupt viel Code geschrieben wurde: Wo liegen Schnittstellen zur Außenwelt, wie werden Zugangsdaten verwaltet, welche Annahmen über Vertrauenswürdigkeit trifft das System. Ein Penetrationstest setzt später an, wenn ein funktionsfähiges System oder ein Prototyp vorliegt, und prüft aktiv, ob sich Schwachstellen tatsächlich ausnutzen lassen. Beide Verfahren ergänzen sich: Das eine deckt strukturelle Schwächen auf, bevor sie teuer werden, das andere bestätigt oder widerlegt, ob die Umsetzung in der Praxis hält, was das Konzept verspricht.

Man stelle sich ein mittelständisches Unternehmen vor, das ein neues vernetztes Steuerungsmodul neun Monate vor der geplanten Markteinführung in die Entwicklung gibt. Würde die Sicherheitsprüfung erst kurz vor dem Launch angesetzt, bliebe im Zweifel keine Zeit mehr, um eine gefundene Architekturschwäche sauber zu beheben, ohne den Termin zu gefährden. Wird der Secure Design Review dagegen früh in der Konzeptphase eingeplant und der Penetrationstest rechtzeitig vor dem geplanten Produktionsstart, bleibt genug Spielraum, um Befunde in den regulären Entwicklungsprozess einzuarbeiten, statt sie als Nachbesserung unter Zeitdruck umzusetzen.

Eine strukturierte Begleitung über den gesamten Produktlebenszyklus reduziert genau dieses Risiko kurzfristiger Nachbesserungen vor der Markteinführung. Für diese Aufgabe greifen Unternehmen zunehmend auf spezialisierte Prüfdienstleister zurück: SySS bietet Penetrationstests, Code Reviews und Beratung zur Umsetzung des Cyber Resilience Act an und ist dabei selbst nach ISO 27001 zertifiziert.

Die frühzeitige Einbindung solcher spezialisierten Prüfprozesse schafft Planungssicherheit für Entwicklungs- und Zeitpläne, weil Sicherheitsarbeit dann als fester Baustein im Projektplan auftaucht und nicht als unkalkulierbares Risiko am Ende der Entwicklung.

Bußgelder, Marktausschluss und Haftung bei Verstößen gegen den Cyber Resilience Act

Verstöße gegen die Anforderungen des Cyber Resilience Act können zu empfindlichen Bußgeldern und Beschränkungen des Marktzugangs führen. Für ein Unternehmen bedeutet ein Marktausschluss in der Praxis mehr als nur eine verzögerte Markteinführung: Vertriebspartner, Ausschreibungen und laufende Lieferverträge können betroffen sein, wenn ein Produkt plötzlich nicht mehr verkauft werden darf, weil die geforderten Nachweise fehlen.

Parallel dazu gewinnen Produkthaftungsfragen durch die Anforderungen des Cyber Resilience Act zusätzliches Gewicht. Wenn ein Gerät wegen einer bekannten, aber nicht behobenen Schwachstelle einen Schaden verursacht, verschärft sich die Frage, ob der Hersteller seine Sorgfaltspflichten erfüllt hat. Entscheidend ist dabei regelmäßig, ob angemessene Maßnahmen zur Risikominimierung ergriffen und dokumentiert wurden, nicht ob ein Schaden grundsätzlich hätte verhindert werden können. Diese Abwägung macht deutlich, warum lückenlose Dokumentation nicht nur eine Formalie ist, sondern im Streitfall den Unterschied machen kann.

Reputationsschäden wirken häufig länger nach als unmittelbare finanzielle Sanktionen.

Ein Bußgeld lässt sich budgetieren und ist irgendwann beglichen. Der Vertrauensverlust bei Geschäftspartnern oder Endkunden, die von einer Sicherheitslücke in einem bereits verkauften Produkt erfahren, wirkt dagegen oft über Jahre nach, etwa in Form zurückhaltenderer Einkaufsentscheidungen oder strengerer Auditanforderungen in künftigen Ausschreibungen. Diese Kombination aus unmittelbarem wirtschaftlichem Risiko und langfristigem Vertrauensschaden ist der eigentliche Grund, warum der Cyber Resilience Act auf Ebene der Geschäftsführung verankert gehört und nicht als rein technische Fußnote behandelt werden sollte.

Praktische Empfehlungen für die Umsetzung des Cyber Resilience Act im Unternehmen

Eine strukturierte Umsetzung beginnt mit einer klaren Zuständigkeit, nicht mit einem Werkzeug oder einer Checkliste. Bevor über einzelne Prüfverfahren gesprochen wird, sollte feststehen, wer im Unternehmen die Gesamtverantwortung trägt und wer welche Teilaufgaben koordiniert. In der Praxis haben sich dafür einige wiederkehrende Schritte bewährt:

• Eine vollständige Inventur aller vernetzten Produktlinien und ihrer Softwarekomponenten, einschließlich Zulieferteile
• Eine frühe Risikoeinschätzung je Produktkategorie, um Prüfaufwand und Priorität sinnvoll zu verteilen
• Die Festlegung, welche Funktion im Unternehmen für Sicherheitsnachweise und Update-Prozesse dauerhaft zuständig ist
• Die Einplanung von Design Reviews und Tests als feste Meilensteine im Entwicklungsplan, nicht als Option am Ende

Diese Reihenfolge ist bewusst gewählt: Erst die Bestandsaufnahme, dann die Priorisierung, dann die organisatorische Zuordnung, erst zuletzt die konkrete technische Prüfung. Wird diese Abfolge umgedreht und zuerst in einzelne Tests investiert, ohne vorher zu wissen, welche Produkte überhaupt vom Cyber Resilience Act betroffen sind, entstehen Lücken, die später teuer nachgebessert werden müssen.

Häufig gestellte Fragen zum Cyber Resilience Act für Hersteller

Wie unterscheidet sich der Cyber Resilience Act von bestehenden IT-Sicherheitsgesetzen?

Bestehende Regelwerke adressieren häufig den Betrieb von IT-Infrastrukturen oder bestimmte Branchen, während der Cyber Resilience Act am Produkt selbst ansetzt, unabhängig davon, wer es später betreibt. Beide Ebenen können parallel relevant sein, weshalb eine Einzelfallprüfung je Produkt sinnvoll ist.

Wie viel Zeit sollte für die unternehmensinterne Umsetzung des Cyber Resilience Act eingeplant werden?

Der zeitliche Rahmen wird in der Praxis häufig unterschätzt, weil Sicherheitsnachweise nicht nachträglich aufgesetzt, sondern in bestehende Entwicklungsprozesse integriert werden müssen. Je früher Produktinventur, Risikobewertung und Prüfplanung beginnen, desto geringer ist der Druck kurz vor der Markteinführung.

Welche Abteilung sollte die Umsetzung des Cyber Resilience Act intern koordinieren?

Eine pauschale Antwort gibt es nicht, da dies von Unternehmensgröße und Produktportfolio abhängt. Entscheidend ist weniger die formale Zuordnung zu IT, Qualitätssicherung oder Compliance, sondern dass eine einzelne Stelle mit Rückhalt der Geschäftsführung den Gesamtüberblick über alle betroffenen Produktlinien behält.

Titelbild: Bild KI-generiert (Nano Banana 2)

Hinweis: Der Artikel wurde mit Unterstützung von KI erstellt und von uns redaktionell geprüft.