Cyber Resilience Act: Informationssicherheit, Fristen & Sanktionen

Die EU schärft ihre regulatorischen Anforderungen an die Cybersicherheit digitaler Produkte und Software. Mit dem Cyber Resilience Act (CRA), der im März 2024 final verabschiedet wurde, schafft die EU Rahmenbedingungen für die Entwicklung sicherer Produkte, damit sich die Hersteller während des gesamten Lebenszyklus eines Produkts konsequent um die Sicherheit kümmern. Für ein Unternehmen, das digitale Produkte und Software entwickelt, bedeutet das: Neue Pflichten, strengere Anforderungen – und eine tiefgreifende Überprüfung der Informationssicherheitsstrategie. In diesem Artikel werden die Auswirkungen des CRA aus Sicht der Informationssicherheit beleuchtet, aufgezeigt, welche konkreten Maßnahmen notwendig sind, und erläutert, welche Fristen eingehalten werden müssen.

Was ist der Cyber Resilience Act?

Der Cyber Resilience Act ist eine EU-Verordnung, die den Cybersicherheitsrahmen für Produkte mit digitalen Elementen vereinheitlichen und stärken soll. Ziel ist es, ein Mindestmaß an Cybersicherheit über den gesamten Lebenszyklus digitaler Produkte hinweg zu gewährleisten – von der Entwicklung bis zur Außerbetriebnahme.

Kernpunkte des CRA

• Gilt für alle neuen Produkte mit digitalen Elementen, die ab dem 11.12.2027 in der EU in Verkehr gebracht werden, auch für Software.
• Hersteller müssen Cybersicherheitsrisiken bereits in der Entwicklungsphase eines Produkts identifizieren und minimieren („Security by Design“).
• Es besteht die Pflicht zur regelmäßigen Aktualisierung und Behebung von Schwachstellen.
• Es gelten umfangreiche Dokumentations- und Meldepflichten.

Wofür der CRA nicht nicht gilt

Es gibt Ausnahmen. Der CRA gilt nicht für:

• Medizinprodukte (EU 2017/745)
• In-vitro-Diagnostika (EU 2017/746)
• Systeme, Bauteilen und selbstständige technische Einheiten für Fahrzeuge (EU 2019/2144)
• Entsprechend der Festlegung gemeinsamer Vorschriften für die Zivilluftfahrt zertifizierte Produkte (EU 2018/1139)
• Schiffsausrüstung (2014/90/EU)
  oder auch
• Ersatzteile, die nach denselben Spezifikationen hergestellt werden, wie die Originalteile
• Produkte zum Zweck der nationalen Sicherheit, zu Verteidigungszwecken oder für die Verarbeitung von Verschlusssachen

Anforderungen an die Cybersicherheit

Der CRA definiert im Anhang 1 Teil 1 eine glücklicherweise noch recht übersichtliche Liste vor grundlegenden Cybersicherheitsanforderungen, und im Anhang 1 Teil 2 ein Verfahren zur Umsetzung und Überwachung dieser Anforderungen. Diese Anforderung und das Verfahren zu ihrer Überwachung müssen erfüllt sein, bevor das Produkt auf dem Markt bereitgestellt wird.

Der CRA gilt daher nicht nur für Hersteller in der EU, sondern auch für Importeure, die Waren von außerhalb der EU beziehen.

Sich der Vermutung hinzugeben, dass bis zum 11.12.2027 noch viel Zeit ist und der CRA nur für neue Produkte gilt, mag verlockend sein.

Doch für diese Produkte gilt nach Art. 18 Abs. 8 CRA:

• Es gibt zukünftig eine Verpflichtung zur wirksamen Behandlung von Schwachstellen während der erwartbaren Lebensdauer und dem Unterstützungszeitraum.
• Der Unterstützungszeitraum muss angemessen und verhältnismäßig sein. Er beträgt mindestens 5 Jahre, es sei denn, die erwartete Nutzungsdauer ist kürzer. Dann darf auch der Unterstützungszeitraum kürzer sein.
• Er muss immer in der technischen Dokumentation angeben werden.
• In dieser Zeit ist der Hersteller verpflichtet, Schwachstellen an seinem Produkt zu beheben. Dafür muss das Produkt die Möglichkeit vorsehen, dass dies überhaupt möglich ist. Und das fängt schon bei der Entwicklung an.

Auswirkungen auf die Informationssicherheit

Sicherheit schon beim Design

Der Hersteller ist nach Art. 13 Abs. 1 verpflichtet, eine Bewertung der Cybersicherheitsrisiken für sein Produkt durchzuführen und schon in der Planungs- und Entwicklungsphase zu berücksichtigen. Diese Anforderung deckt sich mit ISO 27001 A. 5.8, Informationssicherheit im Projektmanagement:

• Bedrohungsanalysen müssen bereits in der Konzeptionsphase durchgeführt werden.
• Sicherheitsfunktionen wie Authentifizierung, Zugriffskontrolle oder Verschlüsselung müssen standardmäßig berücksichtigt werden.
• Externe Komponenten (z. B. Open Source Libraries) müssen hinsichtlich ihrer Sicherheit bewertet und dokumentiert werden.

Konkrete Maßnahme: Einführung oder Erweiterung eines Secure Software Development Lifecycle (SSDLC) vorgesehen.

Schwachstellenmanagement und Incident Response

Der CRA verlangt, dass Schwachstellen kontinuierlich identifiziert, bewertet und behoben werden. Darüber hinaus müssen Hersteller über ein koordiniertes Offenlegungsverfahren (Coordinated Vulnerability Disclosure, CVD) verfügen.

Innerhalb von 24 Stunden nach dem Bekanntwerden einer aktiv ausgenutzten Schwachstelle muss diese an die europäische Cybersicherheitsbehörde ENISA gemeldet werden.

Dies gilt auch für Open Source. Wenn ein Hersteller eine Schwachstelle in einer quellenden Komponente findet, meldet er sie dem Maintainer, und behebt sie. Die Korrektur muss dann ebenfalls dem Maintainer übermittelt werden.

Art. 13 Abs. 6 CRA sieht dabei wiederum konkrete Maßnahmen vor:

• Einrichtung eines internen Vulnerability Management Prozesses.
• Aufbau eines Product Security Incident Response Teams (PSIRT).
• Nutzung von Tools für automatisierte Schwachstellenanalysen.

Updates und Patch-Management

Der CRA verpflichtet Hersteller, Sicherheitsupdates über den gesamten Lebenszyklus eines Produkts bereitzustellen – mindestens jedoch für den angegebenen Supportzeitraum.

Konkrete Maßnahme: Definition klarer Patch-Zeitfenster, SLA-Regelungen, sowie sichere Verteilung von Updates (z. B. via Signierung).

Dokumentation und technische Nachweise

Ein zentraler Bestandteil des CRA ist die Verpflichtung, technische Dokumentation zur Informationssicherheit bereitzustellen. Der CRA macht dazu im Anhang VII ganz konkrete Anforderungen, was in der Dokumentation unbedingt enthalten sein muss. Das sind unter anderem:

• Die Beschreibung der Systemarchitektur
• Festgelegte Verfahren zur Behandlung von Schwachstellen
• Eine Software-Stückliste (Software Bill of Materials, SBOM)
• Das Konzept für die koordinierte Offenlegung von Schwachstellen
• Eine Kontaktadresse für die Meldung von Schwachstellen
• Das Patchkonzept
• Die Risikobewertung, bezogen auf Entwicklung, Herstellung, Lieferung und Wartung
• Der Unterstützungszeitraum
• Berichte zu Tests und Prüfungen, bezogen auf die Anforderungen von Anhang I, Teil I und II.

Konkrete Maßnahme: Aufbau einer zentralen Sicherheitsdokumentationsplattform.

