Praxisleitfaden für eine belastbare OT-Security-Roadmap: Risiken priorisieren, Anlagen schützen und innerhalb von zwölf Monaten wirksame Strukturen etablieren.
Eine OT-Security-Roadmap übersetzt ein abstraktes Sicherheitsziel in eine belastbare Reihenfolge aus Entscheidungen, Maßnahmen und Nachweisen. Gerade in Produktionsumgebungen genügt es nicht, bekannte IT-Kontrollen unverändert zu übernehmen: Anlagen haben lange Lebenszyklen, Wartungsfenster sind knapp, Verfügbarkeit und funktionale Sicherheit besitzen besonderes Gewicht und viele Komponenten wurden nie für eine vernetzte Bedrohungslage entwickelt. Dieser Leitfaden zeigt, wie Unternehmen innerhalb von zwölf Monaten ein wirksames OT-Sicherheitsprogramm aufbauen – ohne die Produktion mit einem überdimensionierten Maßnahmenkatalog zu blockieren.
Warum OT-Security heute ein Steuerungsthema ist
Produktionsnetze, Gebäudeautomation, Laborumgebungen und logistische Steuerungssysteme sind heute eng mit klassischen IT-Diensten, Cloud-Plattformen, Fernwartungszugängen und Lieferanten verbunden. Dadurch entstehen wirtschaftliche Vorteile, aber auch zusätzliche Angriffs- und Ausfallpfade. Ein Sicherheitsvorfall kann in der OT nicht nur Daten betreffen. Er kann Fertigungskapazität, Lieferfähigkeit, Produktqualität, Arbeitssicherheit und vertragliche Verpflichtungen gleichzeitig beeinträchtigen.
Die europäische Bedrohungslage unterstreicht diese Entwicklung. Die ENISA wertete für ihren Threat Landscape 2025 insgesamt 4.875 Vorfälle aus und beschreibt eine zunehmende Konvergenz, Automatisierung und Industrialisierung von Angriffen. Sie empfiehlt unter anderem eine umfassende Erfassung von Assets, automatisiertes Schwachstellenmanagement und Resilienzplanung für vernetzte Systeme und Dienste. Für OT-Verantwortliche folgt daraus keine Pflicht zu maximaler Technik, sondern zu besserer Transparenz und nachvollziehbarer Priorisierung.
Eine Roadmap ist deshalb kein Projektplan der IT-Abteilung. Sie ist ein gemeinsames Steuerungsinstrument für Produktion, Engineering, Instandhaltung, Informationssicherheit, Einkauf, Datenschutz und Geschäftsleitung. Ihr Wert liegt darin, Abhängigkeiten sichtbar zu machen: Bevor Segmentierung umgesetzt wird, müssen Kommunikationsbeziehungen bekannt sein. Bevor Fernzugriffe gehärtet werden, müssen Betreiber und Vertragspartner identifiziert sein. Bevor Wiederanlaufpläne getestet werden, müssen kritische Prozesse und technische Voraussetzungen feststehen.
Das Zielbild: sicherer Betrieb statt vollständiger Umbau
Ein realistisches OT-Sicherheitsprogramm verfolgt drei Ziele. Erstens soll es die Wahrscheinlichkeit erfolgreicher Angriffe und Fehlkonfigurationen reduzieren. Zweitens soll es Auswirkungen begrenzen, falls ein Ereignis dennoch eintritt. Drittens muss es die Wiederherstellung kritischer Funktionen vorbereiten. Diese drei Ziele helfen, Maßnahmen sachlich zu bewerten. Eine Kontrolle ist nicht deshalb wichtig, weil sie modern klingt, sondern weil sie mindestens eines dieser Ziele wirksam unterstützt.
Das Zielbild sollte außerdem konkrete Leitplanken enthalten. Dazu gehören eine definierte OT-Governance, ein gepflegtes Asset-Inventar, nachvollziehbare Zonen und Kommunikationswege, kontrollierte administrative und externe Zugänge, ein risikobasiertes Schwachstellenverfahren, überwachbare sicherheitsrelevante Ereignisse, getestete Wiederanlaufverfahren und ein Incident-Response-Modell, das die Besonderheiten der Produktion berücksichtigt.
Die IEC-62443-Reihe kann als fachlicher Orientierungsrahmen für industrielle Automatisierungs- und Steuerungssysteme dienen. Gleichzeitig lassen sich Governance, Risikomanagement und kontinuierliche Verbesserung in ein bestehendes ISMS nach ISO/IEC 27001 integrieren. Betroffene Unternehmen sollten zusätzlich regulatorische Vorgaben wie NIS2, nationale KRITIS-Regelungen oder branchenspezifische Anforderungen berücksichtigen. Wichtig ist eine einheitliche Steuerung: Mehrere Rahmenwerke sollten nicht zu parallelen Maßnahmenlisten führen, sondern in einem gemeinsamen Kontrollmodell zusammenlaufen.
Monat 1 bis 2: Auftrag, Geltungsbereich und Verantwortung klären
Der erste Schritt ist kein technischer Scan, sondern ein belastbares Mandat. Die Geschäftsleitung muss festlegen, welche Standorte, Produktionsbereiche und unterstützenden Systeme betrachtet werden, wer Risiken akzeptieren darf und wie Konflikte zwischen Sicherheit und Verfügbarkeit entschieden werden. Ohne diese Klarheit bleibt OT-Security eine unverbindliche Zusatzaufgabe.
Ein schlankes Governance-Modell umfasst mindestens einen geschäftlich verantwortlichen Sponsor, einen Programmverantwortlichen, benannte Ansprechpartner in den Werken sowie feste Schnittstellen zu IT, Engineering, Instandhaltung, Einkauf und Krisenmanagement. Rollen sollten nicht nur in einem Organigramm stehen. Für typische Entscheidungen ist festzulegen, wer vorbereitet, entscheidet, umsetzt und informiert wird. Beispiele sind die Freigabe eines Fernzugangs, die Behandlung einer kritischen Schwachstelle, die Beschaffung einer neuen Anlage oder die Reaktion auf verdächtige Netzwerkaktivität.
Ergebnisse dieser Phase
- freigegebener Scope mit Standorten, Bereichen und wesentlichen Abhängigkeiten,
- benannte Rollen einschließlich Risiko- und Ausnahmeentscheidungen,
- gemeinsame Schutzziele für Verfügbarkeit, Integrität, Vertraulichkeit und Safety,
- ein abgestimmter Rhythmus für Steuerung, Reporting und Eskalation,
- Kriterien, nach denen Maßnahmen priorisiert und finanziert werden.
Monat 2 bis 4: Transparenz über Assets und Abhängigkeiten schaffen
Ein OT-Asset-Inventar ist mehr als eine Geräteliste. Es muss beantworten, welche Funktion ein Asset erfüllt, welchen Prozess es unterstützt, wie kritisch ein Ausfall wäre, welche Kommunikationsbeziehungen bestehen, wer verantwortlich ist und wie das System gewartet wird. Ohne diesen Kontext produziert ein Scan viele Daten, aber wenig Entscheidungsfähigkeit.
Beginnen Sie mit vorhandenen Quellen: Netzwerkpläne, Stücklisten, Wartungsverträge, Ersatzteilkataloge, Engineering-Dokumentation, Firewall-Regeln und Informationen aus Leitsystemen. Ergänzen Sie diese Daten durch moderierte Workshops und passive technische Erkennung. Passive Verfahren sind in empfindlichen Produktionsnetzen häufig der bessere Einstieg, weil aktive Scans unerwartete Last oder Reaktionen auslösen können. Jede technische Erhebung sollte deshalb mit Anlagenverantwortlichen geplant und in einem kontrollierten Umfang erprobt werden.
Für die Priorisierung reicht ein binäres Merkmal wie „kritisch“ nicht aus. Sinnvoll ist eine Bewertung entlang mehrerer Auswirkungen: Produktionsstillstand, Safety, Umwelt, Qualität, Lieferverpflichtung, finanzielle Wirkung, regulatorische Konsequenz und Wiederbeschaffungszeit. So wird sichtbar, dass ein älteres, unscheinbares Engineering-System für den Wiederanlauf wichtiger sein kann als eine moderne zentrale Plattform.
Qualitätskriterien für das Inventar
- Jedes relevante Asset hat einen fachlichen und technischen Verantwortlichen.
- Geschäftsprozess, Standort, Zone und Kommunikationsbeziehungen sind zugeordnet.
- Betriebssystem, Firmware, Hersteller, Modell und Supportstatus sind soweit möglich dokumentiert.
- Externe Zugriffe, Wartungswege und verwendete Identitäten sind sichtbar.
- Kritikalität und Wiederanlaufreihenfolge sind nachvollziehbar begründet.
Monat 3 bis 5: Risiken bewerten und Quick Wins auswählen
OT-Risiken sollten als konkrete Szenarien formuliert werden. „Malware“ ist noch kein bewertbares Risiko. Ein belastbares Szenario beschreibt Bedrohung, Eintrittspfad, betroffene Anlage, mögliche Auswirkung und vorhandene Schutzmaßnahmen. Beispiel: Ein kompromittierter Fernwartungsaccount ermöglicht unautorisierte Änderungen an einer Abfülllinie; dadurch entstehen Produktionsausfall und Qualitätsrisiken.
Die Bewertung muss technische Schwächen mit betrieblichen Auswirkungen verbinden. Eine öffentlich bekannte Schwachstelle ist nicht automatisch das höchste Risiko. Entscheidend ist unter anderem, ob das Asset erreichbar ist, ob ein Exploit praktisch einsetzbar ist, welche Kompensationsmaßnahmen bestehen und wie kritisch die Funktion ausfällt. Umgekehrt kann ein schlecht kontrollierter Standardzugang ohne spektakuläre CVE ein sehr hohes Risiko darstellen.
Quick Wins sollten sofort wirksam, betrieblich vertretbar und überprüfbar sein. Typische Kandidaten sind das Schließen nicht benötigter Verbindungen, die Inventarisierung und Absicherung externer Zugänge, individuelle administrative Konten, gesicherte Offline-Kopien kritischer Konfigurationen, eine zentrale Kontakt- und Eskalationsliste sowie die Kontrolle tragbarer Datenträger. Ein Quick Win ist nur abgeschlossen, wenn Verantwortlichkeit, Nachweis und dauerhafter Betrieb geklärt sind.
Monat 4 bis 7: Zonen, Übergänge und Fernzugriffe absichern
Netzwerksegmentierung ist eine der wirksamsten, aber auch anspruchsvollsten OT-Maßnahmen. Das Ziel ist nicht eine möglichst große Zahl von Firewalls. Ziel ist, Kommunikationswege auf das fachlich Notwendige zu begrenzen, Übergänge kontrollierbar zu machen und die Ausbreitung eines Angriffs zu erschweren. Die Zonierung sollte daher aus Prozessen und Funktionen abgeleitet werden, nicht nur aus vorhandenen IP-Bereichen.
Starten Sie mit einem verständlichen Ist-Bild. Welche Systeme kommunizieren zwischen Unternehmens-IT und Produktion? Wo existieren direkte Internetzugänge? Welche Daten fließen zu Cloud-Diensten? Welche Anbieter greifen wann und mit welchen Rechten zu? Aus diesen Antworten entsteht ein Sollmodell mit definierten Zonen und Übergängen. Änderungen sollten schrittweise, mit dokumentierter Rückfalloption und abgestimmtem Wartungsfenster umgesetzt werden.
Fernwartung verdient besondere Aufmerksamkeit. Gute Praxis umfasst einen zentralen Zugangspfad, starke Authentisierung, zeitlich begrenzte Freigaben, namentlich zugeordnete Konten, minimal erforderliche Berechtigungen, Protokollierung sowie eine fachliche Genehmigung. Dauerhafte Hersteller-VPNs und gemeinsam genutzte Konten erschweren Kontrolle und Nachvollziehbarkeit. Verträge sollten Sicherheitsanforderungen, Reaktionszeiten und Pflichten bei Vorfällen eindeutig regeln.
Monat 5 bis 8: Schwachstellen und Änderungen risikobasiert steuern
Ein OT-Schwachstellenmanagement darf nicht mit einer ungefilterten Patchliste verwechselt werden. Viele Systeme können nur in langen Intervallen aktualisiert werden, benötigen Herstellerfreigaben oder sind nicht mehr vollständig unterstützt. Das Verfahren muss deshalb mehrere Behandlungswege zulassen: Patchen, Konfiguration ändern, Zugriff begrenzen, überwachen, ersetzen oder ein dokumentiertes Restrisiko akzeptieren.
Für jede relevante Meldung sollten Exponierung, Ausnutzbarkeit, Anlagenkritikalität und bestehende Kompensationsmaßnahmen bewertet werden. Eine zentrale Rolle spielt das Change Management. Selbst eine gut begründete Sicherheitsmaßnahme kann ein Betriebsrisiko erzeugen, wenn sie ohne Test, Freigabe oder Rückfallplan umgesetzt wird. Sicherheits- und Betriebsrisiko gehören deshalb in dieselbe Entscheidungsvorlage.
Parallel sollte die Beschaffung neue Altlasten verhindern. Sicherheitsanforderungen gehören in Lastenhefte, Verträge und Abnahmen. Dazu zählen dokumentierte Schnittstellen, Rollen- und Berechtigungskonzepte, Updatefähigkeit, Schwachstellenkommunikation, Protokollierungsfunktionen, sichere Standardkonfiguration und ein geregeltes Supportende. Der Cyber Resilience Act erhöht die Bedeutung von Security by Design und strukturiertem Schwachstellenmanagement zusätzlich für Produkte mit digitalen Elementen.
Monat 6 bis 9: Erkennung und Reaktion für die OT vorbereiten
OT-Monitoring sollte relevante Abweichungen erkennbar machen, ohne die Organisation mit Alarmen zu überlasten. Ein sinnvoller Einstieg fokussiert auf wenige hochwertige Anwendungsfälle: neue oder unbekannte Geräte, ungewöhnliche Verbindungen zwischen Zonen, Änderungen an Steuerungslogik, neue administrative Konten, Nutzung von Fernzugängen außerhalb freigegebener Zeitfenster und auffällige Kommunikation zu externen Zielen.
Technische Erkennung ist nur dann wirksam, wenn die Reaktion geklärt ist. Für jeden Anwendungsfall müssen Empfänger, Prüfpfad, Eskalationsschwelle und sichere Handlungsoptionen beschrieben sein. In einer Produktionsumgebung kann das unkoordinierte Trennen eines Systems größeren Schaden verursachen als die beobachtete Aktivität. Deshalb müssen SOC, IT und Anlagenverantwortliche gemeinsame Playbooks entwickeln.
Der Incident-Response-Plan sollte OT-spezifische Kontakte, Entscheidungsbefugnisse, Beweissicherung, Kommunikation und Wiederanlauf enthalten. Die 2025 veröffentlichte NIST SP 800-61 Revision 3 ordnet Incident Response ausdrücklich in das gesamte Cyberrisikomanagement ein. Dieser Ansatz ist für OT besonders nützlich: Vorbereitung, Erkennung, Reaktion und Wiederherstellung dürfen nicht als isolierter Notfallordner behandelt werden.
Monat 8 bis 11: Wiederanlauf und Resilienz testen
Backups sind in der OT unverzichtbar, aber ihr Vorhandensein beweist noch keine Wiederherstellbarkeit. Benötigt werden neben Daten häufig Steuerungsprogramme, Konfigurationen, Firmwarestände, Lizenzinformationen, Engineering-Projekte, Zertifikate, Zugangsdaten, Installationsmedien und Wissen über die korrekte Reihenfolge. Für kritische Anlagen sollte dokumentiert sein, welche Komponenten in welchem Zustand wiederhergestellt werden müssen.
Definieren Sie RTO und RPO nicht allein technisch. Der Fachbereich muss beschreiben, wie lange ein Prozess ausfallen darf und welcher Daten- oder Produktionsverlust akzeptabel ist. Daraus folgt eine realistische Wiederanlaufreihenfolge. Ersatzteile, externe Spezialisten und Lieferzeiten gehören in dieselbe Betrachtung.
Eine Tabletop-Übung ist ein guter Einstieg. Sie prüft Entscheidungen und Schnittstellen anhand eines plausiblen Szenarios, ohne die Anlage zu beeinflussen. Danach sollten technische Wiederherstellungstests für ausgewählte Systeme folgen. Jede Übung endet mit Verantwortlichen, Fristen und einer erneuten Prüfung der Verbesserungen. Nur so wird aus einem Erkenntnisprotokoll tatsächliche Resilienz.
Monat 10 bis 12: Verstetigen, messen und priorisiert weiterentwickeln
Am Ende des ersten Jahres sollte OT-Security vom Projekt in einen geregelten Betrieb übergehen. Dazu gehören feste Gremien, definierte Kontrollzyklen, ein Maßnahmenportfolio und ein Managementbericht. Kennzahlen sollten Entscheidungen unterstützen. Reine Aktivitätszahlen wie die Anzahl durchgeführter Scans oder Schulungen sagen wenig über Risikoreduktion aus.
Aussagekräftiger sind zum Beispiel der Anteil kritischer Assets mit bestätigtem Verantwortlichen, der Anteil kontrollierter Fernzugänge, die Abdeckung kritischer Konfigurationen durch getestete Sicherungen, die Zeit bis zur Bewertung relevanter Schwachstellen, die Zahl ungeklärter Kommunikationsbeziehungen und der Umsetzungsstand priorisierter Übungsmaßnahmen. Ergänzend sollten wenige Risikoszenarien mit ihrer Entwicklung berichtet werden.
Die Roadmap für das zweite Jahr entsteht aus drei Quellen: verbliebene hohe Risiken, Ergebnisse aus Monitoring und Übungen sowie geplante geschäftliche oder technische Veränderungen. Neue Werke, Anlagenmodernisierung, Cloud-Anbindung, Akquisitionen und Lieferantenwechsel können Prioritäten erheblich verschieben. Eine gute Roadmap wird daher mindestens quartalsweise überprüft.
Typische Fehler bei OT-Security-Roadmaps
Zu viel Technik und zu wenig Betriebsverständnis: Wer mit Produktauswahl beginnt, bevor Prozesse und Abhängigkeiten verstanden sind, erzeugt teure Inseln. Neue Werkzeuge liefern dann zwar Daten, verändern aber weder Verantwortlichkeiten noch riskante Betriebsabläufe. Technik sollte deshalb aus priorisierten Anwendungsfällen abgeleitet und gemeinsam mit Produktion, Engineering und Instandhaltung eingeführt werden. Für jede Investition muss vorab feststehen, welches Risikoszenario sie reduziert und wie die Wirkung im Betrieb überprüft wird.
Vollständigkeit vor Risikowirkung: Ein perfektes Inventar aller Details kann Jahre dauern und darf nicht zur Voraussetzung für erste Schutzmaßnahmen werden. Unternehmen sollten mit kritischen Bereichen beginnen, Mindestinformationen definieren und Datenqualität iterativ verbessern. Parallel können offensichtliche Risiken wie unkontrollierte Fernzugänge, gemeinsame Administrationskonten oder fehlende Konfigurationssicherungen bereits behandelt werden. So wächst die Transparenz, während gleichzeitig messbare Risikoreduktion entsteht.
Unklare Risikoakzeptanz und dauerhafte Ausnahmen: Wenn niemand formell entscheiden darf, bleiben technische Altlasten und Abweichungen häufig unbegrenzt offen. Jede Akzeptanz benötigt einen benannten Entscheider, eine nachvollziehbare Begründung, eine Laufzeit und geeignete kompensierende Maßnahmen. Zusätzlich sollte ein konkreter Anlass für die erneute Bewertung festgelegt werden, etwa eine Anlagenmodernisierung, ein Herstellerupdate oder eine Veränderung der Netzarchitektur. Damit werden Ausnahmen steuerbar, statt unbemerkt zum Normalzustand zu werden.
Segmentierung ohne Kommunikationsanalyse: Übereilte Regeländerungen können den Betrieb gefährden, wenn fachlich notwendige Verbindungen nicht bekannt sind. Vor der Umsetzung stehen deshalb passive Beobachtung, fachliche Validierung, ein kontrollierter Test und ein dokumentierter Rückfallplan. Regeln sollten nicht nur technisch freigegeben, sondern einem Prozess und einem Verantwortlichen zugeordnet werden. Ungeklärte oder temporäre Verbindungen erhalten ein Ablaufdatum und werden nach der Umstellung gezielt nachverfolgt.
Notfallpläne ohne realistische Übung: Dokumente offenbaren ihre Lücken häufig erst dann, wenn ein konkretes Szenario Entscheidungen unter Zeitdruck erzwingt. Bereits eine moderierte Tabletop-Übung zeigt, ob Kontakte erreichbar, Befugnisse klar und Wiederanlaufprioritäten abgestimmt sind. Darauf aufbauend sollten ausgewählte technische Wiederherstellungen sicher getestet werden. Erkenntnisse werden mit Verantwortlichen und Fristen verfolgt und in einer späteren Übung erneut überprüft.
Die kompakte 12-Monats-Checkliste
- Mandat, Scope, Schutzziele und Entscheidungswege freigeben.
- Rollen an Standorten und Schnittstellen zur zentralen IT benennen.
- Kritische Prozesse, Anlagen, Abhängigkeiten und Fernzugänge erfassen.
- Konkrete Risikoszenarien bewerten und priorisieren.
- Quick Wins mit Verantwortlichen und Nachweisen umsetzen.
- Zonen- und Übergangsmodell entwickeln und kontrolliert realisieren.
- Schwachstellen-, Patch- und Ausnahmeprozess etablieren.
- Sicherheitsanforderungen in Beschaffung und Lieferantensteuerung integrieren.
- OT-relevante Monitoring-Anwendungsfälle und Reaktionswege definieren.
- Incident-Response- und Krisenprozesse um OT-Rollen erweitern.
- Konfigurationen sichern, Wiederanlauf planen und Übungen durchführen.
- Kennzahlen berichten und die Roadmap für das Folgejahr aktualisieren.
Häufige Fragen zur OT-Security-Roadmap
Wie lange dauert der Aufbau eines OT-Sicherheitsprogramms?
Ein tragfähiger Grundbetrieb lässt sich häufig innerhalb von zwölf Monaten erreichen. In diesem Zeitraum können Governance, Transparenz, priorisierte Schutzmaßnahmen und erste Notfallübungen etabliert werden. Die vollständige Weiterentwicklung bleibt jedoch ein mehrjähriger Prozess, besonders bei vielen Standorten, komplexen Lieferketten und älteren Anlagen. Wichtig ist deshalb, früh messbare Risikoreduktion zu erzielen und die Roadmap regelmäßig an technische und geschäftliche Veränderungen anzupassen.
Muss zuerst ein vollständiges Asset-Inventar existieren?
Nein. Definieren Sie zunächst die benötigten Mindestinformationen und beginnen Sie mit den kritischsten Prozessen, Anlagen und Standorten. Bereits dieses Teilinventar kann genutzt werden, um Verantwortlichkeiten, Fernzugänge und wesentliche Abhängigkeiten zu klären. Anschließend wird der Bestand iterativ erweitert und seine Datenqualität durch feste Pflegeprozesse verbessert. Entscheidend ist, dass das Inventar konkrete Sicherheits- und Betriebsentscheidungen unterstützt.
Kann ein bestehendes ISO-27001-ISMS genutzt werden?
Ja. Governance, Risikomanagement, Audits und kontinuierliche Verbesserung sollten möglichst in das bestehende ISMS integriert werden. Dadurch entstehen keine parallelen Berichtswege und Verantwortlichkeiten. OT-spezifische Anforderungen an Safety, Verfügbarkeit, Anlagenlebenszyklen, Wartungsfenster und technische Maßnahmen müssen jedoch ergänzend berücksichtigt werden. Hilfreich ist ein gemeinsames Kontrollmodell, das Anforderungen aus ISO 27001, IEC 62443 und regulatorischen Vorgaben zusammenführt.
Welche Maßnahme bringt am schnellsten Wirkung?
Das hängt vom Risikoprofil und von der vorhandenen Architektur ab. Häufig liefern Transparenz über externe Zugänge, individuelle administrative Konten, gesicherte Konfigurationen und das Schließen unnötiger Verbindungen eine hohe Wirkung bei überschaubarem Aufwand. Der beste erste Schritt sollte jedoch aus einem konkreten Risikoszenario abgeleitet werden, damit betriebliche Wirkung und Aufwand vergleichbar bleiben. Eine kurze Bestandsaufnahme verhindert, dass ein leicht sichtbares Problem priorisiert wird, während ein kritischerer Zugangspfad unbeachtet bleibt.
Fazit: Eine gute Roadmap schafft Entscheidungsfähigkeit
OT-Security wird nicht durch eine einzelne Plattform und nicht durch einen einmaligen Audit wirksam. Entscheidend ist eine belastbare Reihenfolge: Verantwortung klären, kritische Abhängigkeiten verstehen, Risiken priorisieren, Zugänge und Kommunikation kontrollieren, Erkennung und Wiederherstellung vorbereiten und Fortschritt regelmäßig bewerten. So entsteht innerhalb eines Jahres ein Sicherheitsprogramm, das Produktion unterstützt statt sie zu behindern.
BlackMount unterstützt Unternehmen dabei, OT-Risiken fachlich und technisch zu bewerten, eine realistische Roadmap zu entwickeln und die Umsetzung gemeinsam mit Betrieb, Engineering und Management zu steuern. Ein Erstgespräch kann genutzt werden, um Scope, Reifegrad und die sinnvollsten ersten Schritte einzuordnen.
