Cyber Resilience Act Aus der Praxis: Fristen und Pflichten zum Cyber Resilience Act

Von Margit Kuther 6 min Lesedauer

Der Cyber Resilience Act verpflichtet Hersteller von Produkten mit digitalen Elementen ab dem 11.9.2026 aktiv ausgenutzte Schwachstellen und schwere Sicherheitsvorfälle zu melden. Ab dem 11.12.2027 gilt die Verordnung vollständig. Aaronn beantwortet Fragen, die dem Embedded- & IoT-Systemintegrator in Kundengesprächen am häufigsten begegnen.

CRA: Hardware, Software, technische Dokumentation, Updatefähigkeit und Lifecycle-Support müssen im Gesamtsystem zusammenspielen.(Bild:  Aaronn)
CRA: Hardware, Software, technische Dokumentation, Updatefähigkeit und Lifecycle-Support müssen im Gesamtsystem zusammenspielen.
(Bild: Aaronn)

Der Cyber Resilience Act ist die Verordnung (EU) 2024/2847. Sie führt erstmals verbindliche und EU-weit einheitliche Cybersicherheitsanforderungen für Produkte mit digitalen Elementen ein. Diese reichen von der sicheren Produktentwicklung bis zum Schwachstellenmanagement während des festgelegten Supportzeitraums. Erfasst werden grundsätzlich Hardware- und Softwareprodukte, deren vorgesehene oder vernünftigerweise vorhersehbare Nutzung eine direkte oder indirekte logische oder physische Datenverbindung zu einem Gerät oder Netzwerk umfasst.

Was sind „digitale Elemente“ in der Praxis?

Der Begriff Cyber Resilience Act umfasst mehr als nur die Software, die ein Nutzer unmittelbar sieht. Ein Produkt mit digitalen Elementen kann aus Hardware, Software und bestimmten Lösungen zur Ferndatenverarbeitung bestehen. Auch Hardware- oder Softwarekomponenten, die separat in Verkehr gebracht werden, können selbst in den Anwendungsbereich fallen. Für industrielle Anwendungen können dazu beispielsweise gehören:

  • ein Industrie-PC mit Ethernet-, WLAN- oder Feldbusanbindung,
  • eine SPS, die mit Sensoren, Antrieben oder einem übergeordneten Netzwerk kommuniziert,
  • ein HMI mit Netzwerkanschluss oder digitaler Wartungsschnittstelle,
  • ein IoT-Gateway, das Maschinendaten erfasst und weiterleitet,
  • ein Computer-on-Module, das als eigenständige Komponente in Verkehr gebracht wird,
  • Firmware, Betriebssysteme, Treiber oder Anwendungssoftware,
  • eine mobile oder webbasierte Anwendung zur Konfiguration eines Geräts.

Auch eine Cloud-Komponente kann zum Produkt gehören, wenn sie vom Hersteller oder unter seiner Verantwortung entwickelt wurde und das Produkt ohne diese Ferndatenverarbeitung eine seiner vorgesehenen Funktionen nicht erfüllen könnte. Entscheidend ist deshalb nicht nur, ob ein Produkt mit dem öffentlichen Internet verbunden ist. Auch eine Verbindung über ein lokales Netzwerk, ein Gateway, eine Funkverbindung oder eine physische Datenschnittstelle kann relevant sein.

Ein rein mechanisches Bauteil ohne die Fähigkeit, digitale Daten zu verarbeiten, zu speichern oder zu übertragen, ist dagegen grundsätzlich kein Produkt mit digitalen Elementen. Bei komplexen Maschinen muss daher geprüft werden, welche Hardware-, Software- und Kommunikationskomponenten zum digitalen Gesamtsystem gehören und in welcher Form sie auf dem EU-Markt bereitgestellt werden.

Wann tritt der CRA vollständig in Kraft, und wie sind die Fristen?

