"Wir sind kein Technologieunternehmen" ist im Jahr 2026 kein gültiges Argument mehr. Lange Zeit galten Vorschriften zur Cybersicherheit als etwas, das in erster Linie Software-Anbieter, Automobil-OEMs oder stark digitalisierte Branchen betraf. Viele Unternehmen gehen immer noch davon aus, dass diese Vorschriften nicht für sie gelten, wenn sie physische Produkte herstellen, Komponenten von Drittanbietern integrieren oder außerhalb der klassischen technischen Bereiche tätig sind.
Worauf der CRA tatsächlich abzielt
Der Cyber Resilience Act ist eine Regelung der Europäischen Union, die darauf abzielt, die Cybersicherheitsstandards für Produkte mit digitalen Elementen auf dem EU-Markt zu stärken. Der Anwendungsbereich ist absichtlich weit gefasst. Er konzentriert sich nicht auf bestimmte Branchen, sondern auf die Funktionalität. Wenn ein Produkt Software, Konnektivität oder irgendeine Form von digitaler Schnittstelle enthält, fällt es wahrscheinlich in den Geltungsbereich.
Im Kern führt der CRA Grunderwartungen für die Herstellung und Wartung von Produkten ein. Dazu gehören sichere Entwicklungspraktiken, ein strukturiertes Schwachstellenmanagement, Unterstützung im Lebenszyklus und eine Dokumentation, die die Umsetzung von Cybersicherheitsmaßnahmen belegt. Keines dieser Konzepte ist völlig neu. Neu ist, dass sie nun verbindlich und durchsetzbar werden. Um zu verstehen, warum dieser Wandel in der Praxis von Bedeutung ist, ist es hilfreich, sich anzusehen, wie sich die Produkte selbst verändern.
Wer ist tatsächlich betroffen – ein Realitätscheck
Ein nützlicher Weg, um den Umfang des CRA zu verstehen, besteht darin, nicht mehr in Branchen, sondern in Produkten zu denken. Nehmen Sie etwas so Einfaches wie einen Wasserfilter. Traditionell ist dies ein rein physisches Produkt. Niemand würde sie mit Cybersicherheitsanforderungen in Verbindung bringen. Aber sobald derselbe Wasserfilter mit einer Bluetooth-Verbindung und einer dazugehörigen App ausgestattet ist – zur Überwachung der Nutzung, zur Bestellung von Ersatz oder zur Verfolgung der Qualität – wird er Teil des Internets der Dinge (Internet of Things, IoT).
Und das ist der Wendepunkt.
In dem Moment, in dem ein Produkt Teil des IoT wird, wird es auch Teil des Problems der Cybersicherheit. Es handelt sich nicht mehr nur um ein physisches Gerät, sondern um ein vernetztes System. Eines, das Daten verarbeitet, mit anderen Komponenten kommuniziert und potenzielle Angriffsflächen bietet.
Im Rahmen des CRA ist diese Unterscheidung ausschlaggebend. Der Regelung ist es egal, ob etwas wie ein einfaches Haushaltsprodukt aussieht. Es ist nur wichtig, ob es sich wie ein angeschlossenes Gerät verhält. Es handelt sich nicht um ein Nischenszenario. Es spiegelt eine breitere Verlagerung wider: Produkte, die ursprünglich nicht mit Blick auf die Cybersicherheit entwickelt wurden, werden mit Konnektivität ausgestattet.
Zum Beispiel:
- Intelligente Haarbürsten
- Intelligente Glühbirnen
- Vernetzte Kaffeemaschinen
Diese Arten von Verbraucher-IoT-Geräten mögen auf den ersten Blick trivial erscheinen, aber sie zeigen, wie schnell Alltagsprodukte Teil eines vernetzten Ökosystems werden.
Das gleiche Muster geht weit über das Smart Home hinaus. Vernetzte Industriekomponenten, Gateways und digital erweiterte Zusatzgeräte folgen alle der gleichen Logik. Was sie gemeinsam haben, ist nicht ihre Branche, sondern die Tatsache, dass sie Teil eines zunehmend vernetzten IoT-Ökosystems sind.
Wenn ein Produkt kommuniziert, Updates empfängt oder Daten austauscht, ist es nicht mehr "nur Hardware". Im Rahmen des CRA fällt es damit direkt in den Anwendungsbereich. Wenn sich dieser Umfang weit gefasst anfühlt, dann ist das so – und er wirft eine wichtige Folgefrage auf: Welchen Platz nimmt der CRA in der breiteren Regulierungslandschaft ein?
Die Stellung des CRA im Gesamtbild
Der CRA existiert nicht für sich allein. Er ist Teil einer umfassenderen Regulierungslandschaft, die branchenspezifische und sektorübergreifende Anforderungen kombiniert:
Vertikale Regelungen, wie die UNECE R155 für die Automobilindustrie oder die Medical Device Regulation (MDR), legen die Anforderungen an die Cybersicherheit für bestimmte Bereiche fest und haben in der Regel Vorrang innerhalb der jeweiligen Branche.
Der CRA hingegen dient als horizontale Grundlinie. Er gilt überall dort, wo es keine spezifischere Regelung gibt, und deckt eine breite Palette von Produkten in allen Sektoren ab. In der Praxis führt dies zu einem mehrschichtigen System: Einige Produkte unterliegen bereichsspezifischen Regelungen, andere fallen direkt unter den CRA, und viele Organisationen sind in beiden Bereichen gleichzeitig tätig.
Für die Unternehmen besteht die Herausforderung nicht nur darin, eine einzelne Regelung zu verstehen, sondern herauszufinden, wo ihre Produkte in dieser Struktur stehen.
Das Missverständnis der Zulieferer
Bei den Zulieferern ist die Situation weniger eindeutig. Eine häufige Annahme ist: "Wir sind nur ein Zulieferer, also betrifft uns das nicht direkt". Der CRA folgt jedoch nicht den organisatorischen Grenzen, sondern dem Produkt und seiner Platzierung auf dem Markt.
Je nachdem, wie eine Komponente geliefert und integriert wird, kann ein Zulieferer im Rahmen der Regelung tatsächlich die Rolle eines Herstellers übernehmen oder zumindest Teil einer Compliance-Kette werden, in der Nachweise und Transparenz erforderlich sind. Selbst wenn es keine direkte rechtliche Verpflichtung gibt, verbreiten sich die Erwartungen über die gesamte Wertschöpfungskette. OEMs und Systemintegratoren werden von ihren Zulieferern zunehmend den Nachweis von Cybersicherheitsmaßnahmen verlangen. In der Praxis ist daher eine indirekte Einhaltung der Vorschriften unvermeidlich.
Was das in der Praxis bedeutet
Auf den ersten Blick scheint der CRA eine dokumentationslastige Regelung zu sein: Anforderungen definieren, Prozesse dokumentieren, Berichte erstellen und die Einhaltung der Regelungen erreichen.
Doch genau hier machen viele Unternehmen einen Fehler. Die eigentliche Herausforderung besteht nicht darin, zu verstehen, was vorhanden sein sollte, sondern darin, zu verstehen, ob es in der Praxis tatsächlich Bestand hat.
Dokumentation allein macht ein System noch nicht sicher. Sie beschreibt Ziel, Struktur und Prozess. Sie beweist jedoch nicht, dass ein Produkt realen Bedingungen, unerwarteten Interaktionen oder gezielten Angriffen standhalten kann. Angreifer gehen anders vor. Sie halten sich nicht an die Dokumentation – sie suchen nach Schwachstellen und nutzen sie aus, unabhängig davon, wie gut ein System auf dem Papier beschrieben ist.
Erforderlich ist stattdessen eine Validierung – nicht als einmalige Aktivität, sondern als fortlaufende Fähigkeit. Die Systeme entwickeln sich weiter, die Software ändert sich, und die Konnektivität führt ständig neue Variablen ein. Ohne Verifizierung können selbst gut dokumentierte Systeme von ihren ursprünglichen Sicherheitsannahmen abdriften.
Dadurch entsteht eine kritische Lücke zwischen der Einhaltung der Regelungen und der tatsächlichen Sicherheit.
Warum das jetzt wichtig ist
Für viele Unternehmen stellt sich nicht mehr die Frage, ob sie betroffen sind, sondern in welchem Ausmaß und wie gut sie darauf vorbereitet sind.
Denn die Reichweite ist nur der erste Schritt. Die Sicherstellung, dass ein System nicht nur den Regelungen entspricht, sondern unter realen Bedingungen auch tatsächlich belastbar ist, ist eine grundlegend andere Herausforderung – und eine, die nicht allein durch Dokumentation gelöst werden kann. Und hier beginnt ein häufiges Missverständnis: Viele Systeme sind zwar konform, aber immer noch anfällig.
Und da die vollständige Einhaltung des CRA bis Ende 2027 vorgeschrieben ist, ist das Zeitfenster für den Übergang von der Dokumentation zur tatsächlichen, überprüfbaren Sicherheit kleiner als es scheint.
Dieser Artikel ist Teil unserer Blogserie "Realitätscheck Cybersicherheit", in der wir untersuchen, wie sich Cybersicherheitsvorschriften auf die reale Produktsicherheit auswirken – und warum Tests eine entscheidende Rolle spielen. Im nächsten Artikel werden wir einen genaueren Blick darauf werfen, warum Konformität nicht gleich Sicherheit ist – und warum Checklisten allein Ihr Produkt nicht schützen können.