Produktkategorien, Produktklassen

Die Produkte, die unter den CRA fallen, sind in zwei Produktkategorien (wichtig/kritisch) und Klassen eingeteilt.

Wichtige Produkte (Klasse I):

• Identitätsmanagementsysteme, Geräte zur Zugangskontrolle und (biometrische) Lesegeräte
• Web-Browser
• Passwortmanager
• Virenscanner
• VPN-Zugänge
• Bootmanager
• Betriebssysteme
• Mikroprozessoren und -controller, FPGAs
• Home-Automation mit Sicherheitsfunktion (Türschlösser, Kameras, Babyphon)

Wichtige Produkte (Klasse II):

• Hypervisoren, Container-Runtime-Systeme
• Firewalls
• Manipulationssichere Mikroprozessoren und -controller

Kritische Produkte (Anhang IV):

• Hardwaregeräte mit Sicherheitsboxen
• Smart-Meter-Gateways
• Geräte für fortgeschrittene Sicherheitszwecke
• Chipkarten und Sicherheitselemente

Grundsätzlich können Produkte ähnlich der Vergabe der CE-Kennzeichnung durch Selbsterklärung („Internal Control“) zertifiziert werden. Für kritische Produkte (Anhang IV) kann eine externe Überprüfung und Zertifizierung vorgeschrieben werden (Art. 8 Abs. 1).

Konkrete Maßnahme: Klassifikation aller Produkte nach Risikostufen und Festlegung des passenden Konformitätsverfahrens.

Fristen zur Umsetzung des CRA

Zeitplan

Fristen für Meldepflichten (Art. 14)

Sanktionen

Diese Sanktionen sind je nach Verstoß zu erwarten:

• Bei Nichteinhaltung der Anforderungen (Art. 64 Abs. 2): 15 Mio. Euro oder bis zu 2,5 % des weltweiten Jahresumsatzes (der höhere Betrag gilt).
• Bei Verstoß gegen Pflichten (Art. 64 Abs. 3): 10 Mio. Euro oder bis zu 2 % des weltweiten Jahresumsatzes (der höhere Betrag gilt).
• Bei falschen Angaben bei Auskunftsersuchen (Art. 64 Abs. 4): 5 Mio. Euro oder bis zu 1 % des weltweiten Jahresumsatzes (der höhere Betrag gilt).

Jeder Mitgliedsstaat der EU entscheidet selbst, ob seine Behörden und öffentlichen Stellen ebenfalls sanktioniert werden können (Art 64 Abs. 7).

Es gibt keine Sanktionierung von Verwaltern quelloffener Software (Art. 64 Abs. 10 b)) und Kleinstunternehmen bei Verstoß gegen Meldepflichten zur aktiven Ausnutzung von Schwachstellen und schwerwiegenden Sicherheitsvorfällen nach 24 Stunden. Es gilt aber dennoch die Verpflichtung zur Meldung nach 72 Stunden!

Informationssicherheit wird Pflicht

Mit dem Cyber Resilience Act vollzieht die EU einen Paradigmenwechsel: Cybersicherheit ist keine freiwillige Zusatzleistung mehr, sondern eine gesetzlich verankerte Pflicht. Für Unternehmen, die digitale Produkte entwickeln, bedeutet das einen erheblichen Anpassungsbedarf, aber natürlich auch die Chance, Vertrauen und Wettbewerbsvorteile durch nachweislich sichere Produkte aufzubauen.

Ein etabliertes ISMS auf Basis der ISO 27001 erleichtert die Umsetzung der Vorgaben des Cyber Resilience Acts – insbesondere die Implementierung und das Monitoring der geforderten Prozesse zur Bedrohungsanalyse und zum Risikomanagement – mit Sicherheit ganz erheblich.

Das ist also nichts Neues. Ähnlich wie bei NIS2 gilt: Wer ein zertifiziertes ISMS bereits umgesetzt hat, der hat die Konformitätsvermutung schon einmal für sich.