NIS2 OT-Sicherheit und das Purdue-Modell: Referenzarchitektur für die IT/OT-Segmentierung in Industrie und Energie

96 Prozent aller OT-Sicherheitsvorfälle gehen nicht auf einen Angriff direkt gegen die Produktionsanlage zurück, sondern auf eine Kompromittierung, die aus der klassischen IT herüberschwappt – 56 Prozent als direkter Durchgriff, 40 Prozent als Kollateralschaden. Das zeigt der Annual OT/ICS Cybersecurity Report 2026 von TXOne Networks, der zusätzlich beziffert, dass 60 Prozent der befragten Unternehmen innerhalb von zwölf Monaten mindestens einen OT-Sicherheitsvorfall registrierten[1]. Die Konsequenz für jeden, der NIS2 in einer Fertigungshalle oder einem Umspannwerk umsetzen muss: Die Grenze zwischen IT und OT ist die Stelle, an der sich entscheidet, ob ein IT-Vorfall auf dem Bürorechner bleibt oder eine Turbine stoppt.

Das Purdue-Modell ist die Antwort der Industrie auf genau dieses Problem – eine Referenzarchitektur, die Netzwerke in klar getrennte Ebenen zerlegt und genau festlegt, welche Systeme miteinander sprechen dürfen und welche nicht. Dieser Artikel zeigt, wie die sechs Purdue-Ebenen und das Zonen-Konzept der IEC 62443 zusammenwirken, wo Netzsegmentierung im deutschen NIS2-Recht (§ 30 BSIG) und in Art. 21(2) der NIS2-Richtlinie tatsächlich verankert ist – und warum eine oft zitierte EU-Verordnung dafür nicht die Rechtsgrundlage liefert. Grundlage sind unter anderem die zehn NIS2-Risikomanagementmaßnahmen, die diesen Artikel als Hub referenziert.

Was ist das Purdue-Modell? Die sechs Ebenen der OT-Sicherheit

Kurz gesagt: Das Purdue-Modell ordnet jedes Gerät in einer Produktionsanlage einer von sechs Ebenen zu – von der Physik der Maschine bis zur Unternehmens-IT – und macht damit sichtbar, wo eine Firewall zwingend hingehört.

Entwickelt wurde das Purdue Enterprise Reference Architecture Model (PERA) bereits in den 1990er-Jahren an der Purdue University – ursprünglich nicht als Sicherheitsmodell, sondern zur Integration von Unternehmens- und Fertigungssystemen. Heute ist es der De-facto-Standard für die Segmentierung industrieller Netzwerke[2]:

Die Ebene 3.5 verdient besondere Aufmerksamkeit, weil hier die meisten Sicherheitskonzepte scheitern: Die industrielle DMZ darf niemals eine Verbindung in die OT-Zone hinein selbst aufbauen – jede Sitzung muss aus der OT-Zone heraus initiiert werden, nie umgekehrt[2]. Ein Jump-Server in der DMZ, auf den ein IT-Techniker zugreift, um von dort in die OT-Zone weiterzuspringen, ist damit etwas anderes als ein Server in der IT, der aktiv Befehle in die Fertigung schickt. Diese Asymmetrie ist der eigentliche Schutzmechanismus – nicht die Firewall allein.

Zwei Einschränkungen gehören ehrlich dazu: IIoT-Sensoren und Cloud-Anbindungen an Historians überspringen die strikte Hierarchie zunehmend, weil sie Daten direkt aus Level 2 oder 3 in eine Cloud-Plattform senden. Segmentierung allein reicht deshalb ohne kontinuierliches Monitoring der Zonenübergänge nicht mehr aus[2]. Für die reine Frage, welche Zone existieren muss und wo eine Firewall hingehört, bleibt das Modell aber der richtige Ausgangspunkt.

IEC 62443: Zonen, Conduits und Security Levels als technisches Fundament

Kurz gesagt: Das Purdue-Modell sagt Ihnen, wo eine Grenze verläuft; die IEC 62443 sagt Ihnen, wie stark diese Grenze gesichert sein muss.

Die IEC 62443 ist der internationale Referenzstandard für industrielle Automatisierungssicherheit und ergänzt das Purdue-Modell um ein risikobasiertes Konzept: Eine Zone ist eine Gruppierung von Anlagen mit gleichen Sicherheitsanforderungen, ein Conduit ist der kontrollierte Kommunikationsweg zwischen zwei Zonen[3]. Statt die sechs Purdue-Ebenen starr zu übernehmen, verlangt die Norm eine Risikobewertung je Zone, aus der sich ein Ziel-Sicherheitsniveau (Target Security Level, SL-T) ableitet – abgegrenzt vom Fähigkeits-Sicherheitsniveau eines Bauteils (SL-C, was das Gerät technisch von Haus aus leistet) und dem erreichten Sicherheitsniveau im laufenden Betrieb (SL-A)[3]. Die Skala reicht von SL 0 bis SL 4 und beschreibt qualitativ, wie viele Ressourcen, Fachkenntnisse und Motivation ein Angreifer bräuchte, um die Gegenmaßnahmen einer Zone zu überwinden – keine quantitative Kennzahl, sondern eine Einordnung des Bedrohungsniveaus.

