Introduced in the 1990s, the Purdue Enterprise Reference Architecture (PERA) was not about cybersecurity. Its purpose was to provide a structured, layered framework for organizing Industrial Control Systems (ICS) and their relationship with corporate Information Technology (IT) networks.
The Purdue model categorizes industrial functions by role and aligns them into Levels 0–4 according to their operational scope:
- Levels 0–2: Physical processes and control systems (PLCs, DCS, SCADA)
- Level 3: Manufacturing operations — scheduling, MES, quality systems
- Level 4: Enterprise IT — ERP, email, HR, analytics
This layered approach defined natural boundaries for data flow and responsibilities in industrial control system.
To integrate security zoning, organizations introduced intermediate levels — 2.5, 3.5, and 5 — marking boundaries between control and supervisory systems, between OT and enterprise IT, and between the organization and external networks.
Over the past decades, both technology and organizational structures have evolved in ways that challenge how the Purdue model is applied.
- Shared network infrastructure has eroded the traditional boundary between IT and OT, as organizations centralize access control, security monitoring, and remote access.
- Plants now host more connected assets, driven by equipment replacement and new automation or datadriven tools. Each solution often introduces a new supplier and requires remote access.
- Facility systems such as access control, CCTV, alarms, and climate control are increasingly connected but often overlooked in IT/OT security discussions.
- Industry 4.0 applications add cloud services, AI, and analytics, which introduces systems outside the control loop that are hard to classify in the Purdue model and blur zoning and accountability.
Many organizations equate Purdue Levels with security zones. Historically, grouping systems with similar requirements into a single zone was common practice. Yet while these systems often share availability needs, their access requirements will differ. This leads to the following downsides:
- Expanded exposure: an increasing number of systems with more suppliers requiring access raises both the likelihood and the impact of incidents when systems are grouped into a shared zone.
- Loss of ownership: shared access policies blur accountability: defining access policies shift from asset owners to network operations, even though network operations often lacks insight into the solution and its specific access requirements.
- Limited automation: shared access policies hinder automation because it becomes difficult to maintain clear links between assets and their configuration items (CIs). Changing a shared CI can unintentionally affect other assets.
Organizations often try to achieve more granular segmentation by asking IT to replace or reconfigure the network, but such efforts usually fail. The main barriers are the cost, risk, and downtime of re‑IPing systems, as central IT must navigate each plant’s supporting ecosystem of technologies and suppliers that keep operations running.
A more practical approach is to place each new OT solution in its own zone. This allows independent access control with lower cost and risk. The transition can be gradual, aligned with the OT lifecycle, with critical systems prioritized where needed.