15 Oktober 2026

Industrial Security bezeichnet im Automatisierungskontext den Schutz industrieller Anlagen und Systeme vor unbefugter Beeinflussung, Manipulation und sicherheitsrelevanten Beeinträchtigungen. Dazu gehören technische und organisatorische Maßnahmen für Komponenten, Netzwerke, Zugänge und betriebliche Abläufe. Der Schutz muss über Planung, Integration, Betrieb und Änderungen hinweg aufrechterhalten werden.

Was bedeutet Industrial Security?

Industrieanlagen bestehen aus vielen zusammenwirkenden Teilen. Steuerungen, Bediengeräte, Engineering-Werkzeuge und Datenverbindungen bilden mit Menschen und Arbeitsabläufen ein Gesamtsystem. Industrial Security betrachtet diese Zusammenhänge, damit der Schutz nicht an den Grenzen einzelner Produkte oder Zuständigkeiten endet.

Der Begriff wird in der Praxis nicht überall identisch verwendet. Im Umfeld industrieller Automatisierung überschneidet er sich stark mit OT-Security und Industrial Cybersecurity. Eine feste allgemeine Hierarchie zwischen diesen Bezeichnungen ist für die praktische Planung wenig hilfreich. Wichtiger ist, den betrachteten Umfang eindeutig festzulegen.

In einem Projekt sollte beispielsweise klar sein, ob nur eine neue Maschine, ihre Einbindung in das Werksnetz oder auch externe Wartungs- und Datendienste betrachtet werden. Ohne diese Abgrenzung können notwendige Maßnahmen zwischen Lieferant, Integrator und Betreiber offenbleiben.

Defense in Depth: Schutz auf mehreren Ebenen

Defense in Depth beschreibt ein mehrschichtiges Schutzkonzept. Verschiedene Maßnahmen ergänzen sich, sodass der Schutz nicht ausschließlich von einer einzelnen Barriere abhängt. Siemens gliedert sein entsprechendes Industriekonzept in Anlagensicherheit, Netzwerksicherheit und Systemintegrität. Diese herstellerspezifische Darstellung veranschaulicht die unterschiedlichen Ebenen, ersetzt aber keine konkrete Risikobewertung.

Ebene	Beispielhafte Fragestellung	Möglicher Bestandteil
Anlage und Zugang	Wer kann kritische Komponenten erreichen?	Geregelte Zutritte und Zuständigkeiten
Netzwerk	Welche Systeme dürfen miteinander kommunizieren?	Kontrollierte Übergänge zwischen Bereichen
Komponente	Wer darf Programme und Einstellungen verändern?	Geeignete Berechtigungen und Konfigurationen
Betrieb	Wie werden Änderungen und Auffälligkeiten behandelt?	Freigaben, Protokollierung und Reaktionsabläufe

Mehrere Maßnahmen sind nicht automatisch unabhängig. Werden sämtliche Zugänge mit demselben unkontrolliert genutzten Konto verwaltet, kann eine gemeinsame Schwachstelle mehrere Ebenen betreffen. Die Architektur sollte deshalb auch solche Abhängigkeiten berücksichtigen.

Security über den Lebenszyklus einer Anlage

Planung und Beschaffung

Bereits im Lastenheft sollten die benötigten Eigenschaften beschrieben werden. Dazu können unterstützte Zugriffskonzepte, dokumentierte Kommunikationsbeziehungen und die Bereitstellung von Sicherheitsinformationen gehören. Anforderungen müssen so konkret sein, dass ihre Umsetzung geprüft werden kann. Die allgemeine Forderung „Die Anlage muss sicher sein“ reicht dafür nicht aus.

Integration und Abnahme

Bei der Integration entstehen neue Verbindungen und Abhängigkeiten. Ein Produkt mit geeigneten Sicherheitsfunktionen kann durch eine unpassende Einbindung seinen vorgesehenen Schutz verlieren. Die Prüfung sollte deshalb neben Komponenten auch Konfigurationen, Zugänge und die notwendigen betrieblichen Abläufe umfassen.

Betrieb und Änderung