Praktisch bedeutet das: Die Feldebene (Level 0–1) bekommt in aller Regel das höchste Ziel-Sicherheitsniveau zugewiesen, weil ein Ausfall hier unmittelbar physische Folgen hat, während die Unternehmens-IT (Level 4–5) mit einem niedrigeren SL-T auskommt. Eine SCADA-Zone auf Level 2 landet typischerweise bei SL-T 2–3, weil ein Angriff zwar den Prozess beeinträchtigen, aber selten sofort physischen Schaden verursachen kann – die industrielle DMZ selbst wird meist mit SL-T 3 bewertet, weil sie der am stärksten exponierte Übergangspunkt im gesamten Netz ist. Das Purdue-Modell liefert die Landkarte, die IEC 62443 liefert das Lineal, mit dem Sie messen, wie dick jede Zonengrenze sein muss.

Wo Netzsegmentierung im NIS2-Recht tatsächlich steht: § 30 BSIG und Art. 21(2)

Kurz gesagt: Weder das BSIG noch die NIS2-Richtlinie schreiben das Wort „Netzsegmentierung” als eigenen Pflichtpunkt – die Pflicht ergibt sich aus der allgemeinen Risikomanagement-Vorgabe, und Segmentierung ist die anerkannte Umsetzung davon.

§ 30 Abs. 1 BSIG verlangt von besonders wichtigen und wichtigen Einrichtungen „geeignete, verhältnismäßige und wirksame technische und organisatorische Maßnahmen”, orientiert am Stand der Technik, um Störungen der Informationstechnik vorzubeugen und deren Auswirkungen zu begrenzen[4]. Absatz 2 konkretisiert das in zehn Maßnahmenbereichen, deckungsgleich mit Art. 21(2)(a)–(j) der NIS2-Richtlinie[5]. Netzsegmentierung ist darin kein eigener Listenpunkt, sondern ordnet sich in der Praxis zwei Bereichen zu: den „Konzepten zur Risikoanalyse und Sicherheit in der Informationstechnik” (Nr. 1 BSIG / Art. 21(2)(a)) als grundsätzliche Architekturentscheidung, und den „Sicherheitsmaßnahmen bei Erwerb, Entwicklung und Wartung von IT-Systemen” (Nr. 5 BSIG / Art. 21(2)(e)), sobald es um die konkrete Umsetzung an Schnittstellen und beim Patchen von OT-Komponenten geht. Das BSI selbst nennt Netzsegmentierung explizit als Beispiel für eine vorbeugende Maßnahme innerhalb dieser allgemeinen Pflicht[6] – schreibt aber keine bestimmte Architektur wie das Purdue-Modell vor. Das ist der Grund, warum eine reine Auflistung der zehn Maßnahmen für OT-Betreiber wenig hilft, ohne eine technische Referenz wie das Purdue-Modell dahinterzulegen.

Für die Dokumentation bedeutet das konkret: Ein Auditor prüft nicht, ob Sie „Netzsegmentierung” als Wort in einer Richtlinie stehen haben, sondern ob Sie nachweisen können, dass Ihre Zonierung das Ergebnis einer Risikoanalyse ist – mit Begründung, warum genau diese Grenzen an genau diesen Stellen verlaufen.

Der CIR-2690-Irrtum: Warum die Verordnung nicht für Maschinenbau und Energie gilt

Kurz gesagt: Die Durchführungsverordnung (EU) 2024/2690 wird in Beratungsangeboten häufig als technischer Maßstab für „alle” NIS2-Pflichten zitiert – sie bindet aber ausschließlich neun eng definierte Kategorien digitaler Infrastrukturanbieter, keine Fertigungs- oder Energieunternehmen.

Artikel 1 der CIR 2024/2690 legt den Anwendungsbereich abschließend fest: DNS-Diensteanbieter, TLD-Namenregister, Cloud-Computing-Diensteanbieter, Anbieter von Rechenzentrumsdiensten, Betreiber von Content-Delivery-Netzwerken, Managed-Service-Anbieter, Managed-Security-Service-Anbieter, Anbieter von Online-Marktplätzen, Online-Suchmaschinen und Plattformen für soziale Netzwerke sowie Vertrauensdiensteanbieter[7]. Ein Maschinenbauunternehmen oder ein Energieversorger taucht in dieser Liste nicht auf. Wer Ihnen ein CIR-Annex-Kapitel als bindende Pflicht für Ihre Produktionsanlage verkauft, zitiert die falsche Rechtsgrundlage – für Sie gilt die allgemeine, technologieoffene Vorgabe aus § 30 BSIG und Art. 21(2).

