Kostenlose DevOps-Analyse
Zurück zum Blog
Industrial DevOps 13 min Lesezeit 15. März 2026

Cyber Resilience Act im Maschinenbau

Der EU Cyber Resilience Act macht Cybersecurity zur Herstellerpflicht — auch für Maschinenbauer. Was bisher optional war, wird verbindlich: Security by Design, SBOM, Vulnerability Management und sichere Update-Prozesse. Was Sie jetzt tun müssen.

Cyber Resilience Act im Maschinenbau — EU-Regulierung für vernetzte Maschinen

Andreas Schönfeld

Geschäftsführer & DevOps-Berater, Comquent GmbH

18+ Jahre Erfahrung in DevOps, CI/CD und Industrial Automation

Veröffentlicht: 15. März 2026Zuletzt aktualisiert: 25. März 2026
Fachlich geprüft für CRA- und NIS2-Compliance

Warum der CRA den Maschinenbau verändert

Maschinenbauer denken in Mechanik, Antriebstechnik und Steuerungslogik. Cybersecurity war bisher ein Thema der IT-Abteilung — wenn überhaupt. Das ändert sich grundlegend.

Der EU Cyber Resilience Act (CRA), seit September 2024 in Kraft, verpflichtet Hersteller von Produkten mit digitalen Elementen, Cybersecurity über den gesamten Produktlebenszyklus sicherzustellen. Das betrifft jede Maschine mit Software: von der SPS-Steuerung über das HMI bis zum Edge-Gateway.

Für den Maschinenbau bedeutet das einen Paradigmenwechsel: Wer vernetzte Maschinen in der EU in Verkehr bringt, muss nachweisen, dass Security von Anfang an in den Entwicklungsprozess integriert ist — nicht als nachträglicher Patch, sondern als integraler Bestandteil.

Keine CE-Kennzeichnung ohne CRA-Konformität

Ab Dezember 2027 dürfen Produkte mit digitalen Elementen ohne CRA-Konformität nicht mehr in der EU in Verkehr gebracht werden. Ohne Konformitätserklärung keine CE-Kennzeichnung — ohne CE kein Marktzugang.

  • Bußgelder bis zu 15 Mio. EUR oder 2,5 % des weltweiten Jahresumsatzes
  • Marktüberwachungsbehörden können den Rückruf von Produkten anordnen
  • Bereits ab September 2026 gelten die Meldepflichten für Schwachstellen

Die CRA-Timeline: Diese Fristen gelten

Der CRA kennt gestaffelte Übergangsfristen. Die Uhr tickt bereits.

Sep 2024

CRA in Kraft getreten

Veröffentlichung im Amtsblatt der EU. Die Übergangsfrist beginnt.

Sep 2026

Meldepflichten gelten

Hersteller müssen aktiv ausgenutzte Schwachstellen und Sicherheitsvorfälle an die ENISA melden.

Dez 2027

Volle Konformität erforderlich

Alle Anforderungen müssen erfüllt sein. Produkte ohne CE-Kennzeichnung dürfen nicht mehr in Verkehr gebracht werden.

Die 6 Kernanforderungen des CRA

Was der Cyber Resilience Act konkret von Herstellern verlangt — und was das für Ihren Entwicklungsprozess bedeutet.

01

Security by Design

Sicherheit muss von der ersten Zeile Code an in den Entwicklungsprozess integriert werden — nicht nachträglich aufgesetzt.

Threat Modeling, sichere Architektur, Secure Coding Guidelines, regelmäßige Security Reviews während der gesamten Entwicklung.

Impact: Hoch
02

Software Bill of Materials (SBOM)

Vollständige Dokumentation aller Software-Komponenten — proprietär und Open Source — in jedem Produkt.

Automatisierte SBOM-Generierung bei jedem Build, standardisierte Formate (CycloneDX, SPDX), Nachverfolgbarkeit über den gesamten Lebenszyklus.

Impact: Hoch
03

Vulnerability Management

Strukturierte Prozesse zur Identifikation, Bewertung und Behebung von Schwachstellen — über den gesamten Produktlebenszyklus.

Continuous Monitoring gegen CVE-Datenbanken, definierte SLAs für Patch-Bereitstellung, koordinierte Offenlegung (Coordinated Vulnerability Disclosure).

Impact: Hoch
04

Update-Management

Sichere und zuverlässige Mechanismen für Software-Updates über die gesamte erwartete Produktlebensdauer.

