Was ist der Cyber Resilience Act? Anwendungsbereich, Pflichten und Fristen

Der Cyber Resilience Act, kurz CRA, ist die Verordnung (EU) 2024/2847 über horizontale Cybersicherheitsanforderungen für Produkte mit digitalen Elementen. Sie ist am 10. Dezember 2024 in Kraft getreten und gilt in ihrem Kern ab dem 11. Dezember 2027. Ein Teil davon gilt früher: Die Meldepflichten aus Artikel 14 greifen ab dem 11. September 2026, und die Vorschriften über die Notifizierung von Konformitätsbewertungsstellen gelten seit dem 11. Juni 2026.

Der CRA ist Produktrecht, kein Unternehmensrecht. Er verlangt nicht, dass ein Unternehmen ein bestimmtes Sicherheitsniveau hat, sondern dass ein Produkt bestimmte Eigenschaften hat, mit einer CE-Kennzeichnung auf den Markt kommt und über seinen Unterstützungszeitraum hinweg mit Sicherheitsupdates versorgt wird. Wer schon Produkte unter der Maschinenverordnung oder der Funkanlagenrichtlinie in Verkehr bringt, kennt die Mechanik. Für reine Softwarehersteller ist sie neu.

Dieser Text erklärt, für wen der CRA gilt, was er verlangt, wann er gilt und was bei Verstößen passiert. Jede Aussage nennt den Artikel, aus dem sie stammt. Der Text der Verordnung ist auf EUR-Lex verfügbar, auf Deutsch unter eur-lex.europa.eu/eli/reg/2024/2847/oj/deu.

Kurzfassung

• Der CRA gilt für Hardware und Software, die auf dem EU-Markt bereitgestellt wird und eine Datenverbindung zu einem Gerät oder Netz hat. Das ist fast jede Software und fast jedes vernetzte Gerät.
• Hersteller tragen die Hauptlast: grundlegende Anforderungen nach Anhang I, Risikobewertung, technische Dokumentation, Schwachstellenmanagement mit SBOM, Sicherheitsupdates über den Unterstützungszeitraum, Konformitätsbewertung, CE-Kennzeichnung.
• Ab dem 11. September 2026 müssen Hersteller aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle innerhalb von 24 Stunden melden, auch für Produkte, die bereits auf dem Markt sind.
• Ab dem 11. Dezember 2027 gilt der Rest: Ohne Konformitätsbewertung und CE-Kennzeichnung darf ein neues Produkt mit digitalen Elementen nicht mehr in Verkehr gebracht werden.
• Bußgelder reichen bis 15 Millionen Euro oder 2,5 Prozent des weltweiten Jahresumsatzes.

Für wen gilt der CRA?

Artikel 2 Absatz 1 legt den Anwendungsbereich fest: Die Verordnung gilt für Produkte mit digitalen Elementen, die auf dem Markt bereitgestellt werden und deren Zweckbestimmung oder vernünftigerweise vorhersehbare Verwendung eine direkte oder indirekte logische oder physische Datenverbindung mit einem Gerät oder Netz einschließt.

Ein Produkt mit digitalen Elementen ist nach Artikel 3 Nummer 1 ein Software- oder Hardwareprodukt und seine Fernverarbeitungslösungen, einschließlich Software- oder Hardwarekomponenten, die getrennt in Verkehr gebracht werden. Drei Folgen daraus sind in der Praxis wichtig:

• Software ist ein Produkt. Ein Betriebssystem, eine Desktop-Anwendung, eine Mobile App, eine Bibliothek, die ein anderer Hersteller einbaut: alles Produkte mit digitalen Elementen, sobald sie eine Datenverbindung haben.
• Komponenten zählen einzeln. Ein Chip, ein Modul oder eine Softwarebibliothek, die getrennt in Verkehr gebracht wird, ist selbst ein Produkt und braucht eine eigene Konformität.
• Fernverarbeitung gehört dazu. Wenn ein Produkt ohne einen bestimmten Cloud-Dienst seine Funktion nicht erfüllt, ist dieser Dienst Teil des Produkts (Artikel 3 Nummer 2). Reines Software-as-a-Service ohne ein solches Produkt fällt dagegen nicht unter den CRA, sondern unter NIS2, wenn der Anbieter dort erfasst ist.

