von Maximilian Schmöcker

EU Cyber Resilience Act für IoT-Systeme

Wie der Cyber Resilience Act IoT-Produkte betrifft – von Secure-by-Design-Anforderungen bis zum Schwachstellenmanagement nach der Veröffentlichung.

IoTCyber Resilience ActSicherheitSBOM

Einleitung

Die EU hat eine neue Verordnung veröffentlicht, die darauf abzielt, vernetzte Geräte abzusichern. Das reicht vom Einsatz in der Infrastruktur bis zu Verbraucheranwendungen. Konkret betrifft sie nicht nur Hardware, sondern alle Produkte mit digitalen Elementen. Dazu zählt jede programmierbare oder netzwerkfähige Komponente, also Mikrocontroller, Firmware und IoT-Systeme. Wie bei anderen Verordnungen werden viele Hardwarehersteller die Auswirkungen ignorieren, bis es zu spät ist, und so aus einer jahrelangen Übergangsfrist im schlimsten Fall ein paar Monate Stress werden.

Der Cyber Resilience Act ist seit Dezember 2024 in Kraft und gilt ab dem 11. Dezember 2027 in vollem Umfang, wobei Meldepflichten bereits ab dem 11. September 2026 greifen. Produkte, die vor dem 11. Dezember 2027 in Verkehr gebracht wurden, müssen die CRA-Konformitätsanforderungen nur erfüllen, wenn sie wesentlich verändert werden. Die Meldepflicht für Schwachstellen gilt jedoch für alle Produkte mit digitalen Elementen, die sich noch innerhalb ihres Support-Zeitraums befinden oder aktiv in Verkehr gebracht werden.

Hinweis: Ich bin Informatiker, kein Jurist. Bitte ziehen Sie für alle Details den Gesetzestext Verordnung – 2024/2847 – EUR-Lex heran.

Für wen der CRA gilt

Die Verordnung richtet sich an alle, die Produkte mit digitalen Elementen auf den EU-Markt bringen, also Hersteller, Importeure und Händler.

Als Faustregel gilt: Steht Ihr Firmenlogo auf dem Gehäuse, sind Sie verpflichtet, den Cyber Resilience Act für das jeweilige Produkt umzusetzen. Stellt Ihr Unternehmen ausschließlich OEM-Komponenten her, die von einem Dritten zusammengesetzt werden, sind Sie möglicherweise nicht direkt haftbar. In diesem Fall werden Ihre Kunden jedoch von Ihnen Dokumentation, SBOMs und andere sicherheitsrelevante Informationen verlangen. Gut vorbereitet zu sein, verschafft Ihnen einen großen Vorsprung gegenüber Wettbewerbern.

Produktkategorien

Produkte werden grundsätzlich in drei Kategorien eingeteilt: Produkte mit digitalen Elementen, wichtige Produkte und kritische Produkte. Je nach Sicherheitsauswirkung kann die Bewertung durch Sie selbst oder durch eine notifizierte Stelle (Dritte) erfolgen.

KategorieBeispielVollständige ListeBewertung
Produkte mit digitalen ElementenSmarte Spielzeuge, Kühlschränke, Wearables, unkritische IndustriesteuerungenAlles, was nicht in Anhang III oder IV aufgeführt istSelbstbewertung möglich
Wichtiges Produkt (Anhang III, Klasse I/II)Netzwerkmanagement, Firewalls, BetriebssystemeAnhang IIIformale Sicherheitsbewertung teils erforderlich
Kritisches Produkt (Anhang IV)Hardware-Sicherheitsmodule, Root-DNS-/CA-ServerAnhang IVformale Sicherheitsbewertung erforderlich

Auswirkungen

Pflichten der Hersteller

Der Hersteller ist verpflichtet, über den gesamten Produktlebenszyklus hinweg eine Cybersicherheits-Risikobewertung durchzuführen. Dazu gehört auch die Prüfung von Drittanbieter-Komponenten, die in das Endprodukt integriert werden.

Darüber hinaus muss der Hersteller für die erwartete Produktlebensdauer einen Support-Zeitraum festlegen, in dem auftretende Schwachstellen wirksam behandelt werden. Der Support-Zeitraum beträgt in der Regel mindestens 5 Jahre, sofern die Lebensdauer des Geräts nicht kürzer ist. Sowohl die technische Dokumentation als auch Sicherheitsupdates müssen verfügbar sein und mindestens 10 Jahre lang herunterladbar bleiben. Übersteigt der Support-Zeitraum 10 Jahre, gilt dieser längere Zeitraum. Sicherheitsupdates müssen kostenlos und so schnell wie möglich bereitgestellt werden und dürfen nicht in künftige Release-Zyklen gebündelt werden. Wichtig ist außerdem, dass der Support-Zeitraum zum Kaufzeitpunkt klar und verständlich angegeben wird.

