Kostenlose DevOps-Analyse
Zurück zum Blog
INDUSTRIAL DEVOPS·15. März 2026·14 MIN LESEZEIT

Cyber Resilience
Act im
Maschinenbau.

Der EU Cyber Resilience Act macht Cybersecurity zur Herstellerpflicht — auch für Maschinenbauer. Zusammen mit der neuen Maschinen­verordnung und dem AI Act greifen ab 2027 drei EU-Regelwerke parallel auf dieselbe vernetzte Maschine. Was bisher optional war, wird verbindlich: Security by Design, SBOM, Vulnerability Management und sichere Update-Prozesse.

Cyber Resilience Act im Maschinenbau — EU-Regulierung für vernetzte Maschinen
Andreas Schönfeld

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: 4. Juli 2026
Fachlich geprüft für CRA-, AI-Act- und Maschinenverordnungs-Compliance

Stand: 4. Juli 2026 · Nächste Stufe: CRA-24-h-Meldepflicht ab 11. Sep. 2026 · Maschinen­verordnung ab 20. Jan. 2027 · AI-Act-Hochrisiko für KI-Sicherheitsbauteile ab 2. Aug. 2027

// AktuellStand Juli 2026

Die erste CRA-Stufe ist seit 11. Juni 2026 in Kraft — die Konformitäts­bewertungs­stellen nehmen Drittprüfungen für kritische Produkte (Klasse I/II) an. Als Nächstes greift ab 11. September 2026 die 24-Stunden-Meldepflicht. Danach wird es dicht: Die Maschinen­verordnung wird am 20. Januar 2027 verbindlich, die volle CRA-Konformität am 11. Dezember 2027, und für KI-Sicherheitsbauteile in Maschinen greift der AI Act ab 2. August 2027. Wer vernetzte Maschinen baut, sollte Produktklassifizierung und Gap-Analyse für alle drei Regelwerke jetzt bündeln.

01
// 01Kurz erklärt

Der EU Cyber Resilience Act (CRA, Verordnung (EU) 2024/2847) verpflichtet Hersteller von Produkten mit digitalen Elementen zu Cybersicherheit über den gesamten Produktlebenszyklus — von der SPS-Steuerung bis zum Edge-Gateway. Er gilt gestaffelt: Seit 11. Juni 2026 sind die Konformitäts­bewertungs­stellen aktiv, ab 11. September 2026 greifen die Meldepflichten (24 Stunden an die ENISA), ab Dezember 2027 ist volle CRA-Konformität Pflicht. Für vernetzte Maschinen kommt der CRA aber nicht allein: Parallel regulieren die neue Maschinen­verordnung (EU) 2023/1230 (ab 20. Januar 2027) die Maschine als Gesamtprodukt und der AI Act (ab 2. August 2027) KI-gestützte Sicherheitsbauteile — alle drei sind Voraussetzung für die CE-Kennzeichnung.

Paradigmen-
wechsel für
den Maschinenbau.

Maschinenbauer denken in Mechanik, Antriebstechnik und Steuerungslogik. Cybersecurity war bisher ein Thema der IT-Abteilung — wenn überhaupt. Das ändert sich grundlegend. Welche konkreten Herausforderungen im Maschinenbau mit SPS dabei entstehen, zeigt unser Anwendungsfall.

Der EU Cyber Resilience Act (CRA), seit September 2024 in Kraft, verpflichtet Hersteller digitaler Produkte zu Cybersecurity über den gesamten Lebenszyklus. Das betrifft jede Maschine mit Software: SPS-Steuerung, HMI, Edge-Gateway.

15 Mio. €
Max. Bußgeld
2,5 %
oder Jahresumsatz
24 h
Meldefrist ENISA
Dez. 2027
Volle Konformität
// 02 — Keine CE-Kennzeichnung ohne CRA-Konformität

Ohne CE.
Kein EU-Markt.

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 Rückruf anordnen
  • Ab 11. Sep. 2026 gelten die Meldepflichten: 24 h für Schwachstellen, 72 h für Vorfälle
// 03CRA-Timeline

