Cybersicherheit für Maschinenhersteller

Ab 2027 unterliegt eine Maschine mit Steuerung, Bedienerdisplay oder Datenverbindung zwei EU-Verordnungen. Beide beginnen mit derselben Frage: Welche Software ist auf dieser Maschine, Version für Version, und was steckt darin?

1. 11. September 2026Die Meldepflichten des Cyber Resilience Act für aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle gelten.
2. 20. Januar 2027Die Maschinenverordnung, (EU) 2023/1230, gilt und ersetzt die Maschinenrichtlinie.
3. 11. Dezember 2027Der Cyber Resilience Act, (EU) 2024/2847, gilt vollständig.

Maschinenverordnung

Zwei grundlegende Sicherheits- und Gesundheitsschutzanforderungen in Anhang III befassen sich mit Cybersicherheit:

• 1.1.9, Schutz gegen Korrumpierung. Die direkte oder ferngesteuerte Verbindung eines anderen Geräts mit der Maschine darf nicht zu einer Gefährdungssituation führen. Software und Daten, die für die Konformität der Maschine mit den grundlegenden Sicherheits- und Gesundheitsschutzanforderungen entscheidend sind, müssen identifiziert und gegen versehentliche oder vorsätzliche Korrumpierung geschützt werden. Die Maschine muss die auf ihr installierte Software, die sie für den sicheren Betrieb benötigt, identifizieren und diese Information jederzeit bereitstellen. Außerdem muss sie Nachweise über rechtmäßige oder unrechtmäßige Eingriffe in diese Software oder ihre Konfiguration erfassen.
• 1.2.1, Sicherheit und Zuverlässigkeit von Steuerungen. Steuerungen müssen vernünftigerweise vorhersehbaren böswilligen Versuchen Dritter standhalten, die zu einer Gefährdungssituation führen. Nach 1.2.1(f) müssen sie ein Protokoll der Eingriffe und der Versionen von Sicherheitssoftware führen, die nach dem Inverkehrbringen der Maschine aufgespielt wurden, und zwar fünf Jahre lang nach dem Aufspielen.

Cyber Resilience Act

Eine Maschine mit Datenverbindung, oder ein separat verkauftes Teil davon, ist ein Produkt mit digitalen Elementen. Der Hersteller muss bei den Komponenten Dritter, die er integriert, mit der gebotenen Sorgfalt vorgehen, eine SBOM erstellen, die mindestens die Abhängigkeiten der obersten Ebene abdeckt, Schwachstellen während des Unterstützungszeitraums behandeln, der mindestens fünf Jahre beträgt, sofern das Produkt nicht voraussichtlich kürzer im Einsatz ist, und die technische Dokumentation mindestens zehn Jahre oder für den Unterstützungszeitraum aufbewahren, je nachdem, welcher Zeitraum länger ist.

Nicht automatisch. Der Cyber Resilience Act begründet keine Konformitätsvermutung mit der Maschinenverordnung. Sein Erwägungsgrund 53 besagt, dass die Erfüllung der grundlegenden Anforderungen des CRA die Einhaltung der Anforderungen der Maschinenverordnung an den Schutz gegen Korrumpierung und an die Sicherheit und Zuverlässigkeit von Steuerungen erleichtern könnte. Er besagt auch, dass der Hersteller dies nachweisen muss, etwa durch Anwendung harmonisierter Normen nach einer Risikobeurteilung, und dass die Konformitätsbewertungsverfahren beider Verordnungen weiterhin gelten.

