Geräte mit digitalen Komponenten sind heute in jedem Lebensbereich anzutreffen. Smartphone und Smart-TV sind Standard. Die Küchenmaschine verfügt über eine WLAN-Verbindung. Und selbst die Beleuchtung ist im Zuge des „Smart Home“ per App steuerbar. Diese Technologien sind praktisch, modern und mit Komfort verbunden.
Mit der Bequemlichkeit stiegen jedoch die Risiken. Potenziell ist jedes Gerät mit einem Netzwerkanschluss angreifbar. Um das Sicherheitsniveau dieser Geräte in der EU zu vereinheitlichen, verabschiedete die Europäische Union den EU Cyber Resilience Act (CRA).
Seit dem Inkrafttreten dieser Verordnung (EU 2024/2847) am 10. Dezember 2024 läuft für die Hersteller technischer Geräte ein Countdown. Wir beantworten die wichtigsten Fragen zum CRA, damit Sie die Compliance-Hürden meistern.
Der Cyber Resilience Act ist die erste EU-weite Gesetzgebung, die verbindliche Cybersicherheitsanforderungen für Produkte mit digitalen Elementen festlegt. Ziel ist es, den Schutz von Hard- und Softwareprodukten über ihren gesamten Lebenszyklus hinweg sicherzustellen.
Info: Hersteller müssen Updates für die voraussichtliche Nutzungsdauer des Produkts bereitstellen, höchstens jedoch für 5 Jahre. Ausnahme: Das Produkt wird explizit für eine längere Nutzung beworben. Diese konkrete Zeitspanne sichert Unternehmen zu, nicht in eine „ewige Update-Pflicht“ zu geraten.
Bisher war Cybersicherheit eine freiwillige Leistung der Hersteller. Der CRA macht sie zur Voraussetzung für den Marktzugang im EU-Binnenmarkt. Das Gesetz adressiert zwei Hauptprobleme:
- die unzureichende Sicherheit vieler Produkte direkt ab Werk („Security by Design“ bzw. „Security by Default“)
- das Fehlen von Sicherheitsupdates über die Nutzungsdauer hinweg.
Der CRA basiert auf dem New Legislative Framework (NLF). Er ist darum eng mit der CE-Kennzeichnung verknüpft. Produkte, die die im CRA definierten wesentlichen Sicherheitsanforderungen erfüllen, dürfen das CE-Zeichen tragen und in der EU verkauft werden. Dies umfasst sowohl den Schutz vor unbefugtem Zugriff als auch die Vertraulichkeit, Integrität und Verfügbarkeit von Daten. Der CRA schafft damit ein Sicherheitsniveau, das mit den Qualitätsstandards für Spielzeug oder Elektrogeräte vergleichbar ist.
Dies sind zwei der Grundprinzipien des Cyber Resilience Act. Dabei handelt es sich um Anforderungen des CRA, die Hersteller bei der Planung und Fertigung ihrer Produkte zwingend beachten müssen.
Security by Default: Diese Anforderung besagt, dass Standardeinstellungen vernetzter Produkte zu einer Erhöhung ihrer Sicherheit beitragen müssen. Schwache Standardpasswörter sind damit verboten. Ebenso muss das Produkt die automatische Installation von Sicherheitsupdates gewährleisten. Wenn es technisch möglich ist, sollen Sicherheitsupdates getrennt von neuen Funktionsupdates bereitgestellt werden. So wird es Nutzenden möglich, Sicherheitslücken zu schließen, ohne neue Software-Features installieren zu müssen.
Security by Design: Gemäß dem Grundsatz „Security by Design“ müssen vernetzte Produkte von Anfang an mit Blick auf die Cybersicherheit konzipiert werden. Hersteller müssen unter anderem sicherstellen, dass die auf oder mit dem Produkt gespeicherten oder übertragenen Daten verschlüsselt sind und die Angriffsfläche so gering wie möglich gehalten wird.
Der Zeitplan des Cyber Resilience Act ist für Unternehmen von enormer Bedeutung. Die Vorbereitungszeit für technische Anpassungen nimmt oft Jahre in Anspruch. Nach dem Inkrafttreten im Dezember 2024 gewährte die EU eine Übergangsphase von insgesamt 36 Monaten, bis die Verordnung vollständig anwendbar wird. Das bedeutet, dass Unternehmen ab Dezember 2027 kein betroffenes Produkt mehr ohne CRA-Konformität auf den Markt bringen dürfen.
Info: Produkte, die vor dem 11. Dezember 2027 auf den Markt gebracht werden, müssen nicht nachträglich CRA-konform gemacht werden. Die Ausnahme bilden „wesentliche Änderungen“. Wird ein älteres Produkt mit einem Update versorgt, das den Verwendungszweck ändert oder das Sicherheitsrisiko beeinflusst, gilt dies als „wesentliche Änderung“. Das Produkt verliert seinen Bestandsschutz und muss nachträglich vollständig CRA-zertifiziert werden.
Ein besonders kritisches Datum ist der bevorstehende 11. September 2026. In nur wenigen Monaten treten die strengen Meldepflichten für aktiv ausnutzbare Schwachstellen und schwerwiegende Sicherheitsvorfälle in Kraft. Ab diesem Tag müssen Prozesse etabliert sein, um Vorfälle innerhalb von 24 Stunden an die ENISA (Agentur der Europäischen Union für Cybersicherheit) zu melden. Diese vorgezogene Frist soll sicherstellen, dass die EU-Behörden noch vor der Zertifizierung aller Produkte über Bedrohungslagen informiert sind.
Nicht nur Hardware ist von den Vorgaben des CRA betroffen. Auch reine Software fällt unter die Regulierung.
Der Anwendungsbereich des CRA ist extrem breit gefasst. Er gilt für alle „Produkte mit digitalen Elementen“. Einfach ausgedrückt: Nahezu alle Produkte, die über einen Prozessor verfügen, sind betroffen. Darunter fällt physische Hardware wie Smart-Home-Geräte, Router, Laptops und Industriesteuerungen.
Reine Softwareprodukte wie Betriebssysteme, Cloud-Software und mobile Apps fallen ebenfalls in den Geltungsbereich des Cyber Resilience Act. Das bedeutet, dass eine gewaltige Zahl von digitalen Gütern direkt von den Regelungen des CRA betroffen ist, die kommerziell in der EU vertrieben werden sollen.
Die Verordnung unterscheidet dabei zwischen verschiedenen Risikoklassen. Rund 90 % der Produkte fallen in die Kategorie „Standard“ (unbedenkliche Anwendungen). Die restlichen 10 % werden als „Wichtig“ (Klasse I und II) oder „Kritisch“ eingestuft.
Zur Klasse I gehören beispielsweise Browser und Passwortmanager, während Klasse II kritischere Komponenten wie Firewalls umfasst. Je höher die Risikoklasse, desto strenger sind die Anforderungen an die Bewertung der Konformität. Analysieren Sie frühzeitig, in welche Kategorie Ihre Produkte fallen.
Nicht jedes Produkt fällt unter den CRA. Mit dieser Regelung möchte die EU Doppelregulierungen vermeiden. Zu den wichtigsten Ausnahmen gehören Produkte, die bereits durch spezifischere EU-Rechtsvorschriften erfasst werden und die ein vergleichbares Sicherheitsniveau fordern. Beispiele sind Medizinprodukte, die zivile Luftfahrt sowie Fahrzeuge, die unter die Typgenehmigungsverfahren für Kfz fallen.
Produkte, die ausschließlich militärischen Zwecken oder Angelegenheiten der nationalen Sicherheit dienen, sind ebenfalls ausgenommen. Eine weitere wichtige Abgrenzung betrifft Software-as-a-Service (SaaS). Während klassische Softwareprodukte unter den CRA fallen, deckt die NIS2 SaaS-Produkte ab, sofern es sich um wesentliche Dienste handelt.
Dennoch gibt es Grauzonen, die eine Einordnung kompliziert machen. Wenn eine SaaS-Lösung lokale Softwarekomponenten (wie einen Agenten oder eine App) erfordert, unterliegen diese Komponenten dem CRA.
Die Einbeziehung von Open Source war eines der am heftigsten debattierten Themen während des Gesetzgebungsprozesses. Die finale Fassung stellt klar, dass rein nicht-kommerzielle Open-Source-Aktivitäten nicht unter den CRA fallen. Entwickler, die Code unentgeltlich und ohne kommerzielle Absicht zur Verfügung stellen, sind von den Pflichten befreit. Dies soll die Innovationskraft der Community schützen. Wird jedoch eine Open-Source-Komponente kommerziell bereitgestellt (z. B. durch bezahlten Support oder als Teil eines kommerziellen Produkts), greifen die Regelungen des CRA.
Für Sie bedeutet dies eine erhöhte Sorgfaltspflicht, wenn Sie Open-Source-Komponenten in kommerzielle Produkte integrieren. In dem Fall gelten Sie als Hersteller des Endprodukts. Somit sind Sie dafür verantwortlich, dass auch die integrierten Open-Source-Teile sicher sind.
Der CRA führt hier das Konzept des „Open Source Software Stewards“ ein. Das sind Organisationen, die die Entwicklung von Open-Source-Produkten mit kommerziellem Bezug verwalten. Sie müssen zwar keine volle Zertifizierung durchlaufen, aber grundlegende Richtlinien für das Schwachstellenmanagement etablieren.
Open Source Software fällt nur unter die Regelungen des Cyber Resilience Act, wenn sie in kommerziellen Produkten eingesetzt wird.
Eines der zentralen technischen Instrumente des Cyber Resilience Act ist die Software Bill of Materials (SBOM). Stellen Sie sich die SBOM wie eine Zutatenliste für Software vor. Hersteller müssen dokumentieren, welche Komponenten von Drittanbietern oder aus Open-Source-Quellen ihr Produkt enthält. Das ist entscheidend, um im Falle einer neu entdeckten Sicherheitslücke sofort feststellen zu können, welche Produkte betroffen sind.
Ohne eine detaillierte SBOM ist ein effektives Schwachstellenmanagement heute kaum möglich. Der CRA fordert zudem, dass diese Liste in einem maschinenlesbaren Format vorliegt. Die SBOM muss regelmäßig aktualisiert werden und für die Marktaufsichtsbehörden zugänglich sein. Für Sie als Hersteller bedeutet dies die Einführung automatisierter Prozesse in Ihrer Build-Pipeline. Es reicht nicht mehr aus, Software einmalig zu prüfen. Die Transparenz über die gesamte Lieferkette wird zur gesetzlichen Pflicht.
Info: Der CRA nimmt die gesamte Lieferkette in die Pflicht. Wenn der Importeur Produkte aus Asien oder den USA in die EU einführt, muss er prüfen, ob der Hersteller die Konformitätsbewertung durchgeführt hat. Bringt der Importeur das Produkt unter eigenem Namen auf den Markt, wird er rechtlich zum Hersteller und haftet dafür.
Bei der Fülle an neuen EU-Regulierungen den Überblick zu behalten ist schwierig. Der Hauptunterschied zwischen dem CRA und anderen Regulierungen liegt im Fokus:
- Der CRA ist eine Produktverordnung. Er stellt Anforderungen an das Design und die Wartung von technischen Gütern. Wichtig ist, dass der CRA nur für die Hersteller gilt, nicht jedoch für die Betreiber. Er antwortet auf die Frage: „Ist dieses Gerät sicher?“
- Im Gegensatz dazu ist die NIS2-Richtlinie eine Betreiberregulierung. Sie richtet sich an Unternehmen in kritischen Sektoren (Energie, Gesundheit, IT) und fordert organisatorische Sicherheitsmaßnahmen. NIS2 fragt: „Ist das Unternehmen ausreichend geschützt?“
- Die DORA (Digital Operational Resilience Act) ist hingegen eine Sektor-Regulierung speziell für den Finanzmarkt. Sie überschreibt in diesem Bereich teilweise die Anforderungen von NIS2. Während ein Bankserver unter NIS2/DORA fällt, muss die darauf laufende Software oder die Hardware des Servers den CRA-Anforderungen entsprechen.
Zusammen bilden diese Gesetze ein Sicherheitsnetz. Der CRA sichert die Bausteine (Produkte), während NIS2 und DORA den stabilen Betrieb der daraus gebauten Systeme (Infrastruktur) gewährleisten.
Die EU sieht beim CRA drastische Sanktionen vor, um eine konsequente Umsetzung zu erzwingen. Die Bußgelder orientieren sich an denen der Datenschutz-Grundverordnung (DSGVO). Bei Verstößen gegen die wesentlichen Cybersicherheitsanforderungen können Bußgelder von bis zu 15 Millionen Euro oder 2,5 % des weltweiten Jahresumsatzes verhängt werden, je nachdem, welcher Betrag höher ist. Selbst weniger schwere Verstöße können noch mit bis zu 5 Millionen Euro sanktioniert werden. Dazu zählt etwa die Bereitstellung falscher Informationen an Behörden.
Neben den rein finanziellen Strafen haben die Marktaufsichtsbehörden weitreichende Befugnisse. Sie können den Verkauf von Produkten untersagen, einen Rückruf bereits verkaufter Geräte anordnen oder das Produkt vom Markt nehmen. Für Unternehmen ist das Reputationsrisiko oft noch schwerwiegender als das Bußgeld. Ein Produkt, das öffentlich als „unsicher“ markiert wird, ist am Markt praktisch unverkäuflich.
Eine bedeutende Frage ergibt sich durch den Cyber Resilience Act: Wie können Sie als Hersteller nachweisen, dass Ihre Produkte die Anforderungen erfüllen?
Hier sieht die Regelung drei Wege vor:
- Für Standardprodukte genügt eine Selbsterklärung. Der Hersteller führt die technische Dokumentation intern durch und bestätigt die Konformität in Eigenregie.
- Für Produkte der Klasse I („wichtig“) muss der Hersteller entweder harmonisierte Normen anwenden oder eine externe Prüfung durchführen lassen. Gibt es für diese Produkte noch keine harmonisierten EU-Normen, ist die Prüfung durch einen „Notified Body“ zwingend. Dabei handelt es sich um private oder öffentliche Einrichtungen, die digitale Produkte auditieren dürfen.
- Für die Hochrisiko-Produkte der Klasse II ist immer eine externe Zertifizierung durch eine staatlich anerkannte Prüfstelle erforderlich. In Deutschland kann dies unter anderem der TÜV sein. Nach erfolgreichem Abschluss des Verfahrens bringt der Hersteller das CE-Logo an. Damit garantiert er die allgemeine Sicherheit des Geräts und gleichzeitig auch die Cybersicherheit. Diese Dokumentation muss für mindestens 10 Jahre nach dem Inverkehrbringen des Produkts aufbewahrt werden. Das unterstreicht die langfristige Verantwortung der Hersteller.
Die Frage, wann Sie mit den Vorbereitungen auf den CRA beginnen sollten, ist schnell beantwortet: Jetzt!
Folgende Schritte stellen eine Richtschnur dar:
- Bestandsaufnahme: Welche Produkte und Softwarekomponenten vertreiben Sie in der EU?
- Klassifizierung: Fallen Ihre Produkte in die Standard-Kategorie oder in eine der Risikoklassen?
- Schwachstellenmanagement: Professionalisieren Sie das Schwachstellenmanagement parallel zu den anderen Schritten. Sie benötigen Prozesse, um Schwachstellen zu finden, innerhalb der gesetzlichen Fristen zu melden und Patches bereitzustellen.
- Vertragsgestaltung: Ein weiterer kritischer Punkt ist die Vertragsgestaltung mit Zulieferern. Sie als Hersteller haften für das Endprodukt. Sie müssen sicherstellen, dass Ihre Zulieferer ebenfalls CRA-konforme Komponenten liefern und SBOMs bereitstellen.
- Dokumentation: Sie sollten die technische Dokumentation vorbereiten, die alle Sicherheitsaspekte des Produkts beschreibt.
Der Cyber Resilience Act ist – wie auch die Cybersicherheit allgemein – kein einmaliges Projekt. Er erfordert digitale Sicherheit im gesamten Produktlebenszyklus mitzudenken. Das gilt von der ersten Codezeile bis zum „End-of-Life“ jedes Geräts.