Die Uhr
tickt bereits.

CRA, Maschinen­verordnung und AI Act kennen gestaffelte Übergangsfristen — von der ersten Meldepflicht 2026 bis zur vollen Konformität Ende 2027.

01
Sep 2024

CRA in Kraft getreten

Veröffentlichung im Amtsblatt der EU (Verordnung 2024/2847). Die 36-monatige Übergangsfrist beginnt.

02
11. Juni 2026

Konformitäts­bewertungs­stellen aktiv

Benannte Stellen (Notified Bodies) haben ihre Arbeit aufgenommen und können Produkte der Klasse I und II zertifizieren. Hersteller kritischer Produkte sollten jetzt Bewertungstermine vereinbaren.

03
11. Sep 2026

CRA-Meldepflichten — 24-h-Frist

Hersteller müssen aktiv ausgenutzte Schwachstellen innerhalb von 24 Stunden an die ENISA melden. Sicherheitsvorfälle müssen innerhalb von 72 Stunden gemeldet werden.

04
20. Jan 2027

Maschinen­verordnung verbindlich

Die neue EU-Maschinenverordnung 2023/1230 ersetzt die Maschinenrichtlinie und verlangt erstmals Schutz der Sicherheitsfunktionen gegen Cyber-Manipulation.

05
2. Aug 2027

AI Act — Hochrisiko-KI in Maschinen

Für KI-Systeme als Sicherheitsbauteil einer Maschine (Hochrisiko nach Anhang I der KI-Verordnung) gelten ab jetzt die vollen Pflichten inklusive Konformitätsbewertung.

06
11. Dez 2027

CRA — volle Konformität

Alle CRA-Anforderungen müssen erfüllt sein. Produkte ohne CE-Kennzeichnung dürfen nicht mehr in der EU in Verkehr gebracht werden. Bußgelder bis zu 15 Mio. EUR oder 2,5 % des Jahresumsatzes.

04
// 04CRA · AI Act · Maschinen­verordnung

CRA, AI Act oder Maschinen­verordnung —
was gilt für Ihre Maschine?

Der CRA reguliert Produkte (Cybersicherheit über den Lebenszyklus), der AI Act reguliert KI-Systeme (Hochrisiko-Pflichten für KI-Sicherheitsbauteile), die neue Maschinen­verordnung reguliert die Maschine als Gesamtsystem (Safety inklusive Schutz gegen Cyber-Manipulation) und NIS2 reguliert die Organisation (Betreiberpflichten). Eine vernetzte Maschine mit KI-gestütztem Sicherheitsbauteil kann unter alle vier Regelwerke fallen — jedes verlangt für den EU-Marktzugang seinen Beitrag zur CE-Kennzeichnung.

Die gute Nachricht gegen Doppelarbeit: Erfüllt ein Produkt mit digitalen Elementen, das zugleich ein Hochrisiko-KI-System ist, die Cybersicherheits­anforderungen aus Anhang I des CRA, gelten nach Artikel 12 CRA zugleich die Cybersecurity-Pflichten aus Artikel 15 der KI-Verordnung als erfüllt. SBOM, Vulnerability Management und sichere Update-Mechanismen zahlen so auf alle Regelwerke gleichzeitig ein — ein sauber aufgesetzter Secure Development Lifecycle nach IEC 62443 deckt den gemeinsamen technischen Kern ab.

01

Cyber Resilience Act (CRA)

Reguliert / Adressat

Produkte mit digitalen Elementen: Steuerungen, HMIs, Edge-Gateways, Software — Cybersicherheit über den Lebenszyklus

Hersteller, Importeure und Händler

Frist

Meldepflichten ab 11. Sep. 2026, volle Konformität ab 11. Dez. 2027

02

KI-Verordnung / EU AI Act (2024/1689)

Reguliert / Adressat

KI-Systeme: als Sicherheitsbauteil einer Maschine mit Drittprüfpflicht automatisch Hochrisiko (Art. 6 KI-VO) — Risikomanagement, Daten-Governance, menschliche Aufsicht

Anbieter und Betreiber von KI-Systemen in Produkten