Was nicht darunter fällt. Artikel 2 nimmt Produkte aus, für die es bereits sektorale Vorschriften mit Cybersicherheitsanforderungen gibt: Medizinprodukte und In-vitro-Diagnostika nach den Verordnungen (EU) 2017/745 und 2017/746, typgenehmigte Fahrzeuge, Luftfahrtprodukte, Schiffsausrüstung. Ausgenommen sind außerdem Produkte, die ausschließlich für Zwecke der nationalen Sicherheit oder Verteidigung entwickelt wurden, und Ersatzteile, die ein Originalteil mit denselben Eigenschaften ersetzen.

Open Source. Freie und quelloffene Software, die außerhalb einer Geschäftstätigkeit entwickelt und bereitgestellt wird, fällt nicht unter den CRA. Wer Open-Source-Software als Hersteller in ein kommerzielles Produkt einbaut, ist für dieses Produkt voll verantwortlich. Dazwischen steht der Open-Source-Software-Verwalter nach Artikel 24, etwa eine Stiftung, die die Entwicklung eines Projekts systematisch unterstützt: Er hat eine leichtere Pflicht, nämlich eine dokumentierte Cybersicherheitsstrategie, aber keine CE-Kennzeichnung.

Wenn unklar ist, ob ein Produkt erfasst ist, ist die Frage in wenigen Minuten zu klären: Gilt der Cyber Resilience Act für Sie?

Die drei Daten

Für Produkte, die vor dem 11. Dezember 2027 in Verkehr gebracht wurden, gilt eine Übergangsregel: Sie unterliegen den Anforderungen nur, wenn sie danach wesentlich verändert werden (Artikel 69 Absatz 2). Die Meldepflichten nach Artikel 14 gelten aber auch für diese Produkte (Artikel 69 Absatz 3). Ein Hersteller, der heute Software verkauft, muss also ab dem 11. September 2026 melden können, unabhängig davon, wie weit er von der CE-Kennzeichnung entfernt ist. Was die beiden Meldepflichten im Einzelnen verlangen, steht in Artikel 14 enthält zwei Meldepflichten, nicht eine.

Was Hersteller tun müssen

Die Pflichten der Hersteller stehen in Artikel 13. Sie lassen sich in sieben Blöcke fassen.

1. Grundlegende Anforderungen nach Anhang I. Teil I beschreibt die Eigenschaften des Produkts: Es muss ohne bekannte ausnutzbare Schwachstellen ausgeliefert werden, mit sicherer Standardkonfiguration, mit Schutz vor unbefugtem Zugriff, mit Verschlüsselung gespeicherter und übertragener Daten, mit begrenzter Angriffsfläche und mit der Möglichkeit, Sicherheitsupdates einzuspielen. Teil II beschreibt den Prozess: Schwachstellen und Komponenten müssen identifiziert und dokumentiert werden, Schwachstellen unverzüglich behoben, Sicherheitsupdates kostenlos bereitgestellt, eine Richtlinie zur koordinierten Offenlegung veröffentlicht. Die vollständigen Texte: Eigenschaften von Produkten und Behandlung von Schwachstellen.

2. Cybersicherheits-Risikobewertung. Nach Artikel 13 Absatz 2 und 3 bewertet der Hersteller die Risiken des Produkts, dokumentiert das Ergebnis in der technischen Dokumentation und berücksichtigt es in Planung, Entwicklung, Herstellung, Auslieferung und Wartung.

3. Software-Stückliste, SBOM. Anhang I Teil II Nummer 1 verlangt, Schwachstellen und Komponenten zu identifizieren und zu dokumentieren, einschließlich einer Software-Stückliste in einem gängigen, maschinenlesbaren Format, die mindestens die Abhängigkeiten der obersten Ebene erfasst. Die SBOM gehört in die technische Dokumentation (Anhang VII Nummer 8); an die Nutzer muss sie nicht herausgegeben werden. Wer sie herausgibt, nennt in der Nutzerinformation, wo sie zu finden ist (Anhang II Nummer 9).

4. Unterstützungszeitraum. Nach Artikel 13 Absatz 8 legt der Hersteller den Zeitraum fest, in dem Schwachstellen behandelt werden. Er muss der erwarteten Nutzungsdauer entsprechen und mindestens fünf Jahre betragen, es sei denn, das Produkt wird erwartbar kürzer genutzt. Während dieses Zeitraums sind Sicherheitsupdates bereitzustellen, und der Zeitraum ist beim Kauf anzugeben.