Der Cyber Resilience Act gilt in drei Stufen:

  • 10. Dezember 2024: Der CRA tritt in Kraft. Neue Produktentwicklungen sollten Security by Design bereits jetzt berücksichtigen.
  • 11. September 2026: Die Meldepflichten für aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle werden verbindlich.
  • 11. Dezember 2027: Der CRA gilt vollständig. Betroffene Produkte, die ab diesem Datum neu in der Europäischen Union in Verkehr gebracht werden, müssen die grundlegenden Cybersicherheitsanforderungen erfüllen und das erforderliche Konformitätsbewertungsverfahren durchlaufen.

Produkte, die bereits vor dem 11. Dezember 2027 in Verkehr gebracht wurden, müssen grundsätzlich nicht rückwirkend vollständig nach dem CRA bewertet werden. Eine wesentliche Änderung nach diesem Datum kann jedoch eine neue Bewertung erforderlich machen. Entscheidend ist, ob die Änderung die Cybersicherheit oder den vorgesehenen Verwendungszweck des Produkts beeinflusst – nicht allein die Größe eines Firmware-Updates oder einer Hardware-Revision. Hersteller müssen außerdem einen Supportzeitraum festlegen und transparent kommunizieren. Dieser beträgt grundsätzlich mindestens fünf Jahre, sofern die erwartete Nutzungsdauer des Produkts nicht kürzer ist. Bei langlebigen Industrieprodukten kann ein längerer Support erforderlich oder marktseitig erwartet werden.

Wie und wo müssen Sicherheitslücken gemeldet werden?

Hersteller müssen aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle melden, die sich auf die Sicherheit eines Produkts mit digitalen Elementen auswirken. Für beide Kategorien gilt zunächst eine Frühwarnung innerhalb von 24 Stunden und eine ausführlichere Meldung innerhalb von 72 Stunden. Die Fristen beginnen, sobald der Hersteller von dem meldepflichtigen Vorgang Kenntnis erlangt.

Bei einer aktiv ausgenutzten Schwachstelle folgt spätestens 14 Tage nach Verfügbarkeit einer Korrektur- oder Minderungsmaßnahme ein Abschlussbericht. Bei einem schwerwiegenden Sicherheitsvorfall ist dieser grundsätzlich innerhalb eines Monats nach der ausführlichen Meldung einzureichen. Nicht jede intern entdeckte Schwachstelle ist meldepflichtig. Eine Schwachstelle ohne bekannte aktive Ausnutzung muss dennoch im regulären Schwachstellenmanagement bewertet und behandelt werden. Die Meldung erfolgt über die von ENISA bereitgestellte Single Reporting Platform und wird gleichzeitig an ENISA sowie das zuständige koordinierende CSIRT übermittelt.

Für Unternehmen ist die 24-Stunden-Frist vor allem eine Frage der Erkennungs- und Reaktionsfähigkeit. Ohne aktuelle Informationen über eingesetzte Softwarekomponenten, definierte Verantwortlichkeiten und klare Eskalationswege lässt sich das Zeitfenster kaum zuverlässig einhalten.

Was ist eine SBOM?

Eine Software Bill of Materials (SBOM) ist ein maschinenlesbares Verzeichnis der in einem Produkt enthaltenen Softwarekomponenten und ihrer Abhängigkeiten. Sie ermöglicht es, bei Bekanntwerden einer Schwachstelle schnell festzustellen, welche Produkte und Softwarestände betroffen sind. Nach dem Cyber Resilience Act muss die SBOM mindestens die direkten beziehungsweise obersten Softwareabhängigkeiten abdecken. Sie ist Bestandteil der technischen Dokumentation und muss nicht grundsätzlich veröffentlicht werden. Hersteller müssen sie den zuständigen Marktüberwachungsbehörden jedoch auf Anfrage bereitstellen können.

Jetzt Newsletter abonnieren

Verpassen Sie nicht unsere besten Inhalte

Mit Klick auf „Newsletter abonnieren“ erkläre ich mich mit der Verarbeitung und Nutzung meiner Daten gemäß Einwilligungserklärung (bitte aufklappen für Details) einverstanden und akzeptiere die Nutzungsbedingungen. Weitere Informationen finde ich in unserer Datenschutzerklärung. Die Einwilligungserklärung bezieht sich u. a. auf die Zusendung von redaktionellen Newslettern per E-Mail und auf den Datenabgleich zu Marketingzwecken mit ausgewählten Werbepartnern (z. B. LinkedIn, Google, Meta).

