Kostenlose DevOps-Analyse
Zurück zum Blog
Industrial DevOps · Compliance·Aktualisiert 19. Oktober 2026·17 min Lesezeit

Cyber Resilience Act im Maschinenbau.Was seit September gilt und was 2027 kommt.

Seit dem 11. September 2026 müssen Hersteller ausgenutzte Schwachstellen binnen 24 Stunden melden, auch für Maschinen, die längst beim Kunden laufen. Am 20. Januar 2027 löst die Maschinen­verordnung die Maschinenrichtlinie ab, am 11. Dezember 2027 hängt die CE-Kennzeichnung an der vollen CRA-Konformität. Wir gehen die Fragen in der Reihenfolge durch, in der sie in einem Maschinenbau-Unternehmen auf den Tisch kommen.

Montagehalle in der Abenddämmerung: Ein Industrieroboter und ein Bearbeitungszentrum sind über eine leuchtend orange Leitung mit einem offenen Schaltschrank und einem Laptop verbunden, auf dem ein Techniker die Liste der Software-Komponenten prüftAI
// Kurz gesagt

Der EU Cyber Resilience Act (CRA, Verordnung (EU) 2024/2847) verpflichtet Hersteller von Produkten mit digitalen Elementen zu Cybersicherheit über den gesamten Lebenszyklus, auch bei SPS-Steuerungen, HMIs, Edge-Gateways und der Software einer Maschine. Seit dem 11. September 2026 müssen Hersteller aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle binnen 24 Stunden an CSIRT und ENISA melden. Ab dem 11. Dezember 2027 gelten alle Anforderungen. Für die Maschine als Ganzes kommt ab dem 20. Januar 2027 die Maschinen­verordnung (EU) 2023/1230 hinzu. Die CE-Kennzeichnung einer vernetzten Maschine setzt beide Konformitäten voraus.

Stand: 19. Oktober 2026CRA-Meldepflicht seit 11. Sep. 2026Maschinen­verordnung ab 20. Jan. 2027Volle CRA-Konformität ab 11. Dez. 2027KI-Sicherheitsbauteile ab 2. Aug. 2028
// Kurz gefragt1 Klick, anonym

Ist der Cyber Resilience Act bei Ihnen gerade ein Thema?

Wir fragen kurz, wie dringend das Thema bei Ihnen gerade ist. Je nach Antwort zeigen wir Ihnen direkt den passenden nächsten Schritt — ganz ohne Formular.

Andreas Schönfeld

Andreas Schönfeld

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

DevOps, CI/CD und Industrial Automation seit 2006.

Veröffentlicht: 15. März 2026Zuletzt aktualisiert: 19. Oktober 2026
Rechtsstand geprüft gegen CRA, Maschinenverordnung, KI-Omnibus 2026/1744, Leitlinien C(2026) 5252 und BSI-Veröffentlichungen
// 01Einordnung

Was ändert der Cyber Resilience Act für Maschinenbauer?

Er macht Cybersecurity zu einer Produkteigenschaft, die Sie nachweisen müssen, so wie heute die Maschinensicherheit. Wer ab Dezember 2027 eine Maschine mit Software und Datenverbindung in der EU verkauft, braucht dafür eine Risikobewertung, eine Liste der Software-Komponenten, einen Prozess für Schwachstellen und Sicherheitsupdates über mindestens fünf Jahre. Die Meldepflicht gilt schon heute.

Maschinenbauer denken in Mechanik, Antrieben und Steuerungslogik. Cybersecurity lag bisher bei der IT, wenn sie überhaupt jemand auf dem Tisch hatte, und eine budgetierte Stelle dafür gibt es 2026 in den wenigsten Häusern.

Neu ist dabei weniger die Technik als der Nachweis. Viele Häuser segmentieren ihre Netze und patchen ihre Panels längst. Der CRA will das für jeden ausgelieferten Stand belegt sehen, über Jahre. Welche Hürden dabei an der SPS entstehen, zeigt unser Anwendungsfall Maschinenbau und SPS.

24 h
Frühwarnung an CSIRT und ENISA
5 Jahre
Mindest-Unterstützungszeitraum
10 Jahre
Updates verfügbar halten
15 Mio. €
oder 2,5 % Umsatz Bußgeld

Quelle: Verordnung (EU) 2024/2847, Art. 13 Abs. 8 und 9, Art. 14, Art. 64 Abs. 2

// 02Anwendungsbereich

Gilt der CRA für meine Maschine?

Ja, sobald zu ihrer bestimmungsgemäßen oder vorhersehbaren Verwendung eine direkte oder indirekte Datenverbindung zu einem Gerät oder Netz gehört (Art. 2 Abs. 1 CRA). Das trifft auf fast jede Maschine mit SPS, HMI oder Fernwartungszugang zu. Auch eine Steuerung im abgeschotteten Netz, die nur über den Service-Laptop neue Software bekommt, fällt darunter.

Offen ist meist nicht das Ob, sondern welche Pflichten für welche Maschine wann greifen. Drei Fälle decken den Alltag der meisten Hersteller ab.

  • /01

    Neue Maschinen ab Dezember 2027

    Jede Einheit, die ab dem 11. Dezember 2027 in Verkehr gebracht wird, muss alle Anforderungen erfüllen. Es zählt der Tag der Auslieferung, nicht das Jahr der Konstruktion.

    Was das heißt

    Prüfen Sie je Baureihe, ob nach dem Stichtag noch Einheiten das Werk verlassen. Dann ist die Baureihe betroffen, auch wenn ihre Steuerung von 2019 stammt.

  • /02

    Maschinen, die schon beim Kunden laufen

    Für sie gilt seit dem 11. September 2026 die Meldepflicht (Art. 69 Abs. 3). Die übrigen Anforderungen greifen erst, wenn eine solche Maschine nach dem 11. Dezember 2027 wesentlich geändert wird (Art. 69 Abs. 2).

    Was das heißt

    Ein Sicherheitsupdate, das den Zweck der Maschine nicht verändert, ist nach Erwägungsgrund 39 keine wesentliche Änderung. Eine neue Funktion, etwa ein zusätzlicher Fernzugang, kann eine sein.

  • /03

    Zugekaufte Steuerungen und Komponenten

    Für die SPS von Siemens, den Antrieb oder das HMI-Panel tragen deren Hersteller eigene CRA-Pflichten. Für die Maschine bleiben Sie verantwortlich, und Art. 13 Abs. 5 verlangt bei zugekauften Komponenten die gebotene Sorgfalt.

    Was das heißt

    Eine CRA-konforme SPS macht die Maschine noch nicht konform. Finden Sie eine Schwachstelle in einer Komponente, melden Sie sie deren Hersteller (Art. 13 Abs. 6).

// In 2 Klicks: CRA-OrientierungSchritt 1 / 2

Betrifft Sie der Cyber Resilience Act?

Der CRA betrifft fast jedes Produkt mit digitalen Elementen. Wie streng die Konformitätsbewertung ausfällt, hängt von seiner Kernfunktion ab. Diese Einordnung ist unverbindlich und zeigt Ihnen in zwei Klicks die wahrscheinliche Richtung.

Bringen Sie Produkte mit digitalen Elementen in den EU-Markt?

// 03CRA-Fristen

Welche CRA-Fristen gelten ab wann?

