Was ist OT Security im Maschinenbau

Eine Linie läuft sauber an. Dann meldet die HMI erst Kommunikationsfehler, kurz darauf reagiert die SPS nicht mehr wie erwartet. Die Instandhaltung sucht den Fehler in der Hardware, der Einkauf fragt nach Lieferterminen, der Kunde will wissen, ob die Abnahme hält. Parallel taucht im Audit die Frage auf, wie der Fernzugriff abgesichert ist und ob die technische Dokumentation den tatsächlichen Sicherheitszustand der Maschine überhaupt abbildet.

Genau an diesem Punkt wird klar, warum die Frage Was ist OT Security im Maschinenbau keine Theorie ist. Es geht nicht nur um Cyberabwehr. Es geht um Verfügbarkeit, funktionale Sicherheit, belastbare Konformitätsbewertung und um die Frage, ob der Hersteller seine Schutzmaßnahmen nachvollziehbar dokumentiert hat.

Inhaltsverzeichnis

• Einleitung zur OT Security
• Bedeutung und Abgrenzung von OT Security und IT Security
  • Was OT Security in der Maschine wirklich umfasst
  • Wo sich OT und IT praktisch unterscheiden
• Typische Angriffspfade in OT-Umgebungen
  • Der Einstieg passiert oft außerhalb der SPS
  • Warum Firewalls allein nicht reichen
• Fallstudien realer OT-Angriffe
  • Fall eins Ransomware bis an die Linie
  • Fall zwei Fernzugriff als Datenabfluss
• Technische und organisatorische Schutzmaßnahmen
  • Technische Kontrollen mit Wirkung
  • Organisation und Nachweise
• Normen und Compliance im OT Security Kontext
  • Was aus Maschinenrichtlinie und Maschinenverordnung folgt
  • Welche Dokumentationspflichten oft übersehen werden
• Handlungsempfehlungen für KMU und Sondermaschinenbauer
  • Prioritäten für die ersten Schritte
  • Typische Fehler in CE Projekten mit OT Bezug

<a id="einleitung-zur-ot-security"></a>

Einleitung zur OT Security

OT Security schützt die Systeme, die in der Produktion tatsächlich schalten, regeln, visualisieren und freigeben. Im Maschinenbau sind das nicht nur SPS, HMI und Antriebe, sondern auch Engineering Workstations, industrielle Netzwerkkomponenten, Fernwartungszugänge und die Kommunikationswege zwischen ihnen.

Wer OT Security auf Antivirus und eine Firewall reduziert, übersieht das eigentliche Problem. Eine Maschine kann formal sauber konstruiert sein und trotzdem in einen unsicheren Zustand geraten, wenn Zugriffe, Updates oder Netzsegmente schlecht beherrscht sind. Für Hersteller ist das relevant, weil technische Schutzmaßnahmen und organisatorische Regeln nicht nur umgesetzt, sondern im Rahmen von Risikobeurteilung, technischer Dokumentation und Betriebsanleitung konsistent beschrieben werden müssen.

<a id="bedeutung-und-abgrenzung-von-ot-security-und-it-security"></a>

Bedeutung und Abgrenzung von OT Security und IT Security

<a id="was-ot-security-in-der-maschine-wirklich-umfasst"></a>

Was OT Security in der Maschine wirklich umfasst

OT Security bedeutet im Maschinenbau den Schutz von Steuerungsnetzen, Automatisierungskomponenten und Anlagenkommunikation. Dazu gehören unter anderem:

• Steuerungsebene mit SPS, Safety-Controllern, I/O und Feldbuskopplern
• Bedien- und Visualisierungsebene mit HMI, SCADA oder Panel-PCs
• Engineering und Service mit Programmiergeräten, Wartungslaptops und Fernwartungszugängen
• Kommunikationsinfrastruktur mit industriellen Switches, Firewalls, VPN-Gateways und Protokollübergängen
• OT-nahe Server wie Historian, Rezepturverwaltung oder Produktionsfreigaben

Zur Einordnung der Begriffe hilft dieser Überblick:

Wer die Schnittstelle organisatorisch sauber definieren will, findet im Beitrag zur Bedeutung von IT und OT im Maschinenbau eine gute begriffliche Ergänzung.

<a id="wo-sich-ot-und-it-praktisch-unterscheiden"></a>

Wo sich OT und IT praktisch unterscheiden

