MVO #003 Maschinenverordnung 2027 – Cybersicherheit wird Produktsicherheit

Wenn wir über Maschinensicherheit sprechen, denken viele zuerst an Schutzzäune, trennende Schutzeinrichtungen, Not-Halt oder sichere Abstände.

Aber was ist eigentlich, wenn eine Maschine mechanisch völlig sauber konstruiert ist – und trotzdem unsicher wird?

Nicht weil ein Bauteil bricht. Nicht weil jemand eine Schutzeinrichtung entfernt. Sondern weil Daten manipuliert werden. Weil eine sicherheitsrelevante Software nicht zuverlässig funktioniert. Oder weil eine vernetzte Steuerung in einen Zustand gerät, den bei der Entwicklung niemand als echtes Sicherheitsproblem eingeordnet hat.

Genau an dieser Stelle zeigt sich eine der wichtigsten Veränderungen der neuen Maschinenverordnung.

Cybersicherheit ist dort nicht mehr nur ein Thema für die IT-Abteilung. Sondern sie wird dann zum Thema der Produktsicherheit, wenn Software, Daten oder Kommunikationsverbindungen Einfluss auf sicherheitsrelevante Funktionen haben.

In der letzten Folge haben wir uns einen Überblick verschafft: Was kommt mit der Maschinenverordnung grundsätzlich auf Hersteller zu?

Heute gehen wir in eines der spannendsten und zugleich oft missverstandenen Themen hinein.

Denn viele Unternehmen sagen noch immer: Cybersicherheit – das ist doch ein IT-Thema.

Die neue Maschinenverordnung sagt an dieser Stelle: Nicht nur. Jedenfalls nicht dann, wenn aus einem digitalen Problem ein Risiko für Menschen entsteht.

Diese Episode soll die folgenden vier Fragen behandeln:

1. Wann wird Software unter der Maschinenverordnung überhaupt sicherheitsrelevant?

2. Was bedeutet Schutz vor Manipulation oder Korrumpierung in der Praxis?

3. Welche Auswirkungen hat Vernetzung auf die Risikobeurteilung?

4. Welche Fehler machen Hersteller heute typischerweise, wenn Sicherheitsfunktionen von Software abhängen?

Wenn wir diese vier Fragen sauber durchgehen, dann wird schnell klar, warum die MVO an dieser Stelle deutlich moderner denkt als die alte Maschinenrichtlinie.

Beginnen wir mit der ersten Frage.

Wann ist Software im Sinne der Maschinenverordnung eigentlich sicherheitsrelevant?

Die kurze Antwort lautet: Dann, wenn sie eine Sicherheitsfunktion erfüllt. Oder dann, wenn ihr Ausfall, ihre Fehlfunktion oder ihre Manipulation dazu führen kann, dass ein Risiko entsteht oder ansteigt.

Früher wurde Software in vielen Unternehmen eher als unterstützende Ebene betrachtet. Die eigentliche Sicherheit, so das Bauchgefühl, steckte in der Mechanik, in der Elektrik oder in der Sicherheitssteuerung.

Heute ist das häufig anders. Software entscheidet mit darüber,

• ob eine Bewegung freigegeben wird,
• ob Geschwindigkeiten begrenzt werden,
• ob ein sicherer Zustand erkannt wird,
• ob Sensorinformationen plausibel verarbeitet werden,
• oder ob ein Stopp-Befehl tatsächlich korrekt umgesetzt wird.

Sobald Software also nicht nur Komfort, Visualisierung oder Betriebsdaten betrifft, sondern unmittelbar Schutzfunktionen beeinflusst, sprechen wir nicht mehr nur über Digitalisierung. Dann sprechen wir über Sicherheit.

Und die neue Maschinenverordnung greift genau das auf. Sie macht deutlich, dass auch digitale Komponenten – einschließlich Software – sicherheitsrelevant sein können. Und sie verlangt, dass sicherheitsrelevante Software und Daten gegen unbeabsichtigte oder absichtliche Korrumpierung angemessen geschützt werden.