Der Cyber Resilience Act ist am 10. Dezember 2024 in Kraft getreten. Seine Übergangsfrist beträgt 36 Monate und endet am 11. Dezember 2027. Davor liegen zwei Stufen. Seit dem 11. Juni 2026 gelten die Regeln für Konformitäts­bewertungs­stellen, seit dem 11. September 2026 die Meldepflicht. Für Maschinenbauer kommen zwei Termine dazu, die Maschinen­verordnung am 20. Januar 2027 und die Pflichten für KI-Sicherheitsbauteile am 2. August 2028.

Maßgeblich ist das Inverkehrbringen, nicht das Entwicklungsende. Eine Maschine, die im Frühjahr 2028 ausgeliefert wird, entsteht in einem Projekt, das heute startet.

10. Dez. 2024

CRA in Kraft

Die Verordnung (EU) 2024/2847 erschien am 20. November 2024 im Amtsblatt und trat 20 Tage später in Kraft. Damit begann die Übergangsfrist von 36 Monaten.

11. Juni 2026

Regeln für benannte Stellen

Kapitel IV gilt. Die Mitgliedstaaten können Konformitäts­bewertungs­stellen für den CRA notifizieren. Wer Produkte der Klasse II baut, sucht sich jetzt eine Prüfstelle, auch wenn die Liste noch kurz ist.

11. Sep. 2026

Meldepflicht gilt

Aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle gehen binnen 24 Stunden als Frühwarnung an das koordinierende CSIRT und die ENISA. Das gilt auch für Produkte, die schon beim Kunden laufen.

20. Jan. 2027

Maschinen­verordnung gilt

Die Maschinenverordnung (EU) 2023/1230 löst die Maschinenrichtlinie 2006/42/EG ab. Sie verlangt erstmals, dass Steuerungen und sicherheitsrelevante Software gegen Manipulation geschützt sind.

11. Dez. 2027

Volle CRA-Konformität

Neu in Verkehr gebrachte Produkte mit digitalen Elementen brauchen die CRA-Konformität, sonst gibt es keine CE-Kennzeichnung.

2. Aug. 2028

KI-Sicherheits­bauteile

Der KI-Omnibus (Verordnung (EU) 2026/1744) hat diesen Termin vom 2. August 2027 hierher verschoben. Die Anforderungen an KI in Maschinen kommen über delegierte Rechtsakte zur Maschinenverordnung.

// 04Ohne Konformität

Was passiert, wenn eine Maschine nicht CRA-konform ist?

Ab dem 11. Dezember 2027 bekommt sie keine CE-Kennzeichnung mehr, und ohne CE-Kennzeichnung darf sie in der EU nicht in Verkehr gebracht werden. Die Meldepflicht kann ein Hersteller schon heute verletzen.

  • → Bis 15 Mio. Euro oder 2,5 % des weltweiten Jahresumsatzes bei Verstößen gegen Anhang I und die Pflichten aus Art. 13 und 14, darunter die Meldepflicht
  • → Bis 10 Mio. Euro oder 2 % bei anderen Pflichtverstößen, bis 5 Mio. Euro oder 1 % bei falschen Angaben gegenüber Behörden
  • → Marktüberwachungsbehörden können Rücknahme oder Rückruf anordnen

Quelle: Verordnung (EU) 2024/2847, Art. 64 Abs. 2 bis 4

Wer in Deutschland kontrolliert, regelt das CRA-Durchführungsgesetz, das der Bundestag Mitte Oktober 2026 beschlossen hat. Das BSI wird damit Marktüberwachungs- und Bußgeldbehörde. Es kann Produkte prüfen, Nachbesserungen verlangen und Produkte vom Markt nehmen lassen. Verkündet ist das Gesetz noch nicht, der Beschluss des Bundestags liegt vor.

// 05Meldepflicht seit 11.09.2026

Was müssen Hersteller seit dem 11. September melden?

Seit dem 11. September 2026 melden Hersteller zwei Ereignisse, eine aktiv ausgenutzte Schwachstelle in ihrem Produkt und einen schwerwiegenden Sicherheitsvorfall, der die Sicherheit des Produkts beeinträchtigt. In beiden Fällen geht innerhalb von 24 Stunden eine Frühwarnung raus, nach 72 Stunden die eigentliche Meldung, danach ein Abschlussbericht. Die Meldung läuft über die Single Reporting Platform der ENISA gleichzeitig an das koordinierende CSIRT, in Deutschland das CERT-Bund im BSI, und an die ENISA. Gemeldet wird auf Englisch.

Frühwarnung
SchwachstelleInnerhalb von 24 Stunden, mit den Mitgliedstaaten, in denen das Produkt bereitgestellt wurde
VorfallInnerhalb von 24 Stunden, mit dem Hinweis, ob ein rechtswidriger oder böswilliger Eingriff vermutet wird
Meldung
SchwachstelleInnerhalb von 72 Stunden, mit Angaben zu Produkt, Art der Schwachstelle und ergriffenen Gegenmaßnahmen
VorfallInnerhalb von 72 Stunden, mit einer ersten Bewertung des Vorfalls
Abschlussbericht
SchwachstelleSpätestens 14 Tage, nachdem eine Korrektur oder Risikominderung verfügbar ist
VorfallInnerhalb eines Monats nach der 72-Stunden-Meldung

Quelle: Art. 14 Abs. 2 und 4 CRA · EU-Kommission, CRA Reporting

Was zählt als aktiv ausgenutzte Schwachstelle?

Eine Schwachstelle, zu der verlässliche Nachweise vorliegen, dass ein böswilliger Akteur sie in einem System ohne Zustimmung des Systemeigners ausgenutzt hat (Art. 3 Nr. 42 CRA). Eine Lücke, die ein Forscher meldet oder für die ein Proof of Concept kursiert, ist damit noch nicht meldepflichtig. Meldepflichtig wird sie, sobald Sie Hinweise haben, dass jemand sie bei einem Kunden ausgenutzt hat. Behandeln müssen Sie die Lücke in jedem Fall, nur eben im normalen Schwachstellenprozess.

Zwei Fragen beantworten die Leitlinien der EU-Kommission vom 27. Juli 2026 ausdrücklich. Eine Lücke in einer zugekauften Komponente müssen Sie nur melden, wenn sie in Ihrem Produkt ausgenutzt wurde. Ist der verwundbare Code in Ihrer Maschine nicht erreichbar, melden Sie die Lücke dem Hersteller der Komponente, nicht der Behörde (Rn. 218). Rückwirkend melden müssen Sie nichts. Wussten Sie schon vor dem 11. September 2026 von der Ausnutzung, entfällt die Meldung. Erfahren Sie erst danach davon, gilt sie (Rn. 217).

Muss ich jeden Angriff auf eine Maschine melden?

Nein, nur schwerwiegende Vorfälle. Schwerwiegend ist ein Vorfall nach Art. 14 Abs. 5, wenn er die Fähigkeit Ihres Produkts beeinträchtigt oder beeinträchtigen kann, sensible oder wichtige Daten oder Funktionen zu schützen, oder wenn er Schadcode in das Produkt oder ins Netz des Kunden gebracht hat oder bringen kann. Ein Portscan auf den Fernwartungsrouter erfüllt das nicht. Ein Angreifer, der über diesen Router Parameter auf der Steuerung ändert, in aller Regel schon.

