Das Wichtigste zum Cyber Resilience Act für Softwareunternehmen
- Der Cyber Resilience Act betrifft nicht nur Hardware, sondern auch viele Softwareprodukte.
- Software gilt als CRA-relevant, sobald sie Daten verarbeitet, kommuniziert oder aktualisiert wird.
- Hersteller müssen Security-by-Design, Schwachstellenmanagement, SBOMs und Meldeprozesse etablieren.
- Wer früh handelt, erfüllt nicht nur regulatorische Anforderungen, sondern erhöht auch Sicherheit und Kundenvertrauen.
Warum Softwareunternehmen den Cyber Resilience Act nicht ignorieren können
Auf den ersten Blick scheint der Cyber Resilience Act nur für Hardwarehersteller relevant zu sein. In der EU-Verordnung ist von „Produkten mit digitalen Elementen“ die Rede – das klingt zunächst nach vernetzten Geräten, Maschinen oder IoT-Systemen. Viele Softwareunternehmen sehen sich eher als Dienstleister oder Betreiber digitaler Services. Sie stellen nichts Physisches her und glauben daher, der CRA spiele für sie keine Rolle.
Tatsächlich bestätigt der Wortlaut diesen Eindruck teilweise: Reine Dienstleistungen wie SaaS-Angebote, die nicht als Produkt auf dem Markt bereitgestellt werden, sind ausgenommen. Ebenso nicht-kommerzielle Open-Source-Software. Doch dieser erste Eindruck trügt.
Warum auch Softwareprodukte unter den CRA fallen
Artikel 3 des CRA definiert bewusst sehr breit, was ein „Produkt mit digitalen Elementen“ ist: Software oder Hardware – inklusive einzelner Softwarekomponenten. Damit fällt Software in den Geltungsbereich, sobald sie Daten sendet, empfängt oder verarbeitet, über Updates nachgeladen wird, mit anderen Systemen kommuniziert oder als Komponente in ein anderes Produkt integriert wird.
Typische Beispiele sind Apps mit Cloud-Anbindung, Systeme mit Online-Lizenzierung, Backend-Dienste oder APIs, die Daten austauschen, und Softwaremodule in größeren Plattformen oder Fahrzeugservices. Der CRA ist also kein reines Hardware-Gesetz, sondern ein Sicherheitsstandard für moderne, vernetzte Software.
Welche CRA-Anforderungen gelten konkret für Softwarehersteller?
In Artikel 13 und 14 legt der CRA klare Anforderungen fest, die auch für Softwareentwickler gelten: Dazu zählen die Einhaltung grundlegender Sicherheitsanforderungen, die Durchführung einer Konformitätsbewertung, die Erstellung technischer Dokumentation sowie Meldepflichten bei Schwachstellen und Sicherheitsvorfällen.
Für viele Softwareteams bedeutet dies, dass Security-by-Design, aktives Schwachstellenmanagement und strukturierte Lifecycle-Prozesse verpflichtend werden.
Wie der CRA die Unternehmensprozesse verändert
Der CRA betrifft jedes Produkt, das digital kommuniziert – und damit auch die meisten modernen Softwarelösungen. Unternehmen sollten frühzeitig prüfen, welche Produkte in den Geltungsbereich fallen, wer intern als „Hersteller“ im Sinne des CRA gilt und wie sich Security-by-Design, Schwachstellenmanagement und Dokumentation effizient etablieren lassen. Die Übergangsfrist bis 2027 mag großzügig erscheinen, doch besonders bei Prozessen, die erst aufgebaut werden müssen, ist frühes Handeln entscheidend.
Wie setzen wir die CRA-Anfoderungen in der Praxis um?
Unsere Erfahrungen zeigen, wie komplex die Umsetzung der CRA-Anforderungen sein kann – insbesondere im Umgang mit Sicherheitslücken (CVEs) in Software und Drittbibliotheken. In den letzten Jahren haben wir systematisch CVEs analysiert und bewertet, unter anderem mit einem internen Virenscanner. Kritische Lücken, etwa in Drittbibliotheken wie Log4J, werden sofort priorisiert und zeitnah direkt an betroffene Kunden kommuniziert. Besonders wichtig ist dies für On-Prem-Kunden, da sie selbst für die Umsetzung von Updates verantwortlich sind.
Nicht ausnutzbare Lücken werden intern zwar bewertet und behoben, jedoch nicht sofort weitergegeben. Mit dem neuen öffentlichen Prozess nach CRA und BSI ändert sich dies: Zukünftig müssen CVEs über einen offiziellen BSI-Account gemeldet werden, auch wenn sie intern als nicht kritisch eingestuft werden. Die interne Risikoeinschätzung bestimmt also nur die Dringlichkeit der Kundeninformation, nicht die Meldung selbst.
Darüber hinaus erstellen wir eine aktuelle Software Bill of Materials (SBOM). So können wir jederzeit nachweisen, mit welchen Bibliotheken und Komponenten unser Produkt entwickelt wurde. Dieser praxisnahe Ansatz zeigt, dass Sicherheitsprozesse, transparente Kommunikation und offizielle Meldungen entscheidend sind, um sowohl Compliance als auch Kundensicherheit zu gewährleisten.
Fazit: Der CRA – Ein Gamechanger für die Softwareentwicklung
Der CRA setzt neue Maßstäbe für die digitale Produktentwicklung. Unternehmen, die sich frühzeitig anpassen, sichern sich Wettbewerbsvorteile und stärken das Vertrauen ihrer Kunden. Software ist nicht außen vor – im Gegenteil: Viele moderne Softwarelösungen sind direkt betroffen, weil sie Daten austauschen, Updates ausliefern oder in größere Systeme integriert werden. Unternehmen, die den CRA heute verstehen und smart in ihre Prozesse integrieren, entwickeln nicht nur compliant, sondern auch sicherer, transparenter und nachhaltiger.
FAQ: Häufige Fragen zum Cyber Resilience Act und Software
Gilt der Cyber Resilience Act für reine Softwareprodukte?
- Ja. Der CRA gilt für Software, sobald sie als Produkt mit digitalen Elementen gilt – also Daten verarbeitet, kommuniziert, aktualisiert wird oder Teil eines größeren Systems ist.
Ist SaaS vom Cyber Resilience Act betroffen?
- Reine SaaS-Dienstleistungen sind grundsätzlich ausgenommen. Sobald Software jedoch als Produkt vermarktet oder in andere Produkte integriert wird, kann der CRA greifen.
Was müssen Softwarehersteller unter dem CRA konkret umsetzen?
- Dazu gehören Security-by-Design, Schwachstellenmanagement, technische Dokumentation, Konformitätsbewertung sowie Meldepflichten bei Sicherheitslücken und Vorfällen.
Was ist eine SBOM und warum ist sie unter dem CRA wichtig?
- Eine Software Bill of Materials dokumentiert alle verwendeten Bibliotheken und Komponenten. Sie ist entscheidend, um Sicherheitsrisiken transparent zu machen und CRA-Compliance nachzuweisen.
Ab wann gilt der Cyber Resilience Act verbindlich?
- Der CRA sieht Übergangsfristen bis 2027 vor. Unternehmen sollten diese Zeit nutzen, um Prozesse und Strukturen frühzeitig aufzubauen.
