Security vs Safety im Maschinenbau: Abgrenzung und CE-Praxis

Eine Sondermaschine läuft beim Kunden, die Fernwartung ist eingerichtet, und der Service möchte einen Steuerungsparameter ändern. Aus Sicht der IT ist das ein kontrollierter Remote-Zugriff. Aus Sicht der funktionalen Sicherheit kann derselbe Zugriff eine sicherheitsrelevante Funktion beeinflussen. Genau an dieser Stelle versagen viele Dokumentationen: Sie behandeln Security und Safety als getrennte Disziplinen, obwohl ein manipuliertes Steuerungssignal Menschen gefährden kann.

Für technische Entscheider im DACH-Maschinenbau lautet die entscheidende Frage deshalb nicht nur, wie ein System gegen Angriffe geschützt wird. Entscheidend ist, welche Cyber-Risiken in die Risikobeurteilung nach EN ISO 12100 und in den Nachweis der funktionalen Sicherheit gehören, welche im ISMS bleiben und wie die Schnittstelle dokumentiert wird.

Inhaltsverzeichnis

• Warum die Trennung von Security und Safety im Maschinenbau nicht mehr funktioniert
  • Die eigentliche Zuordnungsfrage
• Definitionen und Schutzrichtungen im direkten Vergleich
  • Unterschiedliche Ursachen, gemeinsamer Effekt
• Rechtliche Konsequenzen unter Maschinenrichtlinie und Maschinenverordnung
  • Was sich für die Dokumentation ändert
• Schnittstellen und Konfliktfälle in der Praxis
  • Drei Entscheidungskriterien
• Integration in Risikobeurteilung und Konformitätsbewertung
  • Vorgehen in fünf Arbeitsschritten
  • Nachweisführung statt Maßnahmensammlung
• Praxisbeispiele aus dem Sondermaschinenbau
  • Vernetzte Verpackungsanlage mit Remote-Diagnose
  • Kollaborierender Roboter mit KI-basierter Bahnplanung
• Checkliste für die dokumentierte Umsetzung im KMU

<a id="warum-die-trennung-von-security-und-safety-im-maschinenbau-nicht-mehr-funktioniert"></a>

Warum die Trennung von Security und Safety im Maschinenbau nicht mehr funktioniert

Ein typisches Szenario aus dem Sondermaschinenbau: Eine Verpackungsanlage besitzt einen Remote-Zugang für Diagnose und Wartung. Der Servicetechniker kann Zustände auslesen, Programme prüfen und bestimmte Parameter anpassen. Solange der Zugriff auf Diagnosewerte beschränkt bleibt, liegt der Schwerpunkt zunächst auf Security. Das Unternehmen muss unbefugte Zugriffe verhindern, Berechtigungen kontrollieren und Aktivitäten nachvollziehbar protokollieren.

Die Lage ändert sich, sobald der Zugang sicherheitsrelevante Einstellungen erreicht. Kann ein Angreifer über kompromittierte Zugangsdaten eine Schutztürüberwachung umgehen, eine sichere reduzierte Geschwindigkeit verändern oder einen Ablauf nach dem Ansprechen eines Not-Halts beeinflussen, entsteht neben dem IT-Risiko eine mögliche Gefährdung für Personen. Dann reicht es nicht mehr, den Zugriff im Netzwerkdiagramm oder im ISMS zu beschreiben.

Praktische Regel: Sobald ein erfolgreicher Angriff eine gefährliche Maschinenbewegung, den Verlust einer Schutzfunktion oder eine unzulässige Betriebsart auslösen kann, gehört das Szenario in die CE-Risikobeurteilung.

Das BSI beschreibt Prozessleit- und Automatisierungstechnik als Systeme, die physische Geräte, Prozesse und Ereignisse in industriellen Anlagen steuern. Wegen der zunehmenden IT-Komponenten besteht dort ein ähnlich hoher Gefährdungsgrad wie in der klassischen IT, während OT-spezifische Randbedingungen etablierte Sicherheitsverfahren erschweren. Diese Einordnung ist für Maschinenbauer relevant, weil Verfügbarkeit, Echtzeitverhalten und sichere Zustände in der OT unmittelbar zusammenhängen. Die BSI-Empfehlungen zu industriellen Steuerungs- und Automatisierungssystemen bilden dafür einen wichtigen technischen Referenzrahmen.

