Der Preis des pauschalen Abschaltens

Es ist Dienstagabend, Spätschicht, als die Meldung eingeht: ungewöhnliche Aktivität auf dem Fernwartungszugang eines Anlagenlieferanten, sonst unauffällig, jetzt mit einer Anmeldung außerhalb des vereinbarten Wartungsfensters. Als Leiterin OT-Security für zwei Werke mit rund 1.200 Beschäftigten haben Sie in diesem Moment eine einfache Option und eine schwierige. Die einfache: den betroffenen Produktionsbereich komplett vom Netz trennen. Die schwierige: erst herausfinden, was an diesem Bereich alles hängt, bevor Sie es tun.

Die einfache Option hat einen Haken. In derselben Halle bewegt sich gerade die Flotte fahrerloser Transportsysteme zwischen zwei Fertigungslinien, beladen, in Bewegung. Wird die Flottensteuerung ohne Vorwarnung getrennt, halten die Fahrzeuge nicht automatisch an einem sicheren Platz — sie stehen dort, wo sie gerade waren, mitunter im Gang, mitunter vor einer Notausgangstür. Ein Roboterarm, der eine Schweißnaht mitten in der Bewegung verliert, hinterlässt ein Werkstück in undefinierter Lage, das jemand händisch wieder in einen bekannten Zustand bringen muss, bevor die Zelle weiterlaufen darf.

Der Not-Halt an der einzelnen Maschine bleibt unangetastet — er ist und bleibt die verlässlichste Sicherung gegen Bewegungsgefahr, und der Beitrag zur Sicherheit autonomer Roboter ordnet ihn ein — dort erfahren Sie, wie er in das Sicherheitskonzept eingeordnet wird. Hier geht es um etwas anderes: um das anlagenweite Abschalten unter Cyberangriff, bei dem der Stillstand selbst zur Gefahr wird.

Genau darin liegt die These dieses Beitrags: Ein gestufter Notbetrieb — teils auch als „Degraded Mode“ bezeichnet — ist keine Checkliste, die Sie im Ernstfall aufschlagen. Er ist eine Entwurfsanforderung, die schon entscheidet, bevor die erste Warnmeldung eintrifft: welche Verbindung sofort getrennt werden darf, welche Funktion weiterlaufen muss, und wer in welcher Reihenfolge etwas davon abschaltet.

Wenn die eigene Abwehr zur Gefahr wird

Ein aktueller Fall zeigt, dass nicht nur ein Angriff selbst Schaden anrichtet, sondern auch die Reaktion darauf. Nach Angaben des Sicherheitsunternehmens Gambit Security traf bei einem Online-Händler die automatisierte Bereinigungsroutine eines KI-Agenten, der zuvor selbst als Angreifer in das System eingedrungen war, 180 Tabellen, deren Namen auf das Muster ZQ oder Backup passten — darunter Backup-Tabellen, die die Administratoren des Opfers selbst angelegt hatten. Wichtig ist die Präzision dieser Zahl: Es waren 180 Tabellen, die zu diesem Namensmuster passten, nicht 180 Tabellen des gesamten Opfersystems. Der Bericht ist ein Interimsbericht eines Anbieters mit eigenem wirtschaftlichem Interesse an Resilienz-Software und stützt sich nach eigener Aussage teils auf Angreiferlogs, die selbst von einer KI erzeugt wurden — beides gehört zur Einordnung dazu. Dass Gambit Security tatsächlich existiert und mit Sitz in Tel Aviv arbeitet, bestätigt unabhängig davon ein Reuters-Bericht vom 26. Mai 2026.

Die Lehre daraus lässt sich auf produzierende Betriebe übertragen, obwohl der Fall selbst nichts mit einer Fabrik zu tun hat. Eine automatisierte Reaktion, die zu grob nach Namensmustern statt nach Bedeutung sortiert, trifft nicht nur den Angreifer. Ein Sicherheitsagent, der bei ungewöhnlichem Datenverkehr vorsorglich einen Server isoliert, kann technisch richtig handeln und trotzdem eine Robotersteuerung von ihrer Parameterdatenbank trennen, ohne dass jemand das beabsichtigt hätte. Und ein Backup ist damit auch kein Beweis, dass es im Ernstfall unangetastet bleibt: Nach der Darstellung von Gambit traf die Bereinigungsroutine gerade die Tabellen, die als Sicherung gedacht waren.

Für die technische Reaktion auf einen Vorfall gilt deshalb ein Grundsatz, den auch die im April 2025 veröffentlichte dritte Revision des NIST-Leitfadens SP 800-61 vertritt: Incident Response ist kein isoliertes Feuerwehrmanöver, sondern Teil des laufenden Risikomanagements einer Organisation, mit Vorbereitung, Erkennung, Reaktion und Wiederherstellung als zusammenhängender Fähigkeit, nicht als vier getrennten Ereignissen. Wer diese Verbindung ignoriert, riskiert genau das, was der geschilderte Gambit-Fall nahelegt: dass die Abwehr selbst zur zweiten Schadensursache werden kann.

Welche Verbindung wirklich zählt

Ein Netzplan zeigt, welche Systeme technisch miteinander sprechen. Er zeigt nicht, was passiert, wenn eine dieser Verbindungen verschwindet. Für zwei Werke mit Roboterzellen, einer FTS-Flotte und Fernwartungszugängen mehrerer Maschinenlieferanten reicht die Netzwerktopologie deshalb nicht aus — gebraucht wird eine zweite Karte, die jede Verbindung mit ihrer Wirkung verknüpft.

Diese Karte entsteht nicht aus einer einmaligen Inventur, sondern aus einer wiederkehrenden Befragung jeder Verbindung, mit denselben Feldern:

Aus dieser Befragung wird schnell sichtbar, dass nicht jede Verbindung gleich wichtig ist — die intuitive Einschätzung täuscht dabei jedoch oft. Ein Cloud-Dashboard, über das ein Lieferant Nutzungsstatistiken zieht, ist meist entbehrlich, wenn die Zelle lokal sicher weiterläuft. Eine zentrale Identitätsverwaltung kann dagegen zum größten Einzelrisiko werden, wenn nach ihrem Ausfall kein Mitarbeiter mehr in sicherheitsrelevante Systeme gelangt, gleich wie viele redundante Netzwerkpfade dorthin führen. Genau deshalb prüfen Sie bei jeder Fernwartungsverbindung eines Maschinenlieferanten nicht nur, ob sie verschlüsselt ist, sondern auch, wie schnell sie sich trennen lässt, ohne dass die Maschine dahinter in einen unbekannten Zustand fällt.

Von der Kette zur gestuften Reaktion

Aus der Abhängigkeitskarte lässt sich eine Reihenfolge ableiten, in der Maßnahmen aufeinander aufbauen, statt alles gleichzeitig zu tun. Wir nennen dieses Vorgehen hier Response Ladder — ein Arbeitsbegriff dieser Redaktion, kein Standard, im Weiteren auf Deutsch als gestufte Reaktion bezeichnet. Sie ist eine eigene Systematik, zusammengesetzt aus Prinzipien der Reaktion auf Sicherheitsvorfälle, der Netzsegmentierung und der Betriebsfortführungsplanung, nicht eine Vorschrift aus einer Norm.

Der Grundgedanke ist einfach, auch wenn seine Umsetzung es nicht ist: Zuerst wird Handlungsfähigkeit entzogen, dann erst Infrastruktur abgeschaltet. Wer sofort ganze Segmente vom Netz trennt, verliert häufig genau die Übersicht, die er gebraucht hätte, um gezielt statt pauschal zu reagieren.

Diese fünf Stufen sind eine redaktionelle Systematik, keine Blaupause, die sich unverändert auf jedes Werk übertragen lässt. Was sich übertragen lässt, ist die Reihenfolge: Wer zuerst Rechte entzieht und erst danach Leitungen trennt, verhindert, dass eine kompromittierte Identität den eigenen Wiederanlauf sabotiert, obwohl er gleichzeitig so lange wie vertretbar weiterproduziert, statt bei der ersten Unsicherheit alles stillzulegen.

Ein rein technischer Schalter, der nur auf IP-Adressen oder Ports reagiert, deckt davon nur die unteren Stufen ab. Ab Stufe 3 hilft es, wenn ein System zusätzlich prüft, ob eine Handlung zum aktuellen Auftrag passt — ein Wartungskonto, das plötzlich an zwanzig Zellen gleichzeitig Parameter ändern will, wirkt technisch legitim und ist trotzdem auffällig, wenn sein eigentlicher Auftrag nur eine einzelne Maschine betraf. Wie sich Handlungen von Software-Agenten in einer Fabrik überhaupt eindeutig einer Identität und einem Auftrag zuordnen lassen, vertieft ein eigener Beitrag zur Identität von KI-Agenten in cyberphysischen Systemen; für die gestufte Reaktion genügt hier der Grundsatz, dass ab der vierten Stufe ein Mensch in der Entscheidungsschleife bleibt, nicht nur ein weiterer Agent.

Der sichere Zustand ist je Prozess verschieden

NIST fasst unter Operational Technology Systeme, die unmittelbar auf die physische Umwelt wirken — der Wortlaut steht so im Entwurf der Neufassung SP 800-82 Revision 4, die seit dem 21. September 2026 zur öffentlichen Kommentierung vorliegt, mit Frist bis zum 30. November 2026. Genau diese unmittelbare Wirkung ist der Grund, warum „Sicher stoppen“ in einer Fabrik nicht für jede Maschine dasselbe bedeutet. Manche Roboterzellen lassen sich unmittelbar in einen definierten Safe Stop bringen. Andere Prozesse brauchen eine geordnete Sequenz — Fördertechnik muss unter Umständen erst Material aus einer kritischen Zone bewegen, bevor sie stehen bleiben darf, und eine kontinuierliche Anlage stellt andere Anforderungen als ein einzelner Montagearm.

MITRE führt in seinem Rahmenwerk ATT&CK for ICS mit der Technik T0880, „Loss of Safety“, ausdrücklich Angriffe auf jene Funktionen, die einen gefährlichen Prozess in einen sicheren Zustand überführen sollen. Als Gegenmaßnahmen empfiehlt MITRE unter anderem, Sicherheitssysteme von der normalen Steuerung zu trennen und mechanische Schutzebenen vorzusehen, die von keiner Software abhängen. Daraus folgt ein Architekturprinzip, das über den Einzelfall hinausreicht: Die Sicherheitsfunktion einer Zelle darf nicht an derselben Vertrauenskette hängen wie ihre Prozesssteuerung, denn sonst fällt mit einem kompromittierten Zugang beides zugleich aus.

Für die Struktur des Netzes selbst liefert die Norm IEC 62443-3-2 aus dem Jahr 2020 ein etabliertes Prinzip: die Gliederung industrieller Kommunikation in Zonen und Conduits, also in abgegrenzte Bereiche und die definierten Verbindungen zwischen ihnen. Der Volltext der Norm ist kostenpflichtig und wird hier nicht zitiert; als Architekturidee lässt sich das Prinzip trotzdem nutzen: Jede Zone Ihres Werks sollte wissen, über welche Conduits sie erreichbar ist, und jeder dieser Conduits sollte sich einzeln schließen lassen, ohne die Zone selbst lahmzulegen. Wo die Fertigung darüber hinaus grundsätzlich angreifbar ist — nicht nur am Roboter, sondern an Steuerungen, Sensorik und Datenflüssen insgesamt —, entfaltet ein eigener Beitrag zur Angriffsfläche der Fertigung; hier dienen Zonen und Conduits nur als Schnittkante, an der sich Betrieb gestuft zurücknehmen lässt.

Dass Zugriffsrechte nicht allein aus der Position im Netz folgen sollten — ein Grundsatz, den NIST unter dem Begriff Zero Trust beschreibt — ist dafür eine Voraussetzung; ausführlich behandelt das ein eigener Beitrag zur Netzwerksicherheit in vernetzten Kliniken. Für die Fabrik zählt hier vor allem, dass sich jede Zone einzeln von ihren Conduits trennen lässt, unabhängig davon, wo im Netz sich ein Angreifer gerade aufhält.

Zwei Begriffe helfen, die Planung dahinter zu ordnen. Fail-safe bedeutet: Bei einem Fehler geht ein System in einen Zustand über, der das Risiko begrenzt, meist durch Stillstand. Fail-operational beschreibt dagegen Systeme, die trotz eines Fehlers eine definierte Funktion weiter erbringen müssen, weil ihr Ausfall selbst zur Gefahr würde. Ein verdächtiger Fernzugang darf fail-safe geschlossen werden, jedoch muss die mechanische Sicherheitsfunktion einer Zelle fail-operational bleiben, gleich was mit ihrer Netzwerkanbindung passiert.

Ein Konzept, das diese Unterscheidung erst während eines laufenden Vorfalls trifft, trifft sie unter Zeitdruck und meist falsch. Tragfähiger ist eine vorherige Einteilung jeder Funktion: welche sofort abgeschaltet werden kann, welche zunächst nur eingeschränkt werden darf, welche lokal weiterlaufen muss, welche eine manuelle Rückfallebene braucht, welche niemals von einer externen Cloud abhängen darf, und welche Sicherheitsfunktion unabhängig von der normalen Steuerung bleiben muss. Diese sechs Kategorien lassen sich für jede Roboterzelle und jedes FTS-Segment einmal im Vorfeld durchgehen und dann in die Abhängigkeitskarte aus dem vorigen Abschnitt eintragen.

Wie unscharf die Grenze zwischen einer korrekt ausgelösten Sicherheitsfunktion und einer offenen Frage zur Produktintegrität in der Praxis bleibt, zeigt eine Fallstudie zu einem Roboter, der eine Charge im Sinne der Anlagensicherheit vorschriftsgemäß stoppt, während unabhängig davon offenbleibt, ob die zuvor gefertigten Teile selbst noch in Ordnung sind — der Beitrag führt Anlagensicherheit und Produktintegrität als zwei getrennte Nachweispflichten.

Ob Ihr Werk unter das BSI-Gesetz fällt

Die Unsicherheit, die viele OT-Security-Verantwortliche in produzierenden Unternehmen teilen, lässt sich nicht mit einem Satz auflösen, aber immerhin mit einer klaren Unterscheidung entschärfen. Das BSI-Gesetz 2025 wurde am 2. Dezember 2025 ausgefertigt und ist nach Artikel 30 des Gesetzes am 6. Dezember 2025 in Kraft getreten. Es unterscheidet zwei verschiedene Adressatenkreise mit unterschiedlichen Schwellen, und beide sind ausdrücklich nicht „jedes Unternehmen“.

§ 30 Absatz 2 BSIG verpflichtet besonders wichtige und wichtige Einrichtungen — eine Einstufung, die im Kern an Sektor und Betriebsgröße hängt — unter anderem zur Bewältigung von Sicherheitsvorfällen, zur Aufrechterhaltung des Betriebs mit Backup-Management und Wiederherstellung nach einem Notfall, sowie zu Zugriffskontrolle. Das ist die gesetzliche Grundlage, die einen gestuften Notbetrieb in diesem Kreis nicht nur sinnvoll, sondern zu einer dokumentierten Pflicht macht. § 31 BSIG geht für Betreiber kritischer Anlagen noch einen Schritt weiter und verlangt Systeme zur kontinuierlichen automatischen Erfassung und Auswertung geeigneter Parameter aus dem laufenden Betrieb zur Angriffserkennung — allerdings beschränkt auf die IT-Systeme, Komponenten und Prozesse, die für die Funktionsfähigkeit der jeweiligen kritischen Anlage tatsächlich maßgeblich sind, nicht auf den gesamten IT-Bestand des Unternehmens.

Für zwei Werke mit Roboterzellen und einer FTS-Flotte lohnt sich deshalb zuerst die Frage, in welchen der beiden Kreise das eigene Unternehmen fällt — oder ob keiner von beiden zutrifft. Das ist eine Einordnung, die von Sektor, Beschäftigtenzahl und der Art der betriebenen Anlage abhängt und die dieser Beitrag nicht abschließend für Sie trifft; einen vollständigen Pflichtenbestand mit Schwellenwerten führt ein eigener Beitrag zur Klinik- und Betriebs-Cybersicherheit im Bestand. Festhalten lässt sich hier nur die Konsequenz: Wer unter § 30 oder § 31 fällt, kann einen gestuften Notbetrieb nicht als freiwillige Vorsichtsmaßnahme behandeln, sondern muss ihn als Teil der eigenen Risikomanagementpflicht dokumentieren. Das ist keine Rechtsberatung, sondern eine Einordnung der Gesetzeslage zum Zeitpunkt dieses Beitrags — die konkrete Betroffenheit sollten Sie mit Ihrer Rechtsabteilung oder einer spezialisierten Kanzlei klären.

Was die Beschaffung heute entscheidet

Viele Organisationen entdecken erst im laufenden Vorfall, dass ihr eigentlich geplanter Rückfallweg technisch nicht möglich ist. Eine Maschine benötigt dauerhaft den Cloud-Kontakt des Herstellers, ein lokaler Administratorzugang existiert nicht mehr, weil der letzte Servicetechniker ihn deaktiviert hat, oder ein Servicepartner besitzt einen privilegierten Zugang, dessen Rechte sich nicht granular begrenzen lassen. Diese Lücken entstehen nicht während des Vorfalls — sie entstehen bei der Bestellung, oft Jahre vorher.

Zwei rechtliche Entwicklungen verschieben diesen Zeitpunkt bewusst nach vorne. Die EU-Maschinenverordnung 2023/1230 verlangt in Anhang III Nummer 1.2.1, im Absatz zu Steuerungssystemen, deren Verhalten oder Logik sich vollständig oder teilweise selbst entwickelt, unter Buchstabe a, dass solche Systeme — sofern sie für einen in wechselndem Maße autonomen Betrieb ausgelegt sind — keine Handlungen auslösen, die über die festgelegte Aufgabe und den festgelegten Bewegungsbereich hinausgehen. Diese Anforderung ist beschlossen, aber noch nicht anwendbar: Die Verordnung gilt grundsätzlich erst ab dem 20. Januar 2027 — die ursprüngliche Amtsblattfassung nannte hier noch den 14. Januar 2027, korrigiert durch eine spätere Berichtigung. Wer heute neue Roboterzellen mit lernender oder sich selbst anpassender Steuerung beschafft, kauft damit faktisch schon für diese Anforderung ein, obwohl die Frist noch nicht läuft — ein eigener Beitrag zu Maschinenverordnung und Cyber Resilience Act ordnet die weiteren Fristen ein.

Parallel dazu haben CISA und mehrere internationale Partnerbehörden 2025 einen Leitfaden mit dem Titel „Secure by Demand“ veröffentlicht, der sich gezielt an Betreiber operativer Technik richtet und Anforderungen an Authentisierung, Protokollierung und Wiederherstellungsfähigkeit formuliert, die Hersteller bereits im Produktdesign berücksichtigen sollen. Für einen Einkaufskatalog für Roboterzellen, FTS-Flotten und deren Fernwartungszugänge lassen sich daraus prüfbare Kriterien statt bloßer Absichtserklärungen ableiten:

Diese Kriterien lassen sich in eine Ausschreibung schreiben und im Pflichtenheft abhaken, anders als eine Liste offener Fragen an den Vertrieb. Wer sie erst nach der Bestellung stellt, verhandelt aus einer schwächeren Position, denn die Maschine steht bereits in der Halle, und ein Rückbau ist teurer als eine Vertragsklausel.

Eine Übung, die den Ernstfall vorwegnimmt

Das ausführlichste Konzept nützt wenig, wenn niemand geprüft hat, ob die beschriebenen Schritte in der Praxis funktionieren. Eine Übung, die diesen Namen verdient, geht deshalb über eine reine Tabletop-Diskussion hinaus und simuliert einen konkreten Ablauf mit echten Entscheidungen.

Für ein produzierendes Unternehmen mit Fernwartungszugängen mehrerer Maschinenlieferanten könnte ein solches Szenario so beginnen: Das Konto eines externen Servicetechnikers ist kompromittiert, die zentrale Steuerung der FTS-Flotte bleibt über dieses Konto erreichbar, doch die mechanischen Sicherheitsfunktionen an jeder einzelnen Maschine zeigen keine Auffälligkeit. Wer darf die Flotte isolieren, und auf welcher Stufe der gestuften Reaktion? Welche Zellen dürfen währenddessen lokal weiterlaufen, weil ihre Sicherheitsfunktion unabhängig von der Flottensteuerung ist? Und wie verhindern Sie, dass genau dieses kompromittierte Konto beim Wiederanlauf ohne weitere Prüfung erneut aktiv wird?

Solche Übungen prüfen weniger die Technik als die Organisation dahinter: ob eine Entscheidung tatsächlich innerhalb von Minuten getroffen werden kann, ob die Werkleitung informiert ist, bevor es die Presse wäre, und ob die Person, die laut Stufentabelle entscheiden soll, an diesem Abend überhaupt erreichbar ist. Das Ransomware-Reifegradmodell IR 8374 Revision 1, das NIST 2026 veröffentlicht hat, ordnet genau diese Übungsfähigkeit in den größeren Rahmen des Cybersecurity Framework 2.0 ein — Bereitschaft, Reaktion und Wiederherstellung als eine zusammenhängende, wiederholt zu testende Fähigkeit, nicht als einmal geschriebenes Dokument.

Kennzahlen jenseits der Ausfallzeit

Recovery Time Objective und Recovery Point Objective sind die klassischen Größen der Betriebsfortführungsplanung: Wie schnell muss ein System zurück sein, und wie viel Datenverlust ist hinnehmbar? Für ein Budgetgespräch mit der Werkleitung bleiben diese Zahlen wichtig, weil sie sich unmittelbar in Produktionsausfall und Euro übersetzen lassen.

Für einen gestuften Notbetrieb reichen sie allein jedoch nicht aus, denn sie sagen nichts darüber, wie handlungsfähig ein Betrieb während des Vorfalls selbst bleibt. Aussagekräftiger sind ergänzende Größen wie die Zeit, die es braucht, einem kompromittierten Konto sämtliche Rechte zu entziehen, oder die Zeit, die eine Zelle ohne zentrale Dienste sicher weiterlaufen kann, bevor sie in die nächste Stufe der gestuften Reaktion wechseln muss. Was als minimale sichere Leistung für eine einzelne Zelle oder eine ganze Linie gelten soll und wie ein Betrieb danach sauber wieder anläuft, entwickelt der Beitrag zu Notbetrieb und Wiederanlauf, zusammen mit einer Vertiefung von RTO und RPO über deren klassische Grenzen hinaus; hier geht es nur um die Zeit davor und währenddessen.

Was am Ende zählt

Der digitale Notaus für eine Fabrik ist damit nicht der große rote Knopf, den man im Ernstfall sucht, sondern das Ergebnis vieler kleinerer Entscheidungen, die lange vorher getroffen wurden: bei der Beschaffung, in der Abhängigkeitskarte, in der Übung, die zeigt, ob die eigene Reihenfolge überhaupt funktioniert. Wer diese Entscheidungen jetzt trifft, muss im Ernstfall nicht mehr zwischen Stillstand und Kontrollverlust wählen — er lässt genau so viel Betrieb weiterlaufen, wie sich in diesem Moment noch nachweislich sicher beherrschen lässt.