Signierte Updates, Rollback-Fähigkeit, automatische oder manuelle Update-Kanäle, sichere Übertragungswege.

Impact: Hoch
05

Incident Reporting

Meldepflicht für aktiv ausgenutzte Schwachstellen innerhalb von 24 Stunden an die ENISA.

Interne Prozesse für Incident Detection, klare Eskalationswege, vorbereitete Meldewege an die zuständige Behörde.

Impact: Kritisch
06

Technische Dokumentation

Umfassende Dokumentation der Sicherheitsmaßnahmen, Risikoanalysen und Konformitätsbewertung.

Risikobewertung, Beschreibung der Sicherheitsarchitektur, Testberichte, Gebrauchsanweisungen mit Sicherheitshinweisen.

Impact: Mittel

Produktkategorien: Wo fällt Ihre Maschine hin?

Der CRA unterscheidet drei Kategorien mit unterschiedlichen Konformitätsbewertungsverfahren. Die Einstufung bestimmt, ob Sie selbst bewerten dürfen oder eine externe Prüfstelle benötigen.

Standardprodukte

Die meisten Maschinensteuerungen, HMIs, Sensorik-Software, Edge-Gateways.

Konformität: Selbstbewertung durch den Hersteller (Modul A). Interne Konformitätskontrolle.
SPS-ProgrammeHMI-AnwendungenCondition Monitoring SoftwareStandard-Edge-Gateways

Wichtige Produkte (Klasse I)

Produkte mit höherem Risikoprofil, z.B. Netzwerkkomponenten, Firewalls, industrielle Betriebssysteme.

Konformität: Selbstbewertung nur mit harmonisierten Standards möglich, sonst Drittprüfung erforderlich.
Industrielle FirewallsVPN-GatewaysNetzwerk-Management-SoftwareIdentity-Management

Kritische Produkte (Klasse II)

Hochrisiko-Produkte: industrielle Intrusion-Detection-Systeme, Hardware-Security-Module.

Konformität: Obligatorische Drittprüfung durch eine benannte Stelle (Notified Body).
Industrielle IDS/IPSHSM (Hardware Security Modules)Smart-Card-SystemeSichere Elemente

5 Herausforderungen, die den Maschinenbau besonders treffen

Der CRA wurde primär für IT-Produkte geschrieben. Die Umsetzung im Maschinenbau bringt spezifische Herausforderungen mit sich, die reine Software-Unternehmen nicht haben.

01

Lange Produktlebenszyklen

Maschinen laufen 15–30 Jahre. Der CRA verlangt Security-Updates über die gesamte erwartete Lebensdauer — mindestens 5 Jahre.

Implikation: Sie brauchen eine langfristige Update-Strategie, die über einzelne Projekte hinausgeht.
02

Legacy-Software in neuen Produkten

Bestehender Steuerungscode wird oft über Generationen weiterverwendet. Der CRA gilt für alle neu in Verkehr gebrachten Produkte — auch mit alter Software.

Implikation: Legacy-Code muss auf Schwachstellen geprüft und in die SBOM aufgenommen werden.
03

Heterogene Komponentenlandschaft

Eine Maschine enthält Software von Dutzenden Zulieferern: SPS-Hersteller, Antriebstechnik, HMI, Sensorik.

Implikation: Sie müssen SBOMs von Zulieferern einfordern und in Ihre eigene Dokumentation integrieren.
04

OT-Protokolle ohne Security

Viele industrielle Protokolle (Modbus, PROFINET, EtherCAT) wurden nie für Security designt.

Implikation: Kompensatorische Maßnahmen dokumentieren: Netzwerksegmentierung, Gateways, Monitoring.
05

Fehlende Security-Kompetenz

Maschinenbau-Teams denken in Safety (Maschinensicherheit), nicht in Cybersecurity. Die Disziplinen sind historisch getrennt.

Implikation: Schulungen und klare Verantwortlichkeiten: Product Security Officer, Security Champions im Team.

CRA-Roadmap: In 12 Wochen zum Fundament

Sie müssen nicht alles auf einmal umsetzen. Dieser pragmatische Fahrplan bringt Sie in 12 Wochen von der Bestandsaufnahme zur CRA-Grundkonformität.

1

Bestandsaufnahme

Woche 1–2
  • Produktportfolio kategorisieren (Standard vs. kritisch)
  • Bestehende Software-Komponenten inventarisieren
  • Zulieferer-Abhängigkeiten identifizieren
  • Gap-Analyse: Ist-Stand vs. CRA-Anforderungen
  • Verantwortlichkeiten klären (Product Security Officer)
