Der Cyber Resilience Act (CRA), Verordnung (EU) 2024/2847, legt Cybersicherheitsanforderungen für Produkte mit digitalen Elementen auf dem europäischen Markt fest. Er verbindet sichere Entwicklung, Konformitätsbewertung und den Umgang mit Schwachstellen während des Produktlebenszyklus. Für Hersteller ist die zentrale Aufgabe, Anforderungen mit ihrem konkreten Produkt und überprüfbaren Nachweisen zu verbinden.
Welche Produkte sind betroffen?
Grundsätzlich erfasst der CRA Hardware und Software mit einer direkten oder indirekten logischen oder physischen Datenverbindung. Auch Hersteller außerhalb der EU müssen den Anwendungsbereich prüfen, wenn sie Produkte auf dem EU-Markt bereitstellen. Notwendige Datenfernverarbeitung kann zur Produktgrenze gehören. Gerät, Begleit-App und erforderlicher Backend-Dienst müssen deshalb gemeinsam betrachtet werden, wenn ihre Funktionen zusammenhängen.
Reine SaaS-Angebote liegen grundsätzlich außerhalb dieses Produktbegriffs. Ein entfernter Dienst, der für die Funktion eines erfassten Produkts erforderlich ist, ist gesondert zu beurteilen. Ausnahmen betreffen unter anderem bestimmte Medizinprodukte, Fahrzeuge sowie Bereiche der Luftfahrt und Schifffahrt. Auch nicht gewerblich bereitgestellte Open-Source-Software ist differenziert zu prüfen. Eine Bezeichnung wie „Cloud“ oder „Open Source“ allein entscheidet den Anwendungsbereich nicht. Grundlage sind Artikel 2 und 3 der Verordnung.
Die vier maßgeblichen Termine
| Termin | Bedeutung |
|---|---|
| 10. Dezember 2024 | Die Verordnung ist in Kraft getreten. |
| 11. Juni 2026 | Die Vorschriften für benannte Stellen gelten seit diesem Datum. |
| 11. September 2026 | Die Meldepflicht nach Artikel 14 gilt seit diesem Datum. |
| 11. Dezember 2027 | Die meisten übrigen Pflichten werden anwendbar. |
Diese Staffelung nach Artikel 71 bedeutet: Der Meldeprozess muss bereits funktionieren. Ein späterer Plan für technische Unterlagen verschiebt keine laufende Meldefrist. Die Seite Cyber Resilience Act Fristen zeigt, wie Sie die Termine mit Entwicklung, Prüfung und Markteinführung verbinden.
Produktklassen und Konformitätsbewertung
Bei Produkten außerhalb der besonderen Kategorien ist grundsätzlich eine Selbstbewertung möglich. Das entbindet den Hersteller nicht von Risikobewertung, technischen Nachweisen und der Erfüllung der grundlegenden Cybersicherheitsanforderungen. Die Entscheidung muss sich auf die tatsächliche Hauptfunktion und den vorgesehenen Verwendungszweck stützen.
Wichtige Produkte Klasse I aus Anhang III haben ein bedingtes Verfahren zur Selbstbewertung. Die Voraussetzungen können insbesondere von der vollständigen Anwendung einschlägiger harmonisierter Normen oder anderer zulässiger Verfahrensbedingungen abhängen. Sind sie nicht erfüllt, ist eine dritte Stelle einzubeziehen. Sicherheitskameras, intelligente Türschlösser und Babyphones sind Beispiele aus dem Bereich vernetzter Sicherheitsprodukte. Klasse II verlangt die Beteiligung Dritter. Für kritische Produkte aus Anhang IV ist das jeweils anwendbare Verfahren gesondert zu prüfen. Details finden Sie bei den Produktklassen.
Grundlegende Anforderungen aus Anhang I
Anhang I behandelt sowohl Produkteigenschaften als auch den Umgang mit Schwachstellen. Die Anforderungen müssen anhand der Cybersicherheitsrisiken des Produkts bewertet werden. Sichere Voreinstellungen, Zugriffsschutz, die Integrität von Daten und sichere Aktualisierungen gehören zu den Themen, die technische Entwicklung benötigen können. Ein fertiges Formular ersetzt keine Prüfung des implementierten Verhaltens.
Halten Sie zu jeder einschlägigen Anforderung fest, welches Artefakt die Umsetzung belegt. Das kann eine Architekturentscheidung, eine Konfiguration, ein Test oder ein freigegebener Prozess sein. Dokumentieren Sie auch begründete Entscheidungen zur Nichtanwendbarkeit. Die Verbindung zwischen Anforderung, Nachweis, Produktversion und Prüfer macht die Unterlagen später pflegbar.
Meldepflicht nach Artikel 14
Bei Kenntnis einer aktiv ausgenutzten Schwachstelle oder eines schwerwiegenden Sicherheitsvorfalls ist unverzüglich zu handeln. Die Frühwarnung erfolgt spätestens innerhalb von 24 Stunden, die weitere Meldung spätestens innerhalb von 72 Stunden ab Kenntnis. Für eine Schwachstelle folgt der Abschlussbericht spätestens 14 Tage nach Verfügbarkeit einer Korrektur- oder Abhilfemaßnahme. Bei einem schwerwiegenden Sicherheitsvorfall beträgt die Frist einen Monat nach der Meldung.
Die Single Reporting Platform von ENISA verbindet die elektronische Übermittlung mit dem zuständigen koordinierenden CSIRT. Klären Sie Zugang, Zuständigkeit und Vertretung vor einem Ereignis. Roja kann Meldetexte vorbereiten und Fristen verfolgen. Der Hersteller prüft und reicht ein. Eine interne Freigabe ist noch keine Übermittlung. Der Artikel-14-Leitfaden erläutert diese Schritte.
Software-Stückliste und technische Dokumentation
Die Software-Stückliste (SBOM) muss maschinenlesbar sein und mindestens die obersten Abhängigkeiten erfassen. Sie ist Teil des Schwachstellenmanagements nach Anhang I Teil II. Eine gültige Datei genügt nicht, wenn sie die falsche Firmware oder eine unvollständige Produktgrenze beschreibt. Validieren Sie die Komponenten deshalb gegen den tatsächlich erzeugten Build und dokumentieren Sie bekannte Lücken.
Die technische Dokumentation nach Anhang VII verbindet Produktbeschreibung, Risikobewertung, anwendbare Anforderungen und Nachweise. Nutzerinformationen nach Anhang II und die EU-Konformitätserklärung nach Anhang V erfüllen jeweils andere Aufgaben. Ordnen Sie jedem Dokument einen Verantwortlichen und einen Aktualisierungsanlass zu. Die Seite SBOM Pflicht CRA führt von der Bestandsaufnahme zur technischen Bewertung einzelner Befunde.
Support, Updates und Aufbewahrung
Der Supportzeitraum beträgt grundsätzlich mindestens fünf Jahre, sofern die erwartete Nutzung nicht kürzer ist. Länger genutzte Produkte können einen längeren Zeitraum erfordern. Begründen Sie die Entscheidung mit Produktart, Verwendung und den relevanten Umständen. Eine pauschale Fünfjahresangabe ist für langlebige Produkte keine ausreichende Begründung.
Unterscheiden Sie den Supportzeitraum von der Verfügbarkeit bereitgestellter Sicherheitsupdates und der Aufbewahrung technischer Unterlagen. Das sind eigenständige Pflichten mit eigenen Voraussetzungen. Eine gemeinsame Löschfrist für alle Artefakte kann deshalb zu falschen Ergebnissen führen. Artikel 13 und 31 sind im Zusammenhang mit dem Produkt und dem jeweiligen Dokument zu prüfen.
Ein praktischer Start in 90 Tagen
Erfassen Sie zuerst Produkte, unterstützte Versionen und die verantwortlichen Personen. Prüfen Sie die Produktgrenze und die voraussichtliche Klasse. Erstellen Sie eine erste SBOM aus dem Build und testen Sie den Eingang einer Sicherheitsmeldung. Die erste Phase endet mit einer überprüfbaren Bestandsaufnahme und einem erreichbaren Meldekontakt.
Bewerten Sie anschließend die Befunde und gleichen Sie die Nachweise mit Anhang I ab. Planen Sie notwendige Architekturänderungen, externe Tests und Nutzerinformationen. Beginnen Sie danach mit den wichtigsten Entwicklungsaufgaben und führen Sie eine Meldeübung durch. Halten Sie offene Entscheidungen mit Verantwortlichen und Terminen fest. Dieser Plan strukturiert den Einstieg; er verspricht keinen vollständigen Abschluss für jedes Produkt innerhalb von 90 Tagen.
Häufige Fragen
Ersetzt der Leitfaden eine produktbezogene Bewertung?
Nein. Produktgrenze, Auslegung und Konformitätsbewertungsverfahren brauchen eine dokumentierte Prüfung des konkreten Falls.
Was bleibt beim Hersteller?
Der Hersteller verantwortet die Einordnung, die Konformitätsentscheidung, Meldungen und die Unterzeichnung der EU-Konformitätserklärung. Roja unterstützt bei Nachweisen, Entwürfen und technischer Umsetzung.
Quellen
- Verordnung (EU) 2024/2847 – deutsche Fassung auf EUR-Lex
- ENISA: Fragen zur Single Reporting Platform
Allgemeine technische Informationen, geprüft am oben genannten Datum. Produktbezogene Auslegung, aktuelle Normen und das anwendbare Verfahren sind vor einer Konformitätsentscheidung gesondert zu prüfen.