Die harmonisierte Norm, die für 1.1.9 entsteht, ist EN 50742, Safety of machinery – Protection against corruption. Im November 2026 lag sie als Schlussentwurf FprEN 50742 vor, der 1.1.9 und die zugehörigen Punkte von 1.2.1 behandelt. Solange die Fundstelle einer endgültigen Fassung nicht im Amtsblatt der EU veröffentlicht ist, begründet sie keine Konformitätsvermutung. Sie verbindet die Risikobeurteilung nach EN ISO 12100 mit Sicherheitskonzepten aus IEC 62443 und erkennt die konsequente Anwendung von IEC 62443-4-1, IEC 62443-3-3 und IEC 62443-4-2 als gleichwertigen Weg an, ihre Schutzziele zu erreichen. IEC 62443-4-2 legt die technischen Sicherheitsanforderungen an Komponenten von Steuerungssystemen fest, abgestuft nach Security Capability Level. In Deutschland übersetzen die Prüfgrundsätze GS-IFA-M25 vom Juli 2026 den Schutz gegen Korrumpierung in 66 Prüfkriterien und verwenden dabei die Begriffe der prEN 50742. Eines davon, T46, verlangt, dass das Produkt seine installierte Softwareversion und Konfiguration auf Anfrage bereitstellen kann. Um das für jede Konfiguration zu beantworten, braucht es eine Aufzeichnung dessen, was jede Softwareversion enthält.

Die Maschinenverordnung hat eine eigene Vermutung, und die läuft über einen anderen Weg: europäische Schemata für die Cybersicherheitszertifizierung, die nach dem Cybersecurity Act, Verordnung (EU) 2019/881, angenommen wurden. Ein Zertifikat oder eine Konformitätserklärung nach einem solchen Schema begründet die Vermutung der Konformität mit 1.1.9 und 1.2.1, soweit es diese Anforderungen abdeckt.

Eine Risikobeurteilung und ein Satz Nachweise können also beiden Verordnungen dienen, aber die Konformität weisen Sie für jede einzeln nach. Wenn Ihre Maschine eine Datenverbindung hat, planen Sie für beide. Die Softwarenachweise, also SBOMs, Schwachstellenaufzeichnungen und die Update-Historie, sind der Teil, den sie gemeinsam haben.

Im Januar 2026 forderten Verbände der Maschinenbauindustrie, 1.1.9 und 1.2.1(f) zu verschieben, und im März 2026, sie ab dem Datum des CRA, dem 11. Dezember 2027, anzuwenden. Das ist eine Forderung, kein Recht: Stand November 2026 war keine Verschiebung beschlossen. Die Daten auf dieser Seite sind die Daten aus den Verordnungen.

• Bau-, Fördertechnik-, Bergbau- und Industriemaschinen fallen unter die Maschinenverordnung und zusätzlich unter den CRA, wenn die Maschine oder ihre Teile eine Datenverbindung haben.
• Land- und forstwirtschaftliche Zugmaschinen, die unter die Verordnung (EU) Nr. 167/2013 fallen, sind von der Maschinenverordnung ausgenommen, mit Ausnahme der an ihnen angebrachten Maschinen. Die Ausnahmeliste des CRA nennt diese Verordnung nicht, daher kann eine vernetzte Zugmaschine in den Anwendungsbereich des CRA fallen.
• Straßenfahrzeuge, die nach der Verordnung (EU) 2019/2144 typgenehmigt sind, sind vom CRA ausgenommen.
• Separat verkaufte Komponenten. Der CRA gilt auch für Software- und Hardwarekomponenten, die gesondert in Verkehr gebracht werden. Ein Lieferant, der ein Steuergerät oder eine Telematikeinheit eigenständig verkauft, ist selbst Hersteller im Sinne des CRA. Wird die Einheit nur in die Maschine eingebaut, trägt der Maschinenhersteller die Pflicht für die gesamte Maschine und muss bei der Komponente des Lieferanten mit der gebotenen Sorgfalt vorgehen.

Dies sind allgemeine Informationen, keine Rechtsberatung. Prüfen Sie die Einstufung Ihres eigenen Produkts.

In einer Maschine stammt die Software aus verschiedenen Quellen, und nur das Team, das eine Software baut, kann verlässlich sagen, was darin steckt. Wie wir von Maschinenherstellern hören, enthalten Bare-Metal-Steuergeräte wenig Open Source, Linux-, Android- und Windows-Software dagegen viel.

