Maschinenverordnung ab Januar 2027: Was sich für Entwicklung und Konstruktion wirklich ändert

Ab dem 20. Januar 2027 gilt die Maschinenverordnung (EU) 2023/1230 unmittelbar in allen Mitgliedstaaten und löst die Maschinenrichtlinie 2006/42/EG ab. Eine Übergangsfrist gibt es nicht. Maßgeblich ist der Tag, an dem eine Maschine erstmals in Verkehr gebracht wird: Was davor ausgeliefert wird, läuft noch nach Richtlinie. Was danach ausgeliefert wird, braucht eine Konformitätserklärung nach Verordnung – auch wenn die Konstruktion schon zwei Jahre alt ist.

Die meisten Übersichten zur Maschinenverordnung lesen sich wie ein Gesetzeskommentar. Für die Entwicklung ist die Frage eine andere: Welche Anforderungen verändern, wie wir Steuerungen auslegen, Software freigeben und Nachweise führen? Darum geht es hier. Rechtsberatung ist dieser Artikel ausdrücklich nicht – maßgeblich bleiben der Verordnungstext und im Zweifel die benannte Stelle.

Software ist jetzt Teil der Maschinensicherheit

Die größte Verschiebung steckt in einem Begriff: Ein Sicherheitsbauteil kann nach der neuen Verordnung physisch oder digital sein. Software, die eine Sicherheitsfunktion erfüllt und separat in Verkehr gebracht wird, ist damit selbst ein Sicherheitsbauteil – mit eigener Konformitätsbewertung. Für Entwicklungsteams heißt das: Die Sicherheitssoftware ist kein Anhängsel der Hardware mehr, sondern ein Produkt mit eigenem Lebenszyklus.

Dazu kommen zwei Anforderungen aus Anhang III, die in der Maschinenrichtlinie schlicht fehlten:

Schutz gegen Korrumpierung (Anhang III, 1.1.9). Weder der Anschluss eines anderen Geräts noch ein Fernzugriff darf zu einer gefährlichen Situation führen. Sicherheitsrelevante Hard- und Software muss als solche benannt und gegen unbeabsichtigte wie vorsätzliche Manipulation geschützt sein. Berechtigte und unberechtigte Eingriffe müssen nachweisbar erfasst werden, und welche Version der Sicherheitssoftware installiert ist, muss sich an der Maschine feststellen lassen.

Sicherheit und Zuverlässigkeit von Steuerungen (Anhang III, 1.2.1). Steuerungen müssen auch vorhersehbaren böswilligen Versuchen standhalten, eine gefährliche Situation herbeizuführen. Eingriffe und nach dem Inverkehrbringen aufgespielte Versionen sicherheitsrelevanter Software müssen protokolliert werden – fünf Jahre lang, ausschließlich zum Nachweis der Konformität.

Technisch ist nichts davon exotisch: Rollen und Authentifizierung, Integritätsprüfung beim Booten, getrennte Netzsegmente für Sicherheitsfunktionen, ein manipulationssicheres Ereignisprotokoll. Neu ist, dass es kein Komfortmerkmal mehr ist, sondern Voraussetzung für die CE-Kennzeichnung – und damit in die Risikobeurteilung gehört statt in ein separates IT-Konzept.

KI und selbstlernende Steuerungen

Die Verordnung nimmt Sicherheitsbauteile mit vollständig oder teilweise selbstentwickelndem Verhalten auf Basis von maschinellem Lernen in Anhang I Teil A auf – ebenso Maschinen, in die solche Systeme eingebettet sind. Für diese Kategorie ist eine benannte Stelle Pflicht, eine interne Fertigungskontrolle reicht nicht. Die Risikobeurteilung muss zudem Gefährdungen abdecken, die sich im Lebenszyklus aus dem vorhersehbaren Lernverhalten ergeben können. Geplante Updates und Weiterentwicklungen gehören damit schon in die Konstruktionsphase.

Mit dem Digital Omnibus, der Verordnung (EU) 2026/1744, hat sich seit Juli 2026 die Systematik verschoben: Die KI-spezifischen Anforderungen an Maschinen sollen über delegierte Rechtsakte in die Maschinenverordnung selbst wandern und ab dem 2. August 2028 gelten. Klargestellt ist auch, dass KI nur dann ein Sicherheitsbauteil ist, wenn sie eine Sicherheitsfunktion erfüllt. Eine KI zur optischen Qualitätsprüfung oder zur vorausschauenden Wartung ist es in der Regel nicht, eine lernende Personenerkennung am Roboter sehr wohl. Wie der AI Act außerhalb von Maschinen greift, habe ich im Artikel zum EU AI Act für Industrieunternehmen eingeordnet.

Wesentliche Veränderung: Wann ein Umbau zum Hersteller macht