2

Fundament aufbauen

Woche 3–6
  • SBOM-Generierung in Build-Prozess integrieren
  • Vulnerability Scanning für alle Abhängigkeiten einrichten
  • Secure Coding Guidelines definieren
  • Incident-Response-Prozess aufsetzen
  • Zulieferer-Anforderungen kommunizieren
3

Prozesse etablieren

Woche 7–12
  • Security by Design in den Entwicklungsprozess integrieren
  • Automatisierte Security-Tests in CI/CD-Pipeline
  • Update-Mechanismus für Produkte im Feld implementieren
  • Technische Dokumentation erstellen
  • Konformitätsbewertung vorbereiten
4

Optimieren & Nachweisen

Laufend
  • Continuous Monitoring und Vulnerability Management
  • Regelmäßige Security-Audits und Penetrationstests
  • Schulungsprogramm für Entwicklungsteams
  • Zulieferer-SBOMs regelmäßig aktualisieren
  • CE-Kennzeichnung und Konformitätserklärung

5 Quick Wins: Diese Woche starten

Sie müssen nicht auf die perfekte Strategie warten. Diese fünf Maßnahmen können Sie sofort umsetzen — und sie bringen Sie dem CRA-Ziel messbar näher.

01

SBOM-Generierung automatisieren

Niedrig

Integrieren Sie Syft oder CycloneDX in Ihren Build-Prozess. Bei jedem Build wird automatisch eine vollständige Komponentenliste erzeugt. Aufwand: wenige Stunden.

02

Dependency Scanning einschalten

Niedrig

Trivy oder OWASP Dependency-Check gegen CVE-Datenbanken laufen lassen. Sie wissen sofort, welche bekannten Schwachstellen in Ihren Abhängigkeiten stecken.

03

Zulieferer ansprechen

Niedrig

Fordern Sie SBOMs und Vulnerability-Informationen von Ihren Software-Zulieferern ein. Je früher Sie starten, desto besser — die Lieferkette braucht Zeit.

04

Incident-Response-Prozess definieren

Mittel

Wer wird informiert, wenn eine Schwachstelle entdeckt wird? Wer meldet an die ENISA? Halten Sie den Prozess schriftlich fest — auch wenn er zunächst einfach ist.

05

Product Security Officer benennen

Niedrig

Eine Person im Unternehmen muss die CRA-Konformität verantworten. Das muss kein Vollzeitjob sein — aber eine klare Zuständigkeit ist entscheidend.

Industrial DevOps als CRA-Enabler

Die gute Nachricht: Wer bereits Industrial DevOps praktiziert, hat einen großen Teil der CRA-Anforderungen bereits abgedeckt. CI/CD-Pipelines liefern die Infrastruktur für automatisierte SBOM-Generierung, Vulnerability Scanning und signierte Builds.

Versionierung mit Git, automatisierte Tests, reproduzierbare Builds — all das sind nicht nur DevOps-Best-Practices, sondern auch CRA-Anforderungen. Der Unterschied: Der CRA macht sie zur Pflicht und verlangt den Nachweis.

CRA-Anforderung → DevOps-Praxis

Security by DesignThreat Modeling + Security-Gates in der Pipeline
SBOMAutomatische Generierung bei jedem Build (Syft, CycloneDX)
Vulnerability ManagementContinuous Scanning in CI/CD (Trivy, Grype)
Update-ManagementAutomatisierte Release-Pipelines mit Rollback
Incident ReportingMonitoring + Alerting + definierte Runbooks
DokumentationDocs-as-Code, automatisch generierte Compliance-Reports

Industrial DevOps ist damit nicht nur ein Effizienz-Hebel, sondern der schnellste Weg zur CRA-Konformität. Wer heute in CI/CD-Pipelines und automatisierte Prozesse investiert, baut gleichzeitig die Grundlage für die regulatorische Compliance von morgen.

Fazit: Der CRA ist kein IT-Problem — er ist ein Produktthema

Der Cyber Resilience Act verändert die Spielregeln im Maschinenbau. Cybersecurity ist keine optionale Eigenschaft mehr, sondern eine regulatorische Pflicht — auf einer Stufe mit Maschinensicherheit und CE-Konformität.