Meldepflichten

Sobald eine aktiv ausgenutzte Schwachstelle entdeckt wird, ist der Hersteller verpflichtet, innerhalb von 24 Stunden eine Frühwarnung an das Computer Security Incident Response Team (CSIRT) des EU-Mitgliedstaats, in dem das Unternehmen hauptsächlich tätig ist, sowie an die ENISA (die EU-Agentur für Cybersicherheit) zu übermitteln. Anschließend muss innerhalb von 72 Stunden eine vollständige Meldung erfolgen, in der alle bekannten technischen Details anzugeben sind.

Ein Abschlussbericht ist spätestens 14 Tage nach Verfügbarkeit einer Abhilfemaßnahme einzureichen. Bei schwerwiegenden Vorfällen verlängert sich diese Frist auf einen Monat ab der 72-Stunden-Meldung.

Grundlegende Cybersicherheitsanforderungen

Der Cyber Resilience Act umfasst eine Reihe von grundlegenden Anforderungen, die erfüllt werden müssen. Eine vollständige Liste finden Sie unter https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=OJ:L_202402847#anx_I.

Alle nachstehenden Punkte sollten nach dem Security-by-Design-Ansatz umgesetzt werden und keine nachträgliche Ergänzung sein. Selbst wenn ein Vorfall eintritt, müssen die wesentlichen und grundlegenden Funktionen des Geräts erhalten bleiben, einschließlich Maßnahmen gegen Denial-of-Service-Angriffe.

Sichere Standardeinstellungen & Updates

Abgesehen davon, dass Ihre Produkte selbstverständlich ohne bekannte ausnutzbare Schwachstellen ausgeliefert werden, müssen Produkte mit einer sicheren Standardkonfiguration ausgeliefert werden. So darf das Gerät beispielsweise kein fest vergebenes Standardpasswort verwenden. Stattdessen müssen Hersteller sicherstellen, dass jedes Gerät über ein eindeutiges Passwort verfügt und dass dieses Passwort dem Kunden mitgeteilt wird. Auftretende Schwachstellen müssen durch Sicherheitsupdates behoben werden. Wo möglich, sollten diese Sicherheitsupdates über automatische Updates ausgerollt und innerhalb eines angemessenen Zeitraums installiert werden. Darüber hinaus müssen Mechanismen, um automatische Updates vorübergehend aufzuschieben oder zu deaktivieren, klar und einfach bedienbar bereitgestellt werden. Der Nutzer muss dennoch über verfügbare Updates informiert werden.

Anforderungen an Tests

Es müssen wirksame und regelmäßige Tests sowie Überprüfungen der Produktsicherheit durchgeführt werden. Das bedeutet, dass Ad-hoc-Tests nicht ausreichen. Tests müssen systematisch durchgeführt werden, idealerweise mit automatisierten Hardware-Tests.

Datenschutz

Der Hersteller muss den Schutz vor unbefugtem Zugriff auf die Geräte sicherstellen. Beispielsweise müssen Authentifizierung und Zugriffsverwaltung eingerichtet sein, zusammen mit der Meldung unbefugter Zugriffe.

Auf dem Gerät erhobene und verarbeitete Daten müssen minimal und auf den notwendigen Verwendungszweck beschränkt sein. Relevante Sicherheitsereignisse müssen überwacht und aufgezeichnet werden, mit einer Opt-out-Möglichkeit für Nutzer. Zusätzlich muss der Nutzer in der Lage sein, alle Daten und Einstellungen dauerhaft und sicher zu löschen, einschließlich Daten, die an ein anderes Produkt oder System übertragen wurden.

Die Vertraulichkeit und Integrität von Daten, die auf Geräten gespeichert und übertragen werden, muss geschützt werden. Dies kann durch Verschlüsselung relevanter Daten im Ruhezustand oder während der Übertragung mit dem Stand der Technik entsprechenden Mechanismen erfolgen. In der Praxis bedeutet das den Einsatz von TLS, SSH, VPNs oder anderen Mechanismen, die über Protokolle wie TCP, HTTP oder MQTT übertragen werden.

Wir haben beispielsweise einen Tunnel für TCP über HTTP mittels WebSockets implementiert. Ein Gerät verbindet sich über eine normale HTTP-Anfrage mit einem zentralen Relay, über das eine Verbindung zu einem Zielserver aufgebaut wird. Ab diesem Punkt können sowohl Gerät als auch Server über etablierte Protokolle wie SSH kommunizieren, wobei die zugrunde liegende Verbindung über HTTP-WebSockets geleitet wird. So lässt sich Netzwerkverkehr ermöglichen, ohne unerwünschte Ports zu öffnen. Das Gerät kann hinter einem NAT betrieben werden und benötigt nicht einmal Internetzugang, sondern nur eine Verbindung zum Relay. Auch andere Lösungen wie der Einsatz eines VPN, bei dem Geräte sich nicht gegenseitig erreichen, sondern sich mit einer zentralen oder verteilten Instanz verbinden, sind zulässig, sofern sie korrekt konfiguriert sind.