Frist

Hochrisiko-Pflichten für eingebettete KI-Sicherheitsbauteile (Anhang I) ab 2. August 2027

03

Neue Maschinen­verordnung (EU) 2023/1230

Reguliert / Adressat

Die Maschine als Gesamtprodukt: Safety, erstmals inklusive Schutz gegen Cyberangriffe auf Sicherheitsfunktionen

Maschinenhersteller

Frist

Verbindlich ab 20. Januar 2027, ersetzt die Maschinenrichtlinie 2006/42/EG

04

NIS2-Richtlinie

Reguliert / Adressat

Organisationen und ihr Betrieb: Risikomanagement, Meldewesen, Lieferkette

Betreiber: wichtige und besonders wichtige Einrichtungen, u. a. Maschinenbau ab 50 Mitarbeitern

Frist

Deutsches Umsetzungsgesetz (NIS2UmsuCG) seit Anfang 2026 in Kraft — Pflichten gelten unmittelbar

Wichtig für die Praxis: NIS2 betrifft Sie als Betreiber — ob Ihr Unternehmen unter die Richtlinie fällt und welche Pflichten dann gelten, klärt unser NIS2-Betroffenheits-Leitfaden. Der CRA und die Maschinen­verordnung betreffen Sie als Hersteller. Und sobald ein KI-System eine Sicherheitsfunktion Ihrer Maschine übernimmt — etwa adaptive Geschwindigkeitsbegrenzung bei Mensch-Roboter-Kollaboration —, greift der EU AI Act mit dem Hochrisiko-Regime. Die Details zu CRA, NIS2 und SBOM finden Sie kompakt im Glossar.

05
// 05Die 6 Kernanforderungen

Sechs Pflichten.
Eine Konformität.

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

  • /01

    Security by Design

    Impact: Hoch

    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.

  • /02

    Software Bill of Materials (SBOM)

    Impact: Hoch

    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.

  • /03

    Vulnerability Management

    Impact: Hoch

    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).

  • /04

    Update-Management

    Impact: Hoch

    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.

  • /05

    Incident Reporting (ab 11. September 2026)

    Impact: Kritisch

    Meldepflicht für aktiv ausgenutzte Schwachstellen innerhalb von 24 Stunden und für Sicherheitsvorfälle innerhalb von 72 Stunden an die ENISA.

    Frühwarnung innerhalb von 24 h, vollständige Meldung innerhalb von 72 h, Abschlussbericht innerhalb von 14 Tagen. Interne Prozesse für Incident Detection, klare Eskalationswege und vorbereitete Meldeformulare sind Pflicht.

  • /06

    Technische Dokumentation

    Impact: Mittel

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

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

06
// 06Produktkategorien

Drei Klassen.
Drei Verfahren.

Die Einstufung bestimmt, ob Sie selbst bewerten dürfen oder eine externe Prüfstelle benötigen.

Kategorie / 01

Standardprodukte

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

Konformität

Selbstbewertung durch den Hersteller (Modul A). Interne Konformitätskontrolle.

Beispiele
  • SPS-Programme
  • HMI-Anwendungen
  • Condition Monitoring
  • Standard-Edge-Gateways
Kategorie / 02

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.

Beispiele
  • Industrielle Firewalls
  • VPN-Gateways
  • Netzwerk-Management
  • Identity-Management
Kategorie / 03

Kritische Produkte (Klasse II)

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

Konformität

Obligatorische Drittprüfung durch eine benannte Stelle (Notified Body).

Beispiele
  • Industrielle IDS/IPS
  • HSM (Hardware Security Modules)
  • Smart-Card-Systeme
  • Sichere Elemente
07
// 075 Herausforderungen im Maschinenbau

Der CRA wurde für IT gemacht.
Die OT folgt eigenen Regeln.

Die Umsetzung im Maschinenbau bringt spezifische Herausforderungen, 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.

// 08CRA-Roadmap: 12 Wochen

Nicht alles auf einmal.
Pragmatisch starten.

Von der Bestandsaufnahme zur CRA-Grundkonformität in 12 Wochen.

