Der Cyber Resilience Act betrifft weit mehr Unternehmen als klassische Softwarehersteller. Doch welche Produkte fallen darunter und was ist jetzt zu tun? Wir zeigen, welche technischen und organisatorischen Maßnahmen Unternehmen vorbereiten sollten – von der Produktentwicklung bis zum Umgang mit Schwachstellen.
Der Cyber Resilience Act ist längst keine abstrakte EU-Regulierung mehr. In unserem vorherigen Beitrag haben wir betrachtet, was der CRA für Unternehmen bedeutet und ob die neuen Vorgaben tatsächlich zu mehr Sicherheit führen oder vor allem zusätzliche Bürokratie schaffen.
Die Antwort darauf betrifft weit mehr als die IT-Abteilung. Software steckt heute in Maschinen, Gebäudetechnik, Messgeräten, Steuerungen und zahlreichen anderen Produkten. Geräte kommunizieren mit Netzwerken, erhalten Updates über das Internet oder werden über Apps konfiguriert. Gleichzeitig basieren viele Produkte auf Betriebssystemen, Open-Source-Bibliotheken und Komponenten von Drittanbietern.
Eine Schwachstelle in einer einzigen dieser Komponenten kann damit Auswirkungen auf zahlreiche Produkte und deren Anwender haben.
Genau hier setzt der Cyber Resilience Act an. Cybersecurity soll nicht erst betrachtet werden, wenn eine Schwachstelle bekannt oder ein Produkt bereits angegriffen wurde. Sicherheit muss über den gesamten Produktlebenszyklus berücksichtigt werden – von Planung und Entwicklung über die Bereitstellung bis zu Updates und der Behandlung später entdeckter Schwachstellen.
Für Geschäftsführung und IT-Verantwortliche bedeutet das: Der CRA lässt sich nicht durch ein zusätzliches Security-Tool oder ein einmaliges Compliance-Projekt erfüllen. Gefordert sind beherrschbare Produkte, klare Verantwortlichkeiten und belastbare Entwicklungs- und Sicherheitsprozesse.
Ein verbreiteter Irrtum besteht darin, den CRA ausschließlich als Regulierung für Softwareunternehmen zu betrachten.
Entscheidend ist jedoch nicht die Branche eines Unternehmens, sondern das Produkt.
Der CRA betrifft grundsätzlich Produkte mit digitalen Elementen, die auf dem europäischen Markt bereitgestellt werden. Dazu können sowohl Hardware als auch Software gehören.
Ein klassischer Maschinenbauer kann deshalb genauso betroffen sein wie ein Softwareunternehmen. Das gilt beispielsweise für eine Produktionsmaschine mit Fernwartungszugang, eine Heizungssteuerung, die über eine App konfiguriert wird, oder ein elektronisches Zutrittssystem mit Netzwerkverbindung. Ebenso kann ein Anbieter kommerzieller Desktop- oder Unternehmenssoftware in den Anwendungsbereich fallen.
Weitere Beispiele reichen von IoT-Geräten und Netzwerkkomponenten über Embedded-Systeme und Messgeräte bis hin zu elektronischen Produkten mit eigener Firmware oder Kommunikationsschnittstellen.
Entscheidend ist also nicht, ob sich ein Unternehmen selbst als IT- oder Softwareunternehmen versteht. Entscheidend ist, welche digitalen Funktionen seine Produkte besitzen und unter welcher Verantwortung diese auf dem europäischen Markt bereitgestellt werden.
Auch die eigene Rolle innerhalb der Lieferkette muss berücksichtigt werden. Neben Herstellern sieht der CRA Verpflichtungen für Importeure und Händler vor. Wer Produkte unter dem eigenen Namen oder der eigenen Marke vermarktet oder wesentlich verändert, kann unter bestimmten Voraussetzungen selbst Herstellerpflichten übernehmen.
Die erste Frage für Unternehmen sollte deshalb nicht lauten:
„Sind wir ein Softwareunternehmen?“
Sondern:
„Welche unserer Produkte enthalten digitale Elemente und welche Verantwortung übernehmen wir dafür?“
Die wesentlichen Anforderungen des Cyber Resilience Act gelten ab dem 11. Dezember 2027. Ein wichtiger Teil greift jedoch bereits früher.
Seit dem 11. September 2026 gelten bestimmte Berichtspflichten für aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle.
Damit ist die Vorbereitung keine Aufgabe für irgendwann im Jahr 2027.
Viele der notwendigen Voraussetzungen lassen sich zudem nicht kurzfristig schaffen. Weiß ein Unternehmen heute beispielsweise nicht zuverlässig, welche Softwarekomponenten in welchen Produktversionen eingesetzt werden, fehlen diese Informationen auch dann, wenn morgen eine kritische Schwachstelle veröffentlicht wird.
Gleiches gilt für Verantwortlichkeiten, Dokumentation und den Umgang mit Sicherheitsvorfällen.
Der erste Schritt sollte deshalb weder die Anschaffung eines neuen Security-Tools noch ein umfangreiches Audit sein. Zunächst braucht es eine strukturierte Bestandsaufnahme.
Welche Produkte könnten betroffen sein? Welche Software und Komponenten enthalten sie? Wie werden Sicherheitsanforderungen heute berücksichtigt? Wie werden Schwachstellen erkannt und behandelt? Und wer trägt dafür die Verantwortung?
Darauf aufbauend sollten Unternehmen insbesondere fünf Bereiche betrachten.
Sicherheit darf nicht erst am Ende der Entwicklung geprüft werden.
Architekturentscheidungen, Authentifizierung und Berechtigungen, sichere Standardkonfigurationen, Updatefähigkeit sowie der Schutz von Daten und Schnittstellen müssen bereits bei Konzeption und Entwicklung berücksichtigt werden.
Cybersecurity wird damit zu einer regulären Produktanforderung.
Kaum ein digitales Produkt besteht ausschließlich aus selbst entwickelter Software. Betriebssysteme, Open-Source-Bibliotheken, Frameworks, Firmware oder Komponenten von Lieferanten gehören häufig dazu.
Unternehmen müssen deshalb nachvollziehen können, was in ihren Produkten tatsächlich eingesetzt wird.
Wird beispielsweise eine kritische Schwachstelle in einer verwendeten Bibliothek bekannt, muss schnell beantwortet werden können: Welche Produkte und Versionen sind betroffen? Ist die Schwachstelle tatsächlich ausnutzbar? Gibt es ein Update?
Ohne Transparenz über Komponenten und Abhängigkeiten wird diese Bewertung unnötig schwierig.
Schwachstellen müssen nicht nur gefunden, sondern strukturiert behandelt werden.
Dazu braucht es Prozesse für Aufnahme, Bewertung, Priorisierung und Behebung sowie für die Bereitstellung von Sicherheitsupdates.
Ebenso muss klar sein, wer innerhalb des Unternehmens verantwortlich ist und wie externe Hinweise auf Sicherheitsprobleme entgegengenommen und bearbeitet werden.
Der CRA sieht für bestimmte Sicherheitsereignisse kurze Meldefristen vor.
Unternehmen sollten deshalb nicht erst während eines Vorfalls klären, wer die Situation bewertet, welche Informationen benötigt werden, wer Entscheidungen trifft und wer die notwendigen Meldungen übernimmt.
Ein funktionierender Incident-Response-Prozess wird damit zu einem wichtigen Bestandteil der CRA-Vorbereitung.
Der CRA verlangt nicht nur Maßnahmen. Unternehmen müssen deren Umsetzung auch nachvollziehbar dokumentieren können.
Risikobewertungen, Architekturinformationen, verwendete Komponenten, Sicherheitsmaßnahmen und relevante Entscheidungen sollten deshalb möglichst aus den bestehenden Entwicklungs- und Produktprozessen heraus dokumentiert werden.
Wer diese Informationen erst kurz vor einer Konformitätsbewertung zusammentragen muss, schafft zusätzlichen Aufwand und riskiert Lücken.
Genau an diesem Punkt wird deutlich, warum der Cyber Resilience Act nicht einfach an die IT- oder Entwicklungsabteilung delegiert werden kann.
Produktmanagement muss Produktlebenszyklen und Supportzeiträume berücksichtigen. Entwicklung und Architektur müssen Sicherheitsanforderungen umsetzen. Einkauf und Lieferantenmanagement müssen Abhängigkeiten von Komponenten und Herstellern im Blick behalten. Qualitätsmanagement und Dokumentation müssen die notwendigen Nachweise gewährleisten.
Die Geschäftsführung wiederum muss sicherstellen, dass Verantwortlichkeiten, Prozesse und notwendige Ressourcen vorhanden sind.
Der CRA ist damit nicht nur eine technische Herausforderung. Er betrifft die Art und Weise, wie Unternehmen digitale Produkte entwickeln, bereitstellen und über Jahre betreuen.
Die gute Nachricht ist: Die meisten Unternehmen beginnen beim Cyber Resilience Act nicht bei null.
Entwicklungsprozesse, Qualitätsmanagement, Security-Maßnahmen und technische Dokumentationen existieren häufig bereits. Entscheidend ist nun herauszufinden, welche Anforderungen damit bereits abgedeckt werden und wo tatsächlich Lücken bestehen.
Genau dabei unterstützen wir Unternehmen.
Wir betrachten gemeinsam die betroffenen Produkte, ihre Software- und Systemarchitektur sowie bestehende Entwicklungs-, Sicherheits- und Dokumentationsprozesse. Daraus entsteht keine allgemeine CRA-Checkliste, sondern ein konkretes Bild davon, was bereits vorhanden ist, wo Handlungsbedarf besteht und welche Maßnahmen als Nächstes sinnvoll sind.
Gemeinsam prüfen wir, welche Produkte betroffen sein können, welche Anforderungen bereits berücksichtigt werden und welche technischen und organisatorischen Maßnahmen für eine strukturierte Vorbereitung auf den CRA notwendig sind.
Ich bin Jochen Kärcher, Solution Architect und Unternehmer mit über 22 Jahren Erfahrung in der Entwicklung komplexer Web- und Cloud-Systeme. Mein Fokus liegt auf Softwarearchitektur, technischer Leitung sowie der strategischen Umsetzung digitaler Projekte.
In unterschiedlichen Rollen – als Entwickler, Projektmanager, Gründer und Geschäftsführer – habe ich technische Systeme konzipiert, Teams aufgebaut und Prozesse strukturiert. Dabei lege ich besonderen Wert auf skalierbare Architekturen, moderne Technologien und nachhaltige Lösungen an der Schnittstelle von Technologie und Unternehmensstrategie.
