.svg "ABB AG"){kind=logo}
Ist die neue EU-Maschinenverordnung tatsächlich ein Generationenwechsel für den Maschinenbau?
Ja, nach rund 20 Jahren kann man von einem Generationenwechsel sprechen. Trotzdem ist das für mich eher Evolution als Revolution. Die Risikobeurteilung bleibt, die grundlegenden Anforderungen ändern sich nicht und auch die bewährten Mechanismen der Konformitätsbewertung bleiben im Kern erhalten. Neu ist vor allem, dass Cybersecurity expliziter adressiert wird. Die Maschinenverordnung schärft den Schutz vor Korrumpierung nach und macht klar: Ein erfolgreicher Cyberangriff darf nicht dazu führen, dass eine Maschine für Bediener oder Umgebung unsicher wird. Maschinenbauer müssen diese mögliche Rückwirkung auf die funktionale Sicherheit künftig systematisch betrachten und dokumentieren.
Was bedeutet diese Rückwirkung auf die funktionale Sicherheit in der Praxis?
Zunächst einmal bedeutet sie nicht, dass jede Maschine gegen jeden denkbaren Angriff absolut geschützt sein muss. Einen ultimativen Schutz gibt es nicht. Entscheidend ist, dass die Maßnahmen zum Risiko der Maschine und zur Kritikalität der jeweiligen Sicherheitsfunktion passen. Eine Funktion, deren Fehlverhalten vielleicht nur einen kleinen Kratzer verursachen kann, muss anders abgesichert werden als eine Funktion, die Menschen vor tödlichen Gefahren schützt. Genau diese risikobasierte Logik kennen Maschinenbauer bereits aus der funktionalen Sicherheit. Sie müssen sie nun um Cyberrisiken erweitern. Die EN 50742 „Safety of machinery – Protection against corruption“ soll diese Anforderungen methodisch konkretisieren. Wichtig ist: Nicht überall muss man mit Kryptografie und maximaler Absicherung alle Register ziehen. Die Maßnahmen müssen zur realen Gefährdung passen – sonst wird Cybersecurity unnötig teuer.
Welche Fristen müssen Maschinenbauer jetzt besonders im Blick behalten?
Wir haben drei entscheidende Termine. Seit dem 11. September 2026 gelten die Meldepflichten des EU Cyber Resilience Act, kurz CRA. Ab dem 20. Januar 2027 ist die EU-Maschinenverordnung anzuwenden. Und ab dem 11. Dezember 2027 gilt der CRA umfassend. Bei der Maschinenverordnung sind viele Unternehmen inzwischen aus der Orientierung heraus und arbeiten an der Umsetzung. Beim CRA ist der Reifegrad unterschiedlicher. Für viele Maschinenbauer ist OT-Security noch eine neue Aufgabe. Dafür brauchen sie Prozesse, Verantwortlichkeiten und dauerhaft verfügbare Kompetenzen.
Was genau löst seit September 2026 eine Meldung aus?
Die Meldepflicht bezieht sich nicht auf jede theoretisch bekannte Schwachstelle. Relevant sind insbesondere aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle. Wenn ein Sicherheitsforscher mir nachvollziehbar zeigt, dass mein Produkt eine Schwachstelle besitzt, muss ich diese bewerten und gegebenenfalls beheben. Das ist aber noch nicht automatisch der Fall einer aktiven Ausnutzung im Feld. Kommt dagegen beispielsweise von einem Betreiber die belastbare Information, dass mit einem unserer Produkte etwas passiert ist, müssen wir die nötigen Daten einholen, Logfiles auswerten und den Vorgang nachvollziehen. Sobald feststeht, dass tatsächlich eine aktive Ausnutzung oder ein meldepflichtiger Vorfall vorliegt, läuft die Frist: Innerhalb von 24 Stunden ist eine Frühwarnung abzugeben, innerhalb von 72 Stunden folgt eine ausführlichere Meldung. Unternehmen dürfen eine unklare Information zunächst prüfen, aber diese Prüfung natürlich nicht schuldhaft verschleppen. Das organisatorisch Anspruchsvolle ist: Diese Meldepflicht erfasst auch ältere Produkte im Feld. Hersteller müssen deshalb Meldekanäle offenhalten und in der Lage sein, Informationen zu längst ausgelieferten Produktgenerationen einzuordnen. Wer erst beim Vorfall überlegt, wer zuständig ist, wie die Eskalation funktioniert und welche Behörde informiert werden muss, wird die Fristen kaum einhalten können.
Welche organisatorischen Prozesse braucht ein Maschinenbauer dafür?
Er braucht keinen riesigen neuen Apparat, aber eindeutig definierte Rollen: Wer nimmt Meldungen entgegen, wer führt die technische Bewertung durch, wer entscheidet über die Meldepflicht und wer informiert Kunden sowie Behörden? Entwicklung, Service, Qualitätsmanagement, Recht und Kommunikation müssen zusammenspielen – im Kern als Product Security Incident Response Team. Hinzu kommt das kontinuierliche Schwachstellenmanagement. Spätestens ab dem 11.12.27 muss der Hersteller während des gesamten Produktlebenszyklus inklusive der Supportperiode neue Schwachstellen in Bibliotheken, Treibern, Betriebssystemen und Komponenten beobachten und die Risiken mitigieren. Nicht jede Meldung ist für die konkrete Maschine relevant: Nutzt sie nur eines von 67 Protokollen eines Kommunikations-Stacks, kann eine Lücke in einem nicht erreichbaren Teil ohne praktische Wirkung bleiben. Diese Bewertung muss nachvollziehbar sein. Solche Mengen lassen sich nicht dauerhaft manuell bewältigen. KI-gestützte Agenten können Datenbanken überwachen und Meldungen vorfiltern. Entscheiden sollte am Ende weiterhin ein fachkundiger Mensch.
Müssen Maschinenbauer CRA und Maschinenverordnung getrennt bearbeiten?
Das wäre keine gute Idee, denn beide Regelwerke blicken aus unterschiedlichen Richtungen auf dasselbe Produkt. Die Maschinenverordnung interessiert, ob Manipulationen die Sicherheit der Maschine beeinträchtigen können. Der CRA betrachtet Cybersicherheit umfassender: Vertraulichkeit, Integrität und Verfügbarkeit, also etwa Datendiebstahl, Manipulation oder Denial-of-Service-Angriffe. Der CRA begleitet das Produkt außerdem über seinen digitalen Lebenszyklus. In der Entwicklung sollten beide Perspektiven deshalb in einer gemeinsamen Produktstrategie zusammenlaufen. Ich brauche eine Safety-Risikobeurteilung und eine Cybersecurity-Risikobeurteilung, aber die Schnittstellen müssen verbunden sein. Wenn eine manipulierte Kommunikation, Firmware oder Parametrierung eine Sicherheitsfunktion beeinflussen kann, darf das nicht zwischen zwei Abteilungen verloren gehen. Genau dort treffen Safety und Security technisch und organisatorisch aufeinander.
Wie weit reicht die Verantwortung des Komponentenlieferanten – und was bleibt beim OEM?
Wir als Frequenzumrichterhersteller verantworten den Frequenzumrichter. Für den Maschinenbauer bleibt dessen interne Software weitgehend eine Blackbox. Er braucht von uns aber belastbare Informationen: Supportperiode, Sicherheitshinweise, Updates, relevante Schwachstellenmeldungen, technische Eigenschaften und vorgesehene Einsatzbedingungen. Der OEM muss die Komponente trotzdem korrekt in seine Maschine integrieren. Wenn er einen Umrichter mit offenen Ports, festem Port-Forwarding und ohne Zugriffsschutz direkt an ein ungeschütztes Netz hängt, kann er die Verantwortung nicht auf den Komponentenhersteller verlagern. Er muss den Kreis um seine Maschine ziehen, Angriffsvektoren bewerten und geeignete Maßnahmen treffen. Dazu können Netzwerksegmentierung, Firewalls, Zugriffsbeschränkungen, deaktivierte Schnittstellen und ein abgeschlossener Schaltschrank gehören. Die erwartete Betriebsumgebung muss klar dokumentiert sein. Ein Umrichter in einem verriegelten Schaltschrank und einem segmentierten Netz hat ein anderes Risikoprofil als ein frei zugängliches Gerät im Feld. Es kommt auf Architektur, Zugänglichkeit, Funktion und Schadenspotenzial an.
Was bedeutet das für Updates und die bei vielen OEMs üblichen eingefrorenen Firmwarestände?
Das ist eine der größten praktischen Veränderungen. Viele OEMs qualifizieren eine Maschine mit genau definierten Firmwareversionen und frieren diesen Stand anschließend ein. Das ist verständlich, weil Feldbuskommunikation, Timing und Prozessqualität geprüft sind. Künftig kann ein Hersteller aber keine Version weiter ausliefern, in der bekannte und relevante Schwachstellen stecken. Eine Firmware nach dem Motto „Die lief vor sechs Jahren, also bleibt sie drauf“ wird immer schwieriger. Der OEM muss seinen Qualifizierungsprozess so gestalten, dass Updates schneller bewertet werden können. Alternativ kann er Komponenten kapseln und das Risiko durch eine abgesicherte Architektur reduzieren. Auch der Betreiber muss relevante Cybersecurity-Updates einspielen. Bleibt eine Anlage trotz verfügbarer Updates jahrelang ungepatcht, kann das nicht allein dem Hersteller zugerechnet werden. Jedes Update muss auf Nebenwirkungen geprüft werden. Ein reiner Security-Fix ist etwas anderes als eine Version, die zusätzliche Kommunikationsfunktionen aktiviert. Dann kann sich das Risikoprofil der Gesamtmaschine ändern. Der Maschinenbauer muss dieses Delta bewerten und dokumentieren.
Maschinen laufen häufig 20 Jahre oder länger. Wie lässt sich eine so lange Cybersecurity-Unterstützung wirtschaftlich darstellen?
Hier sehe ich einen Konstruktionsfehler des CRA. Eine Maschine besitzt eine mechanische, eine leistungselektronische und eine digitale Lebensdauer – und diese Zeiträume sind nicht identisch. Trotzdem verlangt der CRA eine definierte Supportperiode, in der Schwachstellen behandelt und Sicherheitsupdates bereitgestellt werden. Ich rechne damit, dass sich bei vielen Industrieprodukten Supportperioden um zehn Jahre etablieren. Bei Frequenzumrichtern passt das beispielsweise zu bestehenden Anforderungen an die Ersatzteilverfügbarkeit und zu Lebensdauerannahmen aus der Nachhaltigkeitsbewertung. Für eine Maschine mit 20 Jahren mechanischer Nutzungsdauer braucht es dann ein Konzept für die digitale Erneuerung: Welche Komponenten werden dann getauscht oder sind noch supportfähig? Wo ist eine Migration vorgesehen? Diese Fragen müssen bereits in die Produktarchitektur und in das Geschäftsmodell einfließen.
Drohen kleinere Maschinenbauer an diesem Aufwand zu scheitern?
Der Aufwand ist real, aber kleinere Unternehmen müssen nicht jede Kompetenz selbst aufbauen. Risikoanalyse, Supportperiode, Bewertung relevanter Schwachstellen und Gesamtverantwortung für die Konformität bleiben beim OEM. Prüfungen, Monitoring, Beratung oder Teile des Incident Response lassen sich vergeben. Wichtig ist, nicht mit maximaler Technik auf jedes theoretische Risiko zu reagieren. Zuerst muss der Hersteller klären, ob sein Produkt überhaupt in den Anwendungsbereich des CRA fällt und welche extern erreichbaren digitalen Elemente vorhanden sind. Eine intern kommunizierende, vollständig abgeschlossene Maschine ohne externe Schnittstelle ist anders zu bewerten als ein vernetztes Bearbeitungszentrum mit Cloud-Anbindung und Kommunikation zu vor- und nachgelagerten Anlagen. Wer zielgerichtet priorisiert, kann Aufwand und Kosten begrenzen.
Kann nachweisbare Cyberresilienz am Ende sogar ein Wettbewerbsvorteil sein?
Davon bin ich überzeugt. Der deutsche Maschinenbau ist exportorientiert. Andere Märkte werden bei Cybersecurity nachziehen – China, die USA und weitere Industrieregionen arbeiten bereits an vergleichbaren Anforderungen. In drei bis fünf Jahren wird kaum ein anspruchsvoller Betreiber eine vernetzte Maschine kaufen wollen, deren Hersteller keine belastbaren Security-Prozesse nachweisen kann. Zu viele Unternehmen haben erlebt, was es bedeutet, wenn Ransomware die Produktion über Wochen stilllegt. Europa ist regulatorisch früher dran. Das erzeugt zunächst Aufwand, kann aber einen Vorsprung schaffen. Wer Security by Design, Schwachstellenmanagement, Updateprozesse und nachvollziehbare Dokumentation heute beherrscht, kann diese Fähigkeiten international nutzen. Für die kommenden Jahre ist das ein klarer Wettbewerbsvorteil; später wird es zum Standard werden. Der CRA kommt auch nicht völlig überraschend. Wir haben gelernt, elektrische und mechanische Risiken systematisch zu beherrschen. Jetzt müssen wir dasselbe mit digitalen Risiken tun. Ja, die Lernkurve ist steil. Aber für Unternehmen, die früh handeln, steckt darin eine echte Marktchance.
Wie kann ABB Maschinenbauern helfen, sicher und kosteneffizient durch den CRA- und MVO-Dschungel zu navigieren?
Wir können auf mehreren Ebenen unterstützen. Für größere Maschinen- und Anlagenbauer haben wir Einheiten, die Cybersecurity als eigene Leistung anbieten und Unternehmen auch beratend begleiten. Auf Produktebene liefern wir Komponenten, bei denen Security-Prozesse, kontinuierliche Tests und Schwachstellenmanagement bereits organisatorisch verankert sind. Dazu gehören belastbare Angaben zu Sicherheitseigenschaften, vorgesehener Betriebsumgebung, Supportperioden, Updates und relevanten Schwachstellen. Für den Maschinenbauer ist entscheidend, dass er nicht die interne Software jeder einzelnen Komponente selbst überwachen muss. Wir kümmern uns um unsere Produkte und stellen die Informationen bereit, die der OEM für seine Risikobeurteilung und die Konformität der Gesamtmaschine benötigt. Gleichzeitig helfen standardisierte, gut dokumentierte Komponenten dabei, Test- und Integrationsaufwand zu reduzieren. Die Verantwortung für die Gesamtmaschine können wir dem OEM nicht abnehmen. Aber wir können dafür sorgen, dass er auf einer belastbaren Basis arbeitet – und nicht bei jeder Komponente wieder bei null anfangen muss.
