Purdue Model

What is the Purdue Model?

The Purdue Model, formally the Purdue Enterprise Reference Architecture (PERA), is a reference model that organises the systems of an industrial enterprise into hierarchical levels, from the physical process at level 0 up to the enterprise networks at level 5. It was developed at Purdue University in the early 1990s as a framework for integrating production automation with business processes. Today it is above all the common language for classifying, segmenting and securing industrial control systems and OT networks, and a cornerstone of industrial architecture.

🕰️ Where does the Purdue Model come from?

The groundwork was laid by Theodore J. Williams, director of the Purdue Laboratory for Applied Industrial Control from 1965 to 1994. Under his leadership, the International Purdue Workshop on Industrial Computer Systems published the Reference Model for Computer Integrated Manufacturing (CIM) in 1989, together with the Instrument Society of America (ISA). That model was based on research with companies from the US and Canadian steel and paper industries.

In 1992 the fully worked-out Purdue Enterprise Reference Architecture followed, developed with the Industry-Purdue University Consortium for CIM. Its original purpose was not cybersecurity but organising information flows and responsibilities in a fully automated plant. Only after 2000 did the model become the reference framework for network segmentation in the OT world.

🧱 Which levels does the Purdue Model define?

The model has six levels, supplemented by level 3.5, which was added later:

Levels 0 to 3 together form the manufacturing or OT zone; levels 4 and 5 form the enterprise or IT zone. A safety instrumented system sits functionally at level 1, but in practice it is treated as a separate safety zone because it must keep working independently of the process control system to protect safety. ISA-95 only standardises levels 0 to 4; level 5 falls outside that standard and security architectures treat it together with level 4 as a single enterprise zone.

⏱️ Why does each level work on its own timescale?

A key insight from the model is that each level makes decisions at a different speed. That is why the levels cannot simply be merged:

A PLC controlling an oven must respond within milliseconds and cannot wait for an ERP system that plans in days. That difference in time, availability and criticality is also why each level has its own security requirements and why the model helps to organise industrial processes clearly.

🔄 How does the Purdue Model relate to ISA-95 and IEC 62443?

The Purdue Model itself is not a formal standard, but it lives on in two important standards:

• ISA-95 - part 1 appeared in 2000 as ANSI/ISA-95.00.01 and internationally as IEC 62264. Its functional hierarchy from level 0 to level 4 is derived directly from the Purdue reference model; ISA-95 focuses mainly on the interface between level 3 (MES) and level 4 (ERP).
• IEC 62443 - the ISA99 committee adopted the Purdue levels as the reference model in IEC 62443-1-1. The zones and conduits model builds on this: systems are grouped into zones with similar security requirements and connected through controlled conduits. Risk assessment and zone partitioning are described in IEC 62443-3-2.
• NIST SP 800-82 - the US guide to OT security (Rev. 3 from 2023) uses a Purdue-based defence-in-depth architecture. The general NIST CSF does not prescribe a Purdue structure itself; for OT-specific implementation, SP 800-82 is the relevant NIST document.

So Purdue describes which functions belong where; IEC 62443 describes how you secure the boundaries between them.

🔐 What is level 3.5 and why do you need an IDMZ?

Level 3.5 did not exist in the original model. It emerged from security practice and was worked out in, among others, the Converged Plantwide Ethernet (CPwE) architecture from Cisco and Rockwell Automation. The IDMZ (industrial DMZ) sits between the OT zone and the enterprise zone, so that there is no longer any direct connection between the office and production.

Common principles for an IDMZ:

• No traffic passes straight through - every session ends in the IDMZ; IT and OT only talk to systems inside it
• Mirrored data - a historian replica or data broker in the IDMZ supplies production data to IT, without IT users entering the OT network
• Managed access - remote access goes through a jump server with MFA, encrypted connections and session logging
• Filtered updates - patches and antivirus definitions are staged in the IDMZ and distributed to OT from there
• Two firewall layers - often from different vendors, or a data diode where only one-way traffic is required

Figure: permitted traffic from IT and OT terminates in the IDMZ at level 3.5

🔐 Example: the ERP system at level 4 requests production counts from a historian replica in the IDMZ. That replica is filled from level 3 through a conduit with a firewall and inspection. As a result, the ERP system never communicates directly with the MES or the PLCs.

