The Purdue Security Model: Everything You Need to Know

The Purdue Model originated from work around the Purdue Enterprise Reference Architecture, or PERA, which sought to describe the relationship between industrial control and enterprise functions. Today, the term is commonly used in OT cybersecurity to describe a layered industrial architecture, moving from the physical process at the bottom towards enterprise systems at the top.

• Level 5, Enterprise
• Level 4, Business Planning and Logistics
• Industrial DMZ, commonly called Level 3.5
• Level 3, Site Operations and Control
• Level 2, Area Supervisory Control
• Level 1, Basic Control
• Level 0, Physical Process and Field I/O

NIST uses this type of Purdue representation in its Guide to Operational Technology Security (SP 800-82 Rev. 3) while also showing other models, including ISA/IEC 62443 zones and conduits. That is an important clue as to how Purdue should be used: it is one useful architectural model, not the only way to secure OT.

Level 0: Physical Process

Level 0 is where the industrial process exists in the physical world. Depending on the organisation, this might involve:

• water flowing through a pipe
• a pump operating
• a turbine rotating
• a valve opening
• a breaker changing state
• a conveyor moving
• a robotic arm operating
• pressure inside a vessel
• temperature in a process
• material moving through a production line

Sensors measure what is happening. Actuators influence what happens next.

Level 0 matters because the consequences of OT security can extend beyond data. An incident affecting a business application might cause financial loss or data exposure. An incident involving an industrial process can potentially affect operations, equipment, safety, the environment or essential services. This is one of the reasons OT cybersecurity must consider more than confidentiality alone. Availability, integrity and safe operation can be equally or more important.

Level 1: Basic Control

Level 1 contains the devices responsible for directly controlling or monitoring the physical process:

• programmable logic controllers (PLCs)
• remote terminal units (RTUs)
• intelligent electronic devices (IEDs)
• industrial controllers
• protection relays

OT equipment at this level may remain operational for many years, which creates a very different lifecycle from conventional IT. Some systems cannot be frequently patched. Some depend on legacy protocols. Some have limited authentication capabilities. Some cannot tolerate active security scanning. Replacing them may require shutting down part of an industrial process. Security therefore often depends heavily on the architecture surrounding the device, rather than the device alone.

Level 2: Area Supervisory Control

Level 2 contains the systems used to supervise and interact with a process or production area:

• human-machine interfaces (HMIs)
• operator stations
• engineering workstations
• local SCADA functions
• supervisory control systems
• area historians

An HMI gives an operator visibility of the process. An engineering workstation may allow an engineer to configure a PLC or other controller. That creates an important security distinction. An ordinary office workstation might contain valuable information. An engineering workstation may have the authority and software required to change the behaviour of industrial equipment, and needs to be treated accordingly.

Level 3: Site Operations and Control

Level 3 contains the systems that support wider site or production operations:

• manufacturing execution systems
• plant historians
• operations management
• production databases
• maintenance systems
• asset management
• site-level engineering services

Level 3 is particularly important because it sits close to the boundary between operational systems and business IT. Data often needs to move between these environments. Production figures may be needed by business systems. Maintenance providers may need controlled access. Updates may need to move towards OT. Operational information may need to feed enterprise analytics. The answer is not necessarily to stop every connection. It is to understand and control them.

Level 4: Business Planning and Logistics

Level 4 supports the business processes associated with the industrial operation. NIST describes this level as business planning and logistics. Examples may include enterprise resource planning, planning systems, production scheduling, logistics, reporting, business applications and business databases.

This is an important correction to some simplified Purdue diagrams. Core SCADA and process control systems should not simply be placed at Level 4. The exact architecture will differ between organisations, but the distinction between business and operational functions matters.

Level 5: Enterprise

Level 5 represents the wider enterprise environment, which may include:

• corporate IT
• identity systems
• email
• collaboration platforms
• corporate applications
• data centres
• internet access
• corporate endpoints

Modern organisations often extend beyond this traditional representation. They may also depend on SaaS, public cloud, vendor clouds, managed services, remote operations, external analytics, APIs and IoT platforms. That creates one of the limitations of a simple Purdue pyramid: modern networks do not always communicate neatly from one adjacent layer to another.

You will often hear cybersecurity professionals refer to Purdue Level 3.5. This normally means the industrial demilitarised zone, or industrial DMZ. It is useful shorthand, but Level 3.5 should not be confused with a formal original Purdue level in the same sense as Levels 0 to 5.

The industrial DMZ is a security architecture commonly introduced between operational and enterprise environments. Its purpose is to avoid unrestricted direct communication between enterprise IT and core OT. Services placed in an industrial DMZ might include remote-access gateways, jump hosts, replicated historians, file-transfer services, update repositories, security monitoring services, vendor-access platforms, proxy services and data brokers.

