Zero-Day-Risiko in SCADA: Wenn die Fertigungslinie zum Angriffsziel wird

Fertigungsanlagen laufen, Schicht für Schicht, rund um die Uhr. Irgendwo dazwischen läuft SCADA-Software, die Ventile steuert, Temperaturen überwacht und Produktionslinien synchronisiert – oft auf Systemen, die seit Jahren keinen Patch gesehen haben. Das Bedrohungsbild für industrielle Steuerungssysteme verschärft sich im Sommer 2026 spürbar: Sicherheitsforscher und CERTs melden gehäufte Schwachstellenfunde in OT-Umgebungen, das BSI schärft seine ICS-Empfehlungen, und Angreifer haben längst verstanden, dass die Luftlücke ein Mythos ist.

Was SCADA mit Ihrer Produktion zu tun hat – und warum das brisant ist

SCADA steht für Supervisory Control and Data Acquisition. Klingt technisch, ist aber simpel: Diese Systeme sind das Nervensystem moderner Fabriken. Sie erfassen Sensordaten von Maschinen, steuern Aktuatoren, visualisieren Prozesse auf Leitwarten-Displays und alarmieren bei Abweichungen. Wer eine Fertigungslinie, eine Wasseraufbereitung oder ein Energienetz betreibt, betreibt fast zwangsläufig SCADA.

Das Pikante daran: Diese Software wurde jahrzehntelang für geschlossene, physisch isolierte Netze entworfen. Sicherheit durch Abschottung, nicht durch Kryptografie. Das Vertrauen galt dem Kabel, nicht dem Zertifikat. Dann kam Industrie 4.0, dann kamen Remote-Zugänge für Wartungstechniker, dann kamen Cloud-Dashboards für die Geschäftsführung. Die Luftlücke? Längst perforiert.

Industrielle Steuerungssysteme kommunizieren heute oft über dieselben Netzwerkschichten wie klassische IT. Protokolle wie Modbus oder OPC-UA sind keine Geheimsprachen mehr – sie sind dokumentiert, verbreitet und gut erforscht. Gut erforscht von Verteidigern. Und von Angreifern.

Der strukturelle Angriff: Wie OT-Umgebungen kompromittiert werden

Remote Code Execution auf einer SPS klingt nach Sci-Fi-Thriller. Ist es nicht. Der Angriffsweg ist meist erschreckend prosaisch. Ein Wartungslaptop mit veralteter VPN-Software verbindet sich mit dem OT-Netz. Eine HMI-Schnittstelle hängt ungeschützt im internen Netz, erreichbar für jeden, der einmal die IT-Firewall passiert hat. Ein Techniker öffnet eine präparierte Projektdatei aus einer E-Mail.

Plot Twist: Die gefährlichste Schwachstelle ist oft nicht die Software selbst, sondern die Architektur drumherum. SCADA-Komponenten laufen auf Windows-Rechnern, die seit Jahren kein Update gesehen haben – weil ein Patch im laufenden Betrieb einen Neustart erfordert, und ein Neustart eine Produktionslinie stoppt, und eine gestoppte Linie Geld kostet. Dieses Kalkül ist verständlich. Es ist auch das, worauf Angreifer setzen.

OT-Security-Spezialisten beschreiben dieses Muster seit Jahren. Penetrationstests in industriellen Umgebungen zeigen regelmäßig: Sobald ein Angreifer ins IT-Netz gelangt, ist der Weg ins OT-Netz oft nur eine Frage der Geduld und eines schlecht segmentierten VLANs. Defense-in-Depth ist hier keine Marketing-Formel, sondern eine strukturelle Notwendigkeit.

Siemens WinCC, Legacy-Systeme und die Patch-Resistenz der Produktion

Siemens positioniert WinCC V8.1 – beschrieben im April 2025 auf dem Siemens-Blog – als sicherheitszertifizierte SCADA-Komponente mit Event-Logging und modernen Security-Features. Das ist ermutigend. Die Realität in deutschen Fertigungsbetrieben sieht häufig anders aus.

Industrielle Steuerungssysteme haben Lebenszyklen von zehn, fünfzehn, manchmal zwanzig Jahren. Eine Produktionslinie, die 2010 in Betrieb ging, läuft möglicherweise noch heute mit derselben Softwareversion. Der Hersteller unterstützt diese Version vielleicht nicht mehr. Patches gibt es keine. Eine Migration bedeutet Monate der Planung, Zertifizierungsaufwand, Ausfallzeiten.

Wenig überraschend: Genau diese Legacy-Systeme sind das bevorzugte Ziel. Sie sind bekannt, dokumentiert und ungepacht. Wer die öffentlich verfügbaren Schwachstellendatenbanken kennt, findet dort Einträge für industrielle Steuerungskomponenten, die längst am Ende ihres Support-Zyklus sind. Das BSI weist in seinen Empfehlungen zur Cybersicherheit für Unternehmen ausdrücklich auf die Bedeutung von Schwachstellenmanagement und Patch-Prozessen hin – auch und gerade für OT-Umgebungen.

Das Kalkül der Betreiber ist rational, das Ergebnis strukturell gefährlich. Solange ein Patch teurer erscheint als das kalkulierte Angriffsrisiko, bleibt er aus. Bis der Angriff eintritt.

Geopolitik trifft Fertigungshalle: Wer greift an, und warum

Angriffe auf industrielle Steuerungssysteme sind keine Domäne gelangweilter Scriptkiddies. Die Motivlage ist komplexer und das macht die Bedrohung ernster. Drei Täterprofile dominieren die Einschätzung von Sicherheitsforschern.

Erstens: staatlich gesteuerte Akteure, die kritische Infrastruktur kartieren oder sabotieren wollen. Fertigungsanlagen, die für die Verteidigung, für Energie oder für die Nahrungsmittelversorgung relevant sind, stehen seit Jahren auf Radar-Schirmen geopolitischer Angreifer. OT-Sicherheit ist damit nicht mehr nur eine technische, sondern eine geopolitische Frage.

Zweitens: Ransomware-Gruppen, die erkannt haben, dass ein stillgelegtes Förderband mehr Druck erzeugt als verschlüsselte Office-Dokumente. Wer eine Produktionslinie anhält, hält auch den Cashflow an. Die Bereitschaft zu zahlen steigt rapide.

Drittens – und das wird systematisch unterschätzt: Industriespionage. SCADA-Systeme speichern Produktionsparameter, Rezepturen, Prozessoptimierungen, Qualitätsdaten. Das ist das operative Gedächtnis eines Fertigungsbetriebs. Wer diese Daten exfiltriert, stiehlt nicht Bytes, sondern Jahre von Entwicklungsarbeit. Betriebsgeheimnisse im SCADA-System sind oft schlechter geschützt als in der Buchhaltung.

Die Luftlücke als Wunschdenken: Reale Angriffsvektoren

„Unsere Produktions-IT ist nicht mit dem Internet verbunden.“ Diesen Satz hört man häufiger, als man ihn glauben kann. Stimmt er? Selten vollständig. Meistens existieren Übergänge: ein Jump-Host für Remote-Wartung, eine DMZ, die nicht wirklich als DMZ konfiguriert ist, ein Drucker im OT-Netz mit direktem Internet-Update-Zugang.

USB-Vektoren sind klassisch und weiterhin wirksam. Ein Techniker steckt einen privaten USB-Stick an eine Wartungs-HMI. Fertig. Der bekannte Stuxnet-Angriff aus 2010 – bis heute Referenzfall für ICS-Security – nutzte genau diesen Weg. Seitdem hat sich wenig verändert, außer dass die Angreifer besser geworden sind.

Lieferketten sind ein weiterer Vektor. Software-Updates für SCADA-Komponenten kommen vom Hersteller oder von Drittdienstleistern. Wer diesen Kanal kompromittiert, liefert Schadcode direkt in die Produktionsumgebung – mit gültigem Zertifikat, ohne Firewall-Alarm. OT-Sicherheit endet nicht an der eigenen Netzwerkgrenze.

NIS2 und die Meldepflicht: Was Betreiber jetzt beachten müssen

Die NIS2-Richtlinie ist seit Oktober 2024 in deutsches Recht überführt und betrifft deutlich mehr Unternehmen als ihr Vorgänger. Fertigungsbetriebe, die als Betreiber kritischer Anlagen oder als wichtige Einrichtungen eingestuft werden, unterliegen Meldepflichten bei erheblichen Sicherheitsvorfällen: erste Meldung binnen 24 Stunden, detaillierter Bericht binnen 72 Stunden.

Der Clou: Viele mittelständische Fertigungsbetriebe wissen noch nicht mit Sicherheit, ob sie in den NIS2-Geltungsbereich fallen. Die Selbsteinstufung ist komplex, der Beratungsbedarf hoch. Wer einen OT-Vorfall hat und ihn nicht meldet, riskiert empfindliche Bußgelder – zusätzlich zum Produktionsausfall.

Meine persönliche Einschätzung: NIS2 ist, trotz des bürokratischen Aufwands, strukturell richtig. Sicherheitsvorfälle in OT-Umgebungen wurden viel zu lange intern vergraben. Die Meldepflicht erzeugt Transparenz – und Transparenz ist eine Voraussetzung dafür, dass die Branche aus Vorfällen lernt, nicht nur der Betroffene selbst.

OT-Sicherheit konkret: Was Defense-in-Depth für die Fertigung bedeutet

Segmentierung ist der erste und wichtigste Schritt. OT-Netz und IT-Netz gehören getrennt, mit klar definierten, überwachten Übergängen. Eine DMZ zwischen beiden Netzen, die Kommunikation protokolliert und filtert, ist keine Luxuslösung mehr, sondern Stand der Technik. OT-Sicherheitskonzepte nach dem Purdue-Modell oder der IEC 62443 geben hier klare Orientierung.

Netzwerkmonitoring speziell für OT-Protokolle ist der zweite Schritt. Klassische IT-Security-Tools verstehen Modbus, Profinet oder OPC-UA nicht. Spezialisierte OT-Monitoring-Lösungen erkennen Anomalien im Steuerungsverkehr – ungewöhnliche Kommandosequenzen, neue Teilnehmer im Netz, unerwartete Verbindungsaufbauten. Was man nicht sieht, kann man nicht verteidigen.

Zugriffsmanagement nach Least Privilege ist der dritte Schritt. Wartungszugänge sollten zeitlich befristet sein, Single-Use-Credentials nutzen und vollständig protokolliert werden. Remote-Zugang für Dienstleister über MFA und dedizierte Jump-Server statt VPN-Dauerverbindungen ist dabei keine Paranoia, sondern gute Praxis.

Patch-Management im OT-Kontext braucht eigene Prozesse. Das Tempo der IT gilt hier nicht. Patches müssen in Testumgebungen validiert werden, Wartungsfenster geplant, Rückfalloptionen definiert. Wer keinen Patch-Prozess hat, hat de facto einen Freeze-Prozess – und der ist langfristig gefährlicher als jeder Neustart.

USB-Kontrolle und Wechselmedienmanagement runden das Bild ab. Nicht jeder Produktionsrechner braucht aktive USB-Ports. Wer sie deaktiviert oder durch Allowlisting kontrolliert, schließt einen klassischen Angriffsvektor – ohne großen Aufwand. Das Security-Insider-Portal dokumentiert solche Best Practices für industrielle Umgebungen regelmäßig.

Incident Response in OT-Umgebungen: Warum klassische IT-Playbooks nicht greifen

Wer in der klassischen IT einen kompromittierten Rechner isoliert, zieht ihn vom Netz und setzt ihn neu auf. In der OT-Welt ist dieser Reflex gefährlich. Eine SPS, die mitten im laufenden Produktionsprozess vom Netz getrennt wird, kann unkontrollierte physische Zustände erzeugen – Überdruckventile, die nicht schließen, Temperaturen, die nicht geregelt werden, Förderbänder, die abrupt stoppen. Die Konsequenzen reichen von Materialverlust bis zu Personenschäden.

Daraus folgt: OT-Incident-Response braucht eigene Playbooks, die gemeinsam von IT-Sicherheitsteams und Produktionsingenieuren entwickelt werden. Wer erst im Ernstfall herausfindet, welche Systeme man wann vom Netz nehmen darf, hat zu spät angefangen. Konkret bedeutet das: Für jede kritische OT-Komponente sollte vorab dokumentiert sein, welche Abschaltsequenz sicher ist, welche Abhängigkeiten bestehen und wer die Entscheidungskompetenz trägt.

Ein weiterer Unterschied zur klassischen IT: Forensik in OT-Umgebungen ist aufwändiger und schonender durchzuführen. Viele Steuerungssysteme haben begrenzte Logging-Kapazitäten oder überschreiben Protokolle nach kurzer Zeit. Wer nach einem Vorfall spurensichern will, braucht spezialisierte OT-Forensik-Werkzeuge und muss schnell handeln. Auch in diesem Bereich zeigt die Praxis, dass KI-gestützte Systeme zur Anomalieerkennung in der Industrie zunehmend dabei helfen, verdächtige Muster in Echtzeit sichtbar zu machen, bevor Schaden entsteht.

Das Fachkräfteproblem: OT-Sicherheit braucht Brückenbauer

Ein strukturelles Problem, das in der Diskussion um SCADA-Sicherheit regelmäßig zu kurz kommt: Es gibt zu wenige Menschen, die sowohl OT-Prozesse als auch IT-Sicherheit wirklich verstehen. IT-Sicherheitsexperten kennen Angriffsvektoren, denken in Protokollen und Patches. Produktionsingenieure kennen Prozessabhängigkeiten, denken in Verfügbarkeit und Ausfallzeiten. Beide haben recht. Beide brauchen einander.

In der Praxis werden diese beiden Welten häufig getrennt verantwortet – unterschiedliche Abteilungen, unterschiedliche Budgets, manchmal sogar unterschiedliche Standorte. Diese organisatorische Trennung ist eine Sicherheitslücke, die kein technisches Tool schließen kann. Unternehmen, die OT-Sicherheit ernst nehmen, investieren deshalb nicht nur in Technologie, sondern in gemeinsame Schulungen, gemeinsame Krisenübungen und gemeinsame Governance-Strukturen.

Ein vielversprechender Ansatz: Tabletop-Übungen, bei denen IT-Sicherheitsteam und Produktionsverantwortliche gemeinsam simulierte Angriffsszenarios durchspielen. Diese Übungen decken Kommunikationslücken, unklare Zuständigkeiten und fehlende Eskalationspfade auf – ohne dass eine echte Produktionslinie stillsteht. Der Aufwand ist überschaubar, der Erkenntnisgewinn erheblich.

Betriebsgeheimnisse als unterschätztes Schutzgut

Datenschutz in SCADA-Umgebungen denken die meisten sofort an personenbezogene Daten. Falsch angesetzt. Das eigentliche Schutzgut sind Betriebsgeheimnisse: Rezepturen, Prozessparameter, Qualitätsdaten, Wartungsprotokolle, Produktionsmengen. Diese Daten stecken in SCADA-Historien, in HMI-Datenbanken, in Engineering-Workstations.

Ein Angreifer, der diese Daten exfiltriert, braucht keine Ransomware. Stille Industriespionage – tagelang, wochenlang – ist schwerer zu entdecken als ein lauter Verschlüsselungsangriff. Die forensischen Spuren sind oft gering, der Schaden immens. Ein Wettbewerber, der die Produktionsoptimierungen der letzten fünf Jahre kennt, hat einen strukturellen Vorteil, den kein Patentrecht zurückholt.

Ich finde es bezeichnend, dass in vielen Fertigungsbetrieben die Buchhaltungsdaten besser geschützt sind als die Produktionsdaten. Dabei sind letztere oft der eigentliche Kern des Unternehmenswertes.

Was bleibt: Handlungsschritte und eine offene Frage

Die Bedrohungslage für SCADA und industrielle Steuerungssysteme ist keine abstrakte Zukunftsprognose. Sie ist das aktuelle Betriebsrisiko jeder Fertigungsanlage, die Netzwerkverbindungen hat. Das sind fast alle.

Konkrete erste Schritte:

• Asset-Inventar aller OT-Komponenten erstellen, Softwareversionen und Patchstand dokumentieren
• Netzwerksegmentierung zwischen IT und OT überprüfen und ggf. nachrüsten
• Remote-Zugänge auf Multi-Faktor-Authentifizierung umstellen
• OT-spezifisches Netzwerkmonitoring einführen
• Incident-Response-Playbooks für OT-Szenarien gemeinsam mit Produktionsingenieuren entwickeln
• NIS2-Geltungsbereich für das eigene Unternehmen rechtssicher klären
• Tabletop-Übungen mit IT- und OT-Teams durchführen

Das ist kein Sprint, sondern ein Programm – aber es beginnt mit einem Inventar, das viele Betriebe überraschen wird.

Die offene Frage, die mich beschäftigt: Wie viele Fertigungsbetriebe warten auf den ersten Vorfall, bevor sie OT-Sicherheit ernst nehmen? Und wie viele davon werden nach diesem Vorfall sagen, dass sie es hätten wissen können?