Dieser Artikel erklärt in kompakter Form, was der Cyber Resilience Act für Maschinenbauer bedeutet, welche Ziele verfolgt werden, in welchem Bereich der CRA gilt und welche Fristen existieren.
Cyber Resilience Act – Warum Sie sich jetzt kümmern sollten
Ein neues EU-Gesetz macht ernst mit IT-Sicherheit – nicht nur bei Smartphones und Routern, sondern auch bei Maschinen, Leuchten, Messgeräten oder Steuerungskomponenten mit Software. Der Cyber Resilience Act (CRA) nimmt erstmals Hard- und Softwarehersteller europaweit in die Pflicht, Cybersicherheit in ihre Produkte systematisch zu integrieren – über den gesamten Lebenszyklus hinweg.
Aber was bedeutet das für Maschinen- und Anlagenbauer? Für Hersteller technischer Produkte mit digitalen Funktionen? Und ab wann wird’s wirklich ernst?
Was ist der Cyber Resilience Act?
Der CRA ist eine EU-Verordnung zur Sicherstellung der Cybersicherheit von Produkten mit digitalen Elementen. Ziel ist es, die wachsende Zahl an Sicherheitslücken, Angriffen und Systemschwachstellen nicht nur über Prozesse und Firewalls zu lösen, sondern bereits im Produktdesign.
Kernpunkte des CRA:
Gilt für alle digitalen Produkte (Hard- und Software), die auf dem EU-Markt bereitgestellt werden
Verpflichtet Hersteller zu Sicherheitsupdates, Schwachstellenmanagement und Incident-Meldungen
Wird verbindlich und kontrolliert – mit Marktüberwachung, CE-Kennzeichnung und ggf. Notified Body
Wer ist betroffen?
Kurz gesagt: Alle, die Produkte mit Softwarefunktionalität herstellen, importieren oder vertreiben – auch im B2B-Umfeld.
Für Maschinenbauer besonders relevant:
Steuerungseinheiten
HMI/SCADA-Systeme
Smarte Sensoren & Aktoren
IoT-Gateways, embedded Controller
Begleitsoftware zur Konfiguration, Auswertung oder Fernwartung
Selbst wenn das Produkt nicht „online“ ist: Jede digitale Funktion (z. B. Firmware, Updatefähigkeit, API) kann den CRA triggern.
Zeitplan – Wann wird der CRA verpflichtend?
Schritt
Zeitpunkt
Bedeutung
Finaler Beschluss durch EU-Parlament
23. Oktober 2024
Der CRA wurde formell angenommen (Verabschiedung im Trilogverfahren).
Veröffentlichung im EU-Amtsblatt
20. November 2024
Gesetzestext ist veröffentlicht, Start der Fristen.
Inkrafttreten
11. Dezember 2024
CRA tritt offiziell in Kraft (20 Tage nach Veröffentlichung).
Beginn Meldepflicht
11. September 2026
Meldepflicht für Schwachstellen und Sicherheitsvorfälle an ENISA laut Artikel 14 beginnt
Benennung der Konformitätsbewertungsstellen (KBS)
ab 11. Juni 2026
Die EU-Mitgliedstaaten benennen Stellen zur Konformitätsbewertung. Die Artikel 35 bis 51 treten in Kraft und regeln deren Aufgaben sowie die Marktüberwachung.
Verfügbarkeit der KBS
11. Dezember 2026
Laut Artikel 35 Absatz 2 sind hinreichend KBS zur Engpassvermeidung benannt
Volle Geltung des CRA
ab 11. Dezember 2027
Entsprechend Artikel 71 Abs. 2 endet die Übergangsfrist und alle Produkte mit digitalen Elementen müssen die CRA-Anforderungen erfüllen
Achtung: Der Zeitraum zwischen 11. Juni 2026 und 11. Dezember 2027 könnte eng werden. Artikel 35 Absatz 2 sieht zwar vor, das hinreichend Stellen benannt werden. Es gibt aber keine direkten Sanktionen bei Nichteinhaltung. Das Risiko liegt also auf Unternehmensseite.
Was fordert der CRA?
Die zentralen Anforderungen im Überblick:
Bereich
Was zu tun ist
Sichere Entwicklung
Einführung eines Secure Software Development Lifecycle (z. B. Bedrohungsmodellierung, Codeanalyse, Testing)
Produktdesign
Security by Design & by Default – z. B. Schutz gegen Manipulation, sicheres Booten, Zugriffskontrolle
Dokumentation
Technische Dokumentation mit Risikoanalyse, Sicherheitsarchitektur, Update-Strategie
Updates & Wartung
Verpflichtung zur Beseitigung entdeckter Schwachstellen (je nach Produkt für 5 Jahre und mehr)
Meldung von Sicherheitsvorfällen
Meldepflicht an ENISA bei aktiven Exploits oder schwerwiegenden Lücken innerhalb von 24 Stunden
CE-Kennzeichnung
Nur noch möglich bei vollständiger CRA-Konformität
Was bedeutet das konkret für Maschinenbauer?
Der CRA trifft nicht nur Softwarehäuser, sondern vor allem klassische Hersteller, die ihre Maschinen digitalisiert haben – und dabei oft nicht als Softwareunternehmen aufgestellt sind.
Typische Herausforderungen:
Keine etablierten Secure-Development-Prozesse
Kein durchgängiges Schwachstellenmanagement
Fehlende Dokumentation der Softwarearchitektur
Veraltete Firmware ohne geplanten Wartungsprozess oder Updatefähigkeit
Gerade weil viele Maschinenbauer stark auf Lieferanten und Systemhäuser setzen, braucht es verbindliche Sicherheitsanforderungen an Zulieferer, eine klare Zuordnung der Verantwortung beim Inverkehrbringen sowie nachvollziehbare und vollständige Nachweise über den gesamten Software-Lifecycle.
Und wie hängt das mit anderen Regularien zusammen?
Der CRA ist kein Solist. Er ergänzt und verschärft andere bestehende oder kommende Vorschriften, z. B.:
Maschinenverordnung (2023/1230): fordert ebenfalls sichere Softwarefunktionen und Wartbarkeit
EU Data Act: regelt Datenzugriff und -nutzung – vor allem bei vernetzten Maschinen
NIS-2-Richtlinie: betrifft größere Maschinenbauer als Betreiber kritischer Infrastrukturen
Produktsicherheitsverordnung (GPSR): betrifft u. a. CE-Kennzeichnungspflichten
Wer den CRA ignoriert, riskiert kein CE-Zeichen zu bekommen, Produkt-Rückrufe oder gar Haftung im Schadenfall.
Fazit: Nicht warten, handeln
Der CRA ist da – und er bringt echte Pflichten. Doch wer jetzt handelt, kann nicht nur Bußgelder vermeiden, sondern auch Vertrauen bei Kunden und Partnern gewinnen. Sicherheit wird zum Qualitätsmerkmal.
Wollen Sie vorbereitet sein, dann starten Sie mit unserem CRA Check.
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.
Ab dem 11. September 2026 sind Hersteller verpflichtet, aktiv ausgenutzte Schwachstellen und Sicherheitsvorfälle innerhalb von 24 Stunden an ENISA zu melden – dieser Artikel zeigt, was konkret zu tun ist.