Aufklappen für Details zu Ihrer Einwilligung

Die Verordnung schreibt kein einzelnes technisches Format vor. In der Praxis werden insbesondere CycloneDX und SPDX eingesetzt. Wichtiger als die Formatwahl ist die Aktualität. Eine SBOM, die nur beim Produktstart erstellt und danach nicht gepflegt wird, stimmt möglicherweise nicht mehr mit dem tatsächlich ausgelieferten Softwarestand überein. Ihre Erstellung und Pflege sollte deshalb möglichst in den Build-, Release- und Änderungsprozess integriert werden.

Die BSI TR-03183-2 (Cyber-Resilienz-Anforderungen an Hersteller und Produkte - Teil 2: Software Bill of Materials (SBOM)) bietet hierfür eine praxisnahe technische Orientierung, ist jedoch nicht mit dem verbindlichen Verordnungstext des CRA gleichzusetzen.

Wie erstellt man ein CRA Risk Assessment?

Eine Cybersicherheitsrisikobewertung identifiziert, welchen Risiken ein Produkt während seiner vorgesehenen Verwendung ausgesetzt sein kann und mit welchen Maßnahmen diese Risiken reduziert werden. Der Hersteller muss gemäß Artikel 13 des CRA eine solche Bewertung durchführen. Sie bildet die Grundlage für die Anforderungen aus Anhang I und ist Bestandteil der technischen Dokumentation nach Anhang VII. In der Praxis umfasst die Cybersicherheitsrisikobewertung vier Schritte:

  • 1. Angriffsfläche erfassen: Schnittstellen, Kommunikationskanäle, Wartungszugänge, Update-Pfade und Drittkomponenten dokumentieren.
  • 2. Bedrohungen bewerten: Realistische Angriffsszenarien identifizieren und mögliche Auswirkungen analysieren.
  • 3. Maßnahmen ableiten: Beispielsweise sichere Standardeinstellungen, Zugriffskontrollen, Verschlüsselung und geschützte Update-Mechanismen vorsehen.
  • 4. Lieferkette einbeziehen: Zugekaufte Module, Betriebssysteme, Bibliotheken und Kommunikationskomponenten berücksichtigen.

Die Bewertung sollte nicht erst am Ende der Entwicklung erstellt werden. Neue Schwachstellen, veränderte Bedrohungsszenarien oder wesentliche Produktänderungen können während des Supportzeitraums eine Aktualisierung erforderlich machen.

Ist mein Produkt CRA-ready?

Eine belastbare Vorbereitung auf den Cyber Resilience Act umfasst unter anderem Security by Design, eine aktuelle SBOM, eine dokumentierte Risikobewertung, einen sicheren Update-Mechanismus, einen festgelegten Supportzeitraum und geregelte Prozesse für Schwachstellen und Sicherheitsvorfälle. Einzelne dieser Bausteine reichen nicht aus, um ein Produkt pauschal als CRA-konform zu bezeichnen. Ebenso wichtig sind die technische Dokumentation, die Produktklassifizierung und das erforderliche Konformitätsbewertungsverfahren. Für eine erste Standortbestimmung haben wir die wichtigsten Punkte in einer praktischen CRA-Checkliste zusammengefasst.

Warum wird der CRA jetzt für den deutschen Maschinenbau relevant?

Für Maschinenbauer und OEMs verschiebt sich die Frage zunehmend von „Betrifft uns der CRA?“ zu „Wie setzen wir die Anforderungen auf Produkt- und Systemebene um?“. Entscheidend ist dabei nicht nur die Auswahl einzelner Komponenten. Hardware, Software, technische Dokumentation, Updatefähigkeit und Lifecycle-Support müssen im Gesamtsystem zusammenspielen.

Mit mehr als 30 Jahren Erfahrung in der Embedded- und IoT-Systemintegration unterstützt Aaronn Electronic Kunden dabei, geeignete Plattformen auszuwählen und Anforderungen an Design-in, Lifecycle-Management und Updatefähigkeit frühzeitig auf Systemebene zu berücksichtigen. (mk)

Weiterführende Links:

(ID:50938275)