Das ist ein zentraler Punkt. Denn damit wird nicht erst der eingetretene Cyberangriff relevant, sondern bereits die Frage, ob ein Hersteller solche Einwirkungen in seiner Sicherheitsbetrachtung ausreichend mitgedacht hat.

Mit anderen Worten: Es geht nicht nur darum, ob eine Maschine „gehackt“ werden kann. Es geht darum, ob digitale Einflüsse eine gefährliche Situation auslösen oder begünstigen können.

Kommen wir zur zweiten Frage: Was bedeutet Schutz vor Manipulation oder Korrumpierung konkret?

Hier hilft es, sich von dem typischen Bild des spektakulären Hackerangriffs zu lösen. Denn in der Praxis beginnt das Problem oft viel banaler.

Zum Beispiel dann,

• wenn sicherheitsrelevante Parameter unkontrolliert geändert werden können,
• wenn Zugriffsrechte unsauber geregelt sind,
• wenn Software-Updates ohne ausreichende Prüfung eingespielt werden,
• wenn Daten aus externen Quellen ungeprüft übernommen werden,
• oder wenn eine Kommunikationsstörung dazu führt, dass die Maschine in einen unsicheren Zustand übergeht.

Die MVO verlangt also nicht, dass Hersteller plötzlich zu einem IT-Sicherheitsunternehmen werden. Aber sie verlangt, dass Hersteller die Frage ernst nehmen, ob digitale Schwachstellen die Sicherheit von Personen beeinträchtigen können.

Ein Hersteller muss sich also beispielsweise fragen:

• Welche Daten sind für die Sicherheit kritisch?
• Welche Softwareteile erfüllen direkt oder indirekt eine Schutzfunktion?
• Welche Schnittstellen können sicherheitsrelevante Funktionen beeinflussen?
• Welche Fehlbedienungen, Kommunikationsfehler oder Manipulationen müssen abgefangen werden?
• Und wie stelle ich sicher, dass die Maschine auch bei digitalen Störungen beherrschbar bleibt?

Das sind keine rein abstrakten Fragen. Das sind klassische Fragen der Risikobeurteilung – nur eben in einer digitalisierten Maschinenwelt.

Ein wichtiger Denkfehler in Unternehmen ist an dieser Stelle: „Wir haben doch eine Firewall im Firmennetz, also ist das kein Thema für die Risikobeurteilung.“

Doch, das kann es sehr wohl sein. Oder anders gesagt: Die Frage lautet nicht, ob das IT-System geschützt ist. Die Frage lautet auch, was mit der Maschine passiert, wenn digitale Schutzmechanismen versagen.

Damit sind wir bei unserer dritten Frage: Welche Auswirkungen hat Vernetzung auf die Risikobeurteilung?

Hier liegt einer der größten Umbrüche. Früher konnte man viele Maschinen relativ geschlossen betrachten. Es gab definierte Ein- und Ausgänge, klar abgegrenzte Steuerungen und ein überschaubares Umfeld.

Heute kommunizieren Maschinen mit anderen Maschinen, mit Leitsystemen, mit Cloud-Diensten, mit Fernwartungslösungen oder mit mobilen Endgeräten.

Und jede zusätzliche Verbindung ist zunächst einmal nicht nur ein Komfortgewinn, sondern auch eine zusätzliche Einflussmöglichkeit.

Das bedeutet nicht automatisch, dass jede vernetzte Maschine unsicher ist. Aber es bedeutet, dass die Risikobeurteilung breiter denken muss.

Hersteller sollten sich deshalb nicht nur fragen, welche mechanischen oder elektrischen Gefährdungen von ihrer Maschine ausgehen, sondern auch, welche digitalen Einwirkungen auf sicherheitsrelevante Funktionen denkbar sind.

Zum Beispiel:

Was passiert, wenn Kommunikationsdaten verzögert, verfälscht oder unterbrochen werden? Was passiert, wenn ein Fernzugriff während des Betriebs Änderungen ermöglicht? Was passiert, wenn ein Update unerwartete Auswirkungen auf Sicherheitsfunktionen hat? Was passiert, wenn Sensorwerte digital plausibel wirken, aber tatsächlich manipuliert oder fehlerhaft sind?

Und genau hier wird die Risikobeurteilung anspruchsvoller. Denn der Hersteller muss nicht nur Bauteile bewerten, sondern auch Zustände, Datenflüsse, Schnittstellen und Abhängigkeiten.

Die gute Nachricht ist: Das Grundprinzip bleibt gleich. Man identifiziert Gefährdungen, bewertet Risiken und definiert Schutzmaßnahmen.

Die Herausforderung ist nur: Die Gefährdungen sind heute häufiger immateriell. Sie entstehen nicht allein durch bewegte Teile, sondern auch durch fehlerhafte Logik, ungesicherte Konfigurationen oder unsichere Kommunikationsbeziehungen.

Kommen wir zur vierten Frage: Welche Fehler machen Hersteller heute besonders häufig?

Ich sehe in der Praxis vor allem sechs typisch vorkommende Fehler:

Fehler 1: Software wird funktional betrachtet, aber nicht sicherheitsbezogen

Viele Unternehmen dokumentieren sehr genau, was ihre Software macht. Aber sie dokumentieren nicht sauber genug, welche dieser Funktionen sicherheitsrelevant sind.

Die Folge: Es bleibt unklar, welche Teile besonders geschützt, validiert oder kontrolliert werden müssen.

Fehler 2: Cybersicherheit wird vollständig an die IT delegiert

Natürlich braucht es IT-Kompetenz. Aber die Verantwortung für Produktsicherheit kann nicht einfach an die interne IT-Abteilung abgegeben werden.

Denn die entscheidende Frage lautet nicht nur, wie ein System technisch abgesichert ist, sondern auch, welche Auswirkungen ein digitales Problem auf die Sicherheit der Maschine hat.

Fehler 3: Schnittstellen werden unterschätzt

Viele Risiken entstehen nicht im Kern der Maschine, sondern an ihren Übergängen: zwischen Maschine und HMI, zwischen Steuerung und Sensorik, zwischen Fernzugriff und Bedienebene, zwischen externer Software und interner Sicherheitsfunktion.

Schnittstellen sind oft die Stellen, an denen Zuständigkeiten verschwimmen und Annahmen ungeprüft bleiben.

Fehler 4: Updates werden nicht als Sicherheitsereignis gedacht

Software-Updates werden in manchen Unternehmen noch immer wie reine Servicevorgänge behandelt. Dabei können Änderungen an Logik, Parametern oder Kommunikationswegen unmittelbar sicherheitsrelevant sein.

Die Frage ist dabei nicht nur: Funktioniert das Update? Sondern auch: Bleibt die Sicherheitsfunktion nach dem Update nachweisbar wirksam?

Fehler 5: Risikobeurteilungen bleiben zu mechanisch gedacht

Viele Risikobeurteilungen sind nach wie vor stark auf klassische Gefährdungen zugeschnitten. Das ist wichtig, reicht aber nicht mehr aus.

Wer digitale Einflussmöglichkeiten nicht systematisch mitbewertet, hat am Ende vielleicht eine formal vorhandene Risikobeurteilung – aber keine vollständige.

Fehler 6: Verantwortlichkeiten sind intern nicht klar geregelt

Oft arbeiten Entwicklung, Automatisierung, IT, funktionale Sicherheit, Service und Dokumentation nebeneinander vor sich her. Jeder sieht einen Teil. Aber niemand hat den Gesamtblick auf das Zusammenspiel von Software, Sicherheit und regulatorischer Verantwortung.