Ein Servicetechniker telefoniert am späten Nachmittag im Konstruktionsbüro, auf seinem Laptop ist ein Formular für eine Frühwarnung mit laufendem Countdown geöffnet, hinter der Glaswand steht eine halb montierte Maschine mit offenem SchaltschrankAI
Ab Kenntnis 24 Stunden: Die Frühwarnung braucht Hersteller, Produkt, Softwarestand und betroffene Länder

Die Pflicht gilt auch für Ihre Maschinen im Feld. Alle übrigen CRA-Anforderungen treffen Produkte, die vor dem 11. Dezember 2027 in Verkehr gebracht wurden, nur nach einer wesentlichen Änderung. Die Meldepflicht nimmt Art. 69 Abs. 3 davon ausdrücklich aus. Die Anlage von 2021 mit Fernwartungszugang ist also heute schon meldepflichtig, wenn jemand ihre Schwachstelle ausnutzt.

Wie das in der Praxis aussieht? Freitag, 16 Uhr, ein Kunde ruft an, weil sich jemand über den Fernwartungsrouter an seiner Linie zu schaffen macht. Ab dem Moment, in dem Sie davon Kenntnis haben, laufen 24 Stunden. Die Registrierung auf der Plattform ist dabei das kleinste Problem. Wer erst klären muss, wer im Haus die Meldung abgibt, welcher Softwarestand auf genau dieser Anlage läuft und wie man den Befund auf Englisch beschreibt, ist am Samstagnachmittag noch nicht fertig.

Größere Hersteller bündeln das in einem PSIRT, einem Product Security Incident Response Team. Im Mittelstand sind das oft zwei oder drei Leute aus Entwicklung und Service mit einer festen Rufnummer und einem Runbook, das einmal im Jahr geprobt wird. Mehr braucht es für den Anfang selten.

Neben CSIRT und ENISA müssen Sie auch die betroffenen Nutzer informieren, bei Bedarf mit Hinweisen, was sie selbst tun können. Für Kleinst- und Kleinunternehmen sieht Art. 64 Abs. 10 eine Erleichterung vor. Für eine verpasste 24-Stunden-Frühwarnung verhängt die Behörde gegen sie keine Geldbuße, die Pflicht zur Meldung bleibt.

// 06CRA und Maschinen­verordnung

Wie hängen Cyber Resilience Act und Maschinen­verordnung zusammen?

Es sind zwei eigenständige EU-Verordnungen, die bei einer vernetzten Maschine nebeneinander gelten. Der CRA ist nicht Teil der Maschinen­verordnung. Die Maschinen­verordnung (EU) 2023/1230 schützt die Menschen an der Maschine und verlangt, dass Steuerung und Sicherheitsfunktionen Manipulation aushalten. Der CRA schützt die digitalen Elemente selbst, über ihren ganzen Lebenszyklus. Für die CE-Kennzeichnung brauchen Sie beide Konformitäten, erklärt in einer gemeinsamen EU-Konformitätserklärung.

Schützt
MaschinenverordnungMenschen an und mit der Maschine (Safety)
Cyber Resilience ActDaten und Funktionen des Produkts (Security)
Gegenstand
MaschinenverordnungDie Maschine als Ganzes. Cybersecurity nur, soweit ein Eingriff zu einer Gefährdung führen kann (Anhang III Nr. 1.1.9 und 1.2.1)
Cyber Resilience ActJedes Produkt mit digitalen Elementen, also auch Steuerung, HMI, Gateway und Software für sich
Zeitraum
MaschinenverordnungKonformität beim Inverkehrbringen
Cyber Resilience ActPflichten über den ganzen Unterstützungszeitraum, in der Regel mindestens fünf Jahre
Stichtag
Maschinenverordnung20. Januar 2027
Cyber Resilience ActMeldepflicht seit 11. September 2026, alles Übrige ab 11. Dezember 2027
Nachweis
MaschinenverordnungRisikobeurteilung, Protokoll der Eingriffe und Software-Versionen an der Steuerung
Cyber Resilience ActRisikobewertung, SBOM, Schwachstellenprozess, Meldeweg, technische Dokumentation

Quelle: Verordnung (EU) 2023/1230, Anhang III Nr. 1.1.9 und 1.2.1 · Verordnung (EU) 2024/2847, Art. 13, 14 und 28

Braucht eine Maschine zwei Konformitätserklärungen?

Nein. Unterliegt ein Produkt mehreren Rechtsakten, die eine EU-Konformitätserklärung verlangen, stellen Sie eine einzige aus und nennen darin alle Rechtsakte mit ihrer Fundstelle im Amtsblatt (Art. 28 Abs. 3 CRA). Die Konformitätsverfahren laufen trotzdem getrennt, und jedes braucht seine eigenen Nachweise.

Zählt eine CRA-Konformität für die Maschinen­verordnung mit?

Nicht automatisch. Eine gesetzliche Vermutung zwischen beiden Verordnungen gibt es nicht. Erwägungsgrund 53 des CRA sagt nur, dass die CRA-Umsetzung die Anforderungen der Maschinen­verordnung leichter erfüllbar machen kann. Den Nachweis führt der Hersteller, und beide Verfahren laufen. In der Praxis überschneiden sich die Artefakte aber stark. Anhang III Nr. 1.2.1 der Maschinen­verordnung verlangt zum Beispiel, dass die Steuerung Eingriffe und die Versionen hochgeladener Sicherheitssoftware bis zu fünf Jahre protokolliert. Eine Pipeline, die jeden Stand signiert, versioniert und seiner Seriennummer zuordnet, liefert genau das nebenbei.

In der Gegenrichtung gibt es eine Übergangsregel. Hat eine benannte Stelle eine Maschine nach der Maschinen­verordnung geprüft und eine EU-Baumusterprüfbescheinigung ausgestellt, gilt diese für die Cyberrisiken aus Anhang III Nr. 1.1.9 und 1.2.1 auch für den CRA weiter, solange sie gültig ist, längstens bis zum 11. Juni 2028 (Leitlinien C(2026) 5252, Rn. 255 und 256). Die eigene CRA-Risikobewertung ersetzt das nicht.

Welche Norm deckt den Schutz gegen Korrumpierung ab?

Dafür entsteht die EN 50742, im deutschen Entwurf „Schutz vor Korruption“ genannt. Sie wird im Komitee CLC/TC 44X erarbeitet und zielt ausdrücklich auf Anhang III Nr. 1.1.9 und 1.2.1 der Maschinen­verordnung. Der deutsche Entwurf E DIN EN 50742 (VDE 0113-742) erschien im März 2026. Harmonisiert ist sie noch nicht, und zur Maschinen­verordnung steht bisher überhaupt keine Norm im Amtsblatt. Die EU-Kommission kündigt die erste Liste für das Jahresende an. Bis dahin stützen sich Maschinenbauer für die Security-Anforderungen auf die IEC 62443 und begründen ihre Lösung in der Risikobeurteilung.

Was ändert der KI-Omnibus für Maschinen mit KI?