5. Technische Dokumentation und Nutzerinformation. Anhang VII listet, was die technische Dokumentation enthalten muss: Beschreibung des Produkts, Design und Entwicklung, Schwachstellenbehandlung, Risikobewertung, angewandte Normen, Prüfberichte. Anhang II listet, was der Nutzer bekommt: Kontaktstelle für Schwachstellen, Zweckbestimmung, Unterstützungszeitraum, Anleitung zur sicheren Installation und Außerbetriebnahme. Die Texte: Inhalt der technischen Dokumentation und Informationen und Anleitungen für den Nutzer.

6. Konformitätsbewertung, Konformitätserklärung, CE-Kennzeichnung. Welches Verfahren gilt, hängt von der Produktklasse ab, dazu gleich mehr. Am Ende stehen die EU-Konformitätserklärung nach Anhang V und die CE-Kennzeichnung nach Artikel 30.

7. Meldepflichten. Artikel 14: aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle, jeweils Frühwarnung in 24 Stunden, Meldung in 72 Stunden, Abschlussbericht. Die Meldung geht über die zentrale Meldeplattform der ENISA an das zuständige CSIRT, das sich nach der Hauptniederlassung des Herstellers richtet.

Die vollständige Liste mit dem Wortlaut jedes Absatzes: Pflichten der Hersteller, Artikel 13.

Importeure und Händler

Wer ein Produkt aus einem Drittland in die EU einführt, prüft nach Artikel 19, dass der Hersteller die Konformitätsbewertung durchgeführt hat, die Dokumentation vorliegt und die CE-Kennzeichnung angebracht ist, und bringt seinen eigenen Namen und seine Anschrift auf dem Produkt an. Händler prüfen nach Artikel 20 das Vorhandensein von CE-Kennzeichnung, Konformitätserklärung und Nutzerinformation. Beide dürfen ein Produkt nicht bereitstellen, wenn sie Grund zur Annahme haben, dass es nicht konform ist, und beide müssen Schwachstellen, von denen sie erfahren, an den Hersteller weitergeben.

Ein Importeur oder Händler wird nach Artikel 21 selbst zum Hersteller, wenn er das Produkt unter eigenem Namen oder eigener Marke in Verkehr bringt oder es wesentlich verändert. Das trifft White-Label-Anbieter und Integratoren häufiger, als sie erwarten. Die Texte: Pflichten der Importeure, Pflichten der Händler, Fälle, in denen Herstellerpflichten für Importeure und Händler gelten.

Produktklassen und Konformitätsbewertung

Der CRA kennt vier Stufen, und die Stufe bestimmt, wer die Konformität prüft.

Die Verfahren stehen in Artikel 32, die Module in Anhang VIII: Konformitätsbewertungsverfahren. Die Kommission präzisiert die Produktkategorien der Anhänge III und IV per Durchführungsrechtsakt.

Ein Hinweis zu den Normen. Die harmonisierten Normen zum CRA werden derzeit bei CEN-CENELEC erarbeitet. Solange eine Norm nicht im Amtsblatt der EU zitiert ist, gibt es keine Konformitätsvermutung nach Artikel 27, und ein Hersteller eines Klasse-I-Produkts kann die Selbstbewertung nicht auf sie stützen. Wer heute plant, sollte mit einer benannten Stelle rechnen oder die Klassifizierung seines Produkts sehr genau prüfen.

Bußgelder

Artikel 64 legt drei Stufen fest. Verstöße gegen die grundlegenden Anforderungen nach Anhang I oder gegen die Pflichten aus Artikel 13 und 14 kosten bis zu 15 Millionen Euro oder 2,5 Prozent des weltweiten Jahresumsatzes des vorangegangenen Geschäftsjahres, je nachdem, welcher Betrag höher ist. Verstöße gegen die übrigen Pflichten kosten bis zu 10 Millionen Euro oder 2 Prozent. Falsche, unvollständige oder irreführende Angaben gegenüber benannten Stellen und Marktüberwachungsbehörden kosten bis zu 5 Millionen Euro oder 1 Prozent. Die Mitgliedstaaten legen die Einzelheiten fest; in Deutschland ist die Marktüberwachung beim Bundesamt für Sicherheit in der Informationstechnik angesiedelt.

Für Kleinstunternehmen und kleine Unternehmen gibt es keine Ausnahme von den Pflichten, wohl aber Erleichterungen bei Dokumentation, Gebühren der benannten Stellen und Unterstützung durch die Mitgliedstaaten (Artikel 33).

Der CRA und die KI-Verordnung