Machen wir das einmal mit mehreren Beispielen aus der Praxis greifbar. Das macht das ganze für viele verständlicher. Nicht, wenn man abstrakt über Cyberangriffe spricht. Sondern dann, wenn man sich konkrete Situationen aus dem Maschinenalltag anschaut.

Nehmen wir zunächst eine Maschine mit sicherheitsbezogener Geschwindigkeitsüberwachung und einer Fernwartungsschnittstelle. Solange alles sauber funktioniert, ist das ein modernes und effizientes System. Service ist schneller möglich. Stillstände lassen sich reduzieren. Parameter können gezielt angepasst werden.

Problematisch wird es aber dann, wenn über diese Schnittstelle sicherheitsrelevante Parameter verändert werden können, ohne dass diese Änderung ausreichend abgesichert, protokolliert oder validiert sind.

Dann ist das kein Komfortproblem mehr. Dann kann daraus eine sicherheitsrelevante Gefährdung entstehen.

Zum Beispiel, weil eine reduzierte Geschwindigkeit nicht mehr zuverlässig eingehalten wird. Oder weil Grenzwerte verändert werden, die eigentlich verhindern sollen, dass sich eine Achse in einem bestimmten Betriebszustand zu schnell bewegt. Oder weil nach einer Änderung niemand mehr sicher sagen kann, ob die Schutzfunktion noch genau so wirkt wie vorgesehen.

Schauen wir uns ein zweites Beispiel an.

Stellen wir uns eine Verpackungsmaschine vor, bei der verschiedene Produktformate über Rezepte oder Parametersätze umgestellt werden. Das ist völlig normal. Gerade in automatisierten Linien läuft vieles genau darüber.

Kritisch wird es aber dann, wenn diese Datensätze nicht nur Produktparameter enthalten, sondern auch Werte, die mittelbar Einfluss auf sichere Abstände, Geschwindigkeiten, Reaktionszeiten oder Bewegungsabläufe haben.

Wenn also ein Rezept geändert, eingespielt oder von außen übertragen wird, ohne dass klar geregelt ist, wer das darf, welche Werte geändert werden dürfen, welche Werte gesperrt sein müssen, und wie die Änderung geprüft wird, dann entsteht daraus schnell ein Sicherheitsproblem.

Denn die Maschine läuft äußerlich vielleicht ganz normal weiter. Aber sie läuft möglicherweise in einem Zustand, der sicherheitstechnisch nicht mehr dem entspricht, was ursprünglich bewertet und freigegeben wurde.

Ein drittes Beispiel betrifft Sensoren und Datenintegrität.

Nehmen wir an, eine Maschine verarbeitet Sensordaten, um Bewegungen zu begrenzen oder sichere Zustände zu erkennen. Wenn diese Daten verfälscht, verzögert oder falsch interpretiert werden, dann kann die Steuerung trotzdem auf Basis scheinbar plausibler Informationen entscheiden.

Das ist besonders tückisch. Denn die Maschine „merkt“ unter Umständen gar nicht, dass sie mit fehlerhaften oder manipulierten Daten arbeitet.

Praktisch kann das bedeuten: Eine Schutztür wird als geschlossen interpretiert, obwohl das Signal unplausibel ist. Ein sicherer Stillstand wird angenommen, obwohl noch Bewegung vorhanden ist. Oder ein Bediener erhält auf dem HMI die Information, dass ein Bereich sicher freigegeben ist, obwohl die tatsächliche Situation eine andere ist.

Auch hier gilt: Das Problem ist nicht die Digitalisierung an sich. Das Problem ist, dass digitale Informationen sicherheitsrelevante Entscheidungen beeinflussen.

Ein viertes Beispiel betrifft das Thema Updates.

Viele Unternehmen spielen Software-Updates auf, um Fehler zu beheben, Funktionen zu erweitern oder die Wartbarkeit zu verbessern. Das ist grundsätzlich sinnvoll.

Aber sobald ein Update Komponenten betrifft, die Sicherheitsfunktionen beeinflussen, reicht die Frage „Läuft die Maschine danach wieder?“ nicht mehr aus.