The NCSC's 2026 OT connectivity principles explicitly recommend strong controls at the OT boundary and describe a DMZ as a buffer between externally connected systems and core OT. The August 2026 water-sector worked example goes further, showing independent enforcement points either side of the DMZ so that failure of one boundary control does not automatically expose core OT.

The important idea is mediation. Instead of enterprise IT talking straight to OT:

That creates multiple opportunities to authenticate, inspect, restrict, monitor and log communications.

No. This is a common terminology problem.

A properly designed industrial DMZ provides strong separation, but it remains a connected architecture. Approved network paths still exist. Those paths can be heavily restricted, but a DMZ is not the same thing as physical disconnection. Similarly, a firewall is not an air gap, a VLAN is not an air gap, network segmentation is not necessarily an air gap, and immutable storage is not necessarily offline. These controls can all be useful. They simply solve different problems.

A simplified Purdue architecture looks like this.

This is useful for understanding the environment. It should not be interpreted as saying that every level needs unrestricted connectivity to the level immediately above and below it.

Purdue helps organisations think about separation and trust. A PLC does not need the same network access as somebody's corporate laptop. A safety-related system should not automatically trust an application merely because both belong to the same company. A supplier should not automatically receive access to an entire OT network because it needs to maintain one piece of equipment.

• architecture design
• asset classification
• segmentation
• security assessment
• incident response
• explaining OT architecture
• identifying IT and OT boundaries
• planning remote access

It creates a shared language between engineers, security teams, operations and management.

A Purdue diagram does not enforce anything. This is probably the most important thing to understand about the model. You could draw Level 4 above a DMZ above Level 3 above Level 2 and still have a badly secured network, because the real network may contain:

• excessive firewall rules
• vendor VPNs
• remote desktop
• shared jump servers
• dual-homed workstations
• unmanaged switches
• legacy remote-access equipment
• shared administrator credentials
• temporary maintenance paths
• cloud connections
• incorrectly configured VLANs

An attacker does not care where a system sits on a diagram. They care whether they can reach it.

This is where good OT architecture work becomes more detailed than simply assigning Purdue levels. For each important communication route, an organisation should understand the source, the destination, the purpose, the protocol, the direction, the frequency, the owner, the authority to use or change it, the control that limits it and the evidence of its use.

The NCSC now specifically recommends creating and maintaining a definitive view of OT connectivity rather than relying only on high-level architecture diagrams.

Network segmentation limits which systems can communicate with one another. Instead of operating one large trusted network, systems are divided into zones with controlled communication between them. The benefits include reducing attack surface, restricting lateral movement, limiting the potential impact of compromise, separating systems with different security requirements and applying stronger controls to higher-risk assets.

The NCSC describes segmentation as one of the most effective strategies for limiting the impact of compromise in OT environments, and recommends restricting communication paths to what is strictly necessary. That last point matters. Good segmentation is not simply creating more networks. It is removing unnecessary communication.

Logical and physical segmentation

Logical controls can include firewalls, VLANs, access-control lists, routing policies, microsegmentation and host-based controls. Physical segmentation can include architectures where connectivity is separated through physical network design or hardware controls.

The right approach depends on the system. A physical control is not automatically appropriate everywhere. Likewise, logical segmentation should not automatically be dismissed simply because it is implemented in software. Good OT security generally uses defence in depth, selecting controls according to the risk, operational requirement and potential consequence.

The Purdue Model is often discussed alongside ISA/IEC 62443. They are not the same thing. IEC 62443 uses the concepts of zones and conduits.

A zone groups assets that share common security requirements. For example, two process areas may both sit broadly around Purdue Level 2 while belonging to separate security zones. A conduit describes controlled communication between zones.

Purdue helps explain where systems functionally sit. Zones and conduits help structure how groups of systems communicate securely. NIST presents Purdue and ISA/IEC 62443 as separate but compatible approaches to OT segmentation.

What does a secure conduit look like?

There is no universal answer. The security required depends on what the conduit does. Controls might include firewalling, authentication, protocol restriction, monitoring, logging, content inspection, protocol breaks, application gateways, unidirectional technologies and physical segmentation.

The important principle is proportionality. A read-only telemetry feed does not necessarily require the same architecture as remote engineering access capable of changing controller logic.

A protocol break terminates one connection rather than simply forwarding it directly into another environment. The receiving service then establishes a new connection using an appropriate protocol. The NCSC highlights protocol breaks as a useful technique because they can make attacks that rely on passing malicious protocol behaviour directly through a boundary more difficult.

The enterprise system does not communicate directly with the operational historian.

Modern OT systems often require remote access for legitimate reasons: equipment maintenance, software support, engineering diagnostics, supplier support, monitoring and managed services. The security problem is not that remote access exists. It is how it is designed.