Die Verordnung (EU) 2026/1744 gilt seit dem 27. Juli 2026. Sie hat die Maschinen­verordnung im AI Act von Anhang I Abschnitt A nach Abschnitt B verschoben. KI als Sicherheitsbauteil bleibt Hochrisiko, ihre Anforderungen kommen aber per delegiertem Rechtsakt in die Maschinen­verordnung und gelten ab dem 2. August 2028. Für Hochrisiko-KI in Produkten mit digitalen Elementen koordiniert Art. 12 CRA die Cybersecurity, wer Anhang I des CRA erfüllt, erfüllt auch Art. 15 der KI-Verordnung. Wie das für KI in Maschinen konkret greift, klären die delegierten Rechtsakte, die noch ausstehen. Mehr dazu in unserem Artikel zum EU AI Act in der Industrie und in der Analyse zum BSI-Prüfkatalog A5.

Und wo stehen AI Act und NIS2?

01

KI-Verordnung / AI Act (2024/1689)

Regelt / Adressat

KI-Systeme. KI als Sicherheitsbauteil einer Maschine bleibt Hochrisiko, die Anforderungen kommen seit dem KI-Omnibus aber über die Maschinenverordnung.

Anbieter und Betreiber von KI-Systemen

Frist

Hochrisiko nach Anhang I ab 2. Aug. 2028 (Verordnung (EU) 2026/1744)

02

NIS2 (in Deutschland: NIS2UmsuCG)

Regelt / Adressat

Nicht das Produkt, sondern das Unternehmen und sein Betrieb: Risikomanagement, Meldewesen, Lieferkette.

Maschinenbau (NACE C 28) ist ab 50 Beschäftigten oder mehr als 10 Mio. Euro Umsatz und Bilanzsumme „wichtige Einrichtung“

Frist

In Kraft seit 6. Dez. 2025, Registrierung beim BSI

Nicht zu verwechseln ist das große Digital-Omnibus-Paket (COM(2025) 837). Es soll unter anderem erreichen, dass eine CRA-Meldung eines schwerwiegenden Vorfalls zugleich als NIS2-Meldung zählt. Beschlossen ist es nicht. Im Oktober 2026 berät das Europäische Parlament noch im Ausschuss, und der Rat hat keine gemeinsame Position. Am CRA selbst hat sich bis heute nichts geändert, ein Vorfall muss bei Bedarf also weiter doppelt gemeldet werden.

// 07Produktklassen

In welche CRA-Klasse fällt Ihre Steuerung?

Die meisten Maschinensteuerungen, HMIs und SPS-Programme sind Standardprodukte und dürfen vom Hersteller selbst bewertet werden. Wichtig (Klasse I oder II) oder kritisch ist ein Produkt nur, wenn seine Kernfunktion in Anhang III oder IV des CRA steht, etwa bei Firewalls, Betriebssystemen oder Hardware-Sicherheitsmodulen. Baut ein Maschinenbauer einen solchen Switch oder ein solches Betriebssystem ein, wird die Maschine dadurch nicht selbst zum wichtigen Produkt (Art. 7 Abs. 1 CRA).

Was genau unter die Kategorien fällt, beschreibt die Durchführungsverordnung (EU) 2025/2392. Für Klasse I hat die Sache einen Haken. Selbst bewerten darf nur, wer harmonisierte Normen vollständig anwendet, und keine der CRA-Normen aus dem Normungsauftrag M/606 ist im Oktober 2026 im Amtsblatt zitiert. Die ersten horizontalen Normen, EN 40000-1-1 und -1-2, haben die Abstimmung hinter sich, die für die Praxis wichtigeren Teile zur Schwachstellenbehandlung und zu den Sicherheitsanforderungen stecken noch im Entwurf. Gleichzeitig ist EU-weit noch keine benannte Stelle für den CRA notifiziert. Wer heute ein Klasse-I-Produkt plant, rechnet deshalb vorsorglich mit einer Prüfstelle und mit Wartezeit.

Kategorie / 01

Standardprodukte

Alles, was weder in Anhang III noch in Anhang IV steht. Dazu gehören in aller Regel SPS-Programme, HMI-Anwendungen und die meisten Maschinensteuerungen.

Konformitätsbewertung

Der Hersteller bewertet selbst (interne Kontrolle, Modul A).

Beispiele
  • · SPS- und Steuerungssoftware
  • · HMI-Anwendungen
  • · Condition Monitoring
  • · Edge-Anwendungen
Kategorie / 02

Wichtig, Klasse I

Produkte, deren Kernfunktion eine Sicherheits- oder Netzfunktion ist (Anhang III Teil I).

Konformitätsbewertung

Selbstbewertung nur, wenn harmonisierte Normen, gemeinsame Spezifikationen oder ein Zertifizierungsschema vollständig angewendet werden. Sonst prüft eine benannte Stelle (Modul B+C oder H).

Beispiele
  • · Betriebssysteme, auch Echtzeit-Betriebssysteme
  • · Router und verwaltete Switches
  • · VPN-Produkte
  • · Mikrocontroller mit Sicherheitsfunktionen
Kategorie / 03

Wichtig, Klasse II

Produkte mit höherem Risiko, deren Ausfall viele andere Systeme mitreißt (Anhang III Teil II).

Konformitätsbewertung

Immer mit benannter Stelle (Modul B+C oder H) oder mit einem Zertifizierungsschema mindestens der Stufe „mittel“.

Beispiele
  • · Firewalls, auch industrielle
  • · Systeme zur Angriffserkennung und -abwehr (IDS/IPS)
  • · Hypervisoren und Container-Runtimes
  • · Manipulationssichere Mikrocontroller
Kategorie / 04

Kritische Produkte

Die kurze Liste aus Anhang IV. Im Maschinenbau tauchen diese Produkte meist als zugekaufte Komponente auf.

Konformitätsbewertung

Europäische Cybersicherheitszertifizierung, sobald ein delegierter Rechtsakt sie vorschreibt. Bis dahin gilt dasselbe Verfahren wie für Klasse II.

Beispiele
  • · Hardware-Sicherheitsmodule (HSM)
  • · Smart-Meter-Gateways
  • · Chipkarten
  • · Secure Elements
// 08Sechs Herstellerpflichten

Welche Pflichten haben Hersteller nach dem CRA?