In der IT steht meist der Schutz von Daten, Identitäten und Büroanwendungen im Vordergrund. In der OT zählen andere Prioritäten zuerst. Verfügbarkeit und sicherer Prozesszustand schlagen fast immer den Wunsch nach schnellen Änderungen. Ein Security-Update, das einen Office-PC kurz neu startet, ist in einer laufenden Fertigung oft nicht akzeptabel.

Die Unterschiede zeigen sich in drei Fragen:

Praxisregel: In der OT ist eine technisch richtige Maßnahme wertlos, wenn sie den Prozess destabilisiert oder die Validierung der Maschine aushebelt.

Was in IT-Umgebungen gut funktioniert, scheitert in der Fertigung oft an Echtzeitverhalten, Altanlagen, proprietären Treibern oder Herstellerfreigaben. Deshalb braucht OT Security eigene Regeln für Segmentierung, Zugriff, Backup, Wiederherstellung und Änderungsmanagement.

<a id="typische-angriffspfade-in-ot-umgebungen"></a>

Typische Angriffspfade in OT-Umgebungen

<a id="der-einstieg-passiert-oft-auerhalb-der-sps"></a>

Der Einstieg passiert oft außerhalb der SPS

Angreifer beginnen selten direkt auf der Steuerungsebene. Der erste Zugriff erfolgt häufiger über einen Büroarbeitsplatz, ein kompromittiertes Notebook eines Dienstleisters oder einen unzureichend kontrollierten Fernzugang. Von dort arbeiten sie sich weiter in OT-nahe Systeme vor.

Die typische Kette sieht so aus:

In der Praxis tauchen diese Pfade immer wieder auf:

• Phishing und kompromittierte Clients öffnen den ersten Zugang zu Benutzerkonten, Engineering-Dateien oder VPN-Zugängen.
• Laterale Bewegung über Windows-Hosts bringt Angreifer in Bereiche, in denen HMI, SCADA oder Engineering-Systeme erreichbar sind.
• Manipulierte Updates oder Projektdateien treffen die OT besonders hart, weil sie direkt in den Betriebszustand eingreifen können.
• Unscharfer Remote Access ist ein Dauerproblem. Gemeinsame Konten, dauerhaft offene Tunnel und fehlende Freigabeprozesse sind klassische Schwachstellen.

Einordnen lässt sich die Relevanz auch quantitativ. Die ENISA meldet in ihrem Bedrohungsbericht von 2025, dass 28 % der Cybervorfälle in der Industrieproduktion OT-basiert waren (ENISA Threat Landscape 2025).

Später im Abschnitt hilft dieses Video, die Angriffskette aus Betriebssicht greifbarer zu machen.

<iframe width="100%" style="aspect-ratio: 16 / 9;" src="https://www.youtube.com/embed/w1dgulwlP3c" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe>

<a id="warum-firewalls-allein-nicht-reichen"></a>

Warum Firewalls allein nicht reichen

Viele Maschinenbauer sichern den Übergang zwischen Unternehmensnetz und Anlage mit einer Firewall und halten das Thema damit für erledigt. Das ist zu kurz gedacht. Wenn innerhalb der Zelle alle Geräte frei miteinander sprechen dürfen, wenn Service-Accounts geteilt werden oder wenn Engineering-Rechner ohne Härtung eingesetzt werden, entsteht das Risiko innerhalb des vermeintlich geschützten Bereichs.

Besonders kritisch wird es bei industriellen Protokollen wie OPC UA oder Modbus. Das Problem ist oft nicht das Protokoll allein, sondern dessen Einbettung in eine unklare Architektur. Wer Kommunikationsbeziehungen nicht bewusst freigibt, bekommt später weder saubere Segmentierung noch belastbare Audit-Nachweise.

OT-Security-Vorfälle beginnen häufig mit einer organisatorischen Lücke und enden als technisches Problem auf der Linie.

Wirksam wird Schutz erst, wenn Segmentierung, Zugriffskontrolle, Wiederherstellung und dokumentierte Freigaben zusammenpassen.

<a id="fallstudien-realer-ot-angriffe"></a>

Fallstudien realer OT-Angriffe

<a id="fall-eins-ransomware-bis-an-die-linie"></a>

Fall eins Ransomware bis an die Linie

