Der Cyber Resilience Act (CRA) ist die erste EU-weite Verordnung, die verbindliche Cybersicherheitsanforderungen für nahezu alle „Produkte mit digitalen Elementen“ festlegt – also für jede Hard- und Software, die direkt oder indirekt mit einem Netzwerk oder Gerät verbunden werden kann. Für den Maschinenbau bedeutet das: Sobald in einer Anlage, Steuerung oder einem vernetzten Bauteil Software steckt, fällt sie in aller Regel unter den CRA.
Die wichtigsten Eckdaten:
–In Kraft seit: 10. Dezember 2024 (Verordnung (EU) 2024/2847)
–Erste Pflicht seit 11. September 2026: Meldepflicht für aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle (Erstmeldung binnen 24 Stunden)
–Vollständige Pflicht ab 11. Dezember 2027: Nur noch CRA-konforme, CE-gekennzeichnete Produkte dürfen in der EU in Verkehr gebracht werden
–Keine Ausnahme für KMU – die Pflichten gelten unabhängig von Unternehmensgröße
–Kernprinzip: „Security by Design“ – Cybersicherheit muss von der Produktkonzeption an mitgedacht werden, nicht nachträglich draufgesetzt
Wer jetzt, Mitte 2026, noch nicht mit der Bestandsaufnahme begonnen hat, gerät angesichts realistischer Umsetzungszeiten von 14 bis 20 Monaten zunehmend unter Zeitdruck.
Die 4 wichtigsten Fragen kurz beantwortet
?
Ist mein Maschinenbau-Unternehmen überhaupt betroffen?
In den allermeisten Fällen ja. Sobald eine Maschine, Steuerung, Sensorik oder ein Softwaremodul über eine Netzwerk-, Bluetooth-, WLAN- oder sonstige Datenverbindung verfügt, gilt es als „Produkt mit digitalen Elementen“ im Sinne des CRA. Ausgenommen sind nur bestimmte Sektoren wie Medizinprodukte, Fahrzeuge, In-vitro-Diagnostika oder zivile Luftfahrt, die bereits eigene Cybersicherheitsregeln haben.
?
Gilt der CRA auch für kleine und mittlere Unternehmen?
Ja, es gibt keine generelle Ausnahme für KMU. Es existieren lediglich abgestufte Anforderungen je nach Risikoklasse des Produkts (Standard, Wichtig Klasse I/II, Kritisch) – aber keine Befreiung nach Unternehmensgröße.
?
Was passiert, wenn wir die Frist Dezember 2027 verpassen?
Ab diesem Datum dürfen nicht-konforme Produkte mit digitalen Elementen nicht mehr neu in der EU in Verkehr gebracht werden. Das betrifft nicht nur Bußgelder, sondern schlicht die Marktzugangsfähigkeit des Produkts – ein CE-Kennzeichen ohne CRA-Konformität wird schlicht nicht mehr ausgestellt werden können.
?
Wo fängt man am besten an?
Mit einer vollständigen Bestandsaufnahme: Welche Produkte im Portfolio haben überhaupt digitale Elemente? Welche Risikoklasse liegt jeweils vor? Darauf aufbauend lassen sich Schwachstellenmanagement, Dokumentation (SBOM) und Security-by-Design-Maßnahmen priorisieren, statt panisch an vielen Stellen gleichzeitig zu beginnen.
Was der CRA für den Maschinenbau konkret bedeutet
Für viele Maschinenbauer ist der Cyber Resilience Act aktuell noch ein abstraktes Compliance-Thema – ähnlich wie es die Maschinenrichtlinie oder funktionale Sicherheit vor Jahren einmal waren. Das ist ein Trugschluss, den sich kaum ein Unternehmen leisten kann: Anders als bei vielen bisherigen IT-Sicherheitsvorgaben ist der CRA keine Empfehlung oder ein freiwilliges Zertifikat, sondern eine unmittelbar geltende EU-Verordnung mit CE-Kennzeichnungspflicht. Ohne CRA-Konformität kein CE-Zeichen, ohne CE-Zeichen kein Marktzugang in der EU.
Besonders für den Maschinen- und Anlagenbau ist die Tragweite größer, als es auf den ersten Blick scheint. Wo früher eine SPS-Steuerung als reines Automatisierungsbauteil galt, ist sie heute – sobald sie per Ethernet, WLAN, Mobilfunk oder OPC-UA angebunden ist – ein „Produkt mit digitalen Elementen“ im Sinne des CRA. Das gilt auch für eingebettete Softwaremodule, HMI-Bedienpanels, Retrofit-Lösungen mit IoT-Anbindung oder digitale Zwillinge, die auf Maschinendaten zugreifen. Gerade in gewachsenen Produktportfolios mit Legacy-Steuerungen ist vielen Unternehmen aktuell nicht einmal klar, wie viele ihrer Produkte überhaupt betroffen sind.
Der Zeitplan im Detail
Der CRA ist zwar bereits seit Dezember 2024 in Kraft, entfaltet seine Wirkung aber gestaffelt:
- 11. September 2026: Seitdem gelten die Meldepflichten. Wird eine Schwachstelle aktiv ausgenutzt oder kommt es zu einem schwerwiegenden Sicherheitsvorfall, muss dies binnen 24 Stunden an die zuständige nationale Behörde (in Deutschland das BSI) gemeldet werden – mit Folgemeldungen innerhalb weiterer Fristen. Das setzt voraus, dass ein funktionierendes Schwachstellenmanagement bereits existiert, nicht erst aufgebaut wird.
- 11. Dezember 2027: Alle materiellen Anforderungen gelten vollständig. Neue Produkte müssen dann über eine CRA-konforme technische Dokumentation, ein Software Bill of Materials (SBOM), nachweisbares Security-by-Design und ein etabliertes Update- und Schwachstellenmanagement verfügen – erst dann darf das CE-Kennzeichen mit CRA-Bezug vergeben werden.
Erschwerend kommt hinzu, dass die harmonisierten technischen Normen, an denen sich Hersteller eigentlich orientieren sollen, teils selbst noch in Arbeit sind. CEN, CENELEC und ETSI entwickeln aktuell rund 40 Normen in mehreren Typ-Kategorien; einige zentrale technische Normen werden voraussichtlich erst kurz vor der verbindlichen Frist im Oktober 2027 final vorliegen. Bis dahin können Hersteller sich an bestehenden, verwandten Standards orientieren – etwa ETSI EN 303 645 für vernetzte Consumer-Produkte oder IEC 62443 für industrielle Automatisierung, das im Maschinenbau ohnehin vielen Sicherheitsverantwortlichen bereits bekannt ist.
Warum „Security by Design“ der eigentliche Kern ist
Der CRA verlangt nicht nur, dass ein Produkt zum Zeitpunkt der Markteinführung sicher ist, sondern über den gesamten Produktlebenszyklus hinweg. Das verschiebt den Fokus fundamental: Cybersicherheit ist kein einmaliges Audit mehr, sondern ein kontinuierlicher Prozess aus Risikobewertung, Update-Fähigkeit und Schwachstellenmanagement – von der ersten Architekturentscheidung bis zur Außerbetriebnahme. Für Unternehmen, die Software bislang eher als Nebenprodukt der Maschine betrachtet haben, ist das ein Kulturwandel: Die Softwarearchitektur muss von Anfang an so gestaltet sein, dass Sicherheitsupdates über Jahre hinweg technisch überhaupt möglich sind – eine Anforderung, die viele bestehende Steuerungsarchitekturen heute schlicht nicht erfüllen.
Die 6 Kernpflichten des CRA im Überblick
Für einen schnellen Vergleich mit dem eigenen Produktportfolio lassen sich die CRA-Anforderungen in sechs Handlungsfelder gliedern:
Risikoeinstufung
Einstufung jedes digitalen Produkts als Standard, Wichtig (Klasse I/II) oder Kritisch – abhängig vom Risikopotenzial (z. B. Netzwerkzugriff, Auswirkung bei Ausfall)
Security by Design & Secure Defaults
Sicherheitsmaßnahmen bereits in Architektur und Konzeptphase verankern; Auslieferung mit sicherer Standardkonfiguration statt offener Werkseinstellungen
Schwachstellenmanagement
Kontinuierliches Monitoring, Bewertung und Behebung von Sicherheitslücken über den gesamten Produktlebenszyklus, inkl. koordinierter Offenlegung
Meldepflichten
Aktiv ausgenutzte Schwachstellen und Vorfälle binnen 24 Stunden an ENISA/nationale Behörde (BSI) melden, mit Folgeberichten
Technische Doku & CE-Konformität
Vollständige Dokumentation der Konformitätsbewertung als Voraussetzung für CE-Kennzeichnung; bei kritischen Produkten ggf. Prüfung durch benannte Stelle
Software Bill of Materials (SBOM)
Vollständiges, maschinenlesbares Verzeichnis aller verwendeten Softwarekomponenten inkl. Drittanbieter- und Open-Source-Bibliotheken
Praxisbeispiel: CRA-Readiness in der Retrofit-Praxis
Ausgangslage: Ein mittelständischer Hersteller von Produktionsanlagen wollte eine bestehende Maschinengeneration mit einer IoT-fähigen Steuerung für Predictive Maintenance nachrüsten. Die vorhandene Steuerungssoftware war über Jahre gewachsen, ohne dass ein systematisches Schwachstellenmanagement oder eine Komponentenliste existierte.
Herausforderung: Durch die Netzwerkanbindung fiel das nachgerüstete Produkt eindeutig in den Anwendungsbereich des CRA – gleichzeitig fehlte die Grundlage, um überhaupt eine Risikoklassifizierung vorzunehmen, da unklar war, welche Drittkomponenten in der Legacy-Software überhaupt verbaut waren.
Vorgehen: Zunächst wurde ein vollständiges Software Bill of Materials für die Bestandssoftware erstellt, um Transparenz über alle Abhängigkeiten und bekannte Schwachstellen zu schaffen. Darauf aufbauend erfolgte eine Risikoklassifizierung der neuen IoT-Komponente, gefolgt von einer Architekturanpassung nach Security-by-Design-Prinzipien – unter anderem durch Trennung sicherheitskritischer und unkritischer Softwaremodule sowie den Aufbau eines Update-Mechanismus für zukünftige Sicherheitspatches.
Ergebnis: Die nachgerüstete Produktlinie erreichte die CRA-relevante Dokumentations- und Prozessreife rund 5 Monate vor der internen Zielsetzung – und damit rechtzeitig, bevor die Meldepflichten ab September 2026 ohnehin ein funktionierendes Schwachstellenmanagement vorausgesetzt hätten.
Fazit: Jetzt handeln, nicht erst 2027
Der Cyber Resilience Act ist kein IT-Randthema, sondern eine Frage des Marktzugangs für jedes vernetzte Produkt im Maschinenbau. Wer erst kurz vor Dezember 2027 beginnt, gerät bei realistischen Umsetzungszeiten von 14 bis 20 Monaten zwangsläufig unter Druck – zumal die Meldepflichten für Schwachstellen seit dem 11. September 2026 gelten und schon heute ein funktionierendes Sicherheitsmanagement voraussetzen. Der eigentliche Wendepunkt liegt daher nicht in einem einzelnen Compliance-Projekt, sondern in der Frage, ob Cybersicherheit fest im Entwicklungsprozess verankert wird oder ein wiederkehrendes Nachrüst-Thema bleibt.
Als Softwaredienstleister mit Erfahrung seit 1983 in normativ regulierten und sicherheitskritischen Umgebungen – von funktionaler Sicherheit nach IEC 61508 bis zu Medizinsoftware nach MDR und IVDR – unterstützen wir Maschinenbauer dabei, Security-by-Design-Prinzipien praxisnah in bestehende und neue Softwarearchitekturen zu integrieren: von der Erstellung eines belastbaren SBOM über die Risikoklassifizierung einzelner Produktlinien bis zum Aufbau eines dauerhaften Schwachstellenmanagements. Unser Ziel ist dabei stets, aus einer regulatorischen Pflicht einen belastbaren technischen Standard zu machen, der über den CRA hinaus trägt.
Stehen Sie also vor der Frage, wie Sie Ihr Produktportfolio CRA-fähig machen?
Wir unterstützen Sie von der ersten Bestandsaufnahme bis zur normkonformen Umsetzung – mit langjähriger Erfahrung in funktionaler Sicherheit und Cybersecurity für den Maschinen- und Anlagenbau.