Geringe Stückzahlen, große Vielfalt. Ein Maschinenhersteller kann Hunderte Plattformen auf dem Markt haben, von jeder nur eine Handvoll Einheiten pro Jahr verkaufen und viele Maschinen auf Bestellung konfigurieren. Jede Konfiguration ist ein anderer Satz Software, daher zählt eine SBOM für jeden Build mehr als eine SBOM für jede Produktlinie.

Lange Lebensdauer. Maschinen bleiben zehn Jahre oder länger im Einsatz, während Lieferanten wechseln oder vom Markt verschwinden. Die Aufzeichnung dessen, was in eine Softwareversion eingeflossen ist, muss beim Build entstehen, denn Jahre später lässt sie sich nicht mehr rekonstruieren.

Lieferantensoftware dominiert, und Lieferanten-SBOMs sind oft schlecht. Wir hören von Lieferanten-SBOMs mit fehlenden Komponenten, ohne Package-URLs oder CPEs, ohne Lizenzen und ohne Hashes, manche von Hand geschrieben und ohne bestandene Schemavalidierung. Die Binäranalyse eines geflashten Steuergeräts ist eine Notlösung: Sie rät den Inhalt, statt ihn aufzuzeichnen.

Das Risiko liegt in den vernetzten Schichten. Ein Großteil der Steuergerätelogik wird aus Modellen generiert und enthält wenig Open Source. Open Source und Netzwerkexposition konzentrieren sich in den Linux-, Konnektivitäts- und App-Schichten, also setzen Sie Ihren Aufwand zuerst dort ein.

Ein Beispiel zur Veranschaulichung: der Software-Stack einer fiktiven Radladerplattform, von der Cloud bis zu den Steuergeräten.

1. Cloud-Backend und Begleit-AppEigenentwicklung. Überwiegend Open Source und netzwerkseitig erreichbar. Cyber Resilience Act.
2. Telematik-GatewayEmbedded Linux, überwiegend Open Source, mit dem Mobilfunknetz verbunden. Cyber Resilience Act und 1.1.9 für die Fernverbindung.
3. BedienerdisplayEmbedded-Linux-Image mit UI-Framework, überwiegend Open Source, mit dem Maschinenbus und Service-Tools verbunden. Cyber Resilience Act und 1.1.9.
4. MaschinensteuerungEigene Anwendung auf einer Lieferantenplattform, sicherheitsrelevant. 1.1.9 und 1.2.1 sowie der Cyber Resilience Act, soweit sie über eine Verbindung erreichbar ist.
5. Hydraulik-, Lenkungs- und MotorsteuergeräteLieferanten-Firmware, proprietär und modellgeneriert, wenig Open Source, sicherheitsrelevant. 1.1.9 und 1.2.1; der Cyber Resilience Act über die Maschine.

Open Source und Netzwerkexposition liegen in den oberen drei Schichten, und dort laufen in der Regel auch Ihre eigenen Build-Pipelines. Beginnen Sie dort.

Maschinenhersteller stellen inzwischen SBOM-Anforderungen an die Software, die sie einkaufen, etwa Package-URLs oder CPEs, Lizenzen, Hashes und ein Format, das die Validierung besteht, und schicken Dateien zurück, die durchfallen. Wenn Sie auf GitHub Actions bauen, erzeugt CRACI die SBOM aus dem Build selbst, sodass sie auflistet, was tatsächlich in das Release eingeflossen ist, einschließlich der Komponenten, die in keinem Lockfile stehen, mit einer Package-URL und der deklarierten Lizenz für jede Komponente. Prüfen Sie den Export gegen die vollständige Liste der Felder, die Ihr Kunde verlangt. Mehr zur Beantwortung von SBOM-Anfragen von Kunden.