Erstmals definiert das europäische Maschinenrecht die wesentliche Veränderung. Gemeint ist eine physische oder digitale Veränderung nach dem Inverkehrbringen, die der Hersteller nicht vorgesehen oder geplant hat und die eine neue Gefährdung schafft oder ein bestehendes Risiko erhöht. Wer eine solche Veränderung vornimmt, gilt nach Artikel 18 als Hersteller – mit Risikobeurteilung, technischen Unterlagen, Konformitätsbewertung und Konformitätserklärung.

Das Wort „digital“ ist der Punkt. Ein Firmware-Update der Sicherheitssteuerung, eine geänderte Parametrierung von Schutzfeldern oder eine neu aufgespielte Steuerungslogik kann eine wesentliche Veränderung sein, ohne dass ein Schraubenschlüssel im Spiel war. Betroffen sind damit nicht nur Retrofits und Verkettungen zu Gesamtanlagen, sondern auch Integratoren und Betreiber, die Software anpassen.

Für Hersteller steckt darin ein Gestaltungshebel: Was in der Betriebsanleitung als vorgesehene Änderung beschrieben ist – freigegebene Optionen, Werkzeugwechsel, ein definierter Update-Prozess –, ist keine wesentliche Veränderung. Wer seinen Kunden spätere Änderungen ermöglichen will, muss sie also schon in der Entwicklung als Varianten denken und dokumentieren. Und wer umbaut, sollte das Ergebnis seiner Prüfung festhalten, auch wenn es „nicht wesentlich“ lautet.

Rückverfolgbarkeit: Gefährdung → Anforderung → Nachweis

Alle diese Punkte laufen auf dieselbe Frage hinaus: Lässt sich für jede Gefährdung zeigen, welche Anforderung sie beherrscht und welcher Nachweis das belegt? Mit der Maschinenverordnung wird diese Kette länger. Bedrohungen durch Manipulation stehen gleichberechtigt neben mechanischen Gefährdungen, und der Softwarestand wird Teil der Konfiguration, die nachgewiesen werden muss.

Die Beispiele sind illustrativ, die Struktur ist es nicht. Genau hier liegt der Nutzen von Systems Engineering: Wer Anforderungen ohnehin modellbasiert oder zumindest durchgängig verknüpft führt, erzeugt die Rückverfolgbarkeit als Nebenprodukt. Wer sie aus Excel-Listen, Risikobeurteilung und Prüfberichten nachträglich zusammensucht, findet die Lücke meist erst kurz vor der Konformitätserklärung. Dafür braucht es kein teures Werkzeug – wie das im Mittelstand ohne Toolinvest funktioniert, zeigt der Artikel zu MBSE-Methodik ohne teures Tool.

Technische Dokumentation: was neu hineingehört

Die technischen Unterlagen stehen jetzt in Anhang IV Teil A und werden mindestens zehn Jahre aufbewahrt. Inhaltlich wachsen sie an drei Stellen. Die Risikobeurteilung muss die Korrumpierung von Steuerung und Software abdecken. Die Unterlagen müssen die sicherheitsrelevante Software beschreiben; Quellcode oder Programmierlogik sind der Marktüberwachungsbehörde auf begründetes Verlangen zugänglich zu machen. Und die Nachweise zu Anhang III 1.1.9 und 1.2.1 werden Teil der Konformität – nicht einer separaten IT-Akte.

Erleichterung gibt es bei der Betriebsanleitung: Sie darf digital bereitgestellt werden. Der Käufer kann beim Kauf aber eine kostenlose Papierfassung verlangen, und die digitale Fassung muss über die Lebensdauer der Maschine verfügbar bleiben, mindestens zehn Jahre. Was eine technische Dokumentation unabhängig vom Regelwerk belastbar macht, habe ich in den sieben Prüfpunkten zum Review technischer Dokumentation beschrieben.

Was das für die Praxis bedeutet

Die Maschinenverordnung ist formal ein CE-Thema. Die Arbeit fällt aber in der Entwicklung an: in der Steuerungsarchitektur, im Software-Release-Prozess, in der Frage, welche Änderungen der Kunde später machen darf, und in einer Rückverfolgbarkeit, die eine Gefährdung bis zum Nachweis trägt. Wer das jetzt als Engineering-Aufgabe behandelt, hat am 20. Januar 2027 keinen Dokumentationsnotstand, sondern eine Konstruktion, die die Anforderungen von innen heraus erfüllt.

In meinen Projekten setze ich genau an dieser Kette an – als unabhängiges technisches Review von Risikobeurteilung, Anforderungen und Nachweisen oder im Engineering-Consulting, wenn die Rückverfolgbarkeit erst aufgebaut werden muss. Die rechtliche Bewertung im Einzelfall gehört zur benannten Stelle oder zu einer spezialisierten Kanzlei.