Ein typisches Muster aus der Praxis: Ein Dienstleister verbindet ein Engineering-Notebook mit einer Anlage, nachdem das Gerät zuvor in einer weniger kontrollierten Umgebung genutzt wurde. Einige Zeit später sind HMI und zugehörige Windows-Systeme verschlüsselt. Die SPS läuft noch, aber Bedienung, Diagnose und Freigabe funktionieren nicht mehr zuverlässig.

Die unmittelbare Folge ist nicht nur Stillstand. Es entstehen auch Fragen zur Konformitätsbewertung. Wenn Bedien- und Sicherheitsinformationen auf der HMI nicht mehr verfügbar sind oder Prozesszustände nicht mehr sauber quittiert werden, ist schnell unklar, ob die Maschine noch bestimmungsgemäß betrieben wird.

Die Lehre daraus ist banal, aber oft nicht umgesetzt: Servicegeräte brauchen einen eigenen Sicherheitsstandard, klare Freigaben und einen dokumentierten Prozess für die Kopplung an OT-Systeme.

<a id="fall-zwei-fernzugriff-als-datenabfluss"></a>

Fall zwei Fernzugriff als Datenabfluss

Ein anderes Bild zeigt sich bei Fernwartung. Ein Hersteller oder Integrator richtet einen VPN-Zugang ein, der technisch funktioniert, aber organisatorisch kaum begrenzt ist. Kein zeitlich beschränkter Zugriff, keine saubere Benutzertrennung, kein belastbares Logging. Über genau diesen Weg lassen sich Rezepturen, Parameterstände oder projektrelevante Dateien abziehen, ohne die Maschine sofort stillzulegen.

Das wird im Audit gern unterschätzt. Der Schaden ist nicht nur betriebswirtschaftlich. Wenn Konfigurationsstände nicht mehr eindeutig nachvollziehbar sind, leidet auch die technische Dokumentation. Dann passt der dokumentierte Zustand nicht mehr zum installierten Zustand.

Wer Fernzugriff zulässt, muss nicht nur den Tunnel absichern. Er muss auch belegen können, wer wann woran gearbeitet hat.

<a id="technische-und-organisatorische-schutzmanahmen"></a>

Technische und organisatorische Schutzmaßnahmen

<a id="technische-kontrollen-mit-wirkung"></a>

Technische Kontrollen mit Wirkung

Im Maschinenbau funktionieren keine Wunschlisten, sondern Maßnahmen, die den Betrieb aushalten. Diese Übersicht zeigt die zentralen Bausteine:

Die wirksamen Kontrollen sind meist unspektakulär, aber konsequent umgesetzt:

• Netzwerksegmentierung mit Zonen und Conduits
  Trennen Sie Steuerung, Visualisierung, Engineering, Fernzugriff und Unternehmensanbindung logisch und, wo nötig, physisch. Entscheidend ist nicht die Zeichnung im Lastenheft, sondern eine gepflegte Kommunikationsmatrix. Dokumentieren Sie freigegebene Verbindungen als Teil der technischen Unterlagen.

• Zugriff nach Rollen und Zweck
  Bediener, Instandhalter, Integratoren und Hersteller brauchen unterschiedliche Rechte. Gemeinsame Administrator-Accounts sind in OT-Umgebungen ein Dauerfehler. Legen Sie fest, wer Parameter ändern, Programme übertragen oder nur Diagnose lesen darf. Diese Rollenbeschreibung gehört in Ihre internen Sicherheitsvorgaben und muss zu den Betriebsprozessen passen.

• Härtung von Engineering- und HMI-Systemen
  Ein HMI ist kein normaler Bürorechner. Entfernen Sie unnötige Dienste, begrenzen Sie Wechseldatenträger, sperren Sie nicht benötigte Schnittstellen und definieren Sie klare Freigabewege für Softwareänderungen. In der Dokumentation sollte nachvollziehbar sein, welcher Baseline-Zustand freigegeben ist.

• OT-taugliches Patch- und Update-Management
  Patches werden nicht blind ausgerollt. Erst testen, dann freigeben, dann geplant einspielen. Für SPS-Firmware, Visualisierung, Treiber und Sicherheitskomponenten braucht es einen Änderungsprozess mit Bewertung der Auswirkungen auf Funktion und Sicherheit.

• Monitoring und Erkennung
  Sichtbarkeit ist Pflicht. Protokollieren Sie Anmeldungen, Konfigurationsänderungen, Kommunikationsabweichungen und Fernzugriffe. IDS, zentrale Log-Sammlung oder herstellerspezifische Diagnosefunktionen sind Werkzeuge. Entscheidend ist, dass jemand die Meldungen bewertet und Konsequenzen zieht.