<a id="die-eigentliche-zuordnungsfrage"></a>

Die eigentliche Zuordnungsfrage

Für die tägliche Dokumentationsarbeit hilft eine einfache Kausalkette:

1. Welche Komponente oder Funktion kann ein Angreifer beeinflussen?
2. Welche Maschinenreaktion folgt daraus?
3. Kann diese Reaktion Personen, Umwelt oder die sichere Beherrschung der Maschine gefährden?
4. Welche Schutzmaßnahme verhindert die Manipulation und welche begrenzt die sichere Auswirkung?
5. Wo wird der Nachweis geführt, in der Risikobeurteilung, im Safety-Nachweis, im Security-Konzept oder in mehreren Dokumenten?

Viele KMU haben bereits technische Einzelmaßnahmen, etwa VPN-Zugänge, Rollenmodelle oder Passwortregeln. Was häufig fehlt, ist die nachvollziehbare Verbindung zur Maschinenfunktion. Ein Security-Konzept ohne Safety-Bezug erklärt nicht, warum ein Parameter geschützt werden muss. Eine Safety-Betrachtung ohne Security-Bezug erklärt nicht, wie die sicherheitsrelevante Funktion gegen Manipulation geschützt bleibt.

<a id="definitionen-und-schutzrichtungen-im-direkten-vergleich"></a>

Definitionen und Schutzrichtungen im direkten Vergleich

Safety und Security verfolgen unterschiedliche Schutzziele. Safety schützt Menschen und Umwelt vor unbeabsichtigten Fehlfunktionen. Security schützt Systeme, Daten und Funktionen vor absichtlichen Angriffen, unbefugter Veränderung und Manipulation.

Im Maschinenbau lassen sich beide Bereiche zunächst getrennt analysieren. Die Trennung endet dort, wo ein Security-Ereignis eine Safety-Funktion verändert oder außer Kraft setzt. Das IFA beschreibt diese Kopplung ausdrücklich: Sicherheitsfunktionen von Steuerungen bleiben nur zuverlässig, wenn das Steuerungssystem selbst gegen Manipulation, Angriffe, Netzwerkeinflüsse und Risiken an Schnittstellen abgesichert ist. Die IFA-Informationen zu Industrial Security ordnen Safety und Security deshalb als gekoppelte Anforderungen im Maschinen- und OT-Umfeld ein.

<a id="unterschiedliche-ursachen-gemeinsamer-effekt"></a>

Unterschiedliche Ursachen, gemeinsamer Effekt

Ein Safety-Fehler entsteht typischerweise ohne vorsätzlichen Angriff. Ein fehlerhaftes Signal, ein defekter Sensor oder eine unzureichende Steuerungsarchitektur kann eine gefährliche Situation auslösen. Security betrachtet dagegen den absichtlichen Einfluss auf Vertraulichkeit, Integrität oder Verfügbarkeit.

Für die CE-Bewertung zählt aber der resultierende gefährliche Zustand. Ob ein falscher Wert durch einen defekten Eingang oder durch einen manipulierten Remote-Zugriff entsteht, ändert nichts daran, dass die Maschine diesen Zustand beherrschen muss. Die Ursache bestimmt die zusätzliche Schutzstrategie. Das Schutzziel ergibt sich aus der konkreten Gefährdung.

Darum sollten CE-Beauftragte nicht versuchen, jedes Security-Thema vollständig in die Safety-Dokumentation zu übernehmen. Das würde die Risikobeurteilung unnötig aufblasen und Verantwortlichkeiten verwischen. Umgekehrt darf ein Unternehmen sicherheitsrelevante Cyber-Szenarien nicht in einem allgemeinen ISMS verstecken. Die technische Dokumentation muss erkennen lassen, warum eine Schutzfunktion trotz Netzwerk-, Schnittstellen- oder Manipulationsrisiken zuverlässig bleibt.

<a id="rechtliche-konsequenzen-unter-maschinenrichtlinie-und-maschinenverordnung"></a>

Rechtliche Konsequenzen unter Maschinenrichtlinie und Maschinenverordnung

