Wo der Cyber Resilience Act wirklich relevant wird
Viele Maschinenbauer und Industrieunternehmen ordnen den Cyber Resilience Act (CRA) zunächst als Thema für Software-Hersteller, Consumer-IoT oder klassische IT-Produkte ein. Genau das ist riskant. Der CRA ist ein horizontaler EU-Rechtsrahmen für Hardware- und Softwareprodukte mit digitalen Elementen, die auf dem Unionsmarkt bereitgestellt werden. Er gilt also nicht nur für „offensichtlich digitale“ Endgeräte, sondern grundsätzlich auch für Produkte und Komponenten, deren bestimmungsgemäße oder vernünftigerweise vorhersehbare Nutzung eine direkte oder indirekte Datenverbindung zu einem Gerät oder Netzwerk umfasst.
Für Maschinenbauer und Industrieunternehmen ist das deshalb so relevant, weil viele Produkte heute genau in diese Richtung gehen: vernetzte Maschinen, Steuerungen, HMIs, Sensorik, Gateways, Remote-Maintenance-Funktionen, Edge-Komponenten oder Embedded Software. Das ist eine naheliegende Folge aus dem weiten CRA-Begriff der „Produkte mit digitalen Elementen“. Ob ein konkretes Produkt tatsächlich in den Geltungsbereich fällt, muss zwar im Einzelfall geprüft werden – aber für viele Industrieprodukte ist ein CRA-Check heute keine Kür mehr, sondern Pflicht.
Der Kernpunkt: Der CRA ist kein reines IT-Thema
Der CRA zielt auf Produkte, nicht nur auf interne Unternehmens-IT. Genau deshalb betrifft er Hersteller viel direkter, als viele erwarten. Die EU-Kommission beschreibt den CRA als Regelwerk für sichere Hardware und Software entlang des gesamten Produktlebenszyklus. Hersteller müssen Sicherheitsanforderungen nicht erst kurz vor dem Inverkehrbringen berücksichtigen, sondern bereits in Planung, Design, Entwicklung, Produktion, Bereitstellung und Wartung. Zusätzlich verlangt der CRA einen geregelten Umgang mit Schwachstellen während des Support-Zeitraums.
Für Industrieunternehmen bedeutet das: Wer eigene digitale Produkte, Komponenten oder softwaregestützte Maschinen auf dem EU-Markt bereitstellt, sollte den CRA als Produkt-, Entwicklungs- und Organisationsfrage verstehen – nicht nur als Thema für die IT-Abteilung.
Wann Maschinenbauer typischerweise CRA-relevant werden
Die erste Leitfrage lautet: Stellen wir ein Produkt mit digitalen Elementen auf dem EU-Markt bereit? Der CRA erfasst sowohl Endprodukte als auch Komponenten, die separat auf dem Markt bereitgestellt werden. Wenn ein Produkt digitale Funktionen hat und mit Geräten oder Netzwerken verbunden ist oder verbunden werden kann, ist CRA-Relevanz grundsätzlich möglich.
Für den Maschinenbau und industrielle Hersteller sind damit vor allem vier Konstellationen relevant:
1. Die Maschine selbst enthält digitale Funktionen
Sobald eine Maschine oder Anlage softwaregesteuert, vernetzt oder fernwartbar ist, liegt ein CRA-Check nahe. Das betrifft in der Praxis häufig Steuerungslogik, Bedienpanels, Kommunikationsmodule, Diagnoseschnittstellen oder Sicherheitsfunktionen mit digitalem Bezug. Diese Einordnung ist eine sachlogische Ableitung aus dem CRA-Anwendungsbereich für Hardware- und Softwareprodukte mit digitalen Elementen.
2. Sie liefern Komponenten separat aus
Der CRA erfasst nicht nur komplette Produkte, sondern auch separat in Verkehr gebrachte Komponenten. Für Zulieferer ist das besonders wichtig. Wer also digitale Module, Steuerungseinheiten, Embedded Software oder vernetzte Baugruppen eigenständig vermarktet, sollte nicht nur auf das Endprodukt seines Kunden schauen, sondern auf die eigene Marktbereitstellung.
3. Wesentliche Funktionen laufen über Remote- oder Cloud-Komponenten
Der CRA bezieht ausdrücklich auch Remote Data Processing Solutions ein, wenn deren Fehlen dazu führen würde, dass ein Produkt mit digitalen Elementen eine seiner Funktionen nicht mehr ausführen kann. Für Industrieunternehmen ist das hochrelevant, wenn Maschinen auf Hersteller-Clouds, Remote-Diagnose, zentrale Update-Dienste oder externe Steuerungs-/Analysefunktionen angewiesen sind.
4. Sie vermarkten industrielle Software als Produkt
Auch reine Softwareprodukte können unter den CRA fallen. Für Maschinenbauer betrifft das zum Beispiel separat vermarktete Konfigurationssoftware, Visualisierung, HMI-nahe Anwendungen, Diagnosetools oder andere Softwarekomponenten mit Produktcharakter. Denn der CRA gilt ausdrücklich für Hardware und Softwareprodukte.
Was oft falsch eingeschätzt wird
Ein häufiger Irrtum lautet: „Wir bauen Maschinen, keine IT-Produkte.“ Genau diese Trennung wird regulatorisch immer weniger tragfähig. Sobald digitale Funktionen, Netzwerkfähigkeit oder softwarebasierte Kernfunktionen Teil des Produkts sind, reicht die klassische Sicht auf Mechanik oder Elektrotechnik nicht mehr aus. Der CRA ist gerade dafür geschaffen worden, Cybersecurity-Anforderungen auf solche Produkte anzuwenden.
Ein zweiter Irrtum: „Das betrifft nur den OEM, nicht uns als Zulieferer.“ Auch das kann zu kurz greifen. Der CRA erfasst separat vermarktete Komponenten und verteilt Pflichten nicht nur entlang des Endprodukts, sondern entlang der Marktrollen. Wer als Hersteller, Importeur oder Distributor agiert, muss jeweils bestimmte CRA-Anforderungen beachten.
Warum der CRA für die Industrie organisatorisch so relevant ist
Sobald ein Produkt in den CRA fällt, geht es nicht nur um technische Härtung. Hersteller müssen eine Cybersecurity-Risikobewertung durchführen, die Sicherheitsanforderungen aus Annex I umsetzen, technische Dokumentation erstellen, die passende Konformitätsbewertung durchführen, eine EU-Konformitätserklärung ausstellen und die CE-Kennzeichnung anbringen, bevor das Produkt auf den Markt kommt. Außerdem müssen Schwachstellen während des Support-Zeitraums wirksam behandelt werden.
Für Maschinenbauer ist das besonders wichtig, weil hier mehrere Bereiche zusammenkommen: Entwicklung, Produktmanagement, Qualität, Service, Informationssicherheit, Dokumentation und Geschäftsführung. Der CRA wird in vielen Industrieunternehmen nicht an der einzelnen technischen Maßnahme scheitern, sondern an unklaren Zuständigkeiten, fehlenden Prozessen und lückenhafter Produktdokumentation. Diese Schlussfolgerung ergibt sich aus dem Zusammenspiel der CRA-Herstellerpflichten.
Welche Fristen Industrieunternehmen kennen müssen
Der CRA ist seit 10. Dezember 2024 in Kraft. Die Hauptpflichten gelten ab 11. Dezember 2027. Bereits ab 11. September 2026 greifen die Reporting-Pflichten für aktiv ausgenutzte Schwachstellen und schwere Sicherheitsvorfälle. Produkte, die schon vor dem 11. Dezember 2027 auf dem Markt waren, werden grundsätzlich erst dann CRA-relevant, wenn sie ab diesem Datum eine wesentliche Änderung erfahren; die Reporting-Pflichten gelten jedoch auch für bereits auf dem EU-Markt verfügbare Produkte mit digitalen Elementen.
Gerade im Maschinenbau ist das wichtig, weil Produkte oft lange Lebenszyklen haben. Wer heute nur auf das Enddatum 2027 schaut, unterschätzt die Vorlaufzeit für Produktprüfung, Dokumentation, Architekturentscheidungen, Supportmodelle und Meldeprozesse. Dass industrielle Systeme häufig lange in Betrieb sind, wird auch im CRA selbst aufgegriffen.
Was Maschinenbauer jetzt konkret tun sollten
Der sinnvollste Start ist kein allgemeines „CRA-Projekt“, sondern ein strukturierter Portfolio- und Architekturcheck:
- Welche Produkte, Module und Softwarekomponenten bringen wir in der EU in Verkehr?
- Welche davon sind vernetzt oder enthalten digitale Kernfunktionen?
- Welche Remote- oder Cloud-Dienste sind für die Produktfunktion wesentlich?
- Welche Komponenten kommen von Dritten und wie läuft heute deren Schwachstellenmanagement?
- Wer verantwortet intern Security-by-Design, Support-Zeiträume, Dokumentation und Incident-/Vulnerability-Handling?
Genau an dieser Stelle entsteht meist der größte Mehrwert: Nicht erst mit abstrakter Regulierung starten, sondern mit den eigenen Produkten, den eigenen Rollen und den eigenen Nachweisen.
Fazit
Für Maschinenbauer und Industrieunternehmen ist der CRA kein Randthema. Wer Produkte mit digitalen Elementen auf dem EU-Markt bereitstellt, sollte den CRA frühzeitig prüfen – besonders dann, wenn Maschinen, Steuerungen, Embedded Software, Remote-Funktionen oder separat vermarktete Komponenten Teil des Portfolios sind. Der eigentliche Hebel liegt nicht darin, den CRA möglichst spät zu „erfüllen“, sondern früh genug zu erkennen, welche Produkte betroffen sind und welche organisatorischen Folgen das für Entwicklung, Dokumentation und Support hat.
Sie möchten schnell und belastbar einschätzen, ob Ihre Produkte unter den CRA fallen?Wir unterstützen Sie mit einem pragmatischen CRA-Betroffenheitscheck: Portfolio-Sichtung, regulatorische Einordnung, erste Risikoeinschätzung und klare Prioritäten für die nächsten Schritte.