<a id="organisation-und-nachweise"></a>

Organisation und Nachweise

Technik ohne Zuständigkeit versandet. Gerade in KMU ist oft unklar, wer OT Security fachlich führt. Deshalb braucht es mindestens eine einfache, belastbare Organisationsstruktur.

Eine praxistaugliche Checkliste:

1. Verantwortlichkeiten festlegen
   Konstruktion, Elektrotechnik, Software, Service, IT und Geschäftsführung müssen ihre Rollen kennen. Wer gibt Fernzugriffe frei. Wer entscheidet Updates. Wer pflegt die Nachweise.

2. Risikobeurteilung erweitern
   In der Risikobeurteilung nach EN ISO 12100 tauchen Cyber-bezogene Ursachen oft gar nicht auf, obwohl sie sicherheitsrelevante Funktionen beeinflussen können. Prüfen Sie, ob Manipulation, unautorisierte Änderung oder Kommunikationsverlust zu gefährlichen Situationen führen.

3. Sicherheitsfunktionen sauber abgrenzen
   Wenn eine Schutzmaßnahme Einfluss auf sicherheitsbezogene Teile der Steuerung hat, muss die Betrachtung zur EN ISO 13849-1 passen. Der erforderliche Performance Level wird nicht durch Cybersecurity ersetzt. Aber Cyberereignisse können Sicherheitsfunktionen unwirksam machen. Genau diese Schnittstelle wird oft übersehen.

4. Notfall und Wiederanlauf planen
   Halten Sie fest, wie Sie Projektstände, Parametrierungen, HMI-Images und Konfigurationen wiederherstellen. Ein Backup ohne getesteten Restore ist kein tragfähiges Konzept.

5. Schulung für reale Rollen
   Instandhalter brauchen andere Inhalte als Konstrukteure oder externe Servicetechniker. Schulen Sie entlang der tatsächlichen Zugriffe, nicht entlang eines allgemeinen Awareness-Foliensatzes.

<a id="normen-und-compliance-im-ot-security-kontext"></a>

Normen und Compliance im OT Security Kontext

<a id="was-aus-maschinenrichtlinie-und-maschinenverordnung-folgt"></a>

Was aus Maschinenrichtlinie und Maschinenverordnung folgt

Für Maschinenbauer ist der Kernpunkt nicht, ob OT Security ein IT-Thema ist, sondern welche Pflichten sich für Hersteller ergeben. Dabei muss sauber zwischen der Maschinenrichtlinie 2006/42/EG und der ablösenden Maschinenverordnung (EU) 2023/1230 unterschieden werden. Die Maschinenverordnung ist verbindlich ab 20. Januar 2027. Wer sich auf die Umstellung vorbereitet, sollte die Anforderungen früh in Konstruktion, Software und Dokumentation aufnehmen. Eine kompakte Einordnung bietet der Beitrag zur Maschinenverordnung 2023/1230.

Für die Praxis zählt vor allem dies:

• Die Konformitätsbewertung muss den tatsächlichen Aufbau der Maschine abbilden.
• Die Konformitätsvermutung setzt voraus, dass einschlägige harmonisierte Normen korrekt angewendet werden.
• A-, B- und C-Normen sind nicht austauschbar. Die Risikobeurteilung nach EN ISO 12100 bleibt der Ausgangspunkt.
• Wenn sicherheitsbezogene Teile von Steuerungen betroffen sind, ist die Auslegung nach EN ISO 13849-1 sauber zu begründen.

Zur Orientierung hilft diese Gegenüberstellung:

<a id="welche-dokumentationspflichten-oft-ubersehen-werden"></a>

Welche Dokumentationspflichten oft übersehen werden

Die meisten Lücken liegen nicht in der CE-Erklärung, sondern davor. Übersehen werden oft:

• Fernwartungskonzept mit Freigabe, Authentisierung und Protokollierung
• Änderungsmanagement für SPS-Software, HMI-Projekte, Firmware und Netzparameter
• Nachweis des Soll-Zustands von Kommunikationsbeziehungen und Benutzerrechten
• Abgleich zwischen Risikobeurteilung, Schaltplan, Softwarestand und Betriebsanleitung

