What Is the Purdue Model and Where Does Network Visibility Fit?

The Purdue model is the most widely used way to describe how operational technology (OT) networks should be segmented. You’ve probably seen it on a whiteboard: a stack of numbered levels, with sensors and valves at the bottom and corporate IT at the top.

What the diagram doesn’t show is what’s actually moving between those levels. Segmentation tells you where traffic should go. Visibility tells you where it really goes. And most industrial networks can’t answer that second question yet. In the Dragos 2026 OT Cybersecurity Year in Review, only 46% of security assessments found adequate OT network monitoring in place.

So where does visibility fit? Everywhere traffic crosses a boundary between levels, and especially at Levels 1 to 3, where controllers, operator stations, and site systems talk to each other. Passive network test access points (TAPs) give you a complete copy of that traffic without touching the process. Network packet brokers then gather those copies and deliver the right traffic to your OT monitoring and security tools.

What Is the Purdue Model?

The Purdue model, formally the Purdue Enterprise Reference Architecture (PERA), is a hierarchical reference model for industrial control systems (ICS). It groups every system in a plant or utility into levels, based on what each system does and how close it sits to the physical process. In a well-designed network, each level only talks to the levels directly above and below it, through controlled connections.

The goal is simple. If an attacker compromises an email server at the top of the stack, they shouldn’t have a direct path to the controller that opens a valve at the bottom.

Where the Model Came From

Theodore J. Williams and members of the Industry-Purdue University Consortium for Computer Integrated Manufacturing developed the model in the early 1990s. It started as a way to describe how plant-floor data fed business planning. Security teams adopted it later because its layers map neatly onto network segments.

How It Relates to Industry Standards

The model also sits underneath several standards you may already use:

• ISA-95: The standard for integrating enterprise and control systems, which adopted the Purdue hierarchy of levels
• ISA/IEC 62443: The industrial cybersecurity series, which groups assets into zones joined by controlled conduits that often map onto Purdue levels
• NIST SP 800-82r3: The National Institute of Standards and Technology’s Guide to Operational Technology (OT) Security, which references Purdue levels when describing layered OT architectures

The Levels of the Purdue Model Explained

Most versions of the model describe six levels, numbered 0 to 5, plus an industrial demilitarized zone (IDMZ) at Level 3.5. Levels 0 to 3 form the OT side, and Levels 4 and 5 form the enterprise side.

Level 0: The Physical Process

This is where physical work happens. Level 0 includes the field devices that measure and change the real world:

• Sensors: Temperature, pressure, flow, and level transmitters
• Actuators: Valves, motors, pumps, and drives
• Instrumentation: Analyzers and meters that report process conditions

Many of these devices use analog, serial, or fieldbus connections rather than Ethernet.

Level 1: Basic Control

Level 1 holds the devices that read sensor data and command actuators. Think programmable logic controllers (PLCs), remote terminal units (RTUs), and distributed control system (DCS) controllers. Safety instrumented systems (SIS), which shut a process down when conditions become dangerous, are often treated as their own protected zone alongside Level 1.

Level 2: Area Supervisory Control

Level 2 is where people supervise the process. It includes human-machine interfaces (HMIs), supervisory control and data acquisition (SCADA) servers, alarm systems, and engineering workstations.

Engineering workstations need special attention because they can change controller logic. In the 2017 TRITON attack on a petrochemical plant, attackers used a safety system engineering workstation to push malicious code to the plant’s safety controllers.

Level 3: Site Operations

Level 3 manages production across the whole site. Typical systems include data historians, manufacturing execution systems (MES), OT domain controllers, and patch servers.

Level 3.5: The Industrial DMZ

Security teams added the IDMZ to the original model as IT and OT networks became more connected. It sits between Levels 3 and 4 and brokers every exchange between them. Firewalls, remote access jump hosts, and replicated servers (such as a mirror of the plant historian) mean IT users never connect straight into OT. Some organizations also add unidirectional gateways, or data diodes, so data can only flow out of OT.

Levels 4 and 5: Enterprise Systems

Level 4 covers business planning and logistics: enterprise resource planning (ERP), email, and file servers. Level 5 is the wider enterprise network, including corporate data centers, cloud services, and internet connectivity. Security here follows standard IT practice.

Why the Purdue Model Matters for OT Security

A dropped connection in an office is an inconvenience. In a refinery, water plant, or rail control center, it can stop production or create a safety risk. The Purdue model gives you a structure that protects availability and safety first.

It Limits How Far an Attack Can Spread

The model’s main security benefit is containment. When you follow it well, you get:

• A smaller blast radius: Ransomware that lands on a Level 4 file server has no direct route to Level 1 controllers
• Fewer paths to protect: Traffic between levels passes through a small number of controlled points
• Clearer access rules: Each level has a defined set of systems and users that should reach it
• Safer remote access: Vendors and engineers connect through the IDMZ rather than straight into control networks

It Gives IT and OT Teams a Shared Language

IT and plant engineering teams often describe the same network in different terms. Saying “that historian sits at Level 3 and replicates to the IDMZ” tells both sides exactly where a system lives and what it should talk to. Because standards reference the model too, a Purdue-aligned design is also easier to document and defend in an audit.