Die Herausforderung ist real: lange Produktlebenszyklen, heterogene Komponentenlandschaften, fehlende Security-Kompetenz in OT-Teams. Aber die Lösung ist greifbar: Mit einem strukturierten Ansatz, pragmatischen Quick Wins und Industrial DevOps als technischem Fundament ist CRA-Konformität keine Raketenwissenschaft.

Warten Sie nicht auf Dezember 2027. Die Meldepflichten gelten ab September 2026. Starten Sie jetzt mit der Bestandsaufnahme, automatisieren Sie Ihre SBOM-Generierung und bauen Sie Schritt für Schritt die Prozesse auf, die der CRA verlangt. Ihre Produkte — und Ihre Marktposition — werden es Ihnen danken.

CRA-Readiness-Check für Maschinenbauer

Wo stehen Sie in Bezug auf den Cyber Resilience Act? In einem kostenlosen 90-Minuten-Workshop analysieren wir Ihr Produktportfolio, identifizieren die größten Lücken und erstellen einen pragmatischen Maßnahmenplan.

Häufig gestellte Fragen zum Cyber Resilience Act

Was ist der EU Cyber Resilience Act (CRA)?

Der Cyber Resilience Act ist eine EU-Verordnung, die verbindliche Cybersicherheitsanforderungen für alle Produkte mit digitalen Elementen festlegt — von Konsumentenelektronik bis zu Industriesteuerungen. Er verpflichtet Hersteller zu Security by Design, SBOM-Dokumentation, Vulnerability Management und regelmäßigen Sicherheitsupdates über den gesamten Produktlebenszyklus.

Ab wann gilt der CRA für Maschinenbauer?

Die Meldepflichten für aktiv ausgenutzte Schwachstellen gelten ab September 2026, die volle Konformitätspflicht ab Dezember 2027. Produkte ohne CRA-Konformität dürfen nach diesem Datum nicht mehr mit CE-Kennzeichnung in der EU in Verkehr gebracht werden.

Was ist eine SBOM und warum wird sie Pflicht?

Eine Software Bill of Materials (SBOM) ist eine maschinenlesbare Liste aller Software-Komponenten in einem Produkt — proprietär und Open Source. Der CRA macht die SBOM zur Pflicht, damit Hersteller und Betreiber bekannte Schwachstellen in ihren Abhängigkeiten schnell identifizieren und beheben können.

Welche Strafen drohen bei Nichteinhaltung des CRA?

Bei Verstößen gegen die wesentlichen Cybersicherheitsanforderungen drohen Bußgelder von bis zu 15 Millionen Euro oder 2,5 % des weltweiten Jahresumsatzes. Zusätzlich können Marktüberwachungsbehörden den Rückruf von Produkten anordnen oder den Marktzugang verweigern.

Betrifft der CRA auch bestehende Maschinen im Feld?

Der CRA gilt für Produkte, die nach Dezember 2027 neu in Verkehr gebracht werden — bestehende Maschinen im Feld sind nicht betroffen. Allerdings müssen Hersteller für bereits ausgelieferte Produkte Sicherheitsupdates bereitstellen, wenn diese unter den CRA-Zeitraum fallen.

In welche Produktkategorie fallen typische Maschinensteuerungen?

Die meisten Maschinensteuerungen, HMIs und Edge-Gateways fallen in die Kategorie „Standardprodukte" und können per Selbstbewertung konform erklärt werden. Industrielle Firewalls, VPN-Gateways und Netzwerkkomponenten fallen unter Klasse I oder II und erfordern gegebenenfalls eine Drittprüfung.

Wie hängen CRA und IEC 62443 zusammen?

Die IEC 62443 ist die wichtigste harmonisierte Norm für industrielle Cybersicherheit und wird voraussichtlich als Referenzstandard für die CRA-Konformität anerkannt. Wer die IEC 62443-4-1 (Product Security Development Lifecycle) bereits umsetzt, erfüllt einen Großteil der CRA-Anforderungen.

Wie hilft Industrial DevOps bei der CRA-Konformität?

Industrial DevOps liefert die technische Infrastruktur für CRA-Konformität: CI/CD-Pipelines automatisieren SBOM-Generierung, Vulnerability Scanning und signierte Builds. Versionskontrolle, automatisierte Tests und reproduzierbare Builds sind sowohl DevOps-Best-Practices als auch CRA-Anforderungen.

Bereit für den nächsten Schritt?

Vereinbaren Sie ein kostenloses Erstgespräch — wir klären gemeinsam, wie Sie in 90 Tagen die ersten messbaren Industrial-DevOps-Erfolge erzielen.

Erstgespräch buchen