Operational Technology (OT) ist längst kein Nischenthema mehr. Sobald physische Prozesse zuverlässig funktionieren müssen – egal ob in einer Produktionslinie, einem Umspannwerk, einer Wasseraufbereitung oder einem großen Gebäudecampus – steckt dahinter OT. Security ist ein Fundament, damit OT zuverlässig funktioniert: Nicht im Sinne von „OT ist ein Security-Problem“, sondern weil echte Resilienz nur entsteht, wenn IT und OT konsequent zusammenarbeiten. Es ist kein Entweder-oder, sondern ein Sowohl-als-auch – und genau dort lassen sich Lücken schließen und Synergien heben.
Dieser Artikel ist ein Grundlagen-Guide für technische Entscheider: Was ist OT? Welche Systeme gehören dazu? Wo begegnet dir OT in der Praxis (Industrie, KRITIS, Gebäude)? Wie sieht typische OT-Architektur aus (Purdue-Modell)? Warum wachsen IT und OT zusammen? Security und Standards behandeln wir bewusst kompakt – als Querschnitt, der aus der OT-Grundlogik heraus verständlich wird.
Dieser Artikel ist ein Grundlagen-Guide für technische Entscheider: Was ist OT? Welche Systeme gehören dazu? Wo begegnet dir OT in der Praxis (Industrie, KRITIS, Gebäude)? Wie sieht typische OT-Architektur aus (Purdue-Modell)? Warum wachsen IT und OT zusammen? Security und Standards behandeln wir bewusst kompakt – als Querschnitt, der aus der OT-Grundlogik heraus verständlich wird.
Was ist Operational Technology (OT)?
Operational Technology (OT) umfasst Hardware und Software, die physische Prozesse in Maschinen, Anlagen und Infrastrukturen überwachen, steuern oder verändern – häufig in Echtzeit.
OT ist die Gesamtheit der Technologien, die physische Prozesse in Anlagen und Infrastrukturen überwachen und steuern – meist in Echtzeit.
Abgrenzung: OT steuert physisch, IT verarbeitet Informationen
Eine einfache, praxistaugliche Abgrenzung lautet:
- OT: steuert/überwacht physische Prozesse (Ventile, Motoren, Fördertechnik, HLK-Anlagen, Schaltfelder).
- IT: verarbeitet Informationen und Business-Prozesse (E-Mail, ERP, CRM, Fileservices, Collaboration).
In modernen Umgebungen verschwimmen die Grenzen – OT-Systeme kommunizieren mittels IP, Daten werden analysiert, Herstellerzugriffe finden remote via VPN statt. Trotzdem hilft die Abgrenzung, Verantwortung und Prioritäten zu klären: Wenn Verfügbarkeit, Safety und deterministische Steuerung dominieren, befindest du dich in der OT.
Der OT-„Baukasten": Was gehört dazu?
OT wirkt häufig komplex, lässt sich aber gut über vier Bausteine erklären:
- Feldebene (Process/Floor) Sensoren (z. B. Temperatur, Druck), Aktoren (Ventile), Antriebe, Robotik – hier passiert die physische Arbeit.
- Steuerungsebene (Control) SPS/PLC, DCS-Controller oder RTUs führen Logik aus und regeln Prozesse.
- Leit- und Bedienebene (Supervisory/Operations) HMI, SCADA, Engineering Stations, Alarmierung – Menschen überwachen hier Zustände und greifen ein.
- Daten- und Integrationsebene (Operations IT) Historian, MES-Anbindung, Reporting, Schnittstellen zu IT/Cloud/Edge – hier werden OT-Daten nutzbar gemacht.
Der Nutzen dieses Baukastens ist praktisch: Er schafft Klarheit, wo etwas wirkt (physisch/steuernd/überwachend/integrativ) – und damit auch, welche Anforderungen gelten (Echtzeit, Change Windows, Verfügbarkeit).
Die unterschiedlichen Bereiche von OT
Häufig wird OT mit Maschinenbau oder Produktion gleichgesetzt. Das ist jedoch nicht korrekt. Die physischen Prozesse der OT müssen zuverlässig funktionieren und decken weitaus mehr Bereiche ab.
Typische OT-Domänen
Industrie & Fertigung
KRITIS & Versorgung (Utilities)
Transport & Logistik
Prozessindustrie (Chemie, Raffinerien, Kraftwerke)
Gebäudeautomation & Campus-Management (BMS/BAS)
Besonders das Gebäudemanagement in großen Gebäuden oder auf Firmengeländen ist ein typisches OT-Umfeld: physische Anlagen mit langen Lebenszyklen, viele Dienstleister, heterogene Protokolle – und gleichzeitig zahlreiche Schnittstellen zur IT, etwa bei Netzwerk, Identitäten, Monitoring oder Remote Access.
OT ist kein Branchenlabel, sondern ein Muster: physische Steuerung, hohe Verfügbarkeitsanforderungen, lange Lebenszyklen und Lieferantenökosysteme.
Welche Systeme gehören zur OT? (Komponenten im Überblick)
OT-Infrastrukturen sind sehr vielfältig. Einige Systeme sind jedoch häufig anzutreffen:
SPS / PLC (Speicherprogrammierbare Steuerungen)
SPS/PLCs steuern Maschinen, Zellen oder Linien: Signale einlesen, Logik ausführen, Aktoren ansteuern. In vielen Umgebungen sind PLCs die zentrale Instanz für deterministische Abläufe – und damit oft „betriebskritisch“.
Wichtige Eigenschaften:
- Echtzeit-/Determinismus-Anforderungen
- Lange Lebenszyklen
- Hersteller-Toolchains (Engineering Software, Firmware, Bibliotheken)
DCS (Distributed Control Systems / Prozessleitsysteme)
Ein DCS ist typisch für kontinuierliche Prozesse. DCS-Plattformen sind oft stark integriert: Controller, Engineering, Operator-Stationen, Alarmierung, Historisierung – alles in einem Ökosystem.
SCADA (Supervisory Control and Data Acquisition)
SCADA ist die zentrale Überwachung/Steuerung verteilter Anlagen: Status, Alarme, Trends, Schaltbefehle. SCADA taucht besonders häufig in Versorgungsnetzen und verteilten Infrastrukturen auf.
HMI (Human Machine Interface)
HMI ist die Bedien- und Visualisierungsebene: Prozessbilder, Alarme, Eingaben. HMIs sind in der Praxis häufig Windows-basiert oder embedded und sitzen nahe an Maschinen/Anlagenbereichen.
RTU (Remote Terminal Unit)
RTUs arbeiten an entfernten Standorten: Daten erfassen, weiterleiten, Remote-Kommandos ausführen. Typisch in Energie, Wasser, Pipelines und anderen Remote-Infrastrukturen.
Engineering Stations (oft unterschätzt)
Engineering Stations sind die Systeme, mit denen SPS/DCS/HMI konfiguriert und programmiert werden. Sie bündeln Änderungsrechte – und sind deshalb im Betrieb besonders sensibel. Nicht, weil „Security“ hier sofort das Thema sein muss, sondern weil Änderungen in OT teuer sind und häufig Produktionsfenster benötigen.
Historian / Datenplattform
Ein Historian sammelt Zeitreihen (Prozessdaten, Zustände, Alarme) und macht sie für Analyse/Reporting verfügbar. Historian-Architekturen sind oft der Startpunkt für MES-Integration, OEE, Qualitätsanalysen und später auch Analytics/IIoT.
Building Automation (BMS/BAS)
Gebäude-OT (HLK, Zutritt, Beleuchtung, Sicherheitstechnik) wird organisatorisch oft getrennt betrachtet, ist technisch aber OT. Gerade in großen Liegenschaften ist BMS/BAS ein klassischer OT-Stack – mit eigenen Netzsegmenten, Protokollen und Dienstleisterzugängen.
Übergang: Sobald man diese Komponenten nebeneinander sieht, wird klar: OT ist technisch nah an IT-Infrastruktur (Netze, Server, Interfaces) – folgt aber anderen Prioritäten. Das zeigt der direkte Vergleich.
IT vs. OT – die Unterschiede, die in der Praxis zählen
Der Vergleich zwischen IT und OT zeigt, warum es zwei komplett unterschiedliche Dinge sind. Selbst wenn die Netzwerk-Infrastruktur beispielsweise manchmal ähnlich aussieht.
Der folgende Vergleich zeigt, dass die Prioritäten anders gesetzt sind.
Vergleichstabelle (für schnelle Einordnung)
Kriterium |
IT |
OT |
|---|---|---|
|
Primärziel |
Daten & Geschäftsprozesse |
Physische Prozesse steuern |
|
Top-Priorität |
Vertraulichkeit/Integrität |
Verfügbarkeit |
|
Lebenszyklus |
3–5 Jahre typisch |
10–25 Jahre häufig |
|
Updates/Patches |
regelmäßig, teils automatisiert |
selten, geplant, abnahme-/stillstandsgetrieben |
|
Ausfalltoleranz |
Minuten oft akzeptabel |
Sekunden können kritisch sein |
|
Change-Prozess |
standardisiert, häufig |
abhängig von Produktionsfenstern/Abnahmen |
|
Protokolle |
TCP/IP, HTTP(S), SQL |
Modbus, Profinet, OPC UA, BACnet/KNX u. a. |
Netzwerkprinzipien sind ähnlich – die Realität ist anders
Wichtiges Praxis-Fazit: IT- und OT-Netzwerke unterscheiden sich im Grundaufbau oft weniger als gedacht. Switches, VLANs, Routing, Redundanz – vieles ist vertraut.
Die Herausforderungen entstehen im Betrieb:
- Anbindungen & Herstellerökosysteme: Die Hersteller sind etabliert und bekannt. Die Kommunikation erfolgt mit verschiedenen Ansprechpartnern aus IT, Elektrik, Instandhaltung, Anlagenbauern und Servicedienstleistern.
- Umweltbedingungen: Die verbauten Komponenten sind oft erschwerten Bedingungen wie Staub, Kälte, Hitze, Nässe oder Öl ausgesetzt. Dies gilt es bei der Komponentenauswahl zu beachten.
- Handling & Manageability: Die Verantwortlichen für eine OT-Infrastruktur haben oft wenig Berührungspunkte mit IT. Die Verwaltung der Komponenten muss daher „einfach“ sein und es muss funktionieren.
Diese Herausforderungen zeigen klar, dass OT sich zur IT unterscheidet und andere Anforderungen besitzt. Architekturmodelle wie das Purdue-Modell können in der Praxis hilfreich und wertvoll sein.
OT-Netzwerkarchitektur: Purdue-Modell einfach erklärt
Das Purdue-Modell ist eine Referenzarchitektur, um industrielle Systeme und Netze in Ebenen zu strukturieren. Das Modell ordnet Systeme logisch ein und stellt die Übergänge bewusst dar.
Im oberen Bereich befinden sich eher IT-nahe Systeme. Je weiter man nach unten geht, desto näher kommt man an den physischen Prozess – und die Wichtigkeit der Verfügbarkeit nimmt stetig zu.
Zonen & Schnittstellen statt „flache Netze“
Eine wichtige Grundregel in einer OT-Infrastruktur ist, dass Systeme in Zonen gruppiert und Übergänge bewusst gestaltet werden. Diese Grundregel befolgt diverse Normen, und das Purdue-Modell zeigt dies sehr gut.
DMZ zwischen Level 3 und 4 (als Architekturprinzip)
In einer OT-Infrastruktur wird zwischen Level 3 und 4 oftmals von einer OT-DMZ oder Übergabezone gesprochen. Für diese Zone gelten wichtige Grundprinzipien:
- Datenflüsse werden granular definiert und geregelt.
- Eine Kommunikation von „unten“ nach „oben“ ist zu bevorzugen.
- Kernsysteme werden nicht „direkt“ geöffnet.
- Integrationen werden skalierbar und betrieblich beherrschbar gestaltet.
OT-Protokolle (nur das Wesentliche)
OT-Protokolle wie Modbus, Profinet oder BACnet sind oft historisch gewachsen und robust gestaltet. Security ist oft wenig bis gar nicht implementiert. Klare Übergänge und granular definierte Zugriffe sind daher umso wichtiger.
OT-Designprinzipien aus der Praxis
Der tägliche Betrieb der OT-Infrastruktur entscheidet letztendlich über den Erfolg:
- Zuverlässigkeit: Die Komponenten müssen in den rauen Umgebungen zuverlässig funktionieren.
- Verwaltbarkeit: Der Betrieb und die potentielle Fehleranalyse müssen einfach gestaltet sein, sodass der physische Prozess nur minimal beeinträchtigt wird.
- Herstellerökosysteme: Nutzung der Vorteile von Hersteller-Schnittstellen und Definition von klaren Verantwortlichkeiten.
Wie das Purdue-Modell zeigt, sprechen dort bereits IT- und OT-Systeme und deren Daten über unterschiedliche Layer miteinander. Man spricht von der sogenannten IT/OT-Konvergenz.
IT/OT-Konvergenz & IIoT: Warum vernetzt man IT und OT?
Die IT/OT-Konvergenz bzw. die Vernetzung von IT und OT und die Nutzung von Daten aus dem physischen Prozess bietet viele Vorteile:
- Transparenz: Nahezu Echtzeit-Einsicht in reale Daten des Prozesses.
- Predictive Maintenance: Durch die Verwendung der Daten können ungeplante Stillstände ggf. reduziert werden.
- Remote Operations: Diagnosen und Serviceeinsätze können überwiegend remote durchgeführt werden.
- Prozessoptimierung: Analyse der vorhandenen Daten kann zur Prozessoptimierung genutzt werden.
IIoT als initialer Startschuss: Daten nutzbar machen ohne größere Änderungen
IIoT-Komponenten wie Edge-Gateways und Sensoren können oftmals in Bestandsanlagen verbaut werden, um vorhandene Daten zu exportieren und zu nutzen. Hierzu ist oftmals noch keine komplette Vernetzung mit der IT notwendig. Jedoch sollte bereits jetzt überlegt werden, wie diese Daten sicher exportiert und bereitgestellt werden.
Der praktische Stolperstein: Schnittstellen, Herstellerzugänge, Verantwortlichkeiten
Die Notwendigkeit einer IT/OT-Konvergenz zeigt sich oftmals in unterschiedlichen Use-Cases:
- „Der Hersteller braucht Fernwartung.“
- „Wir müssen Daten ins MES/Reporting bekommen.“
- „Wir wollen unsere Standorte zentral überwachen und steuern.“
Hier entscheidet weniger die Frage „ob“, sondern „wie”:
- Welche Daten dürfen wohin?
- Wer verantwortet Zugänge?
- Wie werden Änderungen abgestimmt?
- Wie werden Synergien genutzt, ohne neue Lücken zu erzeugen?
OT als Teil der gesamtheitlichen Security-Strategie
OT muss als Teil der gesamtheitlichen Security-Strategie integriert werden. Hierbei können die bereits vorhandenen Teile der Security-Strategie in der OT weiterverwendet werden.
Die drei Bereiche IT, Security und OT müssen zusammenarbeiten und Synergieeffekte nutzen – wie z. B. die Wiederverwendung von bereits integrierten Security-Strategien aus der IT. Wichtig ist dabei, dass die Anforderungen der OT nicht ignoriert, sondern die vorhandenen Themen darauf adaptiert werden.
Der HWI-Ansatz: Autolinguale IT® spricht die Sprache zwischen IT und OT
Eine gut funktionierende IT/OT-Konvergenz scheitert oftmals daran, dass die unterschiedlichen Anforderungen der verschiedenen Bereiche nicht zueinander finden. Das HWI-Framework der Autolinguale IT® adressiert genau dies. Es zielt darauf ab, dass beide Bereiche dieselbe „Sprache“ sprechen und gemeinsame Lösungen finden, die sehr gut miteinander funktionieren.
Unterschiedliche OT-Beispiele aus der Praxis
Folgende Beispiele sollen die mögliche Vielfältigkeit von OT besser darstellen:
Produktionslinie im Werk
Verteilte Wasser-/Energieinfrastruktur (KRITIS-nah)
Großer Gebäudecampus (Gebäudeautomation)
Diese Beispiele zeigen, dass OT sehr breit gefächert mit unterschiedlichen Anforderungen und Komponenten sein kann. Die Inbetriebnahme einer OT-Infrastruktur erfordert daher eine detailreiche Planungsphase, um ein gemeinsames Verständnis zu schaffen, sodass der spätere Betrieb vereinfacht wird.
OT-Security als Teil einer OT-Infrastruktur
OT-Security ist am wirksamsten, wenn sie als Teil von Architektur und Betrieb verstanden wird. Hierzu bedarf es ein klares Leitbild, welches in einer Planungsphase erarbeitet werden muss. Nur dann können die realen Prozesse der OT erfolgreich in eine Security-Strategie integriert werden und den Betrieb nicht beeinflussen.
Fünf Grundprinzipien für OT-Security
- Verfügbarkeit und Safety-Anforderungen müssen beachtet und integriert werden.
- Ohne Sichtbarkeit keine Security. Alle Assets müssen identifiziert und dokumentiert werden.
- Bildung von definierten Zonen und Übergängen.
- Alle Zugriffe müssen entsprechend abgesichert und dokumentiert sein. Fernzugriff ist Teil einer Security-Strategie.
- Der zuverlässige Betrieb ist ebenfalls Teil der Security-Strategie.
Standards & Compliance: Was man kennen sollte und den Einstieg sogar vereinfacht
Vorhandene Standards können einen guten Einstieg liefern und das Thema vereinfachen.
Standards (z. B. IEC 62443): Struktur für Architektur & Betrieb
Standards wie beispielsweise IEC 62443 liefern ein Verständnis für Begriffe und Muster, welche in der OT immer wieder auftauchen. Zonen, Conduits, Rollen oder Mindestanforderungen machen es gerade Einsteigern einfacher. Standards können helfen, die späteren Entscheidungen vergleichbar und auditierbar zu machen.
Regulatorik (z. B. NIS2/KRITIS): Warum OT in der Governance ankommt
Die Regulatorik treibt die Nachweisfähigkeit und Definition von Verantwortlichkeiten voran. Für Entscheider ist frühzeitig zu klären:
- Welche Assets sind relevant?
- Welche Stakeholder müssen in den Prozess eingebunden werden?
- Wie wird eine OT-Infrastruktur aufgebaut, die sich an Standards orientiert?
Fazit: Durch Verständnis für OT die Komplexität reduzieren
Als Grundlage für eine erfolgreiche OT-Infrastruktur sollten folgende Punkte beachtet werden:
- OT steuert physische Prozesse – deshalb gibt es andere Anforderungen und Schutzziele als in der IT.
- OT ist vielfältig – es gibt keinen „Blueprint“, der einfach adaptiert werden kann.
- Aufgrund der Steuerung des realen Prozesses durch die OT sind die Anforderungen greifbar.
- Das Purdue-Modell kann helfen, Systeme zu ordnen und dedizierte Schnittstellen zu schaffen.
- Die IT/OT-Konvergenz bringt viele Vorteile, wenn man klare Verantwortlichkeiten und Schnittstellen definiert, welche einem klaren Plan folgen.
Durch die zunehmende Notwendigkeit der IT/OT-Konvergenz muss OT ein Teil der Security-Strategie sein. Es ist unumgänglich, dass IT und OT eine gemeinsame „Sprache“ sprechen. Nur so entstehen keine Sicherheitslücken und Synergieeffekte können genutzt werden.
FAQ
Was ist Operational Technology (OT)?
OT ist Hardware und Software, die physische Prozesse in Anlagen und Infrastrukturen überwacht und steuert – meist in Echtzeit.
Wo kommt OT vor?
OT findet sich nicht nur in der Produktion, sondern auch in KRITIS-Umgebungen (Energie, Wasser), Transport/Logistik, Prozessindustrie und im Gebäudemanagement großer Liegenschaften.
Was gehört typischerweise zur OT?
Häufige OT-Systeme sind SPS/PLC, DCS, SCADA, HMI, RTU sowie Engineering Stations und Historian-/Integrationskomponenten.
Was ist das Purdue-Modell?
Das Purdue-Modell ist eine Referenzarchitektur, die OT-Systeme in Ebenen (Level 0–5) strukturiert und Schnittstellenplanung erleichtert.
Was bedeutet IT/OT-Konvergenz?
IT/OT-Konvergenz beschreibt das Zusammenwachsen von OT- und IT-Systemen, um OT-Daten und Prozesse für Digitalisierung, IIoT und Optimierung nutzbar zu machen.
