Der Cyber Resilience Act (CRA) macht Cyber Security erstmals zu einer verbindlichen Voraussetzung für viele Produkte mit digitalen Elementen. Künftig müssen Hersteller nachweisen können, dass Sicherheitsanforderungen bereits bei Entwicklung, Betrieb und Schwachstellenmanagement berücksichtigt wurden. Somit wird Cyber Security nicht länger nur zur technischen Qualitätsfrage, sondern zu einem zentralen Bestandteil der Produktkonformität und des Marktzugangs in der EU.
Davon sind besonders Hersteller von IoT-Lösungen, Embedded Devices, industriellen Steuerungssystemen und OT-Komponenten betroffen. Ihre Produkte bestehen häufig aus komplexen Hard- und Softwarelandschaften, langen Lieferketten und mehrjährigen Betriebszyklen. Genau diese Faktoren stellen Unternehmen vor die Herausforderung, Sicherheitsmaßnahmen und Nachweise über den gesamten Produktlebenszyklus hinweg sicherzustellen.
In diesem Beitrag beleuchten wir, welche Anforderungen der CRA an IoT- und OT-Produkte stellt, welche typischen Schwachstellen und Prozesslücken Unternehmen heute identifizieren sollten und wie ein CRA-orientiertes Assessment Ihnen dabei helfen kann, den Handlungsbedarf frühzeitig sichtbar zu machen.
Was regelt der Cyber Resilience Act?
Der CRA ist eine EU-Verordnung für „Produkte mit digitalen Elementen“. Darunter fallen Hardware- und Softwareprodukte, die direkt oder indirekt mit anderen Geräten oder Netzwerken verbunden werden können. Der Anwendungsbereich ist bewusst breit gefasst: Er reicht von Consumer-IoT und Smart-Home-Geräten über Apps und Softwarekomponenten bis hin zu industriellen Steuerungen, Gateways und eingebetteter Firmware.
Allerdings richtet sich der CRA nicht nur an die Hersteller dieser Produkte. Auch Importeure und Händler werden in die Pflicht genommen, wenn sie Produkte auf dem europäischen Markt bereitstellen. Für Hersteller liegt der Schwerpunkt jedoch besonders klar auf der Frage, ob ein Produkt sicher entwickelt, ausgeliefert und über die erwartete Nutzungsdauer hinweg betrieben werden kann.
Warum sind IoT- und OT-Produkte besonders vom CRA betroffen?
IoT- und OT-Produkte sind selten einfache Einzelprodukte. Sie bestehen oft aus Hardware, Firmware, Backend-Systemen, mobilen Anwendungen und Cloud-Diensten. Hinzu kommen lange Lebenszyklen und komplexe Lieferketten. Genau diese Kombination macht sie aus CRA-Sicht anspruchsvoll. Eine Schwachstelle steckt nicht immer nur im Gerät selbst. Sie kann ebenso in einer verwendeten Bibliothek, einer unsicheren Update-Funktion, einer schlecht abgesicherten Schnittstelle oder in fehlenden Prozessen für den Umgang mit gemeldeten Schwachstellen liegen.
Für Unternehmen bedeutet das: Es reicht nicht, ein Produkt kurz vor dem Release technisch testen zu lassen. Der CRA verlangt eine belastbare Sicherheitsbetrachtung über Architektur, Entwicklung, Betrieb, Updates und Vulnerability Management hinweg. Cyber Security muss damit von Anfang an mitgedacht werden, und zwar so, dass Hersteller später auch belegen können, was sie getan haben.
Was müssen Hersteller künftig nachweisen können?
Statt eine einfache Checkliste für Kontrollmaßnahmen zu liefern, beschreibt der CRA vielmehr, welches Sicherheitsniveau Produkte erreichen müssen. Dazu gehört, dass Sicherheitsrisiken bereits in der Design- und Entwicklungsphase berücksichtigt werden. Praktisch kann dies beispielsweise eine Bedrohungsmodellierung in der Architekturphase bedeuten, um Angriffsflächen systematisch zu analysieren und Schwachstellen frühzeitig zu erkennen.
Ein weiterer zentraler Punkt ist die Updatefähigkeit. Hersteller müssen in der Lage sein, Sicherheitsupdates zuverlässig bereitzustellen und nachvollziehbar auszurollen. Gerade bei Geräten, die sich bereits im Betrieb befinden, ist dies entscheidend: Wenn Updates nicht verifiziert werden oder Geräte keine praktikable Patch-Strategie haben, wird aus der Update-Infrastruktur selbst ein Risiko.
Auch organisatorische Prozesse werden wichtiger. Hersteller benötigen klare Zuständigkeiten für den Umgang mit Schwachstellen, etwa über ein Product Security Incident Response Team (PSIRT), definierte Eskalationswege und eine öffentliche Kontaktmöglichkeit für Sicherheitsmeldungen. Zusätzlich müssen Softwarebestandteile nachvollziehbar dokumentiert werden, etwa über eine Software Bill of Materials (SBOM).
Die Notwendigkeit eines PSIRT wird vor allem in Hinsicht auf die Meldepflichten des CRA deutlich. Die Verordnung verpflichtet dazu, aktiv ausgenutzte Sicherheitslücken innerhalb von 24 Stunden nach Bekanntwerden über die Single Reporting Platform der European Union Agency for Cybersecurity (ENISA) zu melden. Weitere Informationen zu den Meldepflichten des CRA finden Sie in unserem Blogpost „CRA-Meldepflichten ab September 2026: Haben Sie es im Blick?“
Was sind die typische Lücken in der Praxis?
In unseren Sicherheitsanalysen zeigt sich häufig sehr schnell, wo der Abstand zwischen regulatorischem Anspruch und aktuellem Produktzustand besonders groß ist. Viele Schwachstellen entstehen nicht durch einen einzelnen Fehler, sondern durch das Zusammenspiel technischer Altlasten und fehlender Prozesse:
- Firmware und Komponenten: Veraltete Bibliotheken, hartcodierte Zugangsdaten, unsichere kryptografische Verfahren oder nicht signierte Firmware können dazu führen, dass bekannte Schwachstellen über lange Zeit im Produkt verbleiben oder manipulierte Updates akzeptiert werden.
- Gerätehärtung: Offene Debug-Schnittstellen, ungeschützte Management-Zugänge oder unsichere Standardkonfigurationen können Angreifenden Einstiegspunkte bieten. Das geschieht insbesondere dann, wenn Geräte physisch erreichbar sind oder in produktionsnahen Netzwerken betrieben werden.
- Backend und Cloud: Unsichere Schnittstellen, fehlende Zugriffskontrollen oder nicht ausreichend getrennte Mandanten- und Gerätedaten können dazu führen, dass Nutzerinnen und Nutzer auf fremde Geräteinformationen zugreifen oder unberechtigte Befehle auslösen können.
- Prozesse und Verantwortlichkeiten: Ohne SBOM, geregelte Patch-Prozesse und definierte Ansprechpartner für Sicherheitsmeldungen bleibt oft unklar, welche Produkte betroffen sind, wer Entscheidungen trifft und wie schnell eine Schwachstelle behoben werden kann.
Wie kann ein CRA-orientiertes Assessment Sie unterstützen?
Ein CRA-orientiertes Assessment sollte dort ansetzen, wo viele spätere Sicherheitsprobleme entstehen: in der Architektur. Deshalb betrachten wir zunächst Vertrauensgrenzen, Datenflüsse und Angriffsflächen. So lassen sich Designrisiken erkennen, die durch dynamische Tests allein nicht aufgedeckt werden können.
Anschließend analysieren wir die Firmware auf fest codierte Geheimnisse, Bibliotheken mit öffentlich bekannten Schwachstellen und unsichere Build-Konfigurationen. Proprietäre Binärdateien können zudem rückentwickelt werden, um Schwachstellen in internen Firmware-Diensten zu identifizieren.
Die Hardware-Prüfung umfasst die Freilegung der physikalischen Debug-Schnittstelle, gegebenenfalls Methoden zur Chip-Entnahme sowie die Bewertung der physikalischen Manipulationssicherheit. Bei den Netzwerk- und Protokolltests werden alle vom Gerät genutzten Kommunikationswege untersucht; dazu gehören unter anderem MQTT, industrielle Protokolle wie S7Comm (Plus), CAN und Modbus sowie die Qualität der TLS-Konfiguration.
Neben den technischen Tests überprüfen wir den Entwicklungsprozess: Wie werden Patches verwaltet und wie werden Abhängigkeiten gehandhabt? Wir analysieren außerdem die SBOM, sofern vorhanden, prüfen, ob sie das ausgelieferte Produkt korrekt widerspiegelt, und untersuchen, inwiefern die offengelegten Komponenten mit bekannten CVEs korrelieren, unter Berücksichtigung der jeweiligen Verwendung dieser Komponenten.
Warum sollten Sie jetzt starten?
Die CRA-Fristen kommen immer näher und Konformitätsbewertungen lassen sich nicht kurzfristig vorbereiten. Viele der notwendigen Maßnahmen betreffen Architekturentscheidungen, Hardwaredesign, Updatekonzepte, Lieferantenmanagement und interne Prozesse. Diese Themen lassen sich nicht kurz vor der Markteinführung vollständig nachholen.
Je früher Sie prüfen, wo Ihr Produkt heute steht, desto besser lassen sich technische Anpassungen, Prozessänderungen und Nachweise in die Roadmap einplanen. Sicherheitslücken können noch vor dem Release behoben, Prozesse rechtzeitig etabliert und Nachweise strukturiert aufgebaut werden. Das reduziert nicht nur Compliance-Risiken, sondern verbessert auch die tatsächliche Resilienz Ihres Produkts.
Der CRA setzt einen verbindlichen Rahmen. Für Hersteller von IoT- und OT-Produkten ist er zugleich eine Chance, Produktsicherheit systematisch zu verankern und Vertrauen bei Kunden, Partnern und Marktaufsicht aufzubauen.
„Für unsere Kunden bedeutet CRA-Konformität vor allem eines: Planungssicherheit. Produkte bleiben marktfähig, Sicherheitsvorfälle werden früher erkannt und Nachweise liegen vor, wenn Auditoren oder Kunden danach fragen. Die Anforderungen der Verordnung sind am Ende genau die Prozesse, die ein Produkt auch im Alltag robuster machen.“
Samir Benzammour, Security Analyst und Experte für OT- und IoT-System Pentests, usd AG
Weitere Einblicke in die praktische Umsetzung gibt das Webinar von unserem Kollegen Phillip Ansorge „Cyber Resilience Act: Warum Risk Assessment jetzt den Takt vorgibt“ am 01.10.2026. Jetzt anmelden!
Sie bereiten Ihr Produkt auf die CRA-Konformität vor? Kontaktieren Sie uns, um den geeigneten Prüfumfang sowie den Zeitplan für Ihr Produkt zu besprechen.