Nach der Inbetriebnahme verändern sich Anlagen, Benutzer und externe Dienste. Die Dokumentation und das Schutzkonzept müssen diese Änderungen nachvollziehen. Eine neue Datenausleitung oder ein zusätzlicher Wartungszugang kann eine erneute Bewertung erfordern, auch wenn am eigentlichen Fertigungsprozess zunächst nichts geändert wird.

Stilllegung und Übergabe

Bei Austausch oder Weitergabe von Komponenten sind gespeicherte Programme, Konfigurationen und Zugänge zu berücksichtigen. Nicht mehr benötigte Verbindungen sollten kontrolliert beendet werden. Welche Daten aufbewahrt oder entfernt werden, muss anhand betrieblicher und sonstiger geltender Anforderungen festgelegt werden.

Wer trägt welche Verantwortung?

Hersteller können Sicherheitsfunktionen und Informationen für ihre Produkte bereitstellen. Integratoren gestalten daraus eine konkrete Lösung. Betreiber legen den betrieblichen Rahmen fest und müssen den vorgesehenen Schutz im Alltag erhalten. Die genaue Aufgabenverteilung ist für das Projekt verbindlich zu klären; sie ergibt sich nicht automatisch aus einer Produktbeschreibung.

Die ISA beschreibt in ihrem Überblick zur Normenreihe ISA/IEC 62443 die Betrachtung von Security über den Lebenszyklus industrieller Automatisierungs- und Steuerungssysteme. Die Reihe umfasst unterschiedliche Rollen und Betrachtungsebenen. Für eine Anwendung ist daher zu prüfen, welche Teile und Anforderungen zum jeweiligen System und Verantwortungsbereich passen.

Eine Zertifizierung muss entsprechend ihrem ausgewiesenen Gegenstand gelesen werden. Ein Nachweis für eine Komponente ist kein pauschaler Nachweis für das gesamte Werk. Ebenso sagt eine qualifizierte Person allein noch nichts über die tatsächlich umgesetzte Anlagenarchitektur aus.

Praxisbeispiel: Neue Maschine im bestehenden Werk

Das folgende Beispiel ist fiktiv. Ein Unternehmen beschafft eine zusätzliche Bearbeitungsmaschine. Die Maschine benötigt Auftragsdaten aus einem übergeordneten System und soll für definierte Wartungsfälle erreichbar sein. Der Lieferant dokumentiert die benötigten Kommunikationsbeziehungen und die vorgesehenen Benutzerrollen.

Bei der Integration prüft das Werk, welche Verbindungen tatsächlich erforderlich sind. Ein vorbereiteter Wartungszugang wird in die betrieblichen Freigabe- und Protokollierungsabläufe eingebunden. Zuständigkeiten für Aktualisierungen, Konfigurationsänderungen und Sicherungen werden ausdrücklich vereinbart.

Während der Abnahme wird nicht nur geprüft, ob Daten übertragen werden. Zusätzlich wird nachvollzogen, ob die vorgesehenen Rollen passende Rechte besitzen und nicht benötigte Zugänge geschlossen sind. Für den späteren Betrieb werden aktuelle Unterlagen und ein abgestimmter Wiederherstellungsablauf übergeben.

Ein Jahr später soll die Maschine zusätzliche Daten an einen externen Analysedienst liefern. Diese Änderung wird erneut bewertet, weil sie die ursprünglichen Kommunikationsbeziehungen erweitert. Das Beispiel zeigt, warum Industrial Security eine fortlaufende Aufgabe und kein einmaliger Punkt auf einer Abnahmeliste ist.

Industrial Security und Safety unterscheiden

Security richtet sich unter anderem gegen unbefugte Einflussnahme auf Systeme und Informationen. Safety behandelt die Beherrschung von Gefährdungen für Menschen und gegebenenfalls weitere Schutzgüter. Beide Bereiche können dieselben Komponenten betreffen, besitzen aber unterschiedliche Nachweise und Methoden.

Ein Sicherheitskonzept muss ihre Wechselwirkungen berücksichtigen. Beispielsweise darf eine neue Zugriffskontrolle notwendige betriebliche Reaktionen nicht unvorhersehbar verhindern. Umgekehrt darf eine vermeintlich praktische Zugriffsmöglichkeit keinen unkontrollierten Weg zur Änderung sicherheitsrelevanter Einstellungen eröffnen. Zuständige Fachleute müssen solche Anforderungen gemeinsam abstimmen.