Für die zeitliche Einordnung zählt der konkrete Bereitstellungszeitpunkt. Bis zum 19. Januar 2027 bleibt die Maschinenrichtlinie 2006/42/EG maßgeblich. Ab dem 20. Januar 2027 gilt die Maschinenverordnung (EU) 2023/1230. Die IHK nennt diesen Stichtag ausdrücklich für Hersteller und andere Wirtschaftsakteure in Deutschland. Die Informationen der IHK Halle zur Maschinenverordnung geben hierfür eine praxisnahe Orientierung.

Die neue Verordnung ersetzt die Maschinenrichtlinie. Nach der Einordnung der DGUV gibt es keine Übergangsphase, in der beide Rechtstexte alternativ angewendet werden können. Für Konformitätserklärung, technische Dokumentation und Marktbereitstellung entsteht damit ein harter Wechsel. Die DGUV erläutert den Cutover zur EU-Maschinenverordnung ausdrücklich als klare Abgrenzung.

<a id="was-sich-fur-die-dokumentation-andert"></a>

Was sich für die Dokumentation ändert

Die Maschinenverordnung bringt verbindliche Cybersicherheitsanforderungen für Maschinen. Für den CE-Prozess bedeutet das nicht, dass jede IT-Maßnahme automatisch Bestandteil der technischen Dokumentation wird. Dokumentationsrelevant werden insbesondere solche Security-Eigenschaften, die eine Maschine vor Korrumpierung schützen oder die Erfüllung von Sicherheits- und Gesundheitsschutzanforderungen beeinflussen.

Bei Maschinen aus Anhang IV der Maschinenrichtlinie sieht Artikel 12 eine bestimmte Konformitätsbewertungsmechanik vor. Wurde eine solche Maschine nach harmonisierten Normen gebaut und decken diese Normen alle relevanten grundlegenden Sicherheits- und Gesundheitsschutzanforderungen ab, kann der Hersteller das Verfahren nach Artikel 12 Absatz 3 oder 4 anwenden. Der Wortlaut der Maschinenrichtlinie 2006/42/EG ist für die Bewertung eines Projekts bis zum Stichtag entscheidend.

Unter der Maschinenverordnung müssen Hersteller die zutreffende Einstufung und das Verfahren anhand der dann geltenden Anforderungen prüfen. Das gilt besonders, wenn eine Manipulation sicherheitsrelevante Steuerungen, Software oder Schutzfunktionen betrifft. Die technische Dokumentation sollte dann nicht nur das Ergebnis der Safety-Bewertung zeigen, sondern auch die sicherheitsbezogene Begründung für Zugriffsschutz, Integrität und sichere Reaktion.

Für die Ablage und Verarbeitung technischer Unterlagen müssen Unternehmen außerdem Datenschutz und Zugriffssicherheit sauber trennen. Eine Orientierung zu organisatorischen Fragen rund um Datenschutz bei cloudbasierter Software kann dabei hilfreich sein, ersetzt aber keine projektspezifische Prüfung der eigenen technischen und rechtlichen Rahmenbedingungen. Eine vertiefte Einordnung der neuen Vorgaben bietet auch der Überblick zur Verordnung (EU) 2023/1230.

Hinweis: Dieser Beitrag enthält allgemeine Informationen und ersetzt keine rechtsverbindliche Beratung. Die Verantwortung für die Konformitätserklärung, die Auswahl des Konformitätsbewertungsverfahrens und die vollständige technische Dokumentation bleibt beim Hersteller.

<a id="schnittstellen-und-konfliktfalle-in-der-praxis"></a>

Schnittstellen und Konfliktfälle in der Praxis

Die entscheidende Abgrenzung lautet: Kann ein erfolgreicher Cyberangriff zu einer Gefährdung von Personen führen? Wenn die Antwort ja lautet, muss das Thema in der Maschinenbewertung berücksichtigt werden. Es bleibt zusätzlich ein Security-Thema, aber es ist nicht mehr ausschließlich Sache des ISMS.

Ein Remote-Wartungszugang ist dafür das typische Beispiel. Die Authentifizierung, Verschlüsselung und Protokollierung gehören zur Security. Wenn derselbe Zugang jedoch Parameter einer sicheren Bewegung verändert, muss die Risikobeurteilung die mögliche Maschinenreaktion bewerten. Die technische Lösung kann dann aus mehreren Ebenen bestehen, etwa einer getrennten Betriebsartenwahl, einer sicheren Abschaltung bei unbefugtem Zugriff und einer Begrenzung der zulässigen Parameter.

