Im deutschen Sprachgebrauch heißt die Verordnung (EU) 2024/2847 auch Cyberresilienz-Verordnung. Sie ist Produktsicherheitsrecht: Nicht die Organisation wird reguliert, sondern das Produkt. Wer Hard- oder Software mit digitalen Elementen auf dem Unionsmarkt bereitstellt, muss dafür Cybersicherheitsanforderungen erfüllen und dies wie bei anderen CE-Vorschriften nachweisen.
Welche Produkte fallen unter den Cyber Resilience Act?
Erfasst sind Produkte mit digitalen Elementen, deren bestimmungsgemäße oder vernünftigerweise vorhersehbare Verwendung eine direkte oder indirekte Datenverbindung zu einem Gerät oder Netz einschließt: von Betriebssystemen, Anwendungen und Bibliotheken bis zu Steuerungen, Sensorik und vernetzten Verbrauchsgeräten.
Ausgenommen sind Produktgruppen mit eigenem sektorspezifischen Unionsrecht, etwa Medizinprodukte, Kraftfahrzeuge, Zivilluftfahrt und Schiffsausrüstung, sowie Produkte ausschließlich für Zwecke der nationalen Sicherheit oder Verteidigung. Freie und quelloffene Software fällt nur in den Anwendungsbereich, wenn sie im Rahmen einer Geschäftstätigkeit bereitgestellt wird; für Verwalter quelloffener Software gilt ein abgeschwächtes Pflichtenprogramm.
Welche Risikoklassen kennt der Cyber Resilience Act?
| Kategorie | Beispiele für die Einordnung | Nachweisweg |
|---|---|---|
| Standardprodukte | der überwiegende Teil aller Produkte mit digitalen Elementen | Selbstbewertung durch den Hersteller |
| Wichtige Produkte, Klasse I (Anhang III) | Produkte mit erhöhter Sicherheitsrelevanz wie Identitätsverwaltung, Netzwerkkomponenten oder Betriebssysteme | Selbstbewertung nur, wenn die einschlägigen harmonisierten Normen vorliegen und vollständig angewendet werden; andernfalls Beteiligung einer notifizierten Stelle |
| Wichtige Produkte, Klasse II (Anhang III) | die zweite, höher eingestufte Gruppe des Anhangs III | keine Selbstbewertung; der Nachweis führt stets über eine Konformitätsbewertung durch Dritte |
| Kritische Produkte (Anhang IV) | besonders sicherheitskritische Produkte | gegebenenfalls europäische Cybersicherheitszertifizierung |
Der Unterschied zwischen den beiden Klassen ist kein gradueller, sondern ein grundsätzlicher: Artikel 32 Absatz 2 eröffnet der Klasse I die Selbstbewertung unter einer Bedingung, Artikel 32 Absatz 3 sieht sie für die Klasse II überhaupt nicht vor. Wer die beiden Klassen zusammenfasst, plant den Nachweisweg für die höhere Klasse zu knapp.
Am Ende stehen technische Dokumentation, EU-Konformitätserklärung und CE-Kennzeichnung. Ohne sie darf ein erfasstes Produkt nicht in Verkehr gebracht werden.
Welche Sicherheitsanforderungen stellt der CRA an Produkte und Hersteller?
Anhang I gliedert sich in zwei Teile. Teil I beschreibt Produkteigenschaften: sichere Standardkonfiguration, keine bekannten ausnutzbaren Schwachstellen beim Inverkehrbringen, Schutz vor unbefugtem Zugriff, Schutz von Vertraulichkeit und Integrität, Datenminimierung, Verfügbarkeit von Kernfunktionen, verringerte Angriffsfläche und die Möglichkeit sicherer Aktualisierungen.
Teil II regelt die Schwachstellenbehandlung über den Lebenszyklus: eine Stückliste der Softwarekomponenten (SBOM), das unverzügliche Beheben von Schwachstellen, regelmäßige Tests, eine Leitlinie zur koordinierten Offenlegung, öffentliche Informationen zu behobenen Schwachstellen und die sichere, grundsätzlich unentgeltliche Verteilung von Sicherheitsaktualisierungen.
Der Hersteller legt einen Unterstützungszeitraum fest. Er soll die erwartete Nutzungsdauer widerspiegeln und beträgt in der Regel mindestens fünf Jahre, sofern die Lebensdauer nicht kürzer ist.
Was muss nach Artikel 14 gemeldet werden?
Artikel 14 adressiert den Hersteller, nicht den Betreiber, und kennt zwei getrennte Stränge mit unterschiedlicher Endfrist.
| Auslöser | Frühwarnung | Meldung | Abschlussbericht |
|---|---|---|---|
| aktiv ausgenutzte Schwachstelle (Art. 14 Abs. 1, 2) | 24 Stunden | 72 Stunden | spätestens 14 Tage, nachdem eine Korrektur- oder Risikominderungsmaßnahme zur Verfügung steht |
| schwerwiegender Sicherheitsvorfall (Art. 14 Abs. 3, 4) | 24 Stunden | 72 Stunden | innerhalb eines Monats nach der 72-Stunden-Meldung |
Beide Uhren laufen ab Kenntniserlangung, nicht ab der jeweils vorherigen Stufe. Einen Zwischenbericht verlangt Artikel 14 Absatz 6 nur auf Ersuchen. Schwerwiegend ist ein Sicherheitsvorfall nach Artikel 14 Absatz 5 dann, wenn er die Fähigkeit des Produkts beeinträchtigt, sensible oder wichtige Daten und Funktionen zu schützen, oder wenn er zur Einführung oder Ausführung von Schadcode geführt hat oder führen kann.
Gemeldet wird gleichzeitig an das als Koordinator benannte CSIRT und an die ENISA, beide über die einheitliche Meldeplattform des Artikels 16. Zuständig ist das CSIRT des Mitgliedstaats der Hauptniederlassung; das ist nach Artikel 14 Absatz 7 der Staat, in dem die Entscheidungen zur Cybersicherheit der Produkte überwiegend getroffen werden. Für Hersteller mit Hauptniederlassung in Deutschland ist es das BSI. Davon zu trennen ist Artikel 14 Absatz 8: Die betroffenen Nutzer sind zusätzlich zu informieren, möglichst in maschinenlesbarer Form.
Welche Fristen setzt Artikel 71?
Die Verordnung wurde am 20. November 2024 im Amtsblatt veröffentlicht (ABl. L, 2024/2847) und trat im Dezember 2024 in Kraft. Artikel 71 Absatz 2 staffelt die Geltung in drei Schritten.
| Ab wann | Was gilt |
|---|---|
| 11. Juni 2026 | Kapitel IV (Artikel 35 bis 51): notifizierende Behörden und Konformitätsbewertungsstellen, damit die Prüfinfrastruktur vor der Konformitätspflicht steht |
| 11. September 2026 | Artikel 14: die Meldepflichten der Hersteller |
| 11. Dezember 2027 | die Verordnung im Übrigen; erfasste Produkte dürfen nur noch mit erfüllter Konformität in Verkehr gebracht werden |
Die Meldepflicht reicht weiter zurück als die Konformitätspflicht: Nach Artikel 69 Absatz 3 gilt Artikel 14 auch für Produkte, die vor dem 11. Dezember 2027 in Verkehr gebracht wurden. Die Schwachstellenbehandlung aus Anhang I Teil II wandert nicht mit; sie erfasst ein älteres Produkt erst bei einer wesentlichen Änderung (Artikel 69 Absatz 2). Für Verstöße sieht die Verordnung gestaffelte Bußgeldrahmen vor, die alternativ an den weltweiten Jahresumsatz anknüpfen.
Worin unterscheidet sich der Cyber Resilience Act von NIS2?
NIS2 verpflichtet Organisationen, ihre eigenen Netz- und Informationssysteme abzusichern; der CRA verpflichtet Hersteller, sichere Produkte auf den Markt zu bringen. Was der CRA an Produktdokumentation, Unterstützungszeiträumen und Schwachstelleninformationen erzeugt, ist genau das Material, das Betreiber für ihr Lieferkettenrisikomanagement benötigen.
Wo die Anforderungen in Rizzqo landen
Der Cyber Resilience Act ist in Rizzqo als Anforderungskatalog hinterlegt. Entscheidend ist, worauf sich seine Anforderungen beziehen, denn das unterscheidet diesen Katalog von den übrigen: Bezugsgröße ist nicht die eigene IT-Landschaft, sondern das ausgelieferte Produkt.
In Rizzqo ist ein Produkt mit digitalen Elementen deshalb ein Wert wie ein Geschäftsprozess, und die Systeme seiner Entwicklungs- und Auslieferungskette hängen als unterstützende Objekte darunter: Build-Umgebung, Repositorien, Abhängigkeitsverwaltung, Signaturinfrastruktur und die eingebundenen Zulieferer, jeweils mit Kategorie und benanntem Verantwortlichen. Über diese Klassifizierung werden die Anforderungen verteilt, sodass jede an dem Objekt erscheint, an dem die zugehörige Arbeit tatsächlich stattfindet. Die technische Dokumentation und die Konformitätserklärung bleiben eigene Dokumente.