01
Phase 01

Bestands­aufnahme

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)
02
Phase 02

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
03
Phase 03

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
04
Phase 04

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
09
// 095 Quick Wins

Diese Woche
starten.

Fünf Maßnahmen, die Sie sofort umsetzen können — und die Sie dem CRA-Ziel messbar näher bringen.

  • /01

    SBOM-Generierung automatisieren

    Aufwand: 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

    Aufwand: 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

    Aufwand: 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

    Aufwand: 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

    Aufwand: Niedrig

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

10
// 10Industrial DevOps als CRA-Enabler

Schon DevOps?
Halber Weg geschafft.

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. Wie man ein vollständiges DevSecOps-Konzept für industrielle Umgebungen aufbaut, beschreibt unsere Leistungsseite.

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

CRA-Anforderung → DevOps-Praxis
01
Security by Design
Threat Modeling + Security-Gates in der Pipeline
02
SBOM
Automatische Generierung bei jedem Build (Syft, CycloneDX)
03
Vulnerability Management
Continuous Scanning in CI/CD (Trivy, Grype)
04
Update-Management
Automatisierte Release-Pipelines mit Rollback
05
Incident Reporting
Monitoring + Alerting + definierte Runbooks
06
Dokumentation
Docs-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.

Wer SBOM-Generierung, Vulnerability-Reports und signierte Artefakte nicht aus Plugins zusammenstückeln will, schaut auf IndustrialFlow: signierte CycloneDX/SPDX-SBOMs pro Build, automatische Trivy-/Container-Scans, VEX-Annotations und CRA-konforme Vulnerability-Reports — out-of-the-box, Jenkins-kompatibel, in 90 Tagen produktiv.

// 11Fazit

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. Die technischen Details zur IEC-62443-konformen DevSecOps-Implementierung finden Sie in unserem Vertiefungsartikel.

Warten Sie nicht auf Dezember 2027. Die CRA-Meldepflichten gelten ab 11. September 2026 — mit einer 24-Stunden-Frist für Schwachstellen. Die Konformitäts­bewertungs­stellen sind seit 11. Juni 2026 aktiv. Und wer KI als Sicherheitsbauteil in Maschinen einsetzt, hat mit dem EU AI Act ab 2. August 2027 den nächsten Stichtag vor sich — dieselbe SBOM- und Security-Pipeline bedient alle drei Regelwerke.

// 12Häufige Fragen zum CRA

Was Kunden
wirklich fragen.

