en

Beyond Purdue: rethinking security for modern OT

Manufacturing
IT OT Convergence
IT Transformations
Today, it is impossible to discuss IT/OT convergence and OT security without referencing the Purdue model. While it resonates with architects, it is often less understood by management or network operations. Architects may design around the model, while other stakeholders struggle to interpret or apply it — leading to unclear responsibilities, inconsistent policies, and delays in implementing effective OT security. This article aims to bridge that gap and provide a shared perspective on securing OT systems.
04 September 2025 minute read

Key takeaways about Purdue

  • The Purdue model provides a layered framework to discuss Industrial Control Systems and IT/OT convergence, but it is not a security architecture.
  • The increasing number of connected systems, Industry 4.0, and shared IT/OT networks have added complexity and blurred boundaries.
  • Grouping systems into broad Purdue-based zones increases both exposure and impact; assigning each solution to its own zone reduces these risks.
  • Better outcomes are achieved by focusing on secure, standardised solutions for common OT use cases rather than on Purdue levels alone.


      A quick refresher: the Purdue model

      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.

      Technology and organizational shifts since Purdue


      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.

      Why traditional shared zones fall short


      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.

      Our recommendation: a use case–driven, scalable architecture

      Managing security at scale requires an approach that is both understood and endorsed by all stakeholders — requestors, managers, integrators, and network operators. Specialist terms like levels, zones, or conduits are interpreted differently across organizations, leading to recurring debates during the architecture lifecycle.

      A more effective method is to focus on the use cases the architecture must support and design generic, scalable solutions for each. This requires deploying every new solution in its own dedicated network security zone and managing access independently. In practice, most companies have three recurring use cases:

      1. Machine-to-machine connectivity: limited to what is required for functionality, controlled with mechanisms such as IP access lists, IDS/IPS, application proxies, or data diodes
      2. User access: operators typically work inside the zone from dedicated operator stations. Increasingly, organizations adopt zero-trust approaches that enable identity-based access from corporate workstations, which may be necessary when manual data exchange between IT and OT is required.
      3. Privileged and remote access: required for maintenance and supplier support, often implemented through Privileged Access Management (PAM) platforms that provide traceability, monitoring, and session control aligned with plant procedures.

      Conclusion


      The Purdue model was never designed as a security framework, but it shaped how industrial systems are structured and protected. Its layered approach supported IT/OT segregation and zoning, but shared security zones based on Purdue levels no longer meet today’s needs.

      Organizations should shift towards a more granular approach: assign each solution to its own zone and manage access through standardized use cases such as machine-to-machine connectivity, user access, and privileged remote access.






        Maarten Vervoorn CTO