The NCSC recommends centralising and standardising remote connectivity rather than creating numerous bespoke routes into OT. Several suppliers should not necessarily require several unrelated VPN endpoints terminating inside the OT environment. A centralised, controlled access architecture can make authentication, monitoring and policy enforcement easier to manage.

Legacy technology is one of the realities of operational environments. An industrial controller may remain in service long after an equivalent IT product would have been replaced. Legacy systems can present unsupported software, insecure protocols, weak authentication, an inability to run endpoint security, limited logging and difficulty applying patches.

The answer is not to connect an old device directly to the internet because modernisation will take time. The NCSC recommends compensating controls including segmentation, trusted boundary controls, hardened jump hosts and protocol gateways for obsolete devices that must remain operational.

Yes. But it should not be interpreted too literally.

Modern OT architecture includes technology that did not fit neatly into the traditional model when it was developed: industrial IoT, edge computing, cloud analytics, private 5G, remote operations, digital twins, vendor SaaS, machine learning and distributed infrastructure.

A sensor may communicate with an edge platform. That platform may send selected data directly to a cloud service. The communication does not necessarily climb through every Purdue level in sequence. That does not make Purdue obsolete. It means we should use Purdue to understand function and separation, while also maintaining an accurate view of the real connectivity.

Ransomware is often used to explain the importance of IT and OT segmentation, but care is required here. Not every ransomware incident reaches OT, and industrial disruption can occur without malware ever reaching a PLC. An organisation may shut down operational systems as a precaution. Enterprise identity may become unavailable. Planning or logistics systems may fail. Remote engineering may become inaccessible. Shared virtual infrastructure may be compromised.

The lesson is therefore wider than "ransomware moves from Level 5 to Level 0". The important issue is dependency and blast radius. Good architecture helps prevent one compromised environment from automatically becoming a compromise of everything else.

Suppliers and engineering partners are a normal part of OT operations, but every third-party connection introduces another trust decision. For each supplier, ask:

• Who requires access?
• Which system do they need?
• Why do they need it?
• How frequently?
• What route do they use?
• What authentication is required?
• Is activity logged?
• How is access removed?
• Could the connection be unavailable when not required?

These are architectural questions as much as identity questions.

One area frequently overlooked in simple Purdue diagrams is the infrastructure used to administer the security controls themselves: firewall management, switch management, hypervisor administration, security consoles, remote-access management and identity administration.

If an attacker can compromise the system used to configure a security boundary, the boundary may be much less effective. A mature architecture therefore considers both the production path and the management path.

Purdue can become particularly useful during incident response. If an enterprise system has been compromised, responders need to know which routes exist towards OT, whether an industrial DMZ separates the environments, which connections are currently active, whether vendors have remote access, which systems share identity, which connections can be safely isolated and what operational consequences isolation would cause.

This requires more than an old network diagram. Organisations need a current and tested isolation plan. The NCSC's 2026 OT principles explicitly include establishing an isolation plan as part of secure OT connectivity.

Can you simply disconnect OT during an incident?

Sometimes a connection can be removed. Sometimes it cannot. A network connection may support safety, process control, emergency shutdown, telemetry, redundancy, regulatory monitoring or remote operation. Disconnecting the wrong path could create additional risk. Isolation therefore needs to be engineered and tested before an incident.

• What must remain connected?
• What could be restricted?
• What could be temporarily isolated?
• What is the safe failure state?
• Who has the authority to make that decision?

Cyber resilience is not only about preventing an attacker from moving towards OT. It is also about being able to recover. An industrial organisation should know which assets are required to rebuild critical systems:

• PLC programmes
• controller configurations
• HMI configurations
• SCADA configuration
• system images
• firmware
• engineering documentation
• network diagrams
• asset inventories
• recovery procedures
• important certificates or keys

Then ask where those copies are stored, whether the production environment can reach them, and whether the same compromise could affect production and recovery. This is part of reducing shared failure domains.

Purdue and Zero Trust are not really competitors. They address different questions. Purdue asks where a system sits functionally. Zones and conduits ask which security domains exist and how they should communicate. Zero Trust asks whether this identity, device or workload should be permitted to access this resource under these conditions. An organisation may use all of these ideas together.

Purdue is frequently discussed alongside standards, frameworks and guidance that it is not equivalent to. The distinctions matter, because each document answers a different question and carries a different status.

Purdue Enterprise Reference Architecture

A reference model. It describes functional layers. It is not a cybersecurity standard, it certifies nothing, and it prescribes no controls.

ISA/IEC 62443 series

A series of international standards for industrial automation and control systems security. It introduces zones, conduits and security levels, and separates responsibilities between asset owners, service providers and product suppliers.

