Wenn IT und Produktion über Netzwerksicherheit sprechen, reden sie oft aneinander vorbei. Die IT denkt in Datenflüssen, Patches und Vertraulichkeit. Die Produktion denkt in Taktzeiten, Verfügbarkeit und einer Steuerung, die seit 2009 zuverlässig läuft und genau deshalb niemand anfassen will. Das Purdue-Modell ist eines der wenigen Werkzeuge, das beide Seiten an denselben Tisch bringt – weil es eine gemeinsame Sprache für die Frage liefert: Was gehört eigentlich wohin, und was darf mit wem sprechen?
Dieser Artikel erklärt das Modell von Grund auf, ordnet es gegenüber Automatisierungspyramide und ISA-95 ein, zeigt das Mapping auf die IEC 62443 – und beantwortet die Frage, die inzwischen fast jeder stellt: Ist das Purdue-Modell im Zeitalter von Cloud, IIoT und Zero Trust überhaupt noch aktuell?
Was ist das Purdue-Modell? Definition in einem Satz
Das Purdue-Modell ist eine Referenzarchitektur, die industrielle Netzwerke in sechs hierarchische Ebenen von der physischen Maschine (Level 0) bis zur Unternehmens-IT (Level 5) gliedert. Es beschreibt, welche Systeme auf welcher Ebene liegen und wie der Datenverkehr zwischen diesen Ebenen kontrolliert wird – und ist damit die Grundlage für Netzwerksegmentierung in der OT.
Entwickelt wurde das Modell Ende der 1980er- und Anfang der 1990er-Jahre am Purdue University Consortium for Computer Integrated Manufacturing, maßgeblich von Theodore J. Williams. Der offizielle Name lautet Purdue Enterprise Reference Architecture, abgekürzt PERA. In der Praxis begegnen Ihnen dieselben Inhalte unter vielen Bezeichnungen: Purdue-Modell, Purdue Model, Purdue Reference Model, Purdue-Referenzmodell oder Purdue-Ebenenmodell. Gemeint ist immer dasselbe.
Ein Detail, das für das Verständnis des ganzen Artikels entscheidend ist: Das Purdue-Modell wurde nicht als Sicherheitsmodell entworfen. Ursprünglich ging es um Fertigungsplanung und darum, computerintegrierte Produktion überhaupt strukturiert beschreiben zu können. Erst Jahrzehnte später entdeckte die OT-Security die Ebenenlogik als idealen Rahmen für Netzwerksegmentierung. Diese Zweckentfremdung erklärt sowohl die Stärken des Modells als auch die Kritik, die ihm heute entgegenschlägt.
Wenn Sie zuvor noch einen Schritt zurückgehen möchten: In unserem Beitrag zu den Grundlagen der Operational Technology klären wir die Begriffe SPS, SCADA, DCS und HMI von Grund auf.
Die Ebenen des Purdue-Modells im Überblick
Das Modell zählt von unten nach oben, von Level 0 direkt am physischen Prozess bis Level 5 in der Unternehmens-IT. Je niedriger die Zahl, desto näher am Prozess.
Level 0 – Prozess
Die physische Ebene: Sensoren, Aktoren, Ventile, Motoren, Antriebe, Roboter. Hier wird gemessen und bewegt. Diese Geräte kennen in der Regel keine Authentifizierung, keine Verschlüsselung und keine Protokollierung. Sie führen aus, was ihnen gesagt wird – von wem auch immer.
Level 1 – Basissteuerung
Speicherprogrammierbare Steuerungen (SPS/PLC), Remote Terminal Units (RTU) und PID-Regler. Sie lesen die Sensordaten aus Level 0 und steuern die Aktoren. Eine SPS trifft Entscheidungen in Millisekunden – Latenz ist hier ein Sicherheitsthema im Sinne von Betriebssicherheit, nicht von Cybersecurity.
Level 2 – Überwachung und Steuerung
SCADA-Systeme, HMIs, Leitwarten und Engineering-Workstations. Hier sitzt der Mensch: Anlagenfahrer beobachten Prozesse, greifen ein, quittieren Alarme. Level 2 ist typischerweise die erste Ebene mit Windows-Betriebssystemen – und damit die erste, auf der klassische IT-Angriffsmuster funktionieren.
Level 3 – Betriebsführung
Manufacturing Execution Systems (MES), Produktionsplanung, Historian-Datenbanken, Batch-Management, Rezepturverwaltung. Level 3 sammelt Daten aus der Produktion und übersetzt sie in Kennzahlen. Diese Ebene ist die letzte, die noch eindeutig zur OT gehört.
Level 3.5 – Die Industrial DMZ als Sicherheitsschleuse
Level 3.5 steht in der ursprünglichen PERA nicht – es wurde nachträglich ergänzt, als klar wurde, dass zwischen Produktions- und Büronetz eine echte Pufferzone nötig ist. Die Industrial DMZ (IDMZ) ist eine entmilitarisierte Zone nach demselben Prinzip, das die IT seit Jahrzehnten für Webserver nutzt: Kein System aus Level 4 spricht direkt mit einem System aus Level 3. Stattdessen treffen sich beide auf neutralem Boden – über Jump-Hosts, Replikations-Server, Patch-Verteiler oder Datendioden.
Wenn es einen einzelnen Baustein gibt, an dem sich die Reife einer OT-Sicherheitsarchitektur ablesen lässt, dann ist es dieser. In der Praxis ist Level 3.5 gleichzeitig der Bereich, in dem wir bei Bestandsanlagen die meisten Direktverbindungen finden, die dort nie hätten entstehen dürfen. Wie sich eine solche Zone technisch umsetzen lässt, beschreiben wir auf unserer Seite zur Netzwerksegmentierung.
Level 4 und 5 – Unternehmens-IT und Internet
Level 4 ist die klassische Business-IT des Standorts: ERP, Warenwirtschaft, E-Mail, Dateiserver, Domain Controller. Level 5 umfasst konzernweite Systeme, Cloud-Dienste und die Anbindung ans Internet. In vielen mittelständischen Betrieben verschwimmen Level 4 und 5 – das ist unproblematisch, solange die Grenze nach unten sauber gezogen ist.
Warum das Purdue-Modell für OT-Security so wichtig ist
Der Kerngedanke lässt sich in einem Satz zusammenfassen: Vertrauen endet an der Zonengrenze.
Daraus folgt unmittelbar eine zweite Regel: Kommunikation ist nur zwischen benachbarten Ebenen vorgesehen. Ein System aus Level 4 spricht nie direkt mit Level 2 oder Level 1 – wer eine Zone überspringt, umgeht genau die Kontrollpunkte, wegen derer das Modell überhaupt existiert. Genau dafür gibt es Level 3.5.
Ein Produktionsnetz ohne Segmentierung ist ein einziger flacher Angriffsraum. Wer es über eine Phishing-Mail in der Buchhaltung auf einen Bürorechner schafft, findet von dort aus im schlechtesten Fall einen ungehinderten Weg bis zur Steuerung der Abfüllanlage. Diese seitliche Ausbreitung – laterale Bewegung – ist das, was aus einem ärgerlichen IT-Vorfall einen Produktionsstillstand macht. Das Purdue-Modell unterbindet sie strukturell, indem es Übergänge zwischen Ebenen zu bewusst gestalteten, überwachten Engstellen macht.
Dazu kommt ein zweiter Punkt, der IT-Verantwortliche oft überrascht: In der OT gelten andere Prioritäten. Die klassische IT-Sicherheit ordnet nach Vertraulichkeit, Integrität, Verfügbarkeit. In der Produktion steht die Verfügbarkeit an erster Stelle – eine Anlage, die aus Sicherheitsgründen stoppt, kann teurer sein als der Vorfall selbst. Hinzu kommen Lebenszyklen von 15 bis 30 Jahren, Steuerungen ohne Update-Pfad und Herstellerfreigaben, die jedes Patchen zur Vertragsfrage machen.
Genau deshalb ist Segmentierung in der OT so wirkungsvoll: Sie schützt Systeme, die sich selbst nicht schützen können, ohne sie anzufassen. Man härtet nicht die Steuerung – man härtet den Weg dorthin. Welche Bausteine dabei zusammenspielen, zeigen wir im Überblick zur Netzwerksicherheit.
Purdue-Modell und Automatisierungspyramide – wo liegt der Unterschied?
Diese drei Begriffe werden ständig verwechselt. Die Abgrenzung ist einfacher, als sie aussieht.
Die Automatisierungspyramide als Sicht der Fertigung
Die Automatisierungspyramide ist das deutschsprachige Pendant aus der Automatisierungstechnik. Sie beschreibt dieselbe Hierarchie – Feldebene, Steuerungsebene, Prozessleitebene, Betriebsleitebene, Unternehmensleitebene – aber aus der Perspektive der Fertigungsorganisation, nicht der Netzwerksicherheit. Ihr Zweck ist die Einordnung von Systemen und Verantwortlichkeiten, nicht die Definition von Sicherheitszonen.
Wie ISA-95 auf dem Purdue-Modell aufbaut
ISA-95 (international als IEC 62264 genormt) ist der Standard für die Integration von Unternehmens- und Produktionssystemen – im Kern also für die Frage, wie ERP und MES sauber miteinander sprechen. Und ISA-95 nutzt als Grundlage genau das Purdue-Ebenenmodell. Wer ISA-95 verstanden hat, kennt das Purdue-Modell bereits, ohne es zu wissen.
| Purdue-Modell / PERA | Automatisierungspyramide | ISA-95 / IEC 62264 | |
| Herkunft | Purdue University, ca. 1990 | Automatisierungstechnik, DACH-Raum | ISA, seit 1995 |
| Ursprünglicher Zweck | Fertigungsplanung, CIM | Einordnung von Systemebenen | Integration ERP ↔ MES |
| Heutiger Hauptnutzen | Netzwerksegmentierung, OT-Security | Kommunikationsmodell in der Fertigung | Datenmodelle und Schnittstellen |
| Ebenen | 0–5 (plus 3.5) | 4–5 Ebenen, ohne DMZ | 0–4, an Purdue angelehnt |
Kurz gesagt: Alle drei beschreiben dieselbe Realität. Das Purdue-Modell ist die Variante, die für Sicherheitsarchitektur taugt – weil nur sie die Übergänge zwischen den Ebenen explizit zum Thema macht.
Purdue-Modell und IEC 62443 zusammenbringen
Die IEC 62443 arbeitet mit Zonen (Gruppen von Systemen mit gleichem Schutzbedarf) und Conduits (definierte, kontrollierte Kommunikationswege zwischen Zonen). Jeder Zone wird ein Security Level von SL 1 bis SL 4 zugewiesen, abgestuft danach, wie hoch das Risiko in der jeweiligen Zone ist. Maßgeblich sind Eintrittswahrscheinlichkeit und mögliche Auswirkung eines Vorfalls, nicht ein bestimmter Angreifertyp: SL 1 deckt zufällige Fehlbedienung und technisches Versagen ab, SL 4 gezielte Angriffe mit hohem Ressourceneinsatz und Spezialwissen über die Anlage. Das Security Level ist damit das Ergebnis der Risikobewertung für die Zone.
Der Zusammenhang ist unmittelbar: Die Purdue-Ebenen sind der naheliegende erste Vorschlag für Ihren Zonenschnitt. Sie sind aber nur der Ausgangspunkt – eine Zone kann auch quer zu Ebenen verlaufen, etwa wenn eine einzelne kritische Anlage stärker abgeschottet gehört als der Rest von Level 1.
Mapping-Tabelle: Purdue-Level auf IEC-62443-Zone
| Purdue-Level | Typische Systeme | IEC-62443-Zone | Typisches Security Level |
| Level 0/1 | Sensoren, Aktoren, SPS, RTU | Control Zone / Safety Zone | SL 2–3 (Safety separat, oft SL 3) |
| Level 2 | SCADA, HMI, Leitwarte | Supervisory Zone | SL 2–3 |
| Level 3 | MES, Historian, Planung | Operations Zone | SL 2 |
| Level 3.5 | Jump-Host, Datendiode, Patch-Server | Industrial DMZ | SL 2–3, alle Conduits kontrolliert |
| Level 4/5 | ERP, Office-IT, Cloud | Enterprise Zone | SL 1–2 |
Die Werte sind Orientierung, kein Rezept – das tatsächliche Security Level ergibt sich aus Ihrer Risikobewertung. Wie wir Normanforderungen in konkrete Infrastruktur übersetzen, zeigen wir im Bereich IT/OT-Compliance.
Was NIS2 für deutsche Produktionsbetriebe daraus macht
Seit dem 6. Dezember 2025 ist das deutsche NIS2-Umsetzungsgesetz (NIS2UmsuCG) in Kraft. Rund 29.500 Unternehmen in 18 Sektoren fallen darunter – die Schwelle liegt in der Regel bei 50 Mitarbeitenden oder 10 Millionen Euro Jahresumsatz. Betroffen sind unter anderem Energie, Wasser und Abwasser, Lebensmittelproduktion, Maschinen- und Fahrzeugbau. Übergangsfristen sieht das Gesetz nicht vor; die BSI-Registrierungsfrist ist im Juli 2026 ausgelaufen.
Für die OT bedeutet das konkret: Risikomanagement, Vorfallmeldungen innerhalb enger Fristen, Nachweispflichten – und eine persönliche Verantwortung der Geschäftsleitung. Netzwerksegmentierung nach Purdue-Logik ist dabei keine formale Pflicht, aber sie ist der praktikabelste Weg, die geforderten technischen Maßnahmen in einer gewachsenen Produktionsumgebung überhaupt umzusetzen. Wie das in einem regulierten Umfeld aussieht, zeigt unser Projekt beim Abwasserzweckverband Breisgauer Bucht.
Ist das Purdue-Modell veraltet? Kritik und Grenzen
Diese Frage kommt fast immer – und sie ist berechtigt.
Das Modell entstand in einer Welt, in der die Produktion physisch vom Rest der Welt getrennt war. Daten verließen diese abgeschottete Welt praktisch nicht: Sie blieben innerhalb der Anlage, und was dennoch ausgetauscht werden musste, wurde offline per Datenträger im- und exportiert. Diese Welt gibt es nicht mehr. Ein IIoT-Sensor auf Level 0, der seine Messwerte per Mobilfunk direkt in eine Herstellercloud schickt, umgeht sämtliche Ebenen. Predictive-Maintenance-Plattformen greifen von Level 5 direkt auf Steuerungsdaten zu. 5G-Campusnetze, Edge Computing und Fernwartungszugänge der Maschinenbauer durchlöchern die saubere Hierarchie an Stellen, an denen das Modell schlicht keine Antwort vorsieht.
Purdue-Modell vs. Zero Trust – Gegensatz oder Ergänzung?
Zero Trust folgt einem anderen Grundsatz: Kein Vertrauen aufgrund von Netzwerkposition, jede Anfrage wird einzeln authentifiziert und autorisiert. Das steht dem Purdue-Modell scheinbar diametral entgegen, das Vertrauen genau aus der Position ableitet.
Unsere Position dazu ist klar: Das Purdue-Modell ist als alleinige Sicherheitsgrenze überholt, als Ordnungsrahmen aber unverzichtbar.
Zero Trust in der OT lässt sich nicht flächendeckend umsetzen – eine SPS von 2011 kann keine Identität nachweisen, kein Zertifikat prüfen und keine Policy auswerten. Sie braucht eine Umgebung, die das für sie übernimmt. Und um diese Umgebung zu bauen, müssen Sie erst einmal wissen, was wo liegt und was mit wem sprechen darf. Genau das leistet das Purdue-Modell. In der Praxis entsteht daraus eine Kombination: Purdue liefert die Zonenstruktur, Zero-Trust-Prinzipien werden dort ergänzt, wo Systeme sie tragen können – bei Fernwartungszugängen, administrativen Zugriffen und modernen Komponenten.
Das Extended Purdue Model als Weiterentwicklung
Als Antwort auf diese Lücken kursieren erweiterte Varianten, oft als Extended Purdue Model bezeichnet. Sie ergänzen das klassische Schema um Cloud-Dienste, IIoT-Geräte mit direkter Anbindung und Fernzugriffspfade – und behandeln diese als eigene Zonen mit eigenen Conduits, statt so zu tun, als gäbe es sie nicht. Das ist weniger eine neue Theorie als eine ehrliche Bestandsaufnahme: Die Ausnahmen werden dokumentiert und abgesichert, statt die Architektur an ihnen scheitern zu lassen.
Purdue-Modell in der Praxis umsetzen – in fünf Schritten
Schritt 1: Asset-Inventar erstellen
Man kann nicht schützen, was man nicht kennt. In gewachsenen Produktionsumgebungen ist die erste Erkenntnis fast immer, dass deutlich mehr Geräte im Netz hängen als dokumentiert – Altsysteme, Testaufbauten, Herstellergeräte, vergessene Switches. Passive Erfassung ist hier Pflicht: Aktives Scannen kann empfindliche Steuerungen aus dem Tritt bringen. Werkzeuge und Vorgehen dazu beschreiben wir unter Netzwerksichtbarkeit und NAC.
Schritt 2: Zonen schneiden und Kommunikationsbeziehungen erfassen
Ordnen Sie jedes Asset einer Purdue-Ebene zu und erfassen Sie, welche Systeme tatsächlich miteinander sprechen – nicht, welche laut Konzept sprechen sollten. Der Abgleich dieser beiden Listen ist regelmäßig der aufschlussreichste Moment im ganzen Projekt. Erfassen lässt sich das durch reine Beobachtung des Netzverkehrs, ohne Eingriff in die Anlage – etwa mit Forescout eyeInspect, das Assets und ihre Kommunikationsbeziehungen im laufenden Betrieb erkennt und als Kommunikationsmatrix darstellt. Diese Matrix ist die eigentliche Arbeitsgrundlage für den Zonenschnitt.
[Hinweis für die Redaktion: An dieser Stelle folgt ein Screenshot aus Forescout eyeInspect (Kommunikationsmatrix bzw. Asset-Übersicht). Bild wird nachgeliefert – vor Veröffentlichung entfernen.]
Schritt 3: Industrial DMZ aufbauen
Jetzt werden die Direktverbindungen zwischen Level 3 und Level 4 aufgelöst und durch kontrollierte Übergänge in Level 3.5 ersetzt. Realistisch erwartbar: Widerstand. Der Historian, der bisher direkt ins ERP schreibt, funktioniert danach anders. Deshalb schrittweise vorgehen – erst überwachen, dann filtern, dann erzwingen.
Schritt 4: Fernwartungszugänge kanalisieren
Jeder Maschinenlieferant will Zugriff, und jeder bringt seine eigene Lösung mit. Das Ergebnis sind oft Dutzende unkontrollierter Wege ins Herz der Produktion. Ziel ist ein einziger, überwachter Pfad über Level 3.5 – mit Zeitfenstern, Freigabe durch die Produktion und vollständiger Protokollierung. Wie das ohne Reibungsverluste gelingt, zeigen wir bei der Fernwartung von Maschinen und Anlagen und im Beitrag zur Fernwartung im Produktionsnetzwerk.
Schritt 5: Monitoring und Anomalieerkennung etablieren
Segmentierung verhindert Ausbreitung, aber sie meldet nichts. Weil OT-Kommunikation im Normalbetrieb extrem gleichförmig ist, funktioniert Anomalieerkennung hier besser als in jeder Büro-IT: Ein Gerät, das plötzlich einen neuen Gesprächspartner hat, fällt sofort auf. Mehr dazu unter Anomalieerkennung und Bedrohungserkennung.
Die häufigsten Fehler bei der Umsetzung
Der mit Abstand häufigste Fehler ist, das Purdue-Modell als Blaupause statt als Referenz zu behandeln – also die Ebenen abzumalen, ohne die eigenen Prozesse zu prüfen. Dicht dahinter folgen:
-
- die Segmentierung ohne die Produktion planen
-
- Ausnahmen für einzelne Anwendungen zulassen und nie wieder anfassen
-
- Level 3.5 als reine Firewall-Regel statt als echte Zone bauen
-
- das Ganze als einmaliges Projekt betrachten statt als Zustand, der gepflegt werden muss
Häufige Fragen zum Purdue-Modell
Was ist das Purdue-Modell und warum ist es für OT-Security relevant?
Das Purdue-Modell gliedert industrielle Netzwerke in sechs Ebenen von der Maschine bis zur Unternehmens-IT. Für die OT-Security ist es relevant, weil es die Grundlage für Netzwerksegmentierung liefert: Es macht sichtbar, welche Systeme zusammengehören und an welchen Stellen der Datenverkehr kontrolliert werden muss, um die Ausbreitung von Angriffen zu verhindern.
Ist das Purdue-Modell veraltet?
Teilweise. Cloud-Anbindungen, IIoT-Geräte und Fernwartung durchbrechen die strikte Ebenenlogik, für die das Modell entworfen wurde. Als alleinige Sicherheitsgrenze reicht es heute nicht mehr aus. Als Ordnungsrahmen, um ein OT-Netz zu strukturieren und Zonen zu definieren, ist es weiterhin die praktikabelste Grundlage.
Wurde das Purdue-Modell durch Zero Trust ersetzt?
Nein, beide ergänzen sich. Zero Trust setzt voraus, dass jedes System seine Identität nachweisen kann – das leisten ältere Steuerungen nicht. Das Purdue-Modell liefert die Zonenstruktur, innerhalb derer Zero-Trust-Prinzipien dort greifen, wo die Technik sie trägt.
Welche Ebenen hat das Purdue-Modell?
Level 0 (Prozess: Sensoren und Aktoren), Level 1 (Basissteuerung: SPS, RTU), Level 2 (Überwachung: SCADA, HMI), Level 3 (Betriebsführung: MES, Historian), Level 3.5 (Industrial DMZ) sowie Level 4 und 5 (Unternehmens-IT, ERP, Cloud und Internet).
Was ist der Unterschied zwischen IEC 62443 und Purdue-Modell?
Das Purdue-Modell ist eine Referenzarchitektur und beschreibt die Struktur eines industriellen Netzes. Die IEC 62443 ist eine Norm und beschreibt Anforderungen an die Sicherheit dieser Struktur – über Zonen, Conduits und Security Level. Das Purdue-Modell liefert den Zonenschnitt, die IEC 62443 das Schutzniveau.
Was ist die Industrial DMZ auf Level 3.5?
Eine Pufferzone zwischen Produktionsnetz und Unternehmens-IT. Sie verhindert direkte Verbindungen zwischen Level 3 und Level 4: Beide Seiten kommunizieren ausschließlich über Systeme in der DMZ, etwa Jump-Hosts, Replikationsserver oder Datendioden.
Was ist der Hauptunterschied zwischen IT-Security und OT-Security?
Die Priorisierung. IT-Security schützt zuerst Vertraulichkeit, OT-Security zuerst Verfügbarkeit und Betriebssicherheit. Dazu kommen Lebenszyklen von 15 bis 30 Jahren, fehlende Update-Möglichkeiten und Herstellerfreigaben, die Standardmaßnahmen der IT in der Produktion unbrauchbar machen.
Ist die IEC 62443 verpflichtend?
Die Norm selbst ist nicht gesetzlich vorgeschrieben. Sie ist aber der etablierte Stand der Technik für industrielle Automatisierungssysteme und wird zunehmend vertraglich gefordert – etwa von Auftraggebern oder Versicherern. Im Kontext von NIS2 und KRITIS dient sie als anerkannter Nachweisrahmen für angemessene technische Maßnahmen.
Wo stehen Sie mit Ihrer OT-Segmentierung?
Das Purdue-Modell ist schnell erklärt und selten schnell umgesetzt – weil jede gewachsene Produktion ihre eigenen Ausnahmen mitbringt. Genau an dieser Stelle arbeiten wir seit Jahren als Übersetzer zwischen IT und Produktion; wir nennen das Autolinguale IT®.
Wenn Sie wissen möchten, wie weit Ihr Netz von einer sauberen Zonenstruktur entfernt ist, buchen Sie einen kostenlosen Ersttermin. Wir schauen uns gemeinsam an, wo Ihre Direktverbindungen liegen und welche Schritte in Ihrem Fall den größten Effekt haben. Vorbereitend finden Sie in unseren Tools und Checklisten einen ersten Einstieg.