Gerade bei Retrofit, kundenspezifischen Optionen und Sondermaschinen reißt diese Kette schnell ab. Dann stimmt die Maschine technisch noch, aber der Nachweis ist lückenhaft. Für Unternehmen, die ihre OT-Sicherheitsorganisation mit regulatorischen Anforderungen zusammendenken wollen, kann ein Überblick zu GSL Groß GmbH NIS2 Services hilfreich sein, weil dort Risikomanagement und organisatorische Pflichten in einem industrietauglichen Kontext eingeordnet werden.

Diese Inhalte sind allgemeine Informationen und ersetzen keine rechtsverbindliche Beratung. Die Verantwortung für die Konformitätserklärung bleibt beim Hersteller.

<a id="handlungsempfehlungen-fur-kmu-und-sondermaschinenbauer"></a>

Handlungsempfehlungen für KMU und Sondermaschinenbauer

<a id="prioritaten-fur-die-ersten-schritte"></a>

Prioritäten für die ersten Schritte

Kleine und mittlere Maschinenbauer brauchen keinen theoretischen Reifegradplan. Sie brauchen einen belastbaren Start. Die Reihenfolge ist wichtiger als der Werkzeugkatalog.

Beginnen Sie mit vier Arbeitspaketen:

• Erstens die Risikobeurteilung schärfen
  Prüfen Sie in der EN ISO 12100-Systematik, an welchen Stellen unautorisierte Änderungen, Kommunikationsausfälle oder fehlerhafte Updates gefährliche Situationen auslösen können. Das gehört nicht in einen IT-Anhang, sondern in die eigentliche Gefährdungsbetrachtung.

• Zweitens die OT-Architektur festziehen
  Legen Sie fest, welche Systeme in welche Zone gehören, welche Verbindungen erlaubt sind und wie Servicezugriffe freigegeben werden. Wenn Sie dazu Orientierung für Betreiber- und Dienstleisteranforderungen suchen, ist die Einordnung zu IEC 62443-2-4 im Maschinenbau nützlich.

• Drittens Dokumentation und Realität zusammenführen
  Schaltplan, Netzstruktur, Benutzerrollen, Softwarestände und Betriebsanleitung müssen denselben Ist-Zustand beschreiben. Genau hier verlieren viele Unternehmen Zeit bei Abnahmen und Audits.

• Viertens Wiederherstellung üben
  Sichern Sie Projekte, Konfigurationen und Images so, dass ein definierter Wiederanlauf möglich ist. Der Test des Restore-Prozesses ist wichtiger als die Existenz des Backups auf dem Papier.

Entscheidungshilfe: Wenn eine Maßnahme technisch sinnvoll ist, aber niemand ihren Zustand nachweisen kann, fehlt Ihnen im Ernstfall die halbe Wirksamkeit.

<a id="typische-fehler-in-ce-projekten-mit-ot-bezug"></a>

Typische Fehler in CE Projekten mit OT Bezug

In Sondermaschinenprojekten sehe ich dieselben Muster immer wieder:

Für viele KMU lohnt sich deshalb ein einfaches Set verbindlicher Standards: freigegebene Fernwartung, definierte Rollen, feste Backup-Regeln, Änderungsprozess und klare Dokumentenvorlagen. Das ist weniger glamourös als ein neues Security-Tool, wirkt aber meist zuerst.

Wenn Sie die Dokumentationsseite mitdenken wollen, kann CE-Copilot als Werkzeug für Risikobeurteilung, Konformitätsbewertung, technische Unterlagen und spätere Anpassungen an die Maschinenverordnung eingesetzt werden. Relevant ist das vor allem dann, wenn OT-Sicherheitsmaßnahmen nachvollziehbar in CE-Dokumente und Betriebsunterlagen überführt werden sollen.

Diese Inhalte sind allgemeine Informationen und ersetzen keine rechtsverbindliche Beratung. Die Verantwortung für die Konformitätserklärung und für die konkrete Auslegung im Einzelfall bleibt beim Hersteller.

---

Wer OT Security im Maschinenbau sauber angeht, spart vor allem Abstimmungsaufwand zwischen Konstruktion, Automatisierung, Service und CE-Verantwortung. CE-Copilot unterstützt dabei, Risikobeurteilung, Konformitätsbewertung und technische Dokumentation in einer durchgängigen Struktur zu pflegen, statt OT-relevante Nachweise über Dateien, Mails und Einzelstände zu verteilen.