<a id="drei-entscheidungskriterien"></a>

Drei Entscheidungskriterien

Erstens, die Wirkung. Ein Angriff auf eine Produktionsdatenbank kann erhebliche betriebliche Folgen haben, ohne eine Maschinengefährdung im Sinne der Safety-Bewertung auszulösen. Ein manipuliertes Signal am Eingang einer Schutzeinrichtung ist anders zu bewerten, wenn dadurch eine gefährliche Bewegung trotz geöffneter Schutzeinrichtung möglich wird.

Zweitens, die Funktion. Fragen Sie nicht nur, ob ein Netzwerkanschluss existiert. Prüfen Sie, welche Befehle, Parameter, Firmwarebestandteile und Diagnosefunktionen über diese Schnittstelle erreichbar sind. Ein ausschließlich lesender Zugriff hat eine andere Safety-Relevanz als ein Zugriff mit Schreib- oder Update-Rechten.

Drittens, die Beherrschung. Die Dokumentation muss zeigen, wie die Maschine bei unzulässigen, widersprüchlichen oder nicht authentisierten Eingaben reagiert. Dazu gehören sichere Zustände, Plausibilitätsprüfungen und die Verhinderung eines unerwarteten Wiederanlaufs, sofern die konkrete Risikobeurteilung dies erfordert.

Entscheidungskriterium: Nicht der Angriffsweg entscheidet über die CE-Relevanz, sondern die gefährliche Wirkung an der Maschine.

Ein weiterer Konflikt entsteht bei Schutzmechanismen selbst. Verschlüsselte Kommunikation kann Manipulation erschweren, darf aber die Reaktionszeiten sicherheitsbezogener Funktionen nicht unkontrolliert verändern. Deshalb sollte die technische Bewertung nicht bei der Architekturzeichnung enden. Sie muss das tatsächliche Verhalten der Funktion unter den vorgesehenen Betriebsbedingungen berücksichtigen.

Für KMU lohnt sich eine separate Zuordnungsmatrix mit den Spalten Asset, Angriffsmöglichkeit, Maschinenwirkung, Safety-Relevanz, Security-Maßnahme, Safety-Maßnahme und Nachweisort. Eine allgemeine compliance checklist for midsize firms kann die organisatorische Struktur unterstützen, ersetzt jedoch keine maschinenspezifische Risikobeurteilung. Bei Funkkomponenten sollte zusätzlich geprüft werden, welche Anforderungen aus dem Funkrecht greifen. Der Beitrag zur Funkanlagenrichtlinie ordnet diesen angrenzenden Bereich ein.

<a id="integration-in-risikobeurteilung-und-konformitatsbewertung"></a>

Integration in Risikobeurteilung und Konformitätsbewertung

Die Integration funktioniert am zuverlässigsten, wenn Security nicht als nachträglicher Anhang zur CE-Dokumentation entsteht. Der Ausgangspunkt bleibt die Risikobeurteilung nach EN ISO 12100. In deren Rahmen müssen die Grenzen der Maschine, bestimmungsgemäße Verwendung, vernünftigerweise vorhersehbare Fehlanwendung und relevante Gefährdungen bestimmt werden. Bei vernetzten Maschinen gehören dazu auch Manipulationsszenarien, wenn sie eine gefährliche Maschinenreaktion auslösen können.

<a id="vorgehen-in-funf-arbeitsschritten"></a>

Vorgehen in fünf Arbeitsschritten

1. Maschinengrenzen festlegen: Erfassen Sie Steuerungen, Netzwerke, Funkverbindungen, Fernzugänge, externe Dienste und Wartungsschnittstellen. Dokumentieren Sie, welche Komponenten die Maschine beeinflussen können.

2. Manipulationsszenarien ergänzen: Beschreiben Sie nicht nur technische Fehler, sondern auch unbefugte Änderungen an Parametern, Programmen, Firmware oder Konfigurationen. Bewerten Sie die daraus entstehende Maschinenreaktion.