🏭 What does the Purdue Model look like in a plant?

Imagine a food production plant

• Level 0 - sensors measure the temperature in the ovens, motors drive the conveyor belts.
• Level 1 - a PLC controls the burners based on the temperature reading.
• Level 2 - the operator monitors the oven status via an HMI and receives alarms when values deviate.
• Level 3 - the MES schedules the baking process, records batches and tracks production in real time.
• Level 3.5 - a historian replica and jump server in the IDMZ.
• Level 4 - the ERP system manages orders, stock and shipping.
• Level 5 - company-wide reporting and cloud analytics give management insight into trends.

🧭 How do you apply the Purdue Model step by step?

1. Take inventory - use an asset inventory to list all systems and their communication.
2. Assign levels - place each system at a Purdue level based on its function, not its physical location.
3. Map the data flows - which traffic runs between which levels, and which traffic skips levels?
4. Define zones and conduits - in line with IEC 62443-3-2, with a target security level per zone.
5. Build the IDMZ - prevent direct connections between level 4 and level 3 or below.
6. Enforce with firewalls - configure a firewall per conduit that only passes explicitly permitted traffic.
7. Monitor - use network monitoring to detect traffic that breaks the structure.

For Dutch organisations within the scope of NIS2, the Dutch Cyberbeveiligingswet has applied since 15 August 2026, without a transition period. For them and for other EU organisations, segmentation based on Purdue and IEC 62443 is a common way to demonstrate that the OT network is appropriately secured.

⚠️ What are the limitations of the Purdue Model?

The model dates from a time when data flowed neatly upwards from level to level. Modern architectures fit it less well:

• IIoT - smart sensors send data directly to a platform and skip levels 1 to 3.
• Cloud and edge computing - analytics and sometimes even supervisory functions run outside the plant, while the model defines no place for the cloud.
• Unified Namespace - a central MQTT broker to which every system publishes and subscribes replaces the strict chain of point-to-point integrations.
• Virtualization - a single server can host systems from several levels, blurring the boundaries.

Even so, the Purdue Model is not obsolete. As a functional model it remains useful for deciding which systems are most critical. Modern architectures combine it with Zero Trust principles and with concepts such as NAMUR Open Architecture, which adds a controlled second data channel alongside the classic automation pyramid.

❓ Frequently asked questions

What does PERA stand for?

PERA stands for Purdue Enterprise Reference Architecture, the formal name of the Purdue Model. It was developed in the early 1990s by Theodore J. Williams and the Industry-Purdue University Consortium for Computer Integrated Manufacturing.

Is the Purdue Model a standard?

The Purdue Model is a reference model, not a formal standard. Its level structure has, however, been adopted in the standards ISA-95 (IEC 62264) and IEC 62443-1-1, which makes it a de facto standard in practice.

What is the difference between the Purdue Model and ISA-95?

The Purdue Model is the original reference model, with levels from the physical process up to the enterprise. ISA-95 builds on Purdue levels 0 to 4 and mainly standardises the information exchange between MES at level 3 and ERP at level 4.

Where does a SIS belong in the Purdue Model?

A safety instrumented system (SIS) belongs functionally to level 1 of the Purdue Model, alongside the basic process control. In practice the SIS gets its own safety zone with stricter access rules, so that a failure of, or attack on, the process control system does not affect the safety function.

Is the Purdue Model still useful with IIoT and cloud?

The Purdue Model remains useful as a functional classification, but not as a strict rule that data may only move up one level at a time. With IIoT and cloud, organisations add controlled connections through the IDMZ or edge gateways and combine the model with the zones and conduits of IEC 62443.

What belongs in level 3.5 of the Purdue Model?

Level 3.5 of the Purdue Model is the industrial DMZ (IDMZ) between OT and IT. It typically contains a historian replica, a jump server for remote access, a patch and antivirus server, and the firewalls that separate the two sides.

📌 In summary

The Purdue Model divides industrial systems into six functional levels, from the physical process to the enterprise, with an IDMZ at level 3.5 as the controlled boundary between OT and IT. It originated at Purdue University in 1989–1992, lives on in ISA-95 and IEC 62443 and, supplemented with zones, conduits and Zero Trust, remains the starting point for secure OT convergence and industrial cybersecurity.

See also OTArchitect.nl