Sechs Pflichten aus Art. 13, Art. 14 und Anhang I tragen den CRA: Security by Design, eine SBOM, Schwachstellenbehandlung, Sicherheitsupdates über den Unterstützungszeitraum, die Meldepflicht und eine vollständige technische Dokumentation. Wie Sie die SBOM-Pflicht technisch umsetzen, zeigt unsere Anleitung zum SBOM erstellen.

  • /01

    Security by Design

    Gewicht: Hoch

    Sicherheit gehört in die Architektur, bevor die erste Zeile Code entsteht. Nachträglich aufgesetzt wird sie teuer und bleibt lückenhaft.

    Risikobewertung je Produkt, Threat Modeling, Secure Coding Guidelines, sichere Standardkonfiguration bei Auslieferung.

  • /02

    Software Bill of Materials (SBOM)

    Gewicht: Hoch

    Der Hersteller muss wissen, welche Komponenten in seinem Produkt stecken, eigene wie zugekaufte und Open Source. Mindestens die obersten Abhängigkeiten gehören maschinenlesbar in die technische Dokumentation.

    SBOM bei jedem Build erzeugen, in CycloneDX oder SPDX, und je Auslieferungsstand aufbewahren.

  • /03

    Schwachstellen­behandlung

    Gewicht: Hoch

    Bekannte Schwachstellen werden erkannt, bewertet und ohne Verzögerung behoben, über den ganzen Unterstützungszeitraum.

    Laufender Abgleich gegen Schwachstellendatenbanken, eine veröffentlichte Adresse für Meldungen von außen, eine Richtlinie zur koordinierten Offenlegung.

  • /04

    Sicherheitsupdates und Unterstützungs­zeitraum

    Gewicht: Hoch

    Der Unterstützungszeitraum beträgt mindestens fünf Jahre, bei kürzerer erwarteter Nutzungsdauer entsprechend weniger. Sein Ende steht beim Kauf mit Monat und Jahr fest.

    Jedes Sicherheitsupdate bleibt nach Veröffentlichung mindestens zehn Jahre verfügbar (Art. 13 Abs. 9). Bei Maschinen mit 15 bis 20 Jahren Laufzeit heißt das, Branches je Auslieferungsstand zu pflegen und Builds so zu bauen, dass sie sich Jahre später noch reproduzieren lassen.

  • /05

    Meldepflicht (seit 11. Sep. 2026)

    Gewicht: Kritisch

    Aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle gehen gestuft an CSIRT und ENISA, nach 24 Stunden, 72 Stunden und mit einem Abschlussbericht.

    Gilt für alle Produkte im Anwendungsbereich, auch für solche, die vor Dezember 2027 ausgeliefert wurden (Art. 69 Abs. 3). Betroffene Nutzer müssen ebenfalls informiert werden.

  • /06

    Technische Dokumentation

    Gewicht: Mittel

    Risikobewertung, Sicherheitsarchitektur, Testnachweise und Konformitätserklärung liegen vollständig vor.

    Aufbewahrung mindestens zehn Jahre oder für den Unterstützungszeitraum, je nachdem, was länger dauert.

// 09Fünf Hürden im Maschinenbau

Warum ist der CRA an der Maschine schwerer umzusetzen?

Weil eine Maschine zwanzig Jahre in der Halle steht, während ein Softwarehaus alle paar Wochen neu ausliefert. Der CRA verlangt Nachweise über die ganze Zeit, und die Software einer Maschine stammt von vielen Zulieferern.

Wie das in der Praxis beginnt, haben wir mehrfach erlebt. Ein OEM verlangt im Liefervertrag eine SBOM für eine Anlage von 2019. Die Zusammensetzung des HMI-Images lässt sich nur noch aus einem alten Build-Rechner und den Mails eines Lieferanten rekonstruieren, und reproduzieren kann den Build seit drei Jahren niemand mehr.

Alter beiger Tower-PC mit handgeschriebenem Zettel „Build HMI, nicht ausschalten“ neben einem geöffneten HMI-Panel, einer abgehakten Komponentenliste und einem USB-Stick, im Hintergrund ein Schaltschrank mit SPS-BaugruppenAI
Der Build-Rechner unter der Werkbank: Wissen, das an genau einer Maschine hängt
  • /01

    Lange Laufzeiten

    Eine Werkzeugmaschine läuft 15 bis 30 Jahre. Ein Unterstützungszeitraum, der die erwartete Nutzungsdauer widerspiegeln soll, reicht damit weit über jedes einzelne Projekt hinaus.

    Was daraus folgt

    Sie brauchen eine Update-Strategie, die Personalwechsel und Toolchain-Wechsel überlebt.

  • /02

    Alter Code in neuen Maschinen

    Steuerungscode wandert oft über Generationen von Maschine zu Maschine. Maßgeblich ist das Inverkehrbringen, nicht das Alter des Codes.

    Was daraus folgt

    Übernommene Bausteine gehören genauso in die SBOM und in den Schwachstellenabgleich wie neuer Code.

  • /03

    Viele Zulieferer, eine Verantwortung

    In einer Maschine steckt Software von SPS-Hersteller, Antriebstechnik, HMI-Anbieter und Sensorik. Gegenüber der Behörde haften Sie als Hersteller.

    Was daraus folgt

    SBOMs und Schwachstelleninformationen fordern Sie vertraglich ein und führen sie in Ihrer Dokumentation zusammen.

  • /04

    Feldbusse ohne Security

    Modbus, PROFINET und EtherCAT sind für Echtzeit gebaut, nicht für Angreifer. Authentifizierung fehlt meist ganz.

    Was daraus folgt

    Ausgleichende Maßnahmen wie Segmentierung, Gateways und Monitoring müssen dokumentiert und begründet sein.

  • /05

    Safety-Denken ohne Security-Rolle

    Konstruktionsteams denken in Maschinensicherheit. Cybersecurity lag bisher bei der IT, und die kennt die Steuerung nicht.

    Was daraus folgt

    Eine benannte Person für Produktsicherheit und Security Champions in den Teams sind der Anfang.

// 10Fünf erste Schritte

Was können Sie noch diese Woche tun?

Fünf Maßnahmen, die ohne Projektantrag auskommen. Die ersten beiden betreffen die Meldepflicht, die schon gilt.

Bei der dritten sehen Sie das Ergebnis nach dem ersten Build mit Syft. Dann liegt eine CycloneDX-Datei vor, und die Kundenfrage nach den Komponenten Ihres HMI ist in Minuten beantwortet statt nach zwei Tagen Suche.

  • /01

    Meldeweg vorbereiten

    Aufwand: Niedrig

    Legen Sie fest, wer als primärer Vertreter auf der ENISA Single Reporting Platform für Ihr Haus meldet und wer ihn vertritt. Beide brauchen einen EU-Login-Zugang. Halten Sie eine englische Vorlage für die 24-Stunden-Frühwarnung bereit, mit Hersteller, Produkt, Softwarestand und betroffenen Ländern.

  • /02

    Zuständigkeit festlegen

    Aufwand: Niedrig

    Eine Person verantwortet die Produktsicherheit und entscheidet, ob ein Fall meldepflichtig ist. Das muss keine Vollzeitstelle sein, aber jeder im Haus muss den Namen kennen, auch am Freitagnachmittag.

  • /03

    SBOM im Build erzeugen

    Aufwand: Niedrig

    Syft oder die CycloneDX-Werkzeuge laufen als zusätzlicher Pipeline-Schritt. Danach entsteht bei jedem Build eine Komponentenliste, ohne dass jemand daran denken muss. Der Einbau dauert wenige Stunden.

  • /04

    Abhängigkeiten scannen

    Aufwand: Niedrig

    Trivy, Grype oder OWASP Dependency-Check gleichen die SBOM gegen bekannte Schwachstellen ab. Beim ersten Lauf sehen Sie, wo Ihre Produkte heute stehen.

  • /05

    Zulieferer anschreiben

    Aufwand: Mittel

    Fordern Sie SBOMs und Schwachstelleninformationen bei Ihren Softwarelieferanten an. Die Antworten brauchen Wochen, manchmal Monate. Deshalb steht dieser Punkt auf der Liste für diese Woche.

// 11Fahrplan: 12 Wochen

Wie sieht ein realistischer Plan für zwölf Wochen aus?

