Cyber Resilience Act: Folgen für den Verkauf von elektronischen Geräten in der EU ab November 2027

Der CRA gilt für alle Produkte mit digitalen Elementen, die in der EU in Verkehr gebracht werden – unabhängig davon, ob es sich um Hardware oder Software handelt. Ausgenommen sind jedoch bestimmte Produktgruppen wie medizinische Geräte, für die bereits spezifische Normen wie IEC 81001-5-1 und eigene Zulassungsauflagen erfüllen müssen. Auch eingebettete Systeme mit digitalen Schnittstellen fallen unter den CRA, sofern sie potenziell angreifbar sind.

The CRA applies to all products sold on or after the enforcement date (December 12, 2027). Products already in use before this date are not retroactively affected unless they are significantly modified. Devices without internet connectivity may still fall under the CRA if they have any interface (e.g., USB) that could be exploited.

Prototypen, die nicht in Verkehr gebracht werden, unterliegen nicht dem CRA. Sobald ein Produkt jedoch in Serie geht oder verkauft wird, gelten die CRA-Anforderungen. Für KMUs gibt es keine Ausnahmeregelungen im CRA – alle Hersteller müssen die gleichen Anforderungen erfüllen.

Hersteller, die Komponenten wie Kameramodule in eigene Produkte integrieren und diese unter eigener Marke vertreiben, gelten als Inverkehrbringer und sind somit vollumfänglich für die CRA-Konformität verantwortlich – inklusive Meldepflichten und Sicherheitsprozesse. Eine Risikoanalyse kann ggf. auf Basis der Vorzertifizierung des Zulieferers erfolgen, ersetzt aber nicht die Gesamtverantwortung.

„Digitale Elemente“ sind laut Gesetz Produkte oder Komponenten, die über eine digitale Funktion verfügen – insbesondere solche mit Mikrocontrollern und Schnittstellen zur Außenwelt. Auch einfache Steuerungen, die intern digitale Logik enthalten, können darunterfallen, selbst wenn sie keine Internetverbindung besitzen.

Ein Produkt gilt als vernetzt, sobald es über eine Schnittstelle verfügt, über die es potenziell manipuliert werden kann – unabhängig davon, ob es sich um eine Internetverbindung, einen USB-Port oder einen VPN-Tunnel handelt. Entscheidend ist die technische Möglichkeit des Zugriffs, nicht die Art der Verbindung. Wenn ein Produkt über eine Schnittselle und/oder die Verbindung verfügt, kann das Produkt vernetzt werden. Es ist nicht entscheidend, ob ein Kunde diese Schnittestelle und/oder Verbindung nutzt.

Ja, auch Geräte ohne Internetverbindung können unter den CRA fallen, wenn sie über Schnittstellen verfügen, die potenziell angreifbar sind – z. B. USB, serielle Ports oder andere physikalische Verbindungen. Die bloße Existenz eines Mikrocontrollers mit externer Schnittstelle kann ausreichen.

Ja, alle Komponenten, die in ein Produkt integriert werden und sicherheitsrelevante Funktionen übernehmen, müssen im Rahmen der CRA-Konformität berücksichtigt werden. Vorzertifizierte Module können helfen, entbinden den Hersteller jedoch nicht von der Pflicht, das Endprodukt vollständig zu bewerten und zu dokumentieren.

Sobald solche Systeme über externe Schnittstellen verfügen, müssen sie hinsichtlich ihrer Sicherheitsrisiken bewertet werden. Die konkrete CRA-Relevanz hängt vom Anwendungsfall, der Architektur und der Art der Schnittstellen ab. Eine Risikoanalyse ist in jedem Fall erforderlich.

Die CRA fordert, dass Produkte über ihren Lebenszyklus hinweg sicherheitsrelevante Updates erhalten können. Daher kann es sinnvoll sein, bei der Entwicklung ausreichend Speicher für zukünftige Software- oder Sicherheitsupdates (z. B. FOTA) einzubauen. Dies ist jedoch abhängig vom erwarteten Updatebedarf und der Produktarchitektur.

Sicherheitsvorfälle müssen innerhalb von 24 Stunden gemeldet werden. Es gibt keine Ausnahmen für Wochenenden oder Feiertage. Die Behebung der Schwachstelle selbst muss „so schnell wie möglich“ erfolgen – eine konkrete Frist ist in der Verordnung nicht definiert, aber dokumentierte Prozesse zur Reaktion sind verpflichtend.

Hersteller müssen eingehende Meldungen bewerten, dokumentieren und – falls berechtigt – innerhalb von 24 Stunden an die zuständige Stelle weiterleiten. Die Kompetenz des meldenden Kunden spielt dabei keine Rolle für die Meldepflicht.