Typische Fehler bei der Umsetzung

Nur Produkte beschaffen: Organisatorische Abläufe und Zuständigkeiten bleiben ungeklärt.
Integration unterschätzen: Geeignete Einzelfunktionen werden durch offene Verbindungen entwertet.
Nachweise verallgemeinern: Der geprüfte Umfang eines Zertifikats wird auf ein größeres System übertragen.
Änderungen nicht nachführen: Dokumentation und tatsächlicher Zustand entwickeln sich auseinander.
Wiederherstellung ausklammern: Schutzmaßnahmen werden geplant, aber ein gestörter Betrieb kann nicht zuverlässig wieder aufgenommen werden.

Eine wirksame Einführung verbindet deshalb konkrete Anforderungen mit einer überprüfbaren Umsetzung und einem dauerhaft tragfähigen Betriebsmodell. Die Wirkung sollte anhand der relevanten Risiken beurteilt werden. Die Anzahl eingesetzter Sicherheitsprodukte ist dafür kein ausreichender Maßstab.

Häufige Fragen zu Industrial Security

Ist Industrial Security dasselbe wie OT-Security?

Im Automatisierungskontext überschneiden sich die Begriffe stark und werden teilweise ähnlich verwendet. Je nach Anbieter oder Organisation kann Industrial Security breiter gefasst sein. Für ein konkretes Vorhaben sollte deshalb der Schutzumfang beschrieben werden. Die Bezeichnung allein klärt noch nicht, welche Anlagen, Dienste und organisatorischen Aufgaben eingeschlossen sind.

Was bedeutet Defense in Depth?

Mehrere aufeinander abgestimmte Schutzmaßnahmen wirken auf unterschiedlichen Ebenen zusammen. Dazu können geregelte Zugänge, kontrollierte Kommunikation und geschützte Konfigurationen gehören. Ziel ist, nicht ausschließlich von einer einzigen Barriere abhängig zu sein. Die Maßnahmen müssen zum konkreten Risiko passen und dürfen nicht durch gemeinsame Schwachstellen gleichzeitig unwirksam werden.

Ist eine zertifizierte Komponente automatisch sicher eingebunden?

Nein. Ein Nachweis bezieht sich auf einen bestimmten Prüfgegenstand und festgelegte Voraussetzungen. Konfiguration, Integration und Betrieb können außerhalb dieses Umfangs liegen. Deshalb muss geprüft werden, welche Annahmen gelten und wie sie im Gesamtsystem eingehalten werden. Die Eigenschaften einer einzelnen Komponente ersetzen keine Bewertung ihrer Einbindung.

Wann sollten Security-Anforderungen festgelegt werden?

Möglichst früh in Planung und Beschaffung, damit Architektur und Verantwortlichkeiten darauf abgestimmt werden können. Nachträgliche Ergänzungen sind teilweise möglich, können aber erheblichen Aufwand verursachen. Die Anforderungen müssen über Integration und Betrieb hinweg weitergeführt werden. Neue Verbindungen oder geänderte Nutzung können später eine erneute Bewertung notwendig machen.

Wer prüft Änderungen nach der Inbetriebnahme?

Das sollte im betrieblichen Änderungsverfahren eindeutig geregelt sein. Je nach Änderung werden Anlagenverantwortliche, IT, OT-Security, Hersteller und weitere Fachstellen benötigt. Entscheidend ist, dass technische und betriebliche Auswirkungen gemeinsam betrachtet werden. Eine Änderung sollte nicht allein deshalb ungeprüft bleiben, weil sie außerhalb der ursprünglichen Projektphase erfolgt.

Quellen und fachliche Einordnung

Siemens: Cybersecurity for Industry, Darstellung des Defense-in-Depth-Konzepts.
ISA: ISA/IEC 62443 Series of Standards, Lebenszyklus und Anwendungsbereich der Normenreihe.

Das Beschaffungsbeispiel und die Prüffragen sind eigenständige Erläuterungen. Stand: Oktober 2026.