In zwölf Wochen kommen Sie von der Bestandsaufnahme zu Prozessen, die ihre Nachweise selbst erzeugen. Die Konformitätsbewertung folgt danach und braucht bei Klasse I und II zusätzlich Vorlauf für die benannte Stelle.

Phase 01

Bestands­aufnahme

Woche 1–2
  • → Portfolio nach Produktklassen einordnen
  • → Software-Komponenten je Produkt erfassen
  • → Zulieferer-Abhängigkeiten auflisten
  • → Gap-Analyse gegen Anhang I CRA
  • → Zuständigkeit für Produktsicherheit festlegen
Phase 02

Grundlagen bauen

Woche 3–6
  • → SBOM-Erzeugung in den Build einbauen
  • → Schwachstellen-Scans für alle Abhängigkeiten
  • → Secure Coding Guidelines festlegen
  • → Meldeprozess testen, mit Probelauf
  • → Anforderungen an Zulieferer verschicken
Phase 03

Prozesse verankern

Woche 7–12
  • → Security-Prüfungen als Gates in CI/CD
  • → Signierte Update-Strecke ins Feld
  • → Unterstützungszeitraum je Produkt festlegen
  • → Technische Dokumentation aufbauen
  • → Konformitätsbewertung vorbereiten
Phase 04

Betreiben und nachweisen

Laufend
  • → Schwachstellen laufend überwachen
  • → Penetrationstests und Audits
  • → Schulungen für die Entwicklung
  • → Zulieferer-SBOMs aktuell halten
  • → Konformitätserklärung und CE-Kennzeichnung
// 12Industrial DevOps und CRA

Wie hilft eine CI/CD-Pipeline bei der CRA-Konformität?

Sie erzeugt die Nachweise, die der CRA verlangt, bei jedem Build mit: SBOM, Schwachstellen-Scan, signierte Artefakte und eine lückenlose Versionshistorie je Auslieferungsstand. Wer schon mit Pipelines arbeitet, hat damit gut die Hälfte des Weges hinter sich.

Versionierung in Git, automatisierte Tests, reproduzierbare Builds sind DevOps-Gewohnheiten, und es sind CRA-Anforderungen. Der Unterschied liegt im Nachweis. Der CRA will sehen, dass es sie gibt, für jeden ausgelieferten Stand und über Jahre.

Wer schon mit CI/CD-Pipelines arbeitet, hängt SBOM-Erzeugung, Schwachstellen-Scans und Signatur als weitere Schritte an. Wer bei null startet, baut sie gleich mit ein. Wie ein vollständiges DevSecOps-Konzept für die Industrie aussieht und wie es zur IEC 62443 passt, beschreiben wir dort im Detail.

Anforderung → DevOps-Praxis
01
Security by Design
→ Threat Modeling plus Security-Gates in der Pipeline
02
SBOM
→ Automatisch bei jedem Build (Syft, CycloneDX)
03
Schwachstellenbehandlung
→ Laufende Scans in CI/CD (Trivy, Grype)
04
Sicherheitsupdates
→ Release-Pipelines mit Signatur und Rollback
05
Meldepflicht
→ Monitoring, Alerting und ein geübtes Runbook
06
Dokumentation
→ Docs-as-Code und erzeugte Compliance-Berichte
07
Eingriffsprotokoll (MaschVO 1.2.1)
→ Versionierte Artefakte mit Deploy-Log je Seriennummer

Wer diese Schritte nicht aus einzelnen Plugins zusammensetzen will, kann sich IndustrialFlow ansehen, unsere CI/CD-Plattform für die Industrie. Sie erzeugt pro Build signierte CycloneDX- und SPDX-SBOMs, scannt Container mit Trivy, verwaltet VEX-Annotationen und exportiert daraus Schwachstellenberichte. Bestehende Jenkins-Pipelines laufen weiter. Wem es allein um die Stückliste geht, für den entsteht derselbe Schritt einzeln als PLC SBOM Builder, der die Komponenten einer ganzen Maschine erfasst, auch über Steuerungen mehrerer Hersteller hinweg.

// 13Nächster Schritt

Wo steht Ihr Portfolio heute?

Die meisten Hersteller, mit denen wir sprechen, haben eine Handvoll Produktlinien, drei Generationen Steuerungscode und genau eine Person, die weiß, was in welchem HMI-Image steckt. Mit dieser Ausgangslage lässt sich gut arbeiten, solange man sie kennt, bevor der erste Meldefall eintritt.

Ob sich der Umbau für Ihr Haus lohnt und ab welcher Größe wir abraten, steht in Für welche Hersteller wir arbeiten.

// 14Häufige Fragen

Häufige Fragen zum CRA im Maschinenbau

Was ist der EU Cyber Resilience Act (CRA)?

Der Cyber Resilience Act, Verordnung (EU) 2024/2847, ist eine EU-Verordnung mit verbindlichen Cybersicherheitsanforderungen für Produkte mit digitalen Elementen, von der Smartwatch bis zur Industriesteuerung. Hersteller müssen ihre Produkte sicher entwickeln, ihre Komponenten in einer SBOM erfassen, Schwachstellen behandeln und über den Unterstützungszeitraum Sicherheitsupdates liefern.

Ist der Cyber Resilience Act schon aktiv?

Ja, teilweise. Der CRA ist seit dem 10. Dezember 2024 in Kraft, und seit dem 11. September 2026 gilt die Meldepflicht für aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle. Die übrigen Anforderungen, darunter die Voraussetzung für die CE-Kennzeichnung, gelten ab dem 11. Dezember 2027.

Ist der Cyber Resilience Act verpflichtend?

Ja. Als EU-Verordnung gilt der CRA unmittelbar in allen Mitgliedstaaten, ohne nationales Umsetzungsgesetz. Verpflichtet sind Hersteller, Importeure und Händler, die ein Produkt mit digitalen Elementen in der EU bereitstellen, unabhängig vom Firmensitz. Eine generelle Ausnahme für kleine und mittlere Unternehmen gibt es nicht; Kleinst- und Kleinunternehmen bekommen lediglich keine Geldbuße, wenn sie die 24-Stunden-Frühwarnung verpassen.

Ab wann gilt der CRA für Maschinenbauer?

In drei Stufen. Seit dem 11. Juni 2026 gelten die Regeln für die Notifizierung von Konformitätsbewertungsstellen, seit dem 11. September 2026 die Meldepflicht, und ab dem 11. Dezember 2027 müssen neu in Verkehr gebrachte Produkte alle Anforderungen erfüllen. Für die Maschine als Ganzes kommt am 20. Januar 2027 die Maschinenverordnung (EU) 2023/1230 hinzu.

Bis wann muss der Cyber Resilience Act umgesetzt sein?

Bis zum 11. Dezember 2027. Die Übergangsfrist beträgt 36 Monate ab Inkrafttreten am 10. Dezember 2024; der CRA war am 20. November 2024 im Amtsblatt erschienen. Die Meldepflicht musste bereits zum 11. September 2026 stehen, und zwar auch für Produkte, die schon ausgeliefert sind.

Wann muss ein Cyberangriff nach dem CRA gemeldet werden?

