Der Cyber Resilience Act: Das sollten Hersteller digitaler Produkte wissen!

Mit dem Cyber Resilience Act (CRA, EU 2022/0272) hat die Europäische Union eine Verordnung geschaffen, die erstmals umfassende Cybersicherheitsanforderungen für Produkte mit digitalen Elementen vorschreibt. Ziel ist eine einheitliche Regelung innerhalb der EU, um die bisher fragmentierten Sicherheitsanforderungen zu harmonisieren.

Eine Ergänzung zur NIS2-Richtlinie

Der CRA versteht sich als produktbezogene Ergänzung zu bereits bestehenden Richtlinien, wie beispielsweise der Richtlinie zur Netzwerk- und Informationssicherheit (NIS2). Während NIS2 auf die Cybersicherheit kritischer Infrastrukturen abzielt, adressiert der CRA explizit vernetzte Produkte mit digitalen Elementen. Er gilt unmittelbar in allen EU-Mitgliedsstaaten und verpflichtet Hersteller, Importeure, Händler und Bevollmächtigte gleichermaßen, Security während des Designs, der Implementierung, des Testens und der Wartung stets zu berücksichtigen.

Ab Dezember 2027 verpflichtend

Spätestens ab Dezember 2027 dürfen nur noch Produkte mit digitalen Elementen auf den Markt gebracht werden, die den Anforderungen des CRA entsprechen. Dabei wird Sicherheit zur zentralen Produkteigenschaft. Hersteller müssen Risiken bewerten, Schutzmaßnahmen umsetzen und über den gesamten Lebenszyklus hinweg Sicherheitslücken beheben können.

Wer ist betroffen?

Der CRA gilt für alle Produkte, die ab 2027 auf den Markt gebracht werden und deren reguläre oder “vorhersehbare Verwendung eine [...] Datenverbindung mit einem Gerät oder Netz einschließt”. Ausgenommen sind Medizin-Produkte, Produkte der In-Vitro Diagnostik, Fahrzeuge, Produkte der Luft- und Schifffahrt, militärische Anwendungen oder Anwendungen der nationalen Sicherheit sowie Ersatzteile für Bestandsprodukte.

Aufbau

Wie viele andere Verordnungen enthält auch der CRA keine Inhaltsübersicht. Daher widme ich dem Aufbau einige Zeilen, damit es für den geneigten Leser leichter wird, sich im CRA zurecht zu finden.
Die Verordnung enthält insgesamt 130 Erwägungsgründe, 71 Artikel und acht Anhänge auf 81 DinA-4-Seiten.
Die Erwägungsgründe gehören nicht zum rechtsverbindlichen Teil des CRA. Dennoch empfehle ich die Durchsicht, weil hier viel über das Warum und den Kontext des CRAs nachzulesen ist.

Die 71 Artikel gliedern sich in folgende Themenbereiche:

• Allgemeine Bestimmungen
• Pflichten der Wirtschaftsakteure und Bestimmungen in Bezug auf freie und quelloffene Software
• Konformität des Produkts mit digitalen Elementen
• Notifizierung von Konformitätsbewertungsstellen
• Marktüberwachung und Durchsetzung
• Übertragene Befugnisse und Ausschussverfahren
• Vertraulichkeit und Sanktionen
• Übergangs- und Schlussbestimmungen.

Die meiner Ansicht nach für die Softwareentwicklung wichtigen Artikel sind in den Kapiteln 1, 2, 3 und 7 zu finden.

Der Anhang gliedert sich in folgende Abschnitte:

• Anhang I: Grundlegende Cybersecurity-Anforderungen
• Anhang II: Informationen und Anleitungen für den Nutzer
• Anhang III: Wichtige Produkte mit digitalen Elementen
• Anhang IV: Kritische Produkte mit digitalen Elementen
• Anhang V: EU-Konformitätserklärung
• Anhang VI: Vereinfachte EU-Konformitätserklärung
• Anhang VII: Inhalt der technischen Dokumentation
• Anhang VIII: Konformitätsbewertungsverfahren

Die für die Softwareentwicklung interessanten Abschnitte befinden sich in Anhang I, evtl. Anhang II und Anhang VII. Für die Entscheidung, in welche Kategorie das eigene Produkt fällt, sind die Anhänge III und IV hilfreich. Hier werden konkrete Beispiele für Produkte aus der jeweiligen Kategorie aufgezählt.

Sanktionen bei Verstößen

Verstöße gegen die Pflichten des CRA können erhebliche finanzielle Folgen haben: Bis zu 15 Mio. EUR oder 2,5 % des weltweiten Jahresumsatzes sind bei schwerwiegenden Mängeln möglich – je nachdem, welcher Betrag höher ist.

Was sollte man jetzt tun...

Ein zentraler erster Schritt zur Umsetzung des CRA ist die Analyse des eigenen Produktportfolios sowie des bestehenden Prozesses der Softwareentwicklung. Darauf aufbauend lassen sich die wichtigen Handlungsfelder identifizieren und gezielt umsetzen. Ein kontinuierlicher Verbesserungsprozess ermöglicht es, das Sicherheitsniveau über die Zeit stetig zu erhöhen. Letzteres gilt übrigens unabhängig davon, ob das eigene Produkt formell vom CRA betroffen ist oder nicht. 😉