Where the Purdue Model Falls Short Today

The Purdue model was designed for networks where data moved up and down a neat hierarchy. Modern industrial networks rarely look that tidy. Most security teams still use the model as their reference point, but they accept that the real network doesn’t match the diagram.

Common Ways Real Networks Break the Model

• Industrial Internet of Things (IIoT) devices: Smart sensors and gateways can send data straight to cloud platforms, skipping every level in between
• Remote access shortcuts: Vendor VPNs and cellular modems often land directly on Level 2 or 3 systems instead of passing through the IDMZ
• Flat networks: Plants that grew over decades sometimes put controllers, HMIs, and business systems on the same subnet
• Dual-homed machines: A workstation with one network card in OT and another in IT quietly bridges the boundary

The Gap Between Design and Reality

A segmentation diagram describes intent. It can’t tell you whether a PLC has started talking to an unknown IP address, or whether an HMI is reaching into the business network. 81% of Dragos assessments identified poor IT/OT segmentation, according to the same year in review.

You can only close that gap by watching the traffic itself.

Where Network Visibility Fits in the Purdue Model

Network visibility means having a complete, reliable copy of your traffic to send to monitoring and security tools. In a Purdue architecture, it acts as a layer alongside every level, checking that each one only talks to the systems it should.

If you’re starting from scratch, we recommend this order:

1. The IDMZ: Your main checkpoint between IT and OT
2. Links between Levels 1 and 2: Where control commands travel
3. Remote access entry points: Vendor connections often bypass the IDMZ
4. Level 3 servers: Attackers use them as stepping stones

Visibility at Levels 1 and 2

This is where monitoring pays off most. Traffic between supervisory systems and controllers uses industrial protocols such as Modbus TCP, EtherNet/IP, PROFINET, and DNP3. With a copy of it, OT security tools can spot:

• Unexpected write commands: A setpoint change or logic download that didn’t come from an approved workstation
• New devices: A laptop or unknown controller appearing on a control network
• Mode changes: Controllers switched into program mode outside a maintenance window
• Reconnaissance: Scans and queries that map controllers ahead of an attack

Visibility at Level 3 and the IDMZ

Level 3 systems connect to both OT and IT, which makes them a common stepping stone. Monitoring links to historians and OT domain controllers helps you catch lateral movement early. At the IDMZ, tapping both sides of the firewalls shows you what’s trying to cross, what gets through, and whether your rules match your policy.

Why Early Detection Pays Off

Many industrial incidents start with a compromised business system at Levels 4 and 5 and work their way down. Dragos reports that organizations with full OT visibility contained OT ransomware in 5 days on average. The industry average was 42 days.

Why Passive Monitoring Suits OT Networks

IT security teams often rely on tools that scan networks, probe devices, and install agents. In OT, those habits can cause outages. Many PLCs and RTUs run on limited processors and old firmware, and some will fault when scanned. Most can’t run agents at all.

Passive monitoring avoids that risk. It analyzes a copy of the traffic instead of interacting with devices.

What Passive Monitoring Gives You

With a reliable copy of OT traffic, your monitoring tools can build:

• Asset inventories: A live list of every device that communicates, often including vendor and firmware details
• Communication baselines: A map of which devices normally talk to each other, so anything new stands out
• Threat detection: Alerts for known attack techniques and abnormal commands
• Forensic records: Packet captures that show exactly what happened during an incident

That last point matters. Once a command reaches a controller, the network keeps no record of it. If you weren’t capturing traffic at the time, the evidence is gone.

Network TAPs vs SPAN Ports in Purdue Environments

Passive monitoring tools need a source of traffic. You have two main options: switch port analyzer (SPAN) ports, which mirror traffic from a managed switch, or TAPs, which sit on the cable and copy everything that passes through.

Why SPAN Ports Struggle in OT

SPAN works for occasional troubleshooting, but it has real limits for permanent OT monitoring:

• Legacy and unmanaged switches: Many plant switches are too old or too basic to support SPAN at all
• Change control: Configuring SPAN means changing a production switch, which often needs a maintenance window
• Dropped packets: Switches treat mirroring as a low priority and drop mirrored packets when they’re busy
• Missing errors: SPAN typically discards malformed frames, which can be early signs of failing equipment or tampering

Why TAPs Fit the Purdue Model

TAPs give you a full-duplex copy of every packet on a link, including errors, without touching switch configuration. For OT networks, a few properties stand out:

• No network presence: TAPs have no IP or MAC address, so attackers can’t see or target them
• One-way design: Passive fiber TAPs split light to the monitoring port and prevent data from flowing back into the network
• No power dependency: Passive fiber TAPs keep passing traffic even during a power outage
• Failsafe copper options: Ethernet TAPs with failsafe modules keep copper links up if power fails, which suits the many OT links still running on copper

Installation needs one short, planned break in the cable. After that, the TAP stays in place.

How Packet Brokers Bring Purdue-Level Visibility Together

A single site might have dozens of monitoring points, and connecting each one directly to each tool doesn’t scale. Your OT intrusion detection system (IDS), packet capture appliance, and IT security tools also need different slices of that traffic.