Für Produkte ist das BSI (Bundesamt für Sicherheit in der Informationstechnik) die zuständige Meldestelle in Deutschland. Die Zuständigkeit kann sich im Detail noch verändern, aber aktuell ist das BSI der zentrale Ansprechpartner für CRA-relevante Vorfälle. In anderen Ländern sind es andere Organisationen.

Ja, für jedes Produkt mit digitalen Elementen muss eine Risikoanalyse durchgeführt und dokumentiert werden – unabhängig davon, ob es sich um ein Grenzfallprodukt oder ein klar vernetztes Gerät handelt. Auch Produkte ohne Internetverbindung können durch andere Schnittstellen sicherheitsrelevant sein.

Für einfache Anwendungen kann Excel ausreichen. Für komplexere Systeme werden oftmals spezialisierte Tools wie Medini von Ansys empfohlen. Auch standardisierte Methoden wie TARA (Threat Analysis and Risk Assessment) bieten strukturierte Vorgehensweisen. Wichtig ist, dass die Methode zur Produktkomplexität passt und dokumentierbar ist.

Diese Normen sind nicht direkt Teil des CRA, bieten aber wertvolle Orientierung. IEC 62443 ist besonders relevant für industrielle Anwendungen, ISO 21434 für den Automotive-Bereich. Eine ISO-Zertifizierung ist für CRA-Konformität nicht zwingend erforderlich, kann aber unterstützend wirken.
 

EN18031 (RED-DA) ist für Funkmodule verpflichtend und enthält spezifische Test- und Dokumentationsanforderungen. Der CRA ergänzt diese Anforderungen um produktspezifische Sicherheitsaspekte. Beide Regelwerke müssen parallel erfüllt werden, wenn ein Produkt unter beide fällt und beide müssen erfüllt sein, um eine CE zu erhalten..

Ob eine Selbsterklärung ausreicht, hängt vom Produkttyp und der Risikokategorie ab. Für viele Produkte ist ein Self-Assessment zulässig, bei kritischen Produkten können jedoch zusätzliche Anforderungen wie Zertifierungen durch Dritte notwendig sein.

Wird Open-Source-Software in ein kommerzielles Produkt integriert, muss der Hersteller sicherstellen, dass diese Komponenten den CRA-Anforderungen entsprechen. Dazu gehört auch die Pflege und Aktualisierung über mindestens fünf Jahre nach dem letzten Verkaufstag hinweg.

Hersteller sind verpflichtet, sicherheitsrelevante Updates über einen Zeitraum von mindestens fünf Jahre nach dem letzten Verkaufstag bereitzustellen. Dies umfasst auch die technische Möglichkeit zur Aktualisierung (z. B. FOTA) sowie die Absicherung des Update-Prozesses.

Der CRA gilt für alle Produkte, die ab dem 12. Dezember 2027 in Verkehr gebracht werden – unabhängig davon, wann sie produziert wurden. Auch Lagerware muss CRA-konform sein, wenn sie nach diesem Datum verkauft wird.

Ohne eine neue Konformitätserklärung nach CRA dürfen Produkte nach dem Stichtag nicht mehr in Verkehr gebracht werden. Ein Bestandsschutz besteht nicht. Auch Ersatzteile können betroffen sein, wenn sie sicherheitsrelevante Funktionen übernehmen.

Wird ein sicherheitsrelevantes Ersatzteil in ein bestehendes Produkt eingebaut, kann dies als „wesentliche Änderung“ gelten und eine neue CRA-Konformitätsbewertung erforderlich machen – insbesondere, wenn dadurch neue Schnittstellen oder Funktionen hinzukommen.

Ja, es gibt sowohl kommerzielle Tools als auch Beratungsangebote, die Unternehmen bei der Umsetzung unterstützen – z. B. für Risikoanalysen, Dokumentation oder Prozessgestaltung. Auch automatisierte Tools für bestimmte Schritte sind verfügbar.

Ein Self-Assessment umfasst die Identifikation sicherheitsrelevanter Funktionen, eine Risikoanalyse, die Dokumentation von Maßnahmen sowie die Erstellung einer Konformitätserklärung. Es ist vergleichbar mit internen Prozessen wie bei ISO 9001, aber produktbezogen.

SIL-Zertifizierungen betreffen funktionale Sicherheit, nicht Cybersicherheit. Daher ist eine ergänzende Bewertung nach CRA erforderlich – insbesondere hinsichtlich der digitalen Schnittstellen und der Updatefähigkeit.

Das hängt vom Sicherheitsbedarf und der Systemarchitektur ab. In der Regel ist es empfehlenswert, mit einem gehärteten Mikrocontroller zu starten und bei Bedarf ein separates Secure Element zu ergänzen, um kritische Daten wie Zugangsdaten besonders zu schützen.