NIST SP 800-82 Rev. 3

A NIST Special Publication, that is, guidance rather than a certification standard. It presents a Purdue-style architecture with a DMZ as one example, alongside ISA/IEC 62443 zones and conduits.

NCSC Cyber Assessment Framework

An outcome-focused UK framework used to assess cyber resilience, particularly for essential services. It does not prescribe a network topology. Purdue can help an organisation describe and evidence the segmentation, boundary protection and recovery outcomes that CAF principles ask about.

A practical implication follows. An organisation cannot be "Purdue compliant". It can, however, use Purdue to describe its architecture, use zones and conduits to define security domains and communication, use SP 800-82 or NCSC guidance to select controls, and use CAF or 62443 to assess whether the resulting outcomes are adequate.

1. Treating the diagram as security. A diagram describes. Controls enforce.
2. Assuming adjacent levels should communicate. They should communicate only where the process requires it.
3. Calling every logical separation an air gap. VLANs, firewall rules and DMZs are not the same thing as physical disconnection.
4. Ignoring remote access. Vendor connectivity needs to appear on the architecture.
5. Ignoring cloud connectivity. A modern OT map should include services outside the traditional pyramid.
6. Treating Level 3.5 as a magical security boundary. A DMZ still needs secure architecture, configuration, monitoring and management.
7. Forgetting management infrastructure. Ask who controls the controls.
8. Failing to maintain the architecture. An outdated Purdue diagram can be worse than no diagram because it creates false confidence.
9. Ignoring recovery architecture. Know where the clean configurations and recovery assets are before an incident.
10. Disconnecting systems without considering safety. OT security decisions must respect the physical process.

For each important part of your OT estate, document:

Asset

What is it?

Function

What does it do?

Purdue level

Where does it functionally sit?

Security zone

Which trust zone does it belong to?

Connections

What can communicate with it?

Direction

Which way does the communication travel?

Protocol

What protocols are used?

Requirement

Why does the connection exist?

Frequency

Does it need to exist continuously?

Third parties

Who outside the organisation can access it?

Authentication

How is access authorised?

Monitoring

What activity is recorded?

Boundary

What control separates it from other zones?

Management

How is that control administered?

Isolation

Could the system or connection be isolated safely?

Recovery

What would be needed to restore it?

That produces something more useful than simply colouring boxes on a diagram.

The Purdue Model does not require Firevault, and Firevault does not replace Purdue, IEC 62443, firewalls, industrial DMZs or established OT security controls. Firevault's work is relevant to two particular questions raised by modern OT architecture.

1. Does this network path need to exist continuously?

Firevault Control is designed for selected network paths where physical path governance is appropriate. The concept is different from creating another Purdue level. A Control Blueprint maps the existing architecture, identifies selected conduits and determines whether a standing physical connection is operationally necessary. Where appropriate, a physical control can complement existing segmentation by changing the state of the selected path itself. This is particularly relevant to connectivity that may be periodic or exceptional, such as some forms of maintenance, recovery or administrative access. It is not appropriate to assume that every OT connection should be physically disconnected. Safety, availability and process requirements come first.

2. Does this critical recovery data need to remain continuously connected?

Firevault Offline Secure Storage® addresses selected data and recovery assets rather than live process connectivity. An organisation might choose to retain known-good copies of configurations, engineering information or recovery material on dedicated storage that is physically disconnected when it is not being accessed. Again, this complements rather than replaces operational backup and recovery systems. The relevant architectural question is whether the recovery copy should share the same reachable failure domain as the environment it may one day be required to restore.

Boundary by boundary: which question applies where

Control is a suite of nine purpose-built tools and techniques that give an organisation physical control over the paths into and across its estate, applied through Blueprints that treat a specific risk. The table below maps each Purdue boundary to the architectural question that belongs there, then to the modules and Blueprints that may be relevant. Nothing here is a recommendation to disconnect a path. Safety, availability and process requirements decide what is appropriate.

Read the Control Blueprints for the full definition of each module and the risk each Blueprint treats.

• NIST SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security

  Purdue-style architecture with a DMZ, alongside ISA/IEC 62443 zones and conduits as an alternative segmentation model.

• NCSC, Secure Connectivity Principles for Operational Technology (January 2026)

  UK guidance on OT exposure, centralised connectivity, boundary protection, segmentation, monitoring and isolation planning.

• NCSC, Creating and Maintaining a Definitive View of Your OT Architecture

  Documenting real OT connectivity, including segmentation and protocol breaks.

• ISA/IEC 62443 series

  International standards for industrial automation and control systems security, including zones and conduits.

• NCSC OT worked examples, water sector (August 2026)

  A practical example of an industrial DMZ with independent enforcement points, so failure of one boundary control does not expose core OT.

Related Firevault guides