3. Safety-Relevanz entscheiden: Führt das Szenario zu einer möglichen Verletzung oder zum Verlust einer Schutzfunktion, gehört es in die Risikobeurteilung. Rein organisatorische IT-Risiken ohne Maschinenwirkung bleiben im geeigneten Security- oder ISMS-Prozess.

4. Risikominderung ableiten: Wenden Sie die 3-Stufen-Methode an. Beginnen Sie mit inhärent sicheren Konstruktionen, ergänzen Sie technische Schutzmaßnahmen und schließen Sie mit Benutzerinformationen und organisatorischen Vorgaben ab.

5. Wirksamkeit nachweisen: Für sicherheitsbezogene Steuerungsfunktionen bestimmen Sie den erforderlichen Performance Level, PLr, nach EN ISO 13849-1. Der erreichte Performance Level muss mindestens dem erforderlichen entsprechen, also PL ≥ PLr. Berechnungen und Annahmen gehören nachvollziehbar in die technische Dokumentation, beispielsweise über einen SISTEMA-Nachweis.

<a id="nachweisfuhrung-statt-manahmensammlung"></a>

Nachweisführung statt Maßnahmensammlung

Eine Liste mit Firewall, VPN und Passwortregeln reicht nicht. Die Dokumentation muss die Beziehung zwischen Maßnahme und Gefährdung zeigen. Ein Eintrag wie „Remote-Zugang abgesichert“ bleibt zu unpräzise, wenn nicht festgehalten wird, welche Rollen zugreifen dürfen, welche Funktionen erreichbar sind, wie Änderungen protokolliert werden und welcher sichere Zustand bei einer unzulässigen Eingabe eintritt.

In der technischen Dokumentation nach Anhang VII der Maschinenrichtlinie beziehungsweise nach den entsprechenden Anforderungen der Maschinenverordnung müssen die relevanten Safety- und Security-Entscheidungen konsistent erscheinen. Betriebsanleitungen sollten insbesondere sichere Wartungsabläufe, Berechtigungen, Update-Prozesse und Reaktionen bei verdächtigen Zuständen erklären, soweit diese für die sichere Verwendung der Maschine erforderlich sind.

Für die strukturierte Bearbeitung eignet sich der Leitfaden zur Risikobeurteilung nach EN ISO 12100. Auch eine Cloud-Plattform für Unternehmen kann für versionierte technische Unterlagen sinnvoll sein, wenn Zugriffsschutz, Verantwortlichkeiten und Aufbewahrung im konkreten Projekt angemessen geregelt sind.

<a id="praxisbeispiele-aus-dem-sondermaschinenbau"></a>

Praxisbeispiele aus dem Sondermaschinenbau

<a id="vernetzte-verpackungsanlage-mit-remote-diagnose"></a>

Vernetzte Verpackungsanlage mit Remote-Diagnose

Bei einer vernetzten Verpackungsanlage soll der Hersteller einen Wartungszugang anbieten. Der erste Entwurf sieht einen allgemeinen Fernzugriff auf die Steuerung vor. Das ist aus Security-Sicht leicht zu administrieren, schafft aber eine unnötig breite Angriffsfläche und erschwert die Safety-Bewertung.

Die bessere Lösung trennt Diagnose, Parametrierung und sicherheitsrelevante Eingriffe. Der Hersteller dokumentiert, welche Rollen welche Funktionen erreichen, wie die Authentifizierung erfolgt, wie die Kommunikation geschützt wird und welche Aktivitäten geloggt werden. Für die Maschinenbewertung wird zusätzlich festgehalten, dass ein unbefugter Zugriff keine gefährliche Betriebsart aktivieren darf, dass sicherheitsrelevante Änderungen eine kontrollierte Freigabe erfordern und dass die Maschine bei einem unzulässigen Zugriff in einen definierten sicheren Zustand wechselt.

Die Betriebsanleitung muss daraus einen nachvollziehbaren Ablauf machen. Sie beschreibt, wann Remote-Wartung zulässig ist, welche Voraussetzungen vorliegen müssen und wie der Betreiber einen verdächtigen Zugriff behandelt. In der technischen Dokumentation stehen dagegen die Begründung der Schutzmaßnahmen, die Prüfungen und die Verknüpfung mit den betroffenen Sicherheitsfunktionen.

