Ab 2027 müssen vernetzte Produkte, die in der EU verkauft werden, grundlegende Cybersicherheitsanforderungen nach dem Cyber Resilience Act erfüllen. Für IoT- und Netzwerkgeräte bedeutet das: Sicherheit von Anfang an, ein belastbares Schwachstellenmanagement und nachvollziehbare Nachweise, dass die Anforderungen eingehalten werden, andernfalls droht realistisch der Verlust des Zugangs zum EU-Markt.
Cybersicherheit verschiebt sich damit vom Differenzierungsmerkmal zur Grundvoraussetzung für den Vertrieb. Diese Veränderung hängt an zwei konkreten Stichtagen in den Jahren 2026 und 2027, ab denen unterschiedliche Pflichten des Cyber Resilience Act schrittweise gelten.
In diesem Artikel betrachten wir, was der Cyber Resilience Act in der Praxis für Hersteller von IoT- und vernetzten Produkten bedeutet, mit besonderem Fokus auf die zwei kommenden Meilensteine. Die Einordnung basiert auf praktischen Inputs eines Engineering-Teams von Promwad, das Unternehmen dabei unterstützt, Sicherheitsanforderungen systematisch in Produktentwicklung zu verankern.
Warum das auch Hersteller außerhalb Europas betrifft
Sie müssen nicht in der EU ansässig sein, um betroffen zu sein. Sobald Ihr vernetztes Produkt in der EU in Verkehr gebracht wird, direkt, über Distributoren oder über den Online-Vertrieb, greifen die CRA-Erwartungen. Für globale Produktteams ist der CRA daher weniger eine regionale Policy-Änderung als vielmehr eine neue kommerzielle Rahmenbedingung, die technisch eingeplant und umgesetzt werden muss.
Die entscheidende Zeitleiste: Was 2026 und 2027 passiert
Der Cyber Resilience Act ist bereits verabschiedet und als EU-Verordnung in Kraft. Für Produktfahrpläne sind zwei Meilensteine entscheidend:
11. September 2026: Meldepflichten werden anwendbar
Ab September 2026 gelten die ersten operativen Pflichten. In dieser Phase wird von Herstellern betroffener Produkte erwartet, dass sie aktiv ausgenutzte Schwachstellen sowie schwere Sicherheitsvorfälle identifizieren, bewerten und innerhalb definierter Fristen melden können.
Dieser Stichtag verhindert noch nicht den Verkauf von Produkten. Er ist jedoch faktisch ein Stresstest, ob ein Unternehmen funktionierende Sicherheitsprozesse etabliert hat, nicht nur technische Schutzmaßnahmen, sondern auch interne Abläufe für Schwachstellenbearbeitung, Eskalation und Kommunikation. Organisationen, denen Transparenz über ihre Softwarekomponenten fehlt oder bei denen Verantwortlichkeiten für Sicherheit unklar sind, werden diese Anforderungen deutlich schwerer erfüllen.
11. Dezember 2027: Zentrale CRA-Anforderungen werden verbindlich
Ab Dezember 2027 gelten die zentralen Sicherheitsanforderungen des Cyber Resilience Act für neue Produkte mit digitalen Elementen, die in der EU in Verkehr gebracht werden. Ab diesem Zeitpunkt ist Cybersicherheit eine formale Voraussetzung für den Marktzugang.
Hersteller müssen nachweisen können, dass ihre Produkte grundlegende Sicherheitserwartungen erfüllen, einschließlich sicherer Designprinzipien, Schwachstellenmanagement über den gesamten Produktlebenszyklus sowie der Fähigkeit, Sicherheitsupdates bereitzustellen. Produkte, die diese gesetzlichen Mindestanforderungen nicht erfüllen, dürfen unabhängig von Funktionalität oder kommerzieller Nachfrage nicht in der EU auf den Markt gebracht werden.
Für viele Produktteams ist das der Moment, in dem Cybersicherheit von einem internen Qualitätsziel zu einer externen regulatorischen Anforderung wird, die direkt bestimmt, ob ein Produkt in Europa überhaupt legal verkauft werden kann.
Was sich unter dem CRA für IoT- und Netzwerkprodukte ändert
Der CRA drängt den Markt in Richtung zweier Ergebnisse: weniger vermeidbare Schwachstellen beim Produktstart und bessere Wartbarkeit über die unterstützte Lebensdauer. Praktisch übersetzt heißt das für Hersteller drei operative Verschiebungen.
Sicherheit wird zur Design-Anforderung
Viele IoT- und Networking-Produkte werden primär entlang von Kosten, Leistung und Time-to-Market entwickelt. Unter CRA-Druck muss Sicherheit ähnlich behandelt werden: als etwas, das von Beginn an mitentworfen, geprüft und getestet wird, als Bestandteil normaler Produktentwicklung.
Bei vernetzten Produkten betrifft das häufig Entscheidungen wie:
- wie Geräte authentifizieren und Identitäten verwalten,
- welche Dienste standardmäßig exponiert sind und warum,
- wie Zugangsdaten, Schlüssel und Geheimnisse gespeichert und geschützt werden,
- was passiert, wenn eine Komponente kompromittiert wird, und wie der Schadensradius begrenzt wird.
Transparenz in der Software-Lieferkette wird unvermeidlich
Moderne Geräte werden mit großen Abhängigkeitsbäumen ausgeliefert: Betriebssysteme, Open-Source-Pakete, Drittanbieter-Bibliotheken und gebündelte Dienste. Im CRA-Umfeld steigt die Erwartung, dass Hersteller genau benennen können, was in ihren Produkten steckt, und reagieren, sobald neue Schwachstellen bekannt werden.
Entsprechend beschleunigen viele Teams aktuell Arbeiten an:
- Erstellung und Pflege einer Software-Stückliste (SBOM),
- Identifikation bekannter Schwachstellen (CVEs) und Priorisierung der Behebung,
- Release-Prozessen, die Sicherheitsupdates zuverlässig ausrollen können.
Schwachstellenbehandlung wird zur Routinefähigkeit
Einmaliges Sicherheitstesten vor dem Produktstart reicht nicht aus. Das CRA-Ökosystem bevorzugt Organisationen, die Sicherheitsthemen als wiederkehrende Routine beherrschen: erkennen, triagieren, beheben und kommunizieren, inklusive der Meldepflichten, die bereits vor den Hauptpflichten ab 2027 starten.
Hier sehen viele Unternehmen die Lücke. Es ist nicht nur „noch ein Test“, sondern eine funktionsübergreifende Veränderung, die Engineering, Qualitätssicherung, Produktmanagement, Kundensupport und Rechtsabteilung betrifft.
Wie CRA-Konformität in echter Engineering-Arbeit aussieht
Regulatorische Sprache lässt Sicherheit schnell abstrakt wirken. In der Praxis ähnelt CRA-konforme Arbeit diszipliniertem Produktsicherheits-Engineering: Bedrohungsmodellierung, Audits über Hardware und Firmware hinweg, nachweisorientiertes Testen und dokumentierte Behebung.
Im Folgenden finden Sie einige Fallbeispiele von Promwad, die zeigen, welche Arten von Sicherheitsarbeit Unternehmen bereits durchführen, um sich auf CRA-Anforderungen vorzubereiten, insbesondere für IoT- und Netzwerk-Equipment.
Router-Sicherheitsaudit (OpenWRT/prplOS, Realtek-Plattform)
In einem aktuellen Router-Audit umfasste die Arbeit den gesamten Stack:
- Bedrohungsanalyse, geleitet durch das MITRE ATT&CK-Framework,
- Hardware-Prüfung inklusive Checks auf Leiterplattenebene (PCB) und Plattform-Merkmalen, die die Angriffsfläche vergrößern könnten,
- Firmware-Analyse inklusive SBOM-Erstellung und Identifikation bekannter verwundbarer Komponenten,
- Penetrationstests, um die Widerstandsfähigkeit gegen realistische Angriffswege zu validieren.
Der Wert dieses Vorgehens liegt nicht nur im Finden von Problemen. Es entsteht ein priorisierter Plan: Was muss sich in Design, Konfiguration, Firmware-Zusammensetzung und Aktualisierungsstrategie ändern, um das Risiko messbar zu reduzieren.
Sicherheitsprüfung industrieller Switches (Firmware-Härtung & Protokoll-Exponierung)
Industrielle Netzwerkgeräte laufen in sensiblen Umgebungen, in denen Verfügbarkeit und Segmentierung kritisch sind. In einer projektbezogenen Sicherheitsprüfung für industrielle Switches umfasste der Umfang:
- Bedrohungsanalyse und Abbildung plausibler Angriffswege,
- Prüfung potenzieller Hardware-Schwachstellen,
- Firmware-Härtung im Kontext der Behebung von Schwachstellen und besserer Transparenz von Abhängigkeiten,
- Protokollprüfung und Tests entlang realistischer Missbrauchsszenarien,
- Penetrationstests, um zu bestätigen, dass die Gegenmaßnahmen unter Belastung funktionieren.
Das ist relevant, weil Industriegeräte oft sehr lange im Feld bleiben. Ohne robuste Wartung und einen verlässlichen Patch-Pfad kann selbst eine kleine Schwäche zu einem dauerhaften Eintrittspunkt werden.
Schwachstellenscanning eines Wi-Fi-Access-Points (autorisiertes Testen)
Wireless-Edge-Geräte sind per Design exponiert. In einer autorisierten Bewertung für einen Anbieter von Wireless-Lösungen testeten Promwad-Ingenieure einen Wi-Fi-Access-Point auf Schwachstellen, unter anderem Risiken durch Passwort-Angriffe sowie Konfigurationsprobleme, die eine Kompromittierung ermöglichen könnten. Die Ergebnisse wurden genutzt, um die Gerätesicherheit zu verbessern, was den Kunden dabei unterstützte, einen Liefervertrag im Enterprise-Umfeld weiterzuführen.
Vollständige technische Fallstudie: Sicherheitsüberprüfung für einen WLAN-Zugangspunkt
Die Lehre ist klar: Compliance-Narrative stoppen keine Angreifer. Nur Tests, die Angreiferverhalten realistisch abbilden, zeigen, welche Annahmen im Feld scheitern.
Eine praktische Checkliste für Teams, die in die EU liefern
Wenn Sie vernetzte Produkte entwickeln oder ausliefern, sind die folgenden Schritte ein pragmatischer Einstieg in CRA-typische Erwartungen:
- Geltungsbereich klären: Gerätevarianten, Softwarekomponenten und gebündelte Dienste abbilden.
- Bedrohungsbasierte Analyse durchführen: plausible Angriffswege identifizieren und nach Auswirkung priorisieren.
- SBOM und Schwachstellenmanagement etablieren: wissen, was ausgeliefert wird, bekannte Probleme verfolgen und klare Verantwortlichkeiten für Behebung definieren.
- Standardkonfigurationen härten: unnötige Dienste entfernen, exponierte Schnittstellen reduzieren, Zugangsdaten und Schlüssel absichern.
- Mit Penetrationstests validieren: Schutzmaßnahmen unter realistischen Bedingungen prüfen und Ergebnisse dokumentieren.
- Operativ vorbereiten: Patches planbar ausrollen können und Vorfall-/Schwachstellenbehandlung inklusive Meldepflichten erfüllen.
Fazit
Der Cyber Resilience Act hebt die Mindestanforderungen an Cybersicherheit in der EU deutlich an. Für IoT- und Netzwerkprodukte ist die kommerzielle Konsequenz schwer zu ignorieren: Ab 2027 geht es bei Sicherheit nicht nur um Reputation oder Kundenvertrauen, sondern darum, ob ein Produkt überhaupt verkauft werden darf.
Organisationen, die den CRA-Übergang frühzeitig starten, Architekturen straffen, Abhängigkeiten sauber dokumentieren und das Patchen als Routinefähigkeit etablieren, werden die Regulierung deutlich weniger disruptiv erleben als diejenigen, die Sicherheit erst am Ende nachrüsten.