A packet broker sits between your TAPs and your tools and manages that traffic in four steps:

1. Collect: Receive traffic copies from TAPs across multiple levels, cells, or sites
2. Aggregate: Combine those feeds into fewer, fuller streams
3. Filter and process: Select the traffic each tool needs and trim what it doesn’t
4. Deliver: Send each stream to the right tool, load balancing across several tools where needed

Aggregation Across Levels and Sites

For smaller sites, the SmartNA combines hot-swappable TAP modules and packet broker functions in a 1RU or 2RU chassis. If you run remote substations or pump stations, the SmartNA-XL supports generic routing encapsulation (GRE). That lets you bring traffic from several sites back to one central location for monitoring.

Filtering for OT Tools

Not every tool needs every packet. Packet brokers let you:

• Filter by protocol, VLAN, or address: Send only Modbus or DNP3 traffic to the OT IDS, and only IDMZ traffic to the IT security team
• Slice and mask packets: Trim payloads or mask sensitive fields, using features such as PacketPro on the SmartNA-XL
• Remove duplicates: Strip the extra copies created when the same traffic is tapped at more than one point

Traffic flows one way, from TAPs through the broker to your tools, so a failed tool never affects the process. And with our Drag-n-Vu interface, you map TAPs to tools using drag-and-drop filters, which cuts the risk of configuration errors.

How to Build Visibility Into a Purdue Architecture

Adding visibility to an operating plant works best as a phased project:

1. Map your real network: Check your Purdue diagram against switch configurations and site walk-downs
2. Prioritize boundaries and control traffic: Start with the IDMZ and the links between Levels 1 and 2
3. Match access to each link: Use passive fiber TAPs on fiber and failsafe TAPs on copper, and keep SPAN for temporary troubleshooting
4. Plan installation with operations: Schedule TAP installs during planned outages or maintenance windows
5. Aggregate through a packet broker: Combine and filter feeds for each tool
6. Connect OT-aware tools: Feed an OT IDS that understands industrial protocols, plus packet capture for forensics
7. Baseline, then tune: Let tools learn normal behavior first, and revisit it when the process changes

Protecting Inline Tools at Level Boundaries

Some sites run inline firewalls or intrusion prevention systems between levels. Bypass TAPs send heartbeat signals through these tools and route traffic around any that stop responding. Decide in advance which links must stay up and which should be isolated if a tool fails. A historian feed and a remote access path may need different answers.

Mistakes to Avoid

• Monitoring only the IT/OT boundary: Attacks that start inside OT, from an infected laptop or vendor connection, never cross the IDMZ
• Relying on SPAN for permanent monitoring: Dropped packets create blind spots exactly when networks are busiest
• Ignoring the environment: Check temperature and humidity ratings, and house hardware in conditioned cabinets or equipment rooms where needed

The Purdue Model and Zero Trust

Some argue zero trust should replace the Purdue model. In OT, the two work better together. The Purdue model defines your zones and boundaries. Zero trust tightens control within and between them by verifying every user, device, and connection.

Why Zero Trust Depends on Visibility

Zero trust policies are only as good as your knowledge of the network. Before you decide what each device should be allowed to do, you need to know:

• Which devices exist: Including the old, undocumented ones
• What they talk to: Their normal communication partners and protocols
• When behavior changes: So you can spot a device acting outside its policy

Passive visibility supplies that information. For an extra layer of protection, our INVIKTUS zero trust cybersecurity system applies policy-based controls at full line rate. Like our TAPs, it has no IP or MAC address for attackers to find.

Frequently Asked Questions

Is the Purdue Model Still Relevant?

Yes, as a reference architecture. Few networks match it exactly, but its core idea of separating the process from the business network still underpins OT security standards. Most teams now pair it with continuous monitoring.

What Is Level 3.5 in the Purdue Model?

Level 3.5 is the industrial DMZ, a buffer zone between site operations (Level 3) and enterprise systems (Level 4). It holds firewalls, jump hosts, and replicated servers so IT and OT systems never connect directly.

Can You Use Network TAPs at Level 0?

Only where Level 0 devices communicate over Ethernet. Many sensors and actuators use analog, serial, or fieldbus connections. Packet-based visibility usually starts at the Ethernet links connecting Level 1 controllers to the rest of the network.

How Network Critical Can Help

The Purdue model tells you how your industrial network should be organized. Visibility shows you how it actually behaves, and gives your security tools and incident responders the data they need.

We’ve designed and manufactured network visibility hardware since 1997, for organizations including BP and Airbus. For Purdue environments, that means:

• Invisible access at every level: Passive and failsafe TAPs with no IP or MAC address and no impact on control traffic
• Compact options for plant sites: Our hybrid TAP and packet broker solutions combine tapping, aggregation, and filtering in 1RU and 2RU chassis
• Room to scale: The SmartNA-PortPlus scales to 194 ports at up to 100Gbps for larger sites and enterprise data centers

Whether you’re starting at the IDMZ or reaching down to your control networks, our team can help you plan where to tap and which tools need which traffic.