Dieser Artikel bietet eine schnelle Orientierung für Hersteller, OEMs und Zulieferer mit Entscheidungstabelle, ob sie vom CRA betroffen sind sowie praxisnahen Fallbeispielen.
Der Cyber Resilience Act (CRA) betrifft nicht nur klassische IT-Hersteller. Auch Maschinenbauer, Geräteproduzenten und deren Zulieferer müssen sich fragen: Sind wir betroffen – und wenn ja, in welchem Umfang?
Diese Entscheidungshilfe liefert eine schnelle Orientierung für Produktverantwortliche. Wir zeigen typische Fallbeispiele, erläutern zentrale Begriffe und bieten eine kompakte Entscheidungsmatrix.
Wen meint der CRA eigentlich?
Hersteller: Entwickeln und bringen Produkte mit digitalen Elementen auf den Markt.
OEMs: Kombinieren bestehende Hardware oder Software zu neuen Produkten.
Zulieferer: Liefern Komponenten oder Software, die in andere Produkte integriert werden.
Entscheidend ist: Wer steht am Ende auf dem Typenschild und trägt die Verantwortung für das fertige Produkt?
Was ist ein Produkt mit digitalen Elementen?
Laut CRA ist das jedes Produkt, das Software enthält oder mit digitaler Kommunikation verbunden ist – also z. B.:
Industriegeräte mit Embedded Software
Maschinen mit Remote-Zugriff oder Cloud-Anbindung
Mobile Apps zur Steuerung oder Konfiguration
Gateways, Steuerungen, HMI-Systeme
Keine Rolle spielt, ob die Software selbst entwickelt oder zugekauft wurde – die Verantwortung bleibt beim Hersteller des Gesamtprodukts.
Entscheidungsmatrix: Bin ich betroffen?
Nutzen Sie diese einfache Entscheidungstabelle, um eine erste Einordnung vorzunehmen:
Frage
Ja
Nein
Wird Software mit dem Produkt ausgeliefert oder ist darin integriert?
Ist das Produkt netzwerkfähig oder mit anderen Systemen verbunden?
Tragen Sie als Hersteller das Typenschild?
Treffen zwei oder mehr Punkte zu, sollten Sie sich dringend mit den Pflichten aus dem CRA befassen.
Typische Fallbeispiele
Fall 1: Maschinenhersteller mit HMI und Remote-Wartung
Ein Sondermaschinenbauer vertreibt weltweit Anlagen mit integrierter Steuerung, Visualisierung und Fernzugriff. Die Software stammt zum Teil von Drittanbietern.
✅ Vom CRA betroffen.
Fall 2: OEM nutzt Fremdkomponenten zur Komplettlösung
Ein Anbieter kombiniert IoT-Gateways und Visualisierungssysteme zu einem
Komplettpaket für seine Kunden. Er ist als Hersteller gelistet.
✅ Vom CRA betroffen.
Fall 3: Zulieferer liefert nur Embedded Library
Ein Softwarezulieferer stellt eine mathematische Bibliothek für Steuergeräte
zur Verfügung, die vom OEM eingebunden wird.
❌ Nicht direkt betroffen, aber ggf. indirekt über
Vertragsverpflichtungen.
Fazit
Der CRA betrifft viele Unternehmen, die sich bislang nicht als IT-Hersteller verstanden haben. Wer Software integriert, netzwerkfähige Produkte vertreibt oder in der Verantwortung für die Gesamtlösung steht, sollte sich aktiv vorbereiten.
Unser CRA-Workshop bietet Ihnen einen kompakten Einstieg und hilft, betroffene Produkte und Pflichten zu identifizieren.
Lars ist Solution Consultant und berät Unternehmen und Entwicklungsteams ganzheitlich bei der Umsetzung ihrer Softwareentwicklungsprojekte, von den Prozessen über die Anforderungen und Architekturen bis hin zu Umsetzung und Betrieb.
Ein Advisory am Freitagnachmittag, ein Schaltschrank voller Komponenten und eine einfache Frage: Welche Maschinen müssen wir prüfen? Wie Produktidentität die Antwort möglich macht.
BSI TR-03183-1 in Version 1.0.0, prEN 40000-1-3, prEN 50742 und die ENISA Single Reporting Platform machen die CRA-Vorbereitung prüfbarer. Der Beitrag zeigt, welche neuen Nachweise Hersteller daraus ableiten können.
Der Cyber Resilience Act schafft erstmals eine eigene Rolle für Open-Source-Verantwortliche. Dieser Artikel erklärt, wer als Open Source Steward gilt, welche Pflichten Art. 24 CRA tatsächlich fordert und was Hersteller beim Einsatz von Open Source beachten müssen.
Der Cyber Resilience Act schreibt je nach Produktkategorie unterschiedliche Konformitätsbewertungsverfahren vor. Dieser Artikel zeigt, welches Verfahren für welches Produkt gilt und wie Hersteller Schritt für Schritt zur CE-Kennzeichnung gelangen.
Unser Artikel in der dotnetpro 3/26 zeigt, warum der Cyber Resilience Act kein reines Compliance-Thema ist, sondern ein ehrlicher Reifegradtest für Softwareentwicklung und Produktverantwortung.
Der Cyber Resilience Act endet nicht an der eigenen Fabrikhalle: Dieser Artikel zeigt, was Hersteller aus Maschinenbau und Industrie von ihren Lieferanten fordern müssen und wie SBOM, Assessments und Vertragsklauseln die Lieferkette absichern.
Der CRA verlangt grundsätzlich ab dem 11. Dezember 2027 eine CVD-Policy und eine Kontaktstelle. Warum Hersteller beides bereits für die Meldepflichten ab September 2026 vorbereiten sollten.
Seit dem 11. September 2026 müssen Hersteller aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle über ENISAs Single Reporting Platform melden. Dieser Beitrag erklärt Meldeweg, Fristen und Umsetzung.