Die grundlegende Frage zu Beginn jeder Analyse lautet: Fallen meine Produkte unter die Definition „Produkt mit digitalen Elementen“ im Sinne des CRA? Und wenn ja, gelten sie als „normal“, „wichtig“ oder „kritisch“ gemäß Anhang III?

Mit der Antwort dieser Frage lassen sich die konkreten Anforderungen des CRA auf die eigenen Produkte abbilden und es klärt sich, ob eine Selbstbeurteilung ausreicht oder ob es der Beurteilung durch einen Dritten bedarf.

Der CRA unterteilt nach Kritikalität in folgende Kategorien:

• Standardprodukte: Diese Produkte haben ein geringes Risiko und machen den Großteil aller Produkte aus. Fotobearbeitungen, intelligente Lautsprecher, Spiele und Apps fallen beispielsweise in diese Kategorie. Hier ist eine Selbstbewertung durch den Hersteller möglich.
• Wichtige Produkte: Diese Produkte spielen eine zentrale Rolle in IT-Umgebungen. Passwort-Manager, Netzmanagementsysteme, Betriebssysteme, Mikrocontroller mit sicherheitsrelevanten Funktionen sind Beispiele für diese Kategorie. Bei diesen Produkten ist entweder eine Selbstbewertung oder eine Bewertung durch Dritte möglich, je nachdem, in welche Klasse sie fallen. Weitere Beispiele siehe Anhang III.
• Kritische Produkte: Diese Produkte enthalten ein sehr hohes Risiko und/oder sind selbst Sicherheitskomponenten. Hardwaregeräte mit Sicherheitsboxen, Smart-Meter-Gateways, Chipkarten fallen in diese Kategorie. Die Bewertung geschieht hier durch akkreditierte Dritte (EU-Sicherheitszertifizierung). Weitere Beispiele siehe Anhang IV.

Worauf sollte man achten...?

Eine wesentliche Anforderung des CRA besteht darin, in allen Phasen des Prozesses bei der Softwareentwicklung Sicherheitsaspekte zu berücksichtigen: von der Architektur und Design über die Implementierung bis hin zu Test, Release und Wartung. Wichtige Fragen sind dabei: Gibt es ein strukturiertes Schwachstellenmanagement? Sind sichere Voreinstellungen (Secure Defaults) implementiert? Ist eine Updatefähigkeit sichergestellt? Ist die technische Dokumentation vollständig und konform? Nicht zuletzt entscheiden die Antworten dieser Fragen, ob die Voraussetzungen zur CE-Kennzeichnung („Conformité Européenne“, übersetzt „Europäische Konformität“) erfüllt sind. Für viele Produkte ist die CE-Kennzeichnung ein wichtiges Verkaufsargument.
Ein pragmatischer erster Schritt kann darin bestehen, die konkreten Anforderungen des CRA aufzulisten und für jede eine einfache Selbsteinschätzung durchzuführen – etwa auf einer Skala von 0 (nicht vorhanden) bis 3 (vollständig umgesetzt). So lassen sich Handlungsfelder schnell identifizieren und priorisieren.

Für eine längerfristige und umfassende Betrachtung der eigenen Security Awareness kann man das OWASP SAMM (Software Assurance Maturity Model) heranziehen. Es erlaubt eine strukturierte Bewertung des Reifegrads. Das hilft, Stärken und Schwächen in Bereichen wie Governance, Design, Implementierung, Verifikation und Betrieb systematisch zu analysieren. Gleichzeitig eignet es sich zur Dokumentation und Planung der kontinuierlichen Verbesserung, um die Anforderungen des CRAs auch nachhaltig zu erfüllen.
Zur Einordnung des eigenen Entwicklungsprozesses bietet OWASP SAMM auch ein Benchmarking-Projekt, das aggregierte Vergleichswerte anderer Unternehmen bereitstellt. Achtung: Diese Ergebnisse sollten nicht als absolute Zielmarke verstanden werden! Der eigentliche Zweck des SAMM-Modells ist es, individuelle Verbesserungspotenziale aufzudecken und die eigene Organisation im Sinne eines langfristigen Sicherheitsbewusstseins weiterzuentwickeln.

Fazit

Die Anforderungen des Cyber Resilience Act sind umfangreich – und sie greifen tief in Entwicklungs-, Dokumentations- und Organisationsprozesse ein. Umso wichtiger ist es, frühzeitig mit der Analyse des eigenen Produktportfolios und der bestehenden Entwicklungspraktiken zu beginnen. Idealerweise werden erste Maßnahmen zur Umsetzung bereits jetzt angestoßen, um rechtzeitig zum Anwendungsbeginn im Jahr 2027 vorbereitet zu sein. Dabei wird sich zeigen, dass Automatisierung – etwa bei Tests, Schwachstellenanalysen oder der Erstellung von Software-Stücklisten zentrale Erfolgsfaktoren für die praktische Umsetzung des CRA darstellen. Das Gleiche gilt für durchgängige, integrierte Sicherheitsprozesse. Sicherheit als festen Bestandteil des Entwicklungs- und Produktlebenszyklus zu verankern schafft nicht nur regulatorische Konformität. Es ist auch die Basis für die dauerhafte Vertrauenswürdigkeit der eigenen digitalen Produkte.

 

NIS2	https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32022L2555
CRA	https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32024R2847