Das heißt nicht, dass die CIR irrelevant ist: Sie kann als Auslegungshilfe dafür dienen, was „angemessen und verhältnismäßig” nach dem Stand der Technik konkret bedeutet, und deutsche Aufsichtsbehörden greifen in der Praxis gelegentlich auf ihre technischen Maßstäbe zurück, wenn sie prüfen, ob eine Maßnahme ausreicht[8]. Sie ist damit ein nützlicher Referenzrahmen – aber keine Rechtspflicht, die Ihr Unternehmen direkt bindet, und kein Ersatz für eine eigene, dokumentierte Risikoanalyse nach § 30 Abs. 1 BSIG.

Wer macht was? Rollenverantwortung für OT-Segmentierung

Kurz gesagt: OT-Segmentierung scheitert in der Praxis seltener an der Technik als an der Zuständigkeit – IT-Sicherheit und Produktionsleitung sprechen selten dieselbe Sprache über dasselbe Netzwerk.

Der häufigste Fehler ist, die Zonierung allein als IT-Projekt zu behandeln. Ohne die Produktionsleitung am Tisch wird eine Firewall-Regel eingeführt, die eine Nachtschicht lahmlegt – und beim nächsten Mal wieder deaktiviert, bevor sie geprüft wurde.

Für Maschinenbau- und Fertigungsbetriebe kommt hinzu, dass Produktionsleitung und Instandhaltung häufig historisch gewachsene Remote-Zugänge von Maschinenherstellern verwalten, die bei der Zonierung mitgedacht werden müssen. In der Energiebranche tritt eine zusätzliche Rolle hinzu: Netzleitstellen-Personal, das rund um die Uhr Verfügbarkeit garantieren muss und jede Zonenänderung an Schutzkonzepten der Netzführung spiegeln muss.

Brownfield-Realität: Segmentierung in bestehenden Anlagen nachrüsten

Kurz gesagt: Die wenigsten Anlagen werden neu gebaut – die eigentliche Arbeit ist, das Purdue-Modell nachträglich über eine gewachsene, oft 15 bis 25 Jahre alte Infrastruktur zu legen, ohne den Betrieb zu unterbrechen.

Eine Analyse des aktuellen Zustands gegen den Zielzustand macht sichtbar, wo der Aufwand tatsächlich liegt:

Der entscheidende Unterschied zu einer Neuanlage: Bei einer 20 Jahre alten SPS, die kein modernes Sicherheitsupdate mehr erhält, ersetzt eine dokumentierte Risikoakzeptanz mit kompensierenden Maßnahmen – strengere Segmentierung, engmaschiges Monitoring des Conduits – häufig das Patchen selbst. Das ist kein Kompromiss zweiter Klasse, sondern genau der risikobasierte Ansatz, den § 30 Abs. 1 BSIG mit „Stand der Technik” meint: angemessen zur tatsächlichen Exposition, nicht zur theoretisch besten Lösung.

Der pragmatischste Einstieg in ein Brownfield-Projekt ist deshalb selten der sofortige Netzumbau, sondern passives Monitoring an den geplanten Zonengrenzen: Ein Sensor protokolliert zunächst nur, welcher Datenverkehr tatsächlich zwischen den künftigen Zonen fließt, bevor eine einzige Firewall-Regel scharf geschaltet wird. Diese Beobachtungsphase von typischerweise vier bis acht Wochen deckt genau die Altlasten auf, die sonst erst beim produktiven Umschalten auffallen – etwa einen Historian, der entgegen der Dokumentation doch aktiv Verbindungen in eine SPS-Zone aufbaut. Erst danach werden die Regeln schrittweise von „beobachten” auf „durchsetzen” umgestellt, Zone für Zone statt in einem einzigen Wartungsfenster.

Der 5-Schritte-Fahrplan mit Aufwandseinschätzung

Kurz gesagt: Segmentierung lässt sich in überschaubare Schritte zerlegen, die nicht alle gleichzeitig Budget und Stillstand erfordern.

1. Asset-Inventar erstellen (Aufwand: Mittel) – jede SPS, jedes HMI, jeden Historian erfassen, inklusive Firmware-Stand und Herstellerzugängen.
2. Purdue-Ebenen zuordnen (Aufwand: Niedrig) – jedes Asset einer Ebene 0–5 zuweisen; das ist reine Dokumentationsarbeit auf Basis des Inventars.
3. Zonen und Conduits definieren (Aufwand: Mittel) – pro Zone ein Ziel-Sicherheitsniveau nach IEC 62443 festlegen und die erlaubten Kommunikationswege benennen.
4. Industrielle DMZ einrichten oder härten (Aufwand: Hoch) – Firewalls und Jump-Server so konfigurieren, dass Verbindungen ausschließlich aus der OT-Zone heraus initiiert werden.
5. Risikoanalyse dokumentieren (Aufwand: Niedrig) – die Zuordnung zu § 30 Abs. 2 BSIG schriftlich festhalten, als Nachweis für die nächste Prüfung.