<a id="kollaborierender-roboter-mit-ki-basierter-bahnplanung"></a>

Kollaborierender Roboter mit KI-basierter Bahnplanung

Bei einem kollaborierenden Roboter mit KI-basierter Bahnplanung liegt die kritische Frage nicht darin, ob KI verwendet wird. Entscheidend ist, ob ein manipuliertes Modell, veränderte Eingangsdaten oder eine kompromittierte Update-Kette eine gefährliche Bewegung ermöglichen kann.

Die Safety-Bewertung muss die Grenzen der Bahnplanung und die unabhängigen Schutzfunktionen klären. Eine KI-Komponente darf nicht stillschweigend die einzige Barriere gegen eine gefährliche Bewegung bilden, wenn die Risikobeurteilung zusätzliche, deterministische Schutzmaßnahmen verlangt. Security muss gleichzeitig die Integrität von Modell, Software, Konfiguration und Update-Prozess absichern.

Für die Dokumentation bedeutet das: Der Hersteller beschreibt die sicherheitsrelevanten Funktionen, die Annahmen über die KI-Komponente, die Begrenzung ihrer Ausgaben und die Reaktion bei ungültigen oder widersprüchlichen Ergebnissen. Unter der ab 20. Januar 2027 geltenden Maschinenverordnung müssen die zusätzlichen Anforderungen an digitale und cybersicherheitsbezogene Eigenschaften frühzeitig in die Projektplanung einfließen. Der Hersteller sollte nicht bis zur abschließenden Konformitätsbewertung warten, um diese Architekturentscheidung zu prüfen.

<a id="checkliste-fur-die-dokumentierte-umsetzung-im-kmu"></a>

Checkliste für die dokumentierte Umsetzung im KMU

Eine belastbare Projektakte sollte mindestens diese Punkte enthalten:

• Rechtsgrundlage bestimmen: Inverkehrbringen bis zum 19. Januar 2027 nach Maschinenrichtlinie 2006/42/EG bewerten, ab dem 20. Januar 2027 die Maschinenverordnung (EU) 2023/1230 anwenden.
• Normenrecherche dokumentieren: Zutreffende harmonisierte A-, B- und C-Normen für Safety prüfen und Security-Anforderungen, etwa aus der IEC-62443-Reihe, passend zum Anwendungsfall bewerten.
• Cyber-Szenarien erfassen: Remote-Zugänge, Netzwerke, Funk, Updates, externe Dienste und manipulierbare Parameter auf mögliche Maschinenwirkungen prüfen.
• Safety-Zuordnung begründen: Jedes Szenario mit möglicher Personen- oder Umweltgefährdung in die Risikobeurteilung nach EN ISO 12100 aufnehmen.
• Funktionale Sicherheit nachweisen: PLr nach EN ISO 13849-1 bestimmen, Architektur und Komponenten bewerten, PL ≥ PLr nachweisen und die Berechnung nachvollziehbar dokumentieren.
• Technische Dokumentation konsistent halten: Risikobeurteilung, Schaltpläne, Softwarebeschreibung, Prüfprotokolle, Betriebsanleitung und Konformitätserklärung müssen dieselben Sicherheitsannahmen verwenden.
• Betriebsinformationen ergänzen: Sichere Wartung, Berechtigungen, Updates, Wiederanlauf und Verhalten bei verdächtigen Zugriffen verständlich beschreiben.
• Verantwortung festhalten: Freigaben, Prüfungen und die finale Entscheidung zur Konformitätserklärung eindeutig zuordnen.

Für die Dokumentationserstellung kann CE-Copilot den geführten Workflow von der Richtlinienbestimmung über Risikobeurteilung und funktionale Sicherheit bis zur Konformitätserklärung abbilden. Die Inhalte müssen fachlich geprüft und an die konkrete Maschine angepasst werden. Diese Hinweise sind allgemeine Information und ersetzen keine rechtsverbindliche Beratung.

---

CE-Copilot unterstützt Sie dabei, Safety- und Security-relevante Entscheidungen in Risikobeurteilung, technischer Dokumentation und Betriebsanleitung strukturiert zusammenzuführen. Prüfen Sie den geführten CE-Workflow für Ihre Maschine direkt bei CE-Copilot.