Dann muss auch gefragt werden: Arbeitet die Schutzfunktion danach noch genau wie vorgesehen? Sind Reaktionszeiten gleich geblieben? Gibt es neue Abhängigkeiten? Wurden Schnittstellen verändert? Und ist das alles überhaupt nachvollziehbar dokumentiert?

Denn es kann durchaus passieren, dass ein Update funktional unauffällig ist, sicherheitstechnisch aber relevante Nebenwirkungen hat. Etwa weil Kommunikationszeiten anders sind, Prüfmechanismen verändert wurden oder eine neue Softwareversion bestimmte Zustände anders interpretiert.

All diese Beispiele zeigen dasselbe Muster: Nicht jedes digitale Problem ist automatisch ein Sicherheitsproblem. Aber überall dort, wo Software, Daten oder Kommunikationsverbindungen Schutzfunktionen beeinflussen, muss der Hersteller sehr genau hinschauen.

Und genau an diesem Punkt wird aus Cybersicherheit ein Thema der Maschinensicherheit.

Wenn Sie heute als Hersteller zuhören und sich fragen, was Sie aus dieser Folge mitnehmen sollten, dann würde ich mit fünf Punkten starten.

1. Identifizieren Sie sicherheitsrelevante Software und Daten gezielt. Nicht alles Digitale ist automatisch kritisch. Aber alles, was Schutzfunktionen beeinflusst, gehört auf den Prüfstand.

2. Erweitern Sie Ihre Risikobeurteilung um digitale Einflussfaktoren. Denken Sie nicht nur an mechanisches Versagen, sondern auch an Manipulation, Kommunikationsfehler, Fehlkonfiguration und unerwartete Zustände.

3. Prüfen Sie Schnittstellen und Zugriffswege besonders sorgfältig. Gerade dort entstehen oft Risiken, weil Systeme miteinander kommunizieren, ohne dass die Sicherheitsfolgen vollständig betrachtet wurden.

4. Behandeln Sie Updates, Parametrierung und Fernzugriffe als sicherheitsrelevante Prozesse, wenn Schutzfunktionen betroffen sind.

5. Sorgen Sie intern für gemeinsame Verantwortung. MVO, Cybersicherheit, funktionale Sicherheit und Dokumentation dürfen nicht in getrennten Silos bearbeitet werden.

Fassen wir die heutige Folge zusammen.

Die neue Maschinenverordnung macht deutlich: Cybersicherheit ist dort Teil der Produktsicherheit, wo Software, Daten oder Kommunikationsverbindungen Einfluss auf sicherheitsrelevante Funktionen haben.

Software kann unter der MVO sicherheitsrelevant sein. Digitale Komponenten können Schutzfunktionen erfüllen. Und sicherheitskritische Software und Daten müssen gegen unbeabsichtigte oder absichtliche Korrumpierung angemessen geschützt werden.

Für Hersteller bedeutet das: Sie müssen Cybersicherheit nicht abstrakt, sondern funktionsbezogen betrachten. Entscheidend ist immer die Frage, ob digitale Einflüsse eine Gefährdung für Personen verursachen oder verstärken können.

Wer das früh erkennt, kann seine Produktentwicklung, Risikobeurteilung und Dokumentation strukturiert anpassen. Wer es zu spät erkennt, läuft Gefahr, Sicherheit, Nachweisführung und Verantwortung auseinanderlaufen zu lassen.

In der nächsten Folge bleiben wir bei den digitalen Themen – und gehen einen Schritt weiter.

Dann sprechen wir über KI in Maschinen und die Frage, was die Maschinenverordnung von lernenden oder selbstanpassenden Systemen verlangt.

Also: Was passiert, wenn Sicherheitsfunktionen nicht mehr nur fest programmiert sind, sondern sich deren Verhalten innerhalb definierter Grenzen verändert? Und welche regulatorischen Fragen entstehen dadurch für Hersteller?