Reduzierung der Angriffsfläche

Darüber hinaus müssen alle Angriffsflächen begrenzt werden, sowohl bei Software- als auch bei Hardware-Schnittstellen. So können beispielsweise USB-Anschlüsse deaktiviert werden, wenn sie im regulären Betrieb keinen Zweck erfüllen.

Anforderungen an den Umgang mit Schwachstellen

Hersteller sind verpflichtet, Schwachstellen zu identifizieren und zu dokumentieren. Konkret muss eine koordinierte Richtlinie zur Offenlegung von Schwachstellen (Coordinated Vulnerability Disclosure) durchgesetzt werden. Das bedeutet, einen dokumentierten Prozess zur Entgegennahme, Bewertung und Beantwortung von Schwachstellenmeldungen einzuführen. Um es Nutzern leicht zu machen, müssen Sie eine Kontaktadresse für Schwachstellenmeldungen bereitstellen, also etwa eine eigene E-Mail-Adresse auf Ihrer Website oder eine Information in Ihrer ausgelieferten Software.

Nach Durchführung eines Sicherheitsupdates müssen Informationen offengelegt und öffentlich geteilt werden. Dazu gehören eine Beschreibung der Schwachstelle sowie Informationen, die es Nutzern ermöglichen, die Auswirkungen und den Schweregrad der Schwachstelle einzuschätzen.

Software Bill of Materials

Um Schwachstellen systematisch aufzudecken, ist es erforderlich, eine Software Bill of Materials (SBOM) für das CVE-Scanning erstellen zu können, die mindestens die Abhängigkeiten der obersten Ebene abdeckt.

Je nach vorhandener Infrastruktur sind mehrere Strategien möglich. Die sauberste Lösung besteht darin, eine SBOM zusammen mit der Software-Build-Pipeline zu erzeugen. Hier sind die genauen Abhängigkeiten in der Regel bekannt. Ein deklarativer Ansatz wie Nix-basierte Systeme oder Yocto-Builds ermöglicht eine feingranulare Kontrolle, und SBOMs können für die spätere Verwendung gespeichert werden. Alternativ ermöglichen verschiedene Projekte wie Trivy oder Syft das Scannen von Images, Containern oder Binärartefakten. Das hat den Nachteil, dass manche Abhängigkeiten oder Versionen nicht korrekt erkannt oder vollständig übersehen werden. Natürlich können SBOMs aus mehreren Quellen gesammelt, erzeugt und zusammengeführt werden, was allerdings ebenfalls nicht trivial ist. Sich auf eine gute Build-Pipeline zu verlassen, ist meist die beste Option und ohnehin vorteilhaft für die Reproduzierbarkeit.

Nichteinhaltung

Die EU-Mitgliedstaaten sind für die Umsetzung und Durchsetzung der Sanktionen verantwortlich. Bei Nichteinhaltung der grundlegenden Cybersicherheitsanforderungen können Bußgelder von bis zu 15 Millionen EUR oder 2,5 % des weltweiten Jahresumsatzes verhängt werden, bei Nichteinhaltung der Pflichten 10 Millionen EUR oder 2 % des weltweiten Jahresumsatzes. Zusätzlich können Behörden den Verkauf Ihres Produkts untersagen und einen Rückruf anordnen.

Fazit

Der Cyber Resilience Act führt strenge, langfristige Pflichten ein, die Hersteller dazu zwingen, Produktdesign und -wartung über den gesamten Produktlebenszyklus hinweg neu zu denken. Die Anforderungen sind zwar streng, aber längst überfällig. Die jüngsten Ereignisse haben uns die Bedeutung einer starken Cyber-Resilienz vor Augen geführt, und der nächste große Vorfall könnte unmittelbar bevorstehen.

Die Verordnung betont zwei zentrale Prinzipien: Security-by-Design-Grundsätze, um Vorfälle von vornherein zu verhindern, ergänzt durch Maßnahmen zur Meldung und Behebung ausgenutzter Schwachstellen. Damit werden die möglichen Auswirkungen und das Ausmaß wirksam reduziert und zugleich der Informationsfluss zu betroffenen Nutzern verbessert.

Bereit, Ihre IoT-Infrastruktur zu transformieren?

Beginnen Sie mit unserer kostenlosen Open-Source-Version oder kontaktieren Sie uns für Enterprise-Lösungen. Komplexes IoT-Setup vereinfacht.

Datenschutz-Einstellungen

Wir verwenden technisch erforderliche Cookies für Betrieb und Sicherheit. Optionale Cookies für Messung und Marketing nutzen wir nur mit Ihrer Einwilligung. Zur Datenschutzerklärung

ende