Innerhalb von 24 Stunden als Frühwarnung, sobald der Hersteller von einem schwerwiegenden Sicherheitsvorfall mit Auswirkung auf sein Produkt oder von einer aktiv ausgenutzten Schwachstelle erfährt. Nach 72 Stunden folgt die eigentliche Meldung, danach ein Abschlussbericht: bei Schwachstellen spätestens 14 Tage nach Verfügbarkeit einer Korrektur, bei Vorfällen innerhalb eines Monats. Gemeldet wird auf Englisch über die Single Reporting Platform der ENISA, gleichzeitig an das koordinierende CSIRT, in Deutschland das CERT-Bund im BSI.

Muss ich jeden Hackerangriff auf eine Maschine melden?

Nein. Meldepflichtig sind nach Art. 14 CRA aktiv ausgenutzte Schwachstellen in Ihrem Produkt und schwerwiegende Sicherheitsvorfälle. Schwerwiegend ist ein Vorfall, wenn er die Fähigkeit des Produkts beeinträchtigt oder beeinträchtigen kann, sensible oder wichtige Daten oder Funktionen zu schützen, oder wenn er Schadcode in das Produkt oder ins Netz des Nutzers gebracht hat oder bringen kann. Ein Portscan auf den Fernwartungszugang fällt nicht darunter, eine Manipulation der Steuerung über diesen Zugang in aller Regel schon.

Muss ich mich vorab auf der ENISA-Meldeplattform registrieren?

Nein. Laut BSI besteht vor dem ersten Meldefall keine Registrierungspflicht, Registrierung und Meldung lassen sich im Bedarfsfall in wenigen Minuten erledigen. Vorher festlegen sollten Sie aber, wer als primärer Vertreter (Primary Assigned Representative) für Ihr Unternehmen meldet und wer ihn vertritt, denn Stellvertreter werden über eine Einladung des primären Vertreters angelegt.

Gilt der CRA auch für alte Maschinen, die schon beim Kunden laufen?

Bei der Meldepflicht ja, bei den übrigen Anforderungen nur nach einer wesentlichen Änderung. Produkte, die vor dem 11. Dezember 2027 in Verkehr gebracht wurden, müssen die CRA-Anforderungen nur erfüllen, wenn sie danach wesentlich geändert werden (Art. 69 Abs. 2). Die Meldepflicht aus Art. 14 gilt nach Art. 69 Abs. 3 dagegen seit dem 11. September 2026 für alle Produkte im Anwendungsbereich, also auch für Maschinen, die schon beim Kunden laufen. Ein Sicherheitsupdate, das den Zweck der Maschine nicht verändert, ist nach Erwägungsgrund 39 keine wesentliche Änderung. Was als wesentliche Änderung zählt, erläutern die Leitlinien der EU-Kommission vom 27. Juli 2026.

Für welche Geräte und Produkte gilt der Cyber Resilience Act?

Für alle Produkte mit digitalen Elementen, die eine direkte oder indirekte Datenverbindung zu einem Gerät oder Netz haben und in der EU in Verkehr gebracht werden. Im Maschinenbau sind das SPS-Steuerungen, HMIs, Edge-Gateways, Industrie-PCs, Fernwartungszugänge und mitgelieferte Software.

Gibt es Ausnahmen vom Cyber Resilience Act?

Ja, für einige Produktgruppen. Ausgenommen sind Produkte, für die eigene EU-Regeln gelten, etwa Medizinprodukte und In-vitro-Diagnostika, typgenehmigte Kraftfahrzeuge, Luftfahrt und Schiffsausrüstung, außerdem Produkte ausschließlich für die nationale Sicherheit oder Verteidigung und nicht-kommerzielle Open-Source-Software. Für den Maschinenbau wichtig: Ersatzteile, die identische Bauteile nach denselben Spezifikationen ersetzen, fallen ebenfalls nicht unter den CRA. Maschinen selbst sind nicht ausgenommen.

Welche Produkte sind laut CRA wichtig oder kritisch?

Wichtig ist ein Produkt, dessen Kernfunktion in Anhang III steht, kritisch eines aus Anhang IV. Zur Klasse I gehören zum Beispiel Betriebssysteme einschließlich Echtzeit-Betriebssysteme, Router und verwaltete Switches, VPN-Produkte und Mikrocontroller mit Sicherheitsfunktionen. Zur Klasse II gehören Firewalls, Systeme zur Angriffserkennung und -abwehr, Hypervisoren und manipulationssichere Mikrocontroller. Kritisch sind Hardwaregeräte mit Sicherheitsboxen wie Hardware-Sicherheitsmodule, Smart-Meter-Gateways sowie Chipkarten und Secure Elements.

In welche Produktklasse fallen typische Maschinensteuerungen?

In aller Regel sind sie Standardprodukte, die der Hersteller selbst bewerten darf. SPS und HMI haben keine eigene Kategorie in Anhang III oder IV. Entscheidend ist die Kernfunktion: Baut ein Maschinenbauer einen Klasse-I-Switch oder ein Echtzeit-Betriebssystem ein, wird die Maschine dadurch nicht selbst zum wichtigen Produkt (Art. 7 Abs. 1 CRA). Die verbindliche Einstufung bleibt eine Einzelfallprüfung.

Bin ich für zugekaufte Steuerungen, etwa eine Siemens-SPS, nach dem CRA verantwortlich?

Für die Maschine ja. Der Hersteller der SPS trägt für sein Produkt eigene CRA-Pflichten, Sie als Maschinenhersteller müssen nach Art. 13 Abs. 5 bei zugekauften Komponenten die gebotene Sorgfalt walten lassen, damit sie die Cybersicherheit der Maschine nicht beeinträchtigen. Finden Sie eine Schwachstelle in einer Komponente, melden Sie sie deren Hersteller (Art. 13 Abs. 6). Eine CRA-konforme Komponente macht die Maschine noch nicht konform.

Ist der CRA Teil der Maschinenverordnung?

Nein. Cyber Resilience Act und Maschinenverordnung sind zwei eigenständige EU-Verordnungen, die bei einer vernetzten Maschine nebeneinander gelten. Die Maschinenverordnung (EU) 2023/1230 gilt ab dem 20. Januar 2027 und verlangt für die Maschine als Ganzes, dass Steuerungen und sicherheitsrelevante Software gegen Manipulation geschützt sind. Der CRA regelt die digitalen Elemente über ihren Lebenszyklus. Eine automatische Vermutung, dass die eine Konformität die andere abdeckt, gibt es nicht; für die CE-Kennzeichnung brauchen Sie beide.

Braucht eine vernetzte Maschine zwei EU-Konformitätserklärungen?

Nein. Unterliegt ein Produkt mehreren Rechtsakten der EU, die jeweils eine EU-Konformitätserklärung verlangen, wird eine einzige Erklärung für alle ausgestellt, in der die Rechtsakte mit ihrer Fundstelle im Amtsblatt stehen (Art. 28 Abs. 3 CRA). Die Konformitätsverfahren nach CRA und Maschinenverordnung laufen trotzdem getrennt.

Wie lange gilt die Maschinenrichtlinie noch, und was ist neu in der Maschinenverordnung?

Bis zum 19. Januar 2027 gilt die Maschinenrichtlinie 2006/42/EG, ab dem 20. Januar 2027 die Maschinenverordnung (EU) 2023/1230. Neu sind vor allem Anforderungen an vernetzte und lernende Systeme: Anhang III Nr. 1.1.9 verlangt Schutz gegen Korrumpierung, Nr. 1.2.1 Steuerungen, die böswillige Eingriffe aushalten und Eingriffe sowie Versionen der Sicherheitssoftware bis zu fünf Jahre protokollieren. Dazu kommen digitale Betriebsanleitungen und strengere Verfahren für bestimmte Maschinenkategorien.

