Die EU-Maschinenverordnung ab 20. Januar 2027: Was sie von Ihrer Maschinensoftware verlangt

Am 20. Januar 2027 wird die Maschinenrichtlinie durch die Verordnung (EU) 2023/1230 abgelöst, die Maschinenverordnung. Das meiste daran wird allen vertraut vorkommen, die Maschinen mit CE-Kennzeichnung bauen. Ein Teil nicht. Zum ersten Mal legt das Maschinenrecht Pflichten direkt auf die Software: Die Maschine muss angeben, welche Software sie für den sicheren Betrieb braucht, bemerken, wenn sich diese Software oder ihre Konfiguration ändert, gegen Korrumpierung geschützt sein und Updates der Sicherheitssoftware fünf Jahre lang nachvollziehbar festhalten.
Dieser Artikel richtet sich an Leiter von Konstruktion und Steuerungstechnik bei Maschinenbauern. Wenn Sie nach diesem Datum Maschinen in die EU liefern, landen diese Anforderungen in Ihren SPS-Programmen, Ihrer HMI, Ihrem Fernzugriff und Ihrem Backend für Updates.
Was das Gesetz tatsächlich sagt
Die Europäische Kommission erklärt, die Verordnung „gilt verbindlich ab dem 20. Januar 2027“ und „enthält Bestimmungen zur Cybersicherheit für konformitätsrelevante Softwaredaten und Sicherheitssteuerungen“. Der 2023 veröffentlichte Text nannte den 14. Januar; eine Berichtigung hat das Datum verschoben.
Die Pflichten für Software stehen in zwei grundlegenden Sicherheits- und Gesundheitsschutzanforderungen in Anhang III der Verordnung.
Abschnitt 1.1.9, Schutz gegen Korrumpierung. Kurz gefasst:
- Der Anschluss einer anderen Einrichtung an die Maschine, direkt oder über Fernzugriff, darf nicht zu einer gefährlichen Situation führen.
- Software und Daten, die für die Übereinstimmung mit den Sicherheitsanforderungen von entscheidender Bedeutung sind, „sind als solche zu benennen“ und gegen unbeabsichtigte oder vorsätzliche Korrumpierung zu schützen.
- Hardware, die Signale oder Daten überträgt, über die man auf diese Software zugreifen kann (denken Sie an eine Programmierschnittstelle oder eine Netzwerkschnittstelle zur Sicherheitssteuerung), muss ebenfalls geschützt sein, und die Maschine muss Nachweise für Eingriffe darin sammeln.
- „Die Maschine bzw. das dazugehörige Produkt muss die installierte Software, die für den sicheren Betrieb erforderlich ist, kenntlich machen und diese Informationen jederzeit in leicht zugänglicher Form bereitstellen können.“
- „Maschinen bzw. dazugehörige Produkte müssen Nachweise für ein rechtmäßiges oder unrechtmäßiges Eingreifen in die Software oder eine Veränderung der in Maschinen bzw. dazugehörigen Produkte installierten Software oder ihrer Konfiguration sammeln.“
Abschnitt 1.2.1, Sicherheit und Zuverlässigkeit von Steuerungen. Steuerungen müssen auch „vernünftigerweise vorhersehbare böswillige Versuche Dritter, die zu einer Gefährdungssituation führen“, standhalten können. Buchstabe f ergänzt die Protokollierungspflicht: Das Rückverfolgungsprotokoll der Daten, die bei einem Eingriff entstehen, und der Versionen der Sicherheitssoftware, die nach dem Inverkehrbringen hochgeladen wurden, muss „bis zu fünf Jahre nach dem Hochladen“ zugänglich sein. Das Protokoll dient dem Nachweis der Konformität auf begründete Anforderung einer nationalen Behörde und nichts anderem.
Ebenfalls auf der Liste: Die technischen Unterlagen müssen auf Antrag einer Behörde „den Quellcode oder die Programmierlogik der Schaltung der sicherheitsrelevanten Software“ liefern können (Anhang IV).
Welche Maschinen erfasst sind
Die Regeln gelten für Maschinen, die ab dem 20. Januar 2027 in Verkehr gebracht werden. Maschinen, die vor diesem Datum nach der alten Richtlinie in Verkehr gebracht wurden, dürfen weiter bereitgestellt werden (Artikel 52), und der Bestand im Feld wird von den neuen Softwareregeln nicht erfasst.
Der Haken liegt darin, was „in Verkehr gebracht“ bedeutet. Laut dem Blue Guide der Kommission bezieht sich der Begriff auf jedes einzelne Produkt, nicht auf einen Produkttyp. Jede Einheit, die Ihr Werk ab dem 20. Januar 2027 für einen Kunden in der EU verlässt, muss die neuen Anforderungen erfüllen, die Software eingeschlossen. Eine Baureihe, die laufend ausgeliefert wird, braucht ihre Steuerungssoftware fertig vor der ersten Einheit des Jahres 2027, nicht erst beim nächsten Modellwechsel.
Auch spätere Updates wollen bedacht sein. Eine vom Hersteller nicht vorgesehene „physische oder digitale Veränderung“, durch die eine neue Gefährdung entsteht oder sich ein bestehendes Risiko erhöht, kann eine wesentliche Veränderung sein. Nach Erwägungsgrund 32 sollte die Risikobeurteilung Software-Updates berücksichtigen, die beim Inverkehrbringen vorgesehen sind. Beschreiben Sie Ihren Update-Weg also jetzt dort.
Was das in jeder Schicht der Maschine bedeutet
Sicherheitssteuerung und SPS
- Festlegen, was sicherheitsrelevant ist. Meist ist das das Sicherheitsprogramm, es können aber auch Teile des Standard-SPS-Codes dazugehören, die eine Sicherheitsfunktion speisen, Sicherheitsparameter in Antrieben und die Konfiguration von Laserscannern oder Lichtgittern. Halten Sie das je Baureihe schriftlich fest; alles andere hängt davon ab.
- Referenzstand festlegen und vergleichen. Erfassen Sie für jede freigegebene Konfiguration eine Prüfsumme oder Signatur jedes sicherheitsrelevanten Elements. Beim Start und in Intervallen vergleicht die Maschine, was läuft, mit diesem Referenzstand und protokolliert jede Abweichung. So fällt auch der Eingriff auf, der an Ihrer Zugriffskontrolle vorbeiging, etwa ein Laptop, der direkt an die Steuerung angeschlossen wurde.
- Den Engineering-Zugang abschotten. Passwörter auf dem Sicherheitsprogramm, ungenutzte Ports und Dienste deaktiviert und Engineering-Zugriff nur über einen Weg, der die Person authentifiziert und protokolliert, was sie getan hat.
HMI
- Eine Bildschirmseite zur Softwarekennzeichnung, die die sicherheitsrelevante Software mit Versionen und Prüfsummen auflistet. Lesen Sie die Werte live aus den Geräten aus. Eine Seite, die zum Release-Zeitpunkt abgetippt wurde, entfernt sich von der Wirklichkeit, und die Anforderung sagt „jederzeit“.
- Parameterseiten. Nach Nummer 1.2.1 Buchstabe d dürfen keine Änderungen an Einstellungen oder Regeln vorgenommen werden, die zu Gefährdungssituationen führen könnten. Sicherheitsrelevante Parameter gehören hinter Zugriffsebenen, mit Grenzwerten, die in der Steuerung durchgesetzt werden und nicht nur in der HMI, und jede Änderung wird mit Person, Zeitpunkt, altem und neuem Wert protokolliert.
Fernzugriff
Abschnitt 1.1.9 nennt Fernzugriffseinrichtungen ausdrücklich. In der Praxis heißt das:
- Sicherheitsfunktionen bleiben lokal. Eine Fernwartungssitzung kann lesen, diagnostizieren und eine Änderung vorbereiten. Sie kann keinen Halt, keine trennende Schutzeinrichtung und keine Zustimmeinrichtung übersteuern.
- Sitzungen werden je Person authentifiziert, nicht über ein gemeinsames Servicekonto, und der Kunde kann sehen, wenn eine offen ist.
- Beginn, Ende und jede Änderung einer Sitzung landen im selben Nachweisprotokoll wie Eingriffe vor Ort.
Backend und Update-Pipeline
Wenn Sie nach der Auslieferung Updates liefern, gehört Ihr Update-Server zum Umfang der Arbeit. Für jede Seriennummer müssen Sie wissen, welche Version der Sicherheitssoftware wann und von wem hochgeladen wurde. Signieren Sie die Updates und lassen Sie die Maschine die Signatur prüfen, bevor sie irgendetwas installiert.
Das Rückverfolgungsprotokoll selbst
Die Verordnung sagt nicht, wo das Protokoll liegt. Unsere Sicht: Die maßgebliche Kopie liegt auf der Maschine, weil viele Kunden keine dauerhafte Verbindung zulassen. Ein Spiegel in der Cloud ist nützlich, darf aber nicht die einzige Kopie sein.
Das Volumen ist klein: Eingriffe und Uploads der Sicherheitssoftware, keine Prozessdaten. Fünf Jahre passen in den lokalen Speicher, wenn Sie ihn bewusst dimensionieren. Schützen Sie das Protokoll gegen Löschung und stellen Sie sicher, dass es einen Tausch der Steuerung übersteht. Wenn Einträge einen Techniker namentlich nennen, sind das personenbezogene Daten beim Kunden: Protokollieren Sie, was die Anforderung braucht, und nicht mehr.
Was Ihr Steuerungshersteller liefert und was nicht
Ihre Steuerungsplattform wird einen Teil davon liefern. Prüfen Sie, bevor Sie irgendetwas bauen, was sie bietet: eine Signatur oder Prüfsumme über das Sicherheitsprogramm, Passwortschutz, Benutzerverwaltung, ein Änderungsprotokoll, das Auslesen der Version. Nutzen Sie, was vorhanden ist.
Das sind Bausteine. Der Hersteller weiß nicht, welche Ihrer Antriebe und Scanner sicherheitsrelevant sind, sieht weder Ihr Fernzugriffs-Gateway noch Ihren Update-Server und kann nicht entscheiden, wie Nachweise fünf Jahre und einen Tausch der Steuerung überstehen. Diese Funktionen zu konfigurieren, sie über die ganze Maschine hinweg zu verbinden und das Ergebnis zu dokumentieren ist Aufgabe des Maschinenbauers, und der Maschinenbauer unterschreibt die EU-Konformitätserklärung.
Wie das mit dem Cyber Resilience Act zusammenhängt
Der Cyber Resilience Act folgt seinem eigenen Kalender. Seine Meldepflichten gelten seit dem 11. September 2026, seine vollständigen Anforderungen ab dem 11. Dezember 2027. Die Maschinenverordnung kommt dazwischen.
Der CRA erkennt die Überschneidung an. Nach Erwägungsgrund 53 der Verordnung (EU) 2024/2847 sollten Hersteller von Maschinen, die zugleich Produkte mit digitalen Elementen sind, beide Verordnungen erfüllen, und die Einhaltung des CRA „könnte“ die Einhaltung der Abschnitte 1.1.9 und 1.2.1 „erleichtern“. Diese Synergieeffekte muss der Hersteller nachweisen. Anhang I des CRA verlangt, die Integrität von Daten, Befehlen, Programmen und Konfigurationen vor Manipulation zu schützen und deren Beschädigung zu melden, was dem nahekommt, was 1.1.9 verlangt.
Ein Unterschied ist für den Entwurf Ihres Protokolls wichtig. Die Anforderung des CRA, interne Vorgänge aufzuzeichnen und zu überwachen, kommt mit einem „Opt-out-Mechanismus“ für die Nutzer. Das Rückverfolgungsprotokoll der Maschinenverordnung muss fünf Jahre lang zugänglich bleiben. Bauen Sie ruhig einen einzigen Protokollierungsmechanismus, aber lassen Sie nicht zu, dass das Opt-out des CRA das Maschinenprotokoll abschaltet.
Bauen Sie jetzt für die Maschinenverordnung, weil sie zuerst kommt, und entwerfen Sie es so, dass derselbe Nachweisspeicher, dieselbe Signierung und dieselben Update-Aufzeichnungen im Dezember 2027 dem CRA dienen.
Normen und die gescheiterte Verschiebung
Rechnen Sie nicht damit, dass bis zum 20. Januar 2027 eine harmonisierte Norm für diese Anforderungen im Amtsblatt veröffentlicht ist. Die Seite der Kommission zu harmonisierten Normen sagt in ihrer Fassung vom September 2026, dass die erste Liste unter der Maschinenverordnung vorbereitet wird. Sie wird die meisten unter der Richtlinie veröffentlichten Normen übernehmen und dort präzisieren, wo diese die neuen Anforderungen „noch nicht vollständig abdecken“, und sie ist „noch vor Ende dieses Jahres zu erwarten“.
Im Januar 2026 forderten CEMA, CECE, CECIMO, EGMF und FEM in einer gemeinsamen Position der Industrie, 1.1.9 und 1.2.1 Buchstabe f im Einklang mit dem CRA auf den 11. Dezember 2027 zu verschieben. Sie bezifferten die Kosten der Umsetzung auf „mehr als 1 Million Euro pro Plattformarchitektur“ und erklärten, die erwarteten Normen blieben beim Datenprotokoll nach 1.2.1 Buchstabe f sehr allgemein.
Diese Forderung wurde nicht übernommen. Die Maschinenverordnung wurde im Juli 2026 durch die Verordnung (EU) 2026/1744 geändert, diese Änderung betrifft aber Hochrisiko-KI-Systeme in Maschinen und lässt den Geltungsbeginn unberührt. Planen Sie mit dem 20. Januar 2027.
Es kann also sein, dass Sie am ersten Tag keine Norm mit Vermutungswirkung für diese beiden Anforderungen haben. Dann müssen Ihre technischen Unterlagen für jede der beiden die angewandte Lösung beschreiben (Anhang IV). Schreiben Sie das, während Sie bauen, nicht danach. Für Maschinen nach Anhang I Teil B kommt ein Schritt hinzu: Die Selbstbewertung (interne Fertigungskontrolle) steht nur offen, wenn harmonisierte Normen oder gemeinsame Spezifikationen alle einschlägigen Anforderungen abdecken; andernfalls ist eine notifizierte Stelle beteiligt (Artikel 25). Maschinen, die nicht in Anhang I aufgeführt sind, bewerten sich in jedem Fall selbst.
Ein 15-Wochen-Plan
Von Montag, dem 5. Oktober 2026, bis zum Stichtag sind es gut 15 Wochen, mit den Feiertagen in der Mitte. Das ist knapp, aber machbar, wenn Sie nach Liefertermin priorisieren: Baureihen, von denen im Januar Einheiten in die EU gehen, kommen zuerst.
- Woche 1 und 2 (5. bis 16. Oktober): Umfang. Listen Sie jede Baureihe auf, die nach dem 20. Januar 2027 Einheiten in die EU liefert. Listen Sie für jede die sicherheitsrelevante Software und die Daten auf: Sicherheitsprogramm, konformitätskritischer Standardcode, Sicherheitsparameter von Antrieben und Sensoren, HMI, Firmware, Fernzugriffs-Gateway. Benennen Sie je Baureihe einen Verantwortlichen.
- Woche 3 und 4 (19. bis 30. Oktober): Risikobeurteilung und Lücken. Aktualisieren Sie die Risikobeurteilung für Anschlüsse, Fernzugriff, böswillige Versuche und den Update-Weg. Prüfen Sie, was Ihre Steuerungsplattform bietet und was davon eingeschaltet ist.
- Woche 5 bis 9 (2. November bis 4. Dezember): Umsetzung. Seite zur Softwarekennzeichnung, Vergleich mit dem Referenzstand, Zugriffskontrolle für Engineering und Fernzugriff, das Rückverfolgungsprotokoll mit Kapazität für fünf Jahre, signierte Updates und Aufzeichnungen je Seriennummer im Backend.
- Woche 10 und 11 (7. bis 18. Dezember): so testen, wie es ein Techniker und ein Angreifer tun würden. Ändern Sie einen Sicherheitsparameter direkt mit dem Werkzeug des Herstellers und bestätigen Sie, dass die Maschine es protokolliert. Tauschen Sie eine Steuerung und prüfen Sie, ob das Protokoll überlebt. Schalten Sie während eines Updates den Strom ab.
- Woche 12 und 13 (21. Dezember bis 1. Januar): Feiertage. Planen Sie keine Entwicklungsarbeit; lassen Sie einen Dauertest laufen, der das Protokoll auf seine Fünfjahresgröße füllt.
- Woche 14 und 15 (4. bis 15. Januar): Dokumentation und Freigabe. Einträge in den technischen Unterlagen zu 1.1.9 und 1.2.1, eine Betriebsanleitung, die erklärt, wie ein Kunde die Softwarekennzeichnung ausliest und was der Fernzugriff kann und was nicht, und ein Fertigungsschritt, der den freigegebenen Referenzstand lädt und je Seriennummer festhält.
Wenn mehr Plattformarchitekturen das brauchen, als in dieses Fenster passen, sagen Sie es jetzt dem Vertrieb: Eine Einheit, die nicht bereit ist, darf nicht rechtmäßig auf dem EU-Markt in Verkehr gebracht werden.
Für wen das nicht gilt
Maschinen, die vor dem 20. Januar 2027 in Verkehr gebracht wurden, erfassen diese Softwareregeln nicht, es sei denn, jemand verändert sie später wesentlich. Wenn Sie Maschinen kaufen statt bauen, liegt die Pflicht bei Ihrem Lieferanten; Ihr Teil ist, in Ihren Lastenheften die Softwarekennzeichnung und den Zugang zum Protokoll zu verlangen.
Wo Sie Hilfe bekommen
Wir sind ein Softwareunternehmen, keine notifizierte Stelle und keine Kanzlei. Wir bauen und ändern die Software, in der diese Anforderungen landen: HMI- und Backend-Anwendungen, Fernzugriffs-Gateways, Update-Pipelines und die Protokollierung von Nachweisen, gemeinsam mit den Steuerungstechnikern, die das Sicherheitsprogramm verantworten. Ältere Plattformen mit jahrelang gewachsenem Code sind der schwierigste Fall, und dort beginnt meist unsere Arbeit an der Wartung von Bestandssystemen; die Seite des CRA behandelt unser CRA-Leitfaden. Wenn Ihr Team den Plan hat, aber nicht die Hände, um ihn bis Januar abzuschließen, schreiben Sie an office@c9group.dev.