Ein KI-System, das zugleich ein Produkt mit digitalen Elementen ist, unterliegt beiden Verordnungen. Artikel 12 des CRA verzahnt sie: Ein Hochrisiko-KI-System, das die grundlegenden Anforderungen des CRA erfüllt und dessen Konformitätsbewertung nach dem CRA durchgeführt wurde, gilt hinsichtlich der Cybersicherheitsanforderungen der KI-Verordnung (Artikel 15) als konform. Wer beide Verordnungen zu bedienen hat, spart sich mit dieser Brücke eine doppelte Prüfung, muss die Dokumentation aber so anlegen, dass sie beiden Rechtsakten standhält.

Was jetzt zu tun ist

1. Betroffenheit schriftlich feststellen. Für jedes Produkt: erfasst oder ausgenommen, und warum. Gilt der Cyber Resilience Act für Sie?
2. Meldefähigkeit bis zum 11. September 2026 herstellen. Zwei Meldepfade, eine Rufbereitschaft, das zuständige CSIRT bestimmt. Checkliste zur Meldebereitschaft
3. Produktklasse bestimmen. Standard, Klasse I, Klasse II oder kritisch. Davon hängt ab, ob eine benannte Stelle nötig ist und wie viel Zeit bis Dezember 2027 bleibt.
4. SBOM und Schwachstellenprozess aufsetzen. Beides ist Voraussetzung für die Meldefähigkeit und für Anhang I Teil II.
5. Unterstützungszeitraum festlegen und veröffentlichen. Mindestens fünf Jahre, es sei denn, die erwartete Nutzungsdauer ist kürzer.
6. Technische Dokumentation nach Anhang VII anlegen, von Anfang an, nicht am Ende.

Häufig gestellte Fragen

Gilt der CRA für Software-as-a-Service? Nicht als solches. Ein reiner Cloud-Dienst ist kein Produkt mit digitalen Elementen. Erfasst ist er nur als Fernverarbeitungslösung eines Produkts, also wenn ein Produkt ohne ihn seine Funktion nicht erfüllt. Für reine Dienste ist NIS2 die einschlägige Vorschrift.

Gilt der CRA für Open-Source-Software? Für Software, die außerhalb einer Geschäftstätigkeit entwickelt und bereitgestellt wird, nicht. Für kommerzielle Produkte, die Open-Source-Komponenten enthalten, gilt er für das Produkt, und der Hersteller ist für die Komponenten verantwortlich. Open-Source-Software-Verwalter nach Artikel 24 haben eine eigene, leichtere Pflicht.

Gilt der CRA für Produkte, die schon auf dem Markt sind? Die Meldepflichten nach Artikel 14 ja, ab dem 11. September 2026. Die übrigen Anforderungen nur, wenn das Produkt nach dem 11. Dezember 2027 wesentlich verändert wird.

Was ist der Unterschied zwischen CRA und NIS2? NIS2 richtet sich an Organisationen, die bestimmte Dienste erbringen, und verlangt von ihnen Risikomanagement und Meldungen. Der CRA richtet sich an Produkte und an die, die sie herstellen und vertreiben. Ein Unternehmen kann beidem unterliegen: als Betreiber unter NIS2 und als Hersteller unter dem CRA.

Brauche ich eine benannte Stelle? Für ein Standardprodukt nicht; die Selbstbewertung genügt. Für Klasse I nur, wenn harmonisierte Normen nicht vollständig angewandt werden können, was derzeit der Fall ist, solange keine im Amtsblatt zitiert ist. Für Klasse II und kritische Produkte immer.

Muss ich die SBOM veröffentlichen? Nein. Sie gehört in die technische Dokumentation und muss auf begründete Anfrage der Marktüberwachung vorgelegt werden. Ob sie den Nutzern zugänglich gemacht wird, entscheidet der Hersteller.

Quellen

• Verordnung (EU) 2024/2847, Cyber Resilience Act, deutsche Fassung im Amtsblatt: eur-lex.europa.eu/eli/reg/2024/2847/oj/deu
• ENISA, Single Reporting Platform für Meldungen nach Artikel 14: enisa.europa.eu/topics/product-security/single-reporting-platform-srp
• Alle Pflichten des CRA mit Wortlaut, Artikel für Artikel: Pflichten aus dem Cyber Resilience Act

Dieser Text ist eine zitierte Einordnung, keine Rechtsberatung. Maßgeblich ist der Text der Verordnung.