Cyber Resilience
Act im
Maschinenbau.
Seit dem 11. September 2026 müssen Hersteller ausgenutzte Schwachstellen binnen 24 Stunden melden, auch für Maschinen, die längst beim Kunden laufen. Im Januar 2027 folgt die Maschinenverordnung, im Dezember 2027 hängt die CE-Kennzeichnung an der vollen CRA-Konformität. Hier stehen Fristen, Produktklassen und Pflichten für Maschinenbauer in der Reihenfolge, in der Sie sie brauchen.
AI
Andreas Schönfeld
Geschäftsführer & DevOps-Berater, Comquent GmbH
18+ Jahre Erfahrung in DevOps, CI/CD und Industrial Automation
Stand: 16. September 2026 · CRA-Meldepflicht aktiv seit 11. Sep. 2026 · Maschinenverordnung ab 20. Jan. 2027 · Volle CRA-Konformität ab 11. Dez. 2027 · KI-Sicherheitsbauteile ab 2. Aug. 2028
Die Meldepflicht läuft. Seit dem 11. September nimmt die Single Reporting Platform der ENISA Meldungen an. In Deutschland ist laut BSI das CERT-Bund das koordinierende CSIRT. Registrieren müssen Sie sich erst im Meldefall, das dauert nach Angabe des BSI wenige Minuten. Wer dann für Ihr Haus meldet und was in die Meldung gehört, sollte vorher feststehen.
KI in Maschinen: neuer Stichtag. Der KI-Omnibus, Verordnung (EU) 2026/1744, gilt seit dem 27. Juli 2026. Er verschiebt die Pflichten für KI-Sicherheitsbauteile vom 2. August 2027 auf den 2. August 2028 und hängt sie an die Maschinenverordnung. Die Kommentierungsphase des BSI-Prüfkatalogs A5 für KI-Systeme endete am 31. August; was er prüft, steht in unserer Analyse zum BSI A5 Prüfkatalog.
Der EU Cyber Resilience Act (CRA, Verordnung (EU) 2024/2847) verpflichtet Hersteller von Produkten mit digitalen Elementen zu Cybersicherheit über den gesamten Lebenszyklus. Das betrifft auch SPS-Steuerungen, HMIs und Edge-Gateways. Der CRA ist seit dem 10. Dezember 2024 in Kraft und gilt in Stufen: Seit dem 11. September 2026 müssen Hersteller aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle binnen 24 Stunden melden, ab dem 11. Dezember 2027 gelten alle Anforderungen. Für vernetzte Maschinen kommt ab dem 20. Januar 2027 die Maschinenverordnung (EU) 2023/1230 hinzu. Beide Konformitäten sind Voraussetzung für die CE-Kennzeichnung.
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.
Was ändert sich
für den
Maschinenbau?
Maschinenbauer denken in Mechanik, Antrieben und Steuerungslogik. Cybersecurity lag bisher bei der IT, wenn sie überhaupt jemand auf dem Tisch hatte. So treffen wir es 2026 in den meisten Häusern an, mit denen wir sprechen, und eine budgetierte Stelle dafür hat kaum eines.
Der CRA macht aus dieser Nebensache eine Produkteigenschaft, die Sie nachweisen müssen, so wie die Maschinensicherheit. Das betrifft jede Maschine mit Software. Welche Hürden dabei an der SPS entstehen, zeigt unser Anwendungsfall Maschinenbau und SPS.
Quelle: Verordnung (EU) 2024/2847, Art. 13 Abs. 8 und 9, Art. 14, Art. 64 Abs. 2
Ohne CE.
Kein EU-Markt.
Ab dem 11. Dezember 2027 bekommt ein Produkt mit digitalen Elementen ohne CRA-Konformität keine CE-Kennzeichnung mehr. Ohne CE-Kennzeichnung darf es in der EU nicht in Verkehr gebracht werden.
- → Bußgelder bis 15 Mio. Euro oder 2,5 % des weltweiten Jahresumsatzes
- → Marktüberwachungsbehörden können Rücknahme oder Rückruf anordnen
- → Seit 11. Sep. 2026: Frühwarnung binnen 24 h, für Schwachstellen und für Vorfälle
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ätsbewertungsstellen, seit dem 11. September 2026 die Meldepflicht. Für Maschinenbauer kommen zwei Termine dazu: die Maschinenverordnung 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.
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.
Regeln für benannte Stellen
Kapitel IV gilt: Die Mitgliedstaaten können Konformitätsbewertungsstellen für den CRA notifizieren. Wer Produkte der Klasse II baut, sucht sich jetzt eine Prüfstelle, auch wenn die Liste noch kurz ist.
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.
Maschinenverordnung 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.
Volle CRA-Konformität
Neu in Verkehr gebrachte Produkte mit digitalen Elementen brauchen die CRA-Konformität, sonst gibt es keine CE-Kennzeichnung. Bußgelder bis 15 Mio. Euro oder 2,5 Prozent des weltweiten Jahresumsatzes.
KI-Sicherheitsbauteile
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.
Was müssen Sie
wann 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 gleichzeitig an das koordinierende CSIRT, in Deutschland das CERT-Bund im BSI, und an die ENISA. Der Weg dorthin ist die Single Reporting Platform, gemeldet wird auf Englisch.
| Stufe | Aktiv ausgenutzte Schwachstelle | Schwerwiegender Vorfall |
|---|---|---|
| Frühwarnung | Innerhalb von 24 Stunden, mit den Mitgliedstaaten, in denen das Produkt bereitgestellt wurde | Innerhalb von 24 Stunden, mit dem Hinweis, ob ein rechtswidriger oder böswilliger Eingriff vermutet wird |
| Meldung | Innerhalb von 72 Stunden, mit Angaben zu Produkt, Art der Schwachstelle und ergriffenen Gegenmaßnahmen | Innerhalb von 72 Stunden, mit einer ersten Bewertung des Vorfalls |
| Abschlussbericht | Spätestens 14 Tage, nachdem eine Korrektur oder Risikominderung verfügbar ist | Innerhalb eines Monats nach der 72-Stunden-Meldung |
Quelle: Art. 14 Abs. 2 und 4 CRA · EU-Kommission, CRA Reporting
AIDie 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.
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.
Welche Klasse hat
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 die CRA-Normen aus dem Normungsauftrag M/606 sind nach unserem Stand vom September 2026 noch nicht im Amtsblatt zitiert. Wer heute ein Klasse-I-Produkt plant, rechnet deshalb vorsorglich mit einer benannten Stelle.
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.
Der Hersteller bewertet selbst (interne Kontrolle, Modul A).
- · SPS- und Steuerungssoftware
- · HMI-Anwendungen
- · Condition Monitoring
- · Edge-Anwendungen
Wichtig, Klasse I
Produkte, deren Kernfunktion eine Sicherheits- oder Netzfunktion ist (Anhang III Teil I).
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).
- · Betriebssysteme, auch Echtzeit-Betriebssysteme
- · Router und verwaltete Switches
- · VPN-Produkte
- · Mikrocontroller mit Sicherheitsfunktionen
Wichtig, Klasse II
Produkte mit höherem Risiko, deren Ausfall viele andere Systeme mitreißt (Anhang III Teil II).
Immer mit benannter Stelle (Modul B+C oder H) oder mit einem Zertifizierungsschema mindestens der Stufe „mittel“.
- · Firewalls, auch industrielle
- · Systeme zur Angriffserkennung und -abwehr (IDS/IPS)
- · Hypervisoren und Container-Runtimes
- · Manipulationssichere Mikrocontroller
Kritische Produkte
Die kurze Liste aus Anhang IV. Im Maschinenbau tauchen diese Produkte meist als zugekaufte Komponente auf.
Europäische Cybersicherheitszertifizierung, sobald ein delegierter Rechtsakt sie vorschreibt. Bis dahin gilt dasselbe Verfahren wie für Klasse II.
- · Hardware-Sicherheitsmodule (HSM)
- · Smart-Meter-Gateways
- · Chipkarten
- · Secure Elements
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?
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. Der CRA regelt die digitalen Elemente und ihre Cybersicherheit über den Lebenszyklus. Die Maschinenverordnung (EU) 2023/1230 regelt die Maschine als Ganzes und verlangt, dass Steuerungen und Sicherheitsfunktionen Manipulation aushalten. Für die CE-Kennzeichnung brauchen Sie beide Konformitäten. Der AI Act kommt hinzu, sobald KI eine Sicherheitsfunktion übernimmt. NIS2 regelt dagegen nicht das Produkt, sondern Ihr Unternehmen als Betreiber.
Cyber Resilience Act (CRA)
Produkte mit digitalen Elementen, also Steuerungen, HMIs, Edge-Gateways und Software. Cybersicherheit über den gesamten Lebenszyklus.
Hersteller, Importeure und Händler
Meldepflicht seit 11. Sep. 2026, volle Konformität ab 11. Dez. 2027
Maschinenverordnung (EU) 2023/1230
Die Maschine als Ganzes. Anhang III Nr. 1.1.9 verlangt Schutz gegen Korrumpierung, Nr. 1.2.1 Steuerungen, die böswillige Eingriffe aushalten und protokollieren.
Maschinenhersteller
Ab 20. Jan. 2027, ersetzt die Maschinenrichtlinie 2006/42/EG
KI-Verordnung / AI Act (2024/1689)
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
Hochrisiko nach Anhang I ab 2. Aug. 2028 (Verordnung (EU) 2026/1744)
NIS2 (in Deutschland: NIS2UmsuCG)
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“
In Kraft seit 6. Dez. 2025, Registrierung beim BSI
Zählt eine CRA-Konformität für die Maschinenverordnung 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 Maschinenverordnung leichter erfüllbar machen kann; den Nachweis führt der Hersteller, und beide Konformitätsverfahren laufen. In der Praxis überschneiden sich die Artefakte aber stark. Anhang III Nr. 1.2.1 der Maschinenverordnung 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.
Was ändert der KI-Omnibus für Maschinen mit KI?
Die Verordnung (EU) 2026/1744 hat die Maschinenverordnung 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 Maschinenverordnung 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. Die Einzelheiten stehen in unserem Artikel zum EU AI Act in der Industrie.
Nicht verwechseln: Das große Digital-Omnibus-Paket (COM(2025) 837), das unter anderem eine gemeinsame Meldestelle für Cybervorfälle bringen soll, ist noch nicht beschlossen. Am CRA hat sich bis heute nichts geändert.
Welche Pflichten
haben Hersteller?
Sechs Pflichten aus Art. 13, Art. 14 und Anhang I des CRA, übersetzt in das, was sie für Ihre Entwicklung bedeuten. Wie Sie die SBOM-Pflicht technisch umsetzen, zeigt unsere Anleitung zum SBOM erstellen.
- /01
Security by Design
Gewicht: HochSicherheit 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: HochDer 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
Schwachstellenbehandlung
Gewicht: HochBekannte 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ützungszeitraum
Gewicht: HochDer 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: gepflegte Branches je Auslieferungsstand und Builds, die sich Jahre später noch reproduzieren lassen.
- /05
Meldepflicht (seit 11. Sep. 2026)
Gewicht: KritischAktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle gehen gestuft an CSIRT und ENISA: 24 Stunden, 72 Stunden, 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: MittelRisikobewertung, 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.
Warum ist es
an der Maschine schwerer?
Ein Softwarehaus liefert alle paar Wochen neu aus. Eine Maschine steht zwanzig Jahre in der Halle. 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.
AI- /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 folgtSie 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 folgtSBOMs 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 folgtAusgleichende 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 folgtEine benannte Person für Produktsicherheit und Security Champions in den Teams sind der Anfang.
Was geht
noch diese Woche?
Fünf Maßnahmen ohne Projektantrag. Die ersten beiden betreffen die Meldepflicht, die schon gilt. Der Ertrag der dritten ist unspektakulär und trotzdem spürbar: Nach dem ersten Build mit Syft in der Pipeline 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: NiedrigLegen 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: Hersteller, Produkt, Softwarestand, betroffene Länder.
- /02
Zuständigkeit festlegen
Aufwand: NiedrigEine 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: NiedrigSyft 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: NiedrigTrivy, 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: MittelFordern 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.
Wie sieht ein
realistischer Plan aus?
In zwölf Wochen 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.
Bestandsaufnahme
- → 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
Grundlagen bauen
- → 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
Prozesse verankern
- → Security-Prüfungen als Gates in CI/CD
- → Signierte Update-Strecke ins Feld
- → Unterstützungszeitraum je Produkt festlegen
- → Technische Dokumentation aufbauen
- → Konformitätsbewertung vorbereiten
Betreiben und nachweisen
- → Schwachstellen laufend überwachen
- → Penetrationstests und Audits
- → Schulungen für die Entwicklung
- → Zulieferer-SBOMs aktuell halten
- → Konformitätserklärung und CE-Kennzeichnung
Schon DevOps?
Halber Weg geschafft.
Versionierung in Git, automatisierte Tests, reproduzierbare Builds: Das 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.
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.
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.
Was Kunden
wirklich fragen.
- 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 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.
- Betrifft der CRA auch bestehende Maschinen im Feld?
- 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. Was als wesentliche Änderung zählt, erläutern die Leitlinien der EU-Kommission vom 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.
- 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.
- Welche Maschinenrichtlinie gilt aktuell, 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 September 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 September 2026 noch nicht im Amtsblatt veröffentlicht. 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.
- 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.
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.
Verwandte Artikel
SBOM erstellen: Anleitung
Formate, Werkzeuge und die SBOM im Build, damit die CRA-Pflicht nicht zur Handarbeit wird.
IEC 62443 in der Praxis: DevSecOps für OT
Normteile, Security Levels und wie die CI/CD-Pipeline die Nachweise liefert.
EU AI Act in der Industrie umsetzen
Hochrisiko-Einstufung, KI-Governance und die verschobenen Fristen nach dem KI-Omnibus.
Erstgespräch.
Kostenlos.
90 Tage zum Ergebnis.
Wir klären gemeinsam, wie Sie in 90 Tagen die ersten messbaren Industrial-DevOps-Erfolge erzielen.
Industrie · Automotive · Finance