Q.01
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.
Q.02
Ab wann gilt der CRA für Maschinenbauer?
Der CRA hat drei Stufen: Seit 11. Juni 2026 sind die Konformitäts­bewertungs­stellen aktiv. Ab 11. September 2026 gelten die Meldepflichten — aktiv ausgenutzte Schwachstellen müssen innerhalb von 24 Stunden an die ENISA gemeldet werden. Ab Dezember 2027 müssen alle Anforderungen vollständig erfüllt sein.
Q.03
Wie hängen CRA, AI Act und Maschinenverordnung zusammen?
Die drei EU-Regelwerke greifen bei einer vernetzten Maschine parallel, adressieren aber verschiedene Ebenen: Der Cyber Resilience Act (CRA) reguliert die Cybersicherheit der digitalen Produkt-Elemente über den Lebenszyklus, der AI Act (KI-Verordnung 2024/1689) reguliert KI-Systeme — als Sicherheitsbauteil einer Maschine werden sie über Anhang I zum Hochrisiko-System —, und die neue Maschinenverordnung (EU) 2023/1230 reguliert die Maschine als Gesamtprodukt inklusive Schutz der Sicherheitsfunktionen gegen Cyber-Manipulation. Alle drei sind Voraussetzung für die CE-Kennzeichnung. Ein sauber aufgesetzter Secure Development Lifecycle nach IEC 62443 deckt den gemeinsamen technischen Kern ab.
Q.04
Fällt meine Maschine gleichzeitig unter CRA, AI Act und Maschinenverordnung?
Bei vernetzten Maschinen mit KI-gestützter Sicherheitsfunktion ist die Dreifach-Regulierung der Regelfall. Der CRA greift für die digitalen Elemente (Steuerung, HMI, Edge-Gateway), die Maschinenverordnung für die Maschine als Gesamtprodukt und der AI Act, sobald ein KI-System als Sicherheitsbauteil dient und einer Drittprüfung unterliegt — dann ist es nach Artikel 6 der KI-Verordnung ein Hochrisiko-System. Alle drei Konformitäten müssen erfüllt sein, damit das CE-Kennzeichen angebracht werden darf.
Q.05
Ab wann gilt der AI Act für Maschinen mit KI?
Für KI-Systeme, die als Sicherheitsbauteil in eine Maschine eingebettet sind (Hochrisiko nach Anhang I der KI-Verordnung), gelten die Pflichten ab dem 2. August 2027. Das ist bewusst später als die übrigen AI-Act-Stufen (Hochrisiko nach Anhang III ab 2. August 2026), weil die bestehenden Konformitätsbewertungsverfahren der Produktvorschriften wie der Maschinenverordnung erst angepasst werden müssen. Maschinen, die 2027 auf den Markt kommen, werden heute entwickelt — die Zeit läuft bereits.
Q.06
Muss ich die Cybersecurity-Anforderungen von CRA und AI Act doppelt erfüllen?
Nein. Artikel 12 des Cyber Resilience Act koordiniert beide Regelwerke: Erfüllt ein Produkt mit digitalen Elementen, das zugleich ein Hochrisiko-KI-System ist, die grundlegenden Cybersicherheitsanforderungen aus Anhang I des CRA, gelten damit auch die Cybersecurity-Pflichten aus Artikel 15 der KI-Verordnung als erfüllt. Sie dokumentieren die Cybersicherheit einmal und weisen sie für beide Verordnungen gemeinsam nach.
Q.07
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.
Q.08
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.
Q.09
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.
Q.10
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.
Q.11
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.
Q.12
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.
Q.13
Was ist der Unterschied zwischen CRA und NIS2?
Der CRA reguliert Produkte, NIS2 reguliert Organisationen. Der Cyber Resilience Act verpflichtet Hersteller, Produkte mit digitalen Elementen über den gesamten Lebenszyklus abzusichern. NIS2 verpflichtet Betreiber, ihr Unternehmen abzusichern — Risikomanagement, Meldeprozesse, Lieferkette. Ein Maschinenbauer kann von beiden betroffen sein: als Hersteller vernetzter Maschinen vom CRA, als Unternehmen ab 50 Mitarbeitern in einem regulierten Sektor von NIS2.
Q.14
Gilt der CRA auch für Open-Source-Software?
Nicht-kommerzielle Open-Source-Software ist vom CRA ausgenommen. Sobald Open-Source-Komponenten aber in einem kommerziellen Produkt stecken — etwa ein Linux-basiertes HMI oder eine Edge-Runtime —, trägt der Hersteller des Produkts die volle Verantwortung: Die Komponenten müssen in der SBOM dokumentiert und auf Schwachstellen überwacht werden. Für Open-Source-Stiftungen gilt ein eigenes, abgemildertes Regime als „Open-Source-Steward".
Q.15
Müssen auch Importeure und Händler den CRA erfüllen?
Ja. Importeure dürfen nur CRA-konforme Produkte in der EU in Verkehr bringen und müssen prüfen, dass der Hersteller die Konformitätsbewertung durchgeführt hat. Händler müssen kontrollieren, dass CE-Kennzeichnung und Konformitätserklärung vorliegen. Wer ein Produkt unter eigener Marke verkauft oder wesentlich verändert, übernimmt die vollen Herstellerpflichten.
// Nächster Schritt

Erstgespräch.
Kostenlos.
90 Tage zum Ergebnis.

Wir klären gemeinsam, wie Sie in 90 Tagen die ersten messbaren Industrial-DevOps-Erfolge erzielen.

Erstgespräch buchen
Seit 2006 · 47+ Projekte
Industrie · Automotive · Finance