Ab wann gilt der AI Act für Maschinen mit KI?

Für KI-Systeme, die als Sicherheitsbauteil in einer Maschine arbeiten, ab dem 2. August 2028. Der KI-Omnibus, Verordnung (EU) 2026/1744, hat diesen Termin vom 2. August 2027 verschoben und die Maschinenverordnung im AI Act nach Anhang I Abschnitt B verlegt. Die Anforderungen an solche KI kommen damit über delegierte Rechtsakte zur Maschinenverordnung, die ab dem 2. August 2028 gelten.

Muss ich die Cybersecurity-Anforderungen von CRA und AI Act doppelt erfüllen?

Nein, Artikel 12 des CRA verhindert das für Hochrisiko-KI-Systeme. Erfüllt ein solches Produkt mit digitalen Elementen die Anforderungen aus Anhang I des CRA, gilt die Cybersicherheitsanforderung aus Artikel 15 der KI-Verordnung als erfüllt. Wie das für KI in Maschinen nach dem KI-Omnibus konkret greift, legen die noch ausstehenden delegierten Rechtsakte zur Maschinenverordnung fest.

Was ändert der Digital Omnibus am Cyber Resilience Act?

Bisher nichts. Der beschlossene KI-Omnibus, Verordnung (EU) 2026/1744, ändert den AI Act und die Maschinenverordnung, nicht den CRA. Das breitere Digital-Omnibus-Paket COM(2025) 837 soll unter anderem erreichen, dass eine CRA-Meldung eines schwerwiegenden Vorfalls zugleich als NIS2-Meldung gilt. Es war im Oktober 2026 noch nicht beschlossen, bis dahin melden Sie einen solchen Vorfall bei Bedarf doppelt.

Was ist eine SBOM und warum wird sie Pflicht?

Eine Software Bill of Materials (SBOM) ist eine maschinenlesbare Liste der Software-Komponenten in einem Produkt, eigene wie zugekaufte und Open Source. Der CRA verlangt sie mindestens für die obersten Abhängigkeiten als Teil der technischen Dokumentation, damit Hersteller bekannte Schwachstellen schnell finden. Wie Sie eine SBOM im Build erzeugen, beschreibt unsere Anleitung zum SBOM erstellen.

Wie lange muss ich nach dem CRA Sicherheitsupdates bereitstellen?

Mindestens fünf Jahre ab dem Inverkehrbringen, es sei denn, die erwartete Nutzungsdauer ist kürzer. Der Zeitraum soll die voraussichtliche Nutzungsdauer widerspiegeln, sein Ende muss beim Kauf mit Monat und Jahr angegeben sein. Jedes veröffentlichte Sicherheitsupdate bleibt mindestens zehn Jahre oder für den restlichen Unterstützungszeitraum verfügbar. Bei Maschinen mit 15 bis 20 Jahren Laufzeit heißt das: reproduzierbare Builds und gepflegte Branches je Auslieferungsstand.

Welche Strafen drohen bei Nichteinhaltung des CRA?

Bei Verstößen gegen die grundlegenden Cybersicherheitsanforderungen oder die Herstellerpflichten aus Art. 13 und 14 bis zu 15 Millionen Euro oder 2,5 Prozent des weltweiten Jahresumsatzes, je nachdem, welcher Betrag höher ist. Andere Pflichtverstöße kosten bis zu 10 Millionen Euro oder 2 Prozent, falsche Angaben gegenüber Behörden bis zu 5 Millionen Euro oder 1 Prozent. Zusätzlich können Marktüberwachungsbehörden Produkte vom Markt nehmen lassen.

Wie hängen CRA und IEC 62443 zusammen?

Die IEC 62443 ist die etablierte Normenreihe für industrielle Cybersicherheit, und die in Arbeit befindlichen produktspezifischen CRA-Normen orientieren sich an ihr. Harmonisierte CRA-Normen mit Vermutungswirkung waren im Oktober 2026 noch nicht im Amtsblatt veröffentlicht, auch die Ergänzungen der IEC 62443-4-1 und 4-2 für den CRA sind noch im Entwurf. Wer die IEC 62443-4-1 für den sicheren Entwicklungsprozess bereits umsetzt, hat einen großen Teil der CRA-Prozessanforderungen trotzdem schon abgedeckt.

Was ist der Unterschied zwischen CRA und NIS2?

Der CRA regelt Produkte, NIS2 regelt Unternehmen. Der CRA verpflichtet Hersteller, Produkte mit digitalen Elementen über den Lebenszyklus abzusichern, NIS2 verpflichtet Einrichtungen zu Risikomanagement, Meldewesen und Lieferkettensicherheit. Ein Maschinenbauer kann beides erfüllen müssen: den CRA als Hersteller und NIS2 als wichtige Einrichtung, in Deutschland ab 50 Beschäftigten oder mehr als 10 Millionen Euro Umsatz und Bilanzsumme.

Gilt der CRA auch für Open-Source-Software?

Nicht-kommerzielle Open-Source-Software ist ausgenommen. Steckt Open Source in einem kommerziellen Produkt, etwa ein Linux im HMI oder eine Edge-Runtime, trägt der Hersteller des Produkts die volle Verantwortung: Die Komponenten gehören in die SBOM und in den Schwachstellenabgleich. Für Stiftungen und ähnliche Organisationen gilt ein leichteres Regime als Open-Source-Steward.

Wer überwacht den CRA in Deutschland?

Das BSI. Mit dem CRA-Durchführungsgesetz, das der Bundestag im Oktober 2026 beschlossen hat, wird es Marktüberwachungsbehörde, Bußgeldbehörde und notifizierende Behörde für Prüfstellen. Es kann Produkte prüfen, Nachbesserungen verlangen und Produkte vom Markt nehmen lassen. Für die Meldepflicht ist das CERT-Bund im BSI schon seit dem 11. September 2026 das koordinierende CSIRT.

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 prüfen, dass der Hersteller die Konformitätsbewertung durchgeführt hat. Händler kontrollieren CE-Kennzeichnung und Unterlagen. Wer ein Produkt unter eigenem Namen vertreibt oder wesentlich verändert, übernimmt die Herstellerpflichten.

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

Eine CI/CD-Pipeline erzeugt die Nachweise, die der CRA verlangt, bei jedem Build mit: SBOM, Schwachstellen-Scan, signierte Artefakte und eine lückenlose Versionshistorie. Versionskontrolle, automatisierte Tests und reproduzierbare Builds sind DevOps-Praxis und zugleich die Grundlage, um Sicherheitsupdates über viele Jahre ausliefern zu können.

// Ihr nächster Schritt1 Klick, anonym

Wie geht es bei Ihnen mit dem Cyber Resilience Act weiter?

Sagen Sie uns mit einem Klick, wie es bei Ihnen weitergeht. Passend dazu bekommen Sie direkt einen konkreten nächsten Schritt — ganz ohne Formular.

// Nächster Schritt

Erstgespräch.
90 Tage zum Ergebnis.

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

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