Ein Roboterarm greift ein Werkstück, verarbeitet es nach einer bestimmten Rezeptvorgabe und übergibt es an die nächste Station. Ein Wartungszugang, eigentlich nur zur Diagnose einer Zelle freigeschaltet, kann durch einen Berechtigungsfehler auch die zentrale Rezeptdatei verändern – eine Funktion, die er für seinen eigentlichen Auftrag nicht braucht. Ein bereits an eine Anlage übergebener Fertigungsauftrag verweist dabei nur auf den Namen eines Rezepts, nicht auf eine konkret geprüfte Version. Keine Schutzeinrichtung wird dabei verändert, keine Bewegungsgrenze verletzt. Trotzdem entsteht eine Wirkungskette, an deren Ende Teile mit einer nicht freigegebenen Prozessparametrierung gefertigt werden könnten.

Dieses Szenario ist konstruiert – ein Prüfbeispiel für die Frage, was Sicherheitstechnik tatsächlich leistet und was sie nicht leistet. Es beschreibt keinen realen Vorfall und keine belegte Schwachstelle eines bestimmten Herstellers. Genau deshalb eignet es sich, um eine Verwechslung sichtbar zu machen, die in der Praxis leicht passiert: die Gleichsetzung von „die Anlage hat sicher gestoppt“ mit „es ist nichts passiert“.

Ein Berechtigungsfehler, keine durchbrochene Schutzgrenze

Der Fertigungsbereich im Szenario verbindet Produktionsplanung, Rezeptverwaltung, Roboterzellen und eine Flotte autonomer Transportfahrzeuge. Ein Optimierungsagent darf Vorschläge für die Auftragsreihenfolge erstellen, ein zeitweise freigeschalteter Wartungsdienst darf Diagnosen an einer bestimmten Zelle durchführen. Lokale Schutzfunktionen begrenzen die Maschinenbewegung unabhängig von der normalen Aufgabenplanung – diese Unabhängigkeit ist im Szenario eine Annahme, keine bewiesene Eigenschaft, und genau das muss jede reale Anlage für sich selbst nachweisen.

Der eigentliche Fehler liegt woanders: Der Wartungszugang kann auch die zentrale Rezeptdatei verändern, obwohl das für seinen Auftrag nicht erforderlich ist. Weil ein zugestellter Fertigungsauftrag nur den Namen des Rezepts referenziert und keine konkrete freigegebene Version bindet, kann eine unbemerkte Änderung an dieser Stelle in die laufende Produktion einfließen – ohne dass irgendeine Safety-Grenze berührt wird.

Warum eine reine Safety-Betrachtung zu kurz greift

Eine erfolgreiche Schutzabschaltung wäre in einem solchen Fall wertvoll, würde aber die Integrität der zuvor gefertigten Teile nicht beweisen. Produktqualität, Nachverfolgbarkeit und mechanische Gefährdung sind unterschiedliche Prüfgegenstände. Umgekehrt bedeutet eine unzulässige Rezeptänderung nicht automatisch, dass eine Maschine dadurch eine Person gefährdet. Diese Differenzierung verhindert sowohl eine voreilige Entwarnung als auch eine unbegründete Übertreibung.

Ein sinnvolles Risikoregister trennt deshalb mindestens drei Fragen: ob eine nicht freigegebene Rezeptversion tatsächlich verwendet wurde, ob nach einem Rechte-Widerruf ein bereits angenommener Auftrag trotzdem zu Ende läuft, und ob die Eingrenzung selbst einen für den sicheren Anlagenzustand nötigen Hilfsprozess unterbricht. Die konkrete sichere Reaktion hängt dabei von Anlage, Material, Energie und Prozess ab – ein pauschales „Strom aus“ ist keine allgemeine Lösung und kann in manchen Fällen selbst zum Risiko werden.

Der Pfad, den die Abwehrreaktion selbst erzeugt

Dass eine Eingrenzungsmaßnahme selbst eine neue Gefährdung erzeugen kann – etwa wenn ein für den sicheren Anlagenzustand notwendiger Hilfsprozess wie eine Kühlung oder eine Positionsüberwachung mit abgeschaltet wird –, entfaltet ein eigener Beitrag zum digitalen Not-Aus im Detail. Für diese Fallstudie zählt nur die Übertragungsfrage, die daraus folgt: Eine Maßnahme, die in einer Testumgebung oder einem anderen Anlagentyp harmlos ist, kann in dieser konkreten Fertigungslinie mit eigener Energie-, Material- und Prozesslogik eine eigene Gefährdung schaffen. Wer eine Eingrenzungsstrategie von einer Anlage auf eine andere übertragen will, muss diese Übertragung selbst prüfen – sie ist keine automatische Eigenschaft der Strategie, und genau das setzt die Gegenprobe unten voraus, ohne es zu wiederholen.

Eingrenzung nach Funktion, nicht nach Netzwerkbild

Dass eine Sperre allein des zentralen Kontos nicht genügt, wenn eine lokal zwischengespeicherte Berechtigung oder ein bereits angenommenes Kommando weiterwirkt, und Flottenmanager, Zellensteuerung und Auftragswarteschlange deshalb getrennt betrachtet werden müssen, behandelt ein eigener Beitrag zur Angriffsfläche von Industrierobotern ausführlich. Im Szenario zeigt sich diese Granularität konkret: Der Wartungszugang verliert zunächst nur die nicht erforderliche Schreibmöglichkeit auf die Rezeptdatei, während verdächtige Änderungen und ihre bisherige Verwendung erhoben werden – nicht der gesamte Zugang und nicht das gesamte Netzwerkbild. Für diese Fallstudie zählt die Konsequenz, dass Freigabe und Absperrung dadurch in derselben Charge auseinanderfallen können.

Die Qualitätssicherung grenzt parallel dazu betroffene Produkte über Versionsverwendung, Prozesszeitraum und Rückverfolgbarkeit ein – ein bloßer Kalenderbereich reicht dafür nicht, wenn verschiedene Zellen Rezeptänderungen unterschiedlich schnell übernehmen.

Was eine Gegenprobe tatsächlich zeigen muss

Eine erste Gegenprobe müsste zeigen, ob ein Auftrag tatsächlich an eine bestimmte freigegebene Rezeptversion gebunden ist: Im Positivfall verwendet er eine gültige Kombination, im Negativfall wird nach der fachlichen Freigabe die referenzierte Version verändert oder eine veraltete Version erneut angefordert. Erwartet wird dabei eine erneute Prüfung oder Ablehnung – nicht die stillschweigende Ausführung eines beliebigen aktuellen Dateiinhalts.

Eine zweite Gegenprobe widerruft den Wartungszugang und beobachtet neue, bereits angenommene und zwischengespeicherte Anforderungen getrennt, weil ein Widerruf eine bereits an eine Warteschlange übergebene Verarbeitung nicht automatisch beendet. Eine dritte prüft im freigegebenen Testaufbau eine unerwartete Flottenmission – als Prüfung der Auftragsberechtigung und der definierten Zustandsübergänge, nicht als absichtlich gefährliche Bewegung im laufenden Betrieb. Eine vierte betrifft die im Szenario zunächst nur angenommene Unabhängigkeit der lokalen Schutzfunktion selbst: Konfiguration, administrative Zugänge und gemeinsame Abhängigkeiten gehören dazu – festgelegt von fachkundigen Safety-Verantwortlichen, nicht verwechselbar mit einem improvisierten Angriff auf eine produktive Sicherheitssteuerung.

Die technische Grundlage für Punkt vier liefern etablierte Normenfamilien: ISO 10218-1 und ISO 10218-2 regeln seit ihrer Neufassung im Februar 2025 die Sicherheit von Industrierobotern, IEC 62443-3-3 die Cybersicherheit industrieller Automatisierungssysteme über ein System abgestufter Sicherheitsanforderungen. Beide Normenwerke behandeln Safety und Security als eigene, ergänzende Anforderungen – keine ersetzt die andere, und ein bestandener Test nach der einen Norm sagt nichts über die Konformität nach der anderen aus. Für kollaborierende Systeme ergänzt zusätzlich ISO/TS 15066 aus dem Jahr 2016, zuletzt 2022 bestätigt, beide Normenreihen um Anforderungen an die gemeinsame Arbeitsumgebung von Mensch und Roboter. Welche dieser Normen für eine reale Anlage im Einzelfall greift und welchen Nachweis sie konkret verlangt, entscheidet die Anlage selbst – eine klassisch abgeschottete Zelle, ein geteilter Arbeitsraum mit Menschen und eine vernetzte Steuerung werfen jeweils andere Fragen auf. Diese Fallstudie benennt nur, dass die Frage gestellt werden muss, nicht, wie sie für eine bestimmte Anlage zu beantworten ist.

Zwei getrennte Freigaben statt einer

Selbst ein bestandenes Wiederanlauf-Gate beantwortet nur, dass die Steuerung wieder sicher läuft – nicht, ob das zuvor gefertigte Produkt in Ordnung ist. Ein geeignetes Prüfergebnis kann die Steuerungsfunktion freigeben, während die Produktfreigabe für einen abgegrenzten Bestand offen bleibt – das ist kein Widerspruch, sondern Ausdruck zweier getrennter Schutzgegenstände. Ebenso kann ein Teilbereich mit validiertem lokalen Betrieb weiterarbeiten, während die zentrale Optimierung deaktiviert bleibt. Die Produktfreigabe scheitert, wenn die verwendeten Rezeptstände nicht rekonstruierbar sind, ein nicht erfasster Administrationspfad weiterbesteht oder die angenommene sichere Betriebsart nicht nachgewiesen werden kann – ein pauschales „Backup eingespielt, Anlage grün“ wäre dafür nicht ausreichend. Wie ein solches Gate den rekonstruierten Zustand gegen freigegebene Engineering-Stände, Rezeptversionen und die reale Anlagenlage abgleicht, bevor eine Anlage überhaupt wieder anläuft, entfaltet ein eigener Beitrag zu Recovery und Notbetrieb nach einem Cyberangriff ausführlicher.

Was sich auf die eigene Anlage übertragen lässt

Dass solche Szenarien praktisch relevant werden können, hat einen realen Größenrahmen: Allein in Deutschland wurden 2024 laut International Federation of Robotics 26.982 Industrieroboter neu installiert, bei einer Roboterdichte von 449 Einheiten je 10.000 Beschäftigten im verarbeitenden Gewerbe – Rang drei weltweit. Ob und wie viele dieser konkreten Anlagen die im Szenario beschriebene Kombination aus Auftragsplanung, Rezeptverwaltung und Zellensteuerung tatsächlich verbinden, lässt sich aus dieser Installationszahl allein nicht ableiten – sie belegt nur die Größenordnung des Feldes, nicht dessen Softwarearchitektur.

Übertragbar ist zunächst die Trennschärfe der Fragen selbst, nicht der konkrete Fall. Wer nach einem Sicherheitsereignis in der eigenen Fertigung nur prüft, ob die Anlage sicher gestoppt hat, beantwortet damit noch nicht, ob die zuletzt produzierten Teile die vorgesehene Prozessparametrierung tatsächlich durchlaufen haben. Beide Antworten brauchen eigene Nachweise, eigene Zuständigkeiten und eigene Freigabekriterien – und beide Freigaben können zu unterschiedlichen Zeitpunkten erfolgen, ohne dass eine die andere ersetzt.

Drei Prüffragen für die eigene Anlage

Für die betriebliche Praxis folgen daraus drei nüchterne Prüffragen: Ist die Unabhängigkeit der lokalen Schutzfunktion von der betrieblichen Steuerung – auch bei gemeinsamen administrativen Zugängen – tatsächlich nachgewiesen, oder wird sie nur angenommen? Ist jeder Fertigungsauftrag an eine konkrete, geprüfte Rezeptversion gebunden, oder nur an einen Namen – und ist dafür überhaupt protokolliert, welche Version wann wo lief? Und ist im Vorfeld geklärt, welcher Hilfsprozess bei einer Eingrenzungsmaßnahme selbst zum Risiko werden könnte? Wo diese drei Prüffragen zur eigenen Anlage unbeantwortet bleiben, ersetzt ein sicherer Stopp keine Aussage über die Charge, die davor gefertigt wurde.

Häufige Fragen