Diese Reihenfolge ist bewusst so gewählt, dass die aufwendigsten Schritte (1 und 4) auf einem soliden Dokumentationsfundament (2, 3, 5) aufsetzen – wer die DMZ zuerst baut, ohne das Inventar zu kennen, baut oft an der falschen Stelle.

Häufig gestellte Fragen

Ersetzt das Purdue-Modell eine Risikoanalyse nach § 30 BSIG?

Nein. Das Purdue-Modell ist eine technische Referenzarchitektur, keine Rechtsnorm. Es hilft, die nach § 30 Abs. 1 BSIG geforderte Risikoanalyse zu strukturieren, ersetzt sie aber nicht – die Dokumentation, warum eine bestimmte Zonierung angemessen ist, bleibt Ihre Aufgabe.

Gilt IEC 62443 verpflichtend für NIS2-Einrichtungen?

Nein, IEC 62443 ist eine internationale Norm, keine gesetzliche Pflicht. Sie wird jedoch von Auditoren und Aufsichtsbehörden regelmäßig als anerkannter Stand der Technik herangezogen, wenn beurteilt wird, ob Ihre technischen Maßnahmen nach § 30 BSIG angemessen sind.

Muss ich mein gesamtes Netzwerk auf einmal umbauen?

Nein. Der risikobasierte Ansatz von § 30 Abs. 1 BSIG erlaubt eine Priorisierung nach Exposition: Zonen mit den höchsten Sicherheitsanforderungen – meist Level 0–1 – zuerst, gefolgt von der industriellen DMZ. Ein vollständiger Umbau in einem Schritt ist weder gefordert noch praktikabel.

Was, wenn eine Legacy-SPS keine Segmentierung technisch zulässt?

Dann tritt eine kompensierende Kontrolle in Kraft: strengere Überwachung des Conduits, restriktivere Zugriffsregeln und eine dokumentierte Risikoakzeptanz. Diese Dokumentation selbst ist die Nachweisführung, die ein Auditor erwartet.

Wie lange dauert eine Purdue-Segmentierung in einer bestehenden Anlage realistisch?

Für einen mittelständischen Fertigungsbetrieb mit einer Produktionslinie ist ein Zeitraum von drei bis sechs Monaten üblich – vier bis acht Wochen passives Monitoring, gefolgt von einer schrittweisen Umsetzung Zone für Zone. Mehrere Standorte oder eine gewachsene Energieinfrastruktur mit Netzleitstellen verlängern das deutlich; ein fester Zeitrahmen lässt sich seriös erst nach dem Asset-Inventar aus Schritt 1 nennen.

Fazit

Das Purdue-Modell beantwortet die Frage, die § 30 BSIG und Art. 21(2) offenlassen: wie eine angemessene Netzsegmentierung in einer Produktionsanlage konkret aussieht. Die Rechtsgrundlage bleibt die allgemeine Risikomanagement-Pflicht – nicht die CIR 2024/2690, die für Maschinenbau und Energie schlicht nicht gilt. Wer beides zusammenbringt – die Architektur aus Purdue und IEC 62443, die Dokumentation aus § 30 Abs. 1 und 2 BSIG – hat die Grundlage für eine Zonierung, die sowohl einem Angreifer als auch einem Auditor standhält.

Dieser Artikel bietet allgemeine Informationen und stellt keine Rechts- oder Regulierungsberatung dar. Anforderungen können je nach Rechtsraum und Unternehmensart variieren. Konsultieren Sie für Ihre spezifische Situation eine qualifizierte Rechts- oder Compliance-Fachkraft.

Quellen

• [1] TXOne Networks – Annual OT/ICS Cybersecurity Report 2026, zitiert via SPS-MAGAZIN
• [2] Fortinet Cyberglossary – What Is the Purdue Model for ICS Security?
• [3] Dragos – Understanding ISA/IEC 62443: A Guide for OT Security Teams
• [4] § 30 BSIG – Risikomanagementmaßnahmen (gesetze-im-internet.de)
• [5] NIS2-Richtlinie (EU) 2022/2555, Artikel 21
• [6] BSI – #nis2know: NIS-2 Risikomanagementmaßnahmen
• [7] Durchführungsverordnung (EU) 2024/2690, Artikel 1 (EUR-Lex)
• [8] nisd2.eu – CIR 2024/2690 Wiki-Übersicht
• [9] § 38 BSIG – Haftung der Geschäftsleitung (gesetze-im-internet.de)