IT/OT Network Segmentation: Purdue Model and IEC 62443 Guide

Just before 5:00 AM on Friday, May 7, 2021, an employee at Colonial Pipeline found a ransom note on a system in the company’s IT network. By 6:10 AM, operators had confirmed that all 5,500 miles of pipeline were shut down. The reason, in the CEO’s own congressional testimony a month later, was to make sure the malware didn’t spread to the operational technology (OT) network that actually runs the pipeline, “if it had not already.”

Read that last part again. If it had not already.

That is the sound of a team that can’t prove, in the moment, where the line between IT and OT really sits, and when you can’t prove the boundary holds, the only safe move left is to pull the big red lever on everything. (To be clear, I think they made the right call, and so did they; I’m not here to armchair someone else’s worst morning.) The lesson for the rest of us is simpler. IT/OT network segmentation isn’t a diagram you hang on the wall for auditors. It’s the thing that lets you answer “could it have spread?” with evidence instead of a shrug.

This post is my practical guide to doing it: what the Purdue model is actually good for, what the ISA/IEC 62443 idea of zones and conduits adds, and a step-by-step way to draw your own boundaries. I’ve worked in critical infrastructure since 2022, where I lead the network engineering team that keeps roughly 2,000 devices across 220 IT and OT sites running 24/7, including an SD-WAN with a security architecture built to keep IT and OT apart. I won’t be drawing my own network on the internet (for reasons that should be obvious in a post about security), but everything below is how I think about the problem, and every standard I cite is linked so you can check my work.

IT and OT are not the same animal

Before any model or standard, you have to accept one uncomfortable fact: the two sides of the house have different priorities, and they’re both right. IT protects data, so confidentiality usually leads. OT protects a physical process, so availability and safety lead, and a “quick reboot to apply patches” can mean a pump, a valve or a breaker doing something nobody planned for. NIST’s guide spells this out: OT has to be secured “while addressing their unique performance, reliability, and safety requirements,” which is government for “you can’t just roll your IT playbook onto the plant floor.”

The protocols make the point for you. Modbus, still one of the most common industrial protocols, was introduced by Modicon in 1979, per the Modbus Organization. I was also born in 1979, and only one of us has learned to ask for ID since. Classic Modbus has no login; a device listening on TCP port 502 will generally take a read or write from anyone who can reach it. The Modbus Organization’s answer is a separate Modbus/TCP Security specification that wraps the protocol in TLS on port 802, but the installed base is what it is, and that FAQ still cheerfully describes logging onto a plant’s control system from home as a benefit. Hmmm.

So when the protocol can’t protect itself, the network has to. That’s the whole job of segmentation.

The Purdue model in five minutes

The Purdue model comes from work at Purdue University led by Theodore J. Williams. The Purdue Reference Model for CIM was published in book form by the Instrument Society of America in 1989, and it grew into the Purdue Enterprise Reference Architecture (PERA) in the early 1990s. It was never written as a security standard; it was a way to describe how a manufacturing enterprise is organized, from the physical process up to business planning. Security folks borrowed the levels because they map so neatly onto “how close is this thing to something that can hurt someone?”

Here’s the version most OT security guidance uses today. The EPA’s IT/OT segmentation fact sheet for water systems describes Levels 0 through 3 as OT, Levels 4 and 5 as the IT enterprise, and the main segmentation boundary as a demilitarized zone (DMZ) between Levels 3 and 4, which people usually call “Level 3.5.”

Level	What lives there	Examples
5	Enterprise network	Corporate apps, email, internet access
4	Business planning and logistics	ERP, site business systems
3.5	IT/OT DMZ	Historian replicas, patch and antivirus staging, remote access jump hosts
3	Site operations	Historians, operations management, OT domain services
2	Supervisory control	SCADA servers, HMIs, engineering workstations
1	Basic control	PLCs, RTUs, controllers
0	The physical process	Sensors, actuators, motors, valves

The Purdue levels as commonly adapted for OT security. Exact names vary by source.

If you’re a network engineer coming from the IT side, think of it like a car. Level 0 is the engine itself, Level 1 is the ECU, Level 2 is the dashboard, and Levels 4 and 5 are the dealership’s billing system. You really, really don’t want the billing system able to talk directly to the ECU.

Purdue is a map, not a firewall policy

Every few months someone declares the Purdue model dead, usually because cloud dashboards, IIoT sensors and remote vendor support don’t fit neatly into a stack of horizontal layers. They have a point. A cellular sensor that reports straight to a cloud service doesn’t care what level you assigned it. Even NIST SP 800-82 Rev. 3 (September 2023), the federal guide to OT security, shows the Purdue model side by side with an IIoT model in its segmentation example (Figure 16) rather than pretending one picture covers everything.

My take is less dramatic. The Purdue model is a fine map of where things live. Where it falls short is telling you who is allowed to talk to whom, over what, and why. Two devices can both sit at Level 2 and have completely different risk (a lab HMI versus the HMI for a safety-relevant process, for example), and a level number alone won’t tell you that.

That’s the gap 62443 fills.

IEC 62443 zones and conduits, in plain English

The ISA/IEC 62443 series is the consensus standard family for securing industrial automation and control systems. ISA started the ISA99 committee in 2002, and the ISA and IEC editions of each part are identical. Two parts matter most for network folks:

IEC 62443-3-2 (2020), “Security risk assessment for system design.” Per the IEC summary, it covers defining the system under consideration, partitioning it into zones and conduits, assessing risk for each one, setting a target security level (SL-T) for each, and documenting the requirements.
IEC 62443-3-3 (2013), “System security requirements and security levels.” This is the catalog of technical requirements you use to meet the target you just set.

A zone is a group of assets that share common security requirements. A conduit is the communication path between zones, plus the security controls on it. Every asset lands in a zone, and every flow between zones rides a conduit. Simple as that.

The part I like is that zones are drawn by risk and consequence, not by VLAN number or by which closet the switch sits in. The standard then gives you a common language for how strong a zone or conduit needs to be:

Security level	Protects against
SL 1	Casual or accidental violation
SL 2	Intentional violation using simple means, low resources, generic skills and low motivation
SL 3	Intentional violation using sophisticated means, moderate resources, IACS specific skills and moderate motivation
SL 4	Intentional violation using sophisticated means, extended resources, IACS specific skills and high motivation

IEC 62443 security levels, paraphrased from the series. Each level builds on the one below it.

Here’s how I explain the difference to IT folks: Purdue tells you which floor of the building a room is on; zones and conduits tell you which doors exist, who has a key, and whether anybody is watching the hallway.

You need both. Use Purdue to sort, use 62443 to decide.

A practical way to draw your own zones and conduits

This is the part where the standards stop being theory. None of it requires a forklift upgrade on day one, and most of it is paperwork you should have anyway (yes, paperwork; stay with me).

[Step 1] Inventory what you actually have

You can’t segment what you can’t see. CISA and its partners published Foundations for OT Cybersecurity: Asset Inventory Guidance for Owners and Operators on August 13, 2025, and it’s a solid starting checklist. For a network engineer, the minimum useful inventory is the device, its IP and MAC, what it talks to, over which protocols and ports, and who owns it. That last column matters more than people think; an asset with no owner is an asset nobody will patch, isolate or defend in a change meeting.

[Step 2] Draw zones by consequence, not by convenience

Start with the Purdue levels as a first sort, then split by what happens if the zone is compromised. Safety-related systems get their own zone. Temporarily connected devices (vendor laptops, contractor gear) get their own zone. Wireless gets its own zone. The 62443-3-2 process treats separating business from control system assets, and safety from non-safety assets, as required splits, and recommends separating temporarily connected, wireless and externally connected devices too. If a single zone contains both the break room kiosk and a PLC, that’s not a zone. That’s a flat network wearing a name tag.

[Step 3] Give every conduit a contract

This is the step people skip, and it’s the one I’d fight hardest for. Every conduit should have a written contract: who initiates, to where, on which port, and why the business needs it. If nobody can explain the “why,” the flow doesn’t get built. Here’s what that looks like on paper.

Conduit	From zone	To zone	Protocol and port	Initiator	Why it exists
C1	Level 2 SCADA	Level 3 historian	OPC UA, TCP 4840	Historian	Collect process data
C2	Level 3 historian	Level 3.5 DMZ replica	Vendor replication service	Level 3	Publish data outward only
C3	Level 4 business users	Level 3.5 DMZ replica	HTTPS, TCP 443	Level 4	Read reports, never touch Level 3
C4	Remote vendor	Level 3.5 jump host	VPN with phishing resistant MFA	Vendor	Supervised, time limited support

Hypothetical example for illustration only. It is not a real network or a recommended rule set; ports shown are the IANA registrations (OPC UA 4840, HTTPS 443).

Notice what isn’t in the table: anything from Level 4 directly to Level 3 or below. Notice also that data flows outward and gets read from the DMZ, rather than business systems reaching in to fetch it. Direction matters as much as the port.

[Step 4] Build the DMZ so nothing crosses in one hop

The Level 3.5 DMZ is where IT and OT meet without touching. NIST SP 800-82r3 lists “a demilitarized zone (DMZ) network architecture with firewalls to prevent network traffic from passing directly between the corporate and OT networks” among its major security objectives, along with separate authentication mechanisms and credentials for the two sides. In practice, that means no flow should ever be able to go straight from Level 4 to Level 3 or below; it terminates in the DMZ, and something in the DMZ brokers it. Separate identity matters here too. If the same domain account works on both sides, you built a very expensive VLAN.

[Step 5] Make remote access walk through the front door

In its Primary Mitigations to Reduce Cyber Threats to Operational Technology (May 6, 2025), CISA, the FBI, EPA and DOE put it bluntly: remove OT connections to the public internet, change default passwords, and if remote access is essential, use a private connection with VPN, strong passwords and phishing resistant MFA, scoped to least privilege, with dormant accounts disabled. The same list says to segment IT and OT with a DMZ. None of that is exotic. What breaks it is the “temporary” vendor modem or remote desktop tool somebody installed during commissioning and never removed (go on, check. I’ll wait).

[Step 6] Watch the conduits, not just the zones

A conduit you don’t monitor is a conduit on the honor system. Log what crosses it, alert on anything outside the contract, and review the firewall rules on a schedule, because rule bases rot slowly and then all at once. This is where a little Python goes a long way; I write my own monitoring tools for exactly this kind of “tell me before it becomes an outage” job.

[Step 7] Practice running without the network

The same CISA list includes one item network engineers rarely own but should care about: practice and maintain the ability to operate OT systems manually. Segmentation buys you containment; manual operation buys you time. Colonial’s testimony mentions returning some lines to manual operation within hours, which is exactly the capability that list is talking about.

Where SD-WAN fits (and where it doesn’t)

If you run a lot of remote sites, the WAN is where segmentation either survives the trip or quietly dies. A good SD-WAN design can carry IT and OT as separate segments end to end, with their own routing and policy, so the separation you built in the substation or plant doesn’t collapse into one big routing table at the hub. That’s the kind of security architecture I work with across 220 sites, and it’s why I’d rather carry segmentation in the overlay than bolt it on site by site.

But let me be clear about the limit. SD-WAN is transport; it carries your conduits, it doesn’t define them. The contract from Step 3 still has to exist, and the enforcement still lives in policy and firewalls. An overlay that faithfully delivers an any/any rule to 220 sites is just a very efficient way to be wrong.

One more gotcha from the field. Every tunnel and overlay adds headers, and OT traffic has a way of finding the edge cases. I once diagnosed a years-long SCADA telemetry problem over MQTT that came down to packet and segment size, and fixing the MTU and MSS settings is what finally cleared it. When you add a conduit, add “check the MTU end to end” to the checklist (yes, this will bite you, and it will wait until the worst possible moment).

The patterns I’d look for first

If you inherited an OT network tomorrow and had one week, these are the things I’d hunt for before I touched a single design document:

The dual homed workstation. An engineering laptop or HMI with one NIC on the corporate network and one on the control network is a bridge with a keyboard.
The commissioning rule that never left. Any/any rules added “just for startup” have a half life measured in decades.
Shared credentials across the boundary. One account that works in Level 4 and Level 2 makes your DMZ decorative.
Remote access nobody owns. If you can’t name the person who approves it, it’s not a conduit. It’s a hole.
Internet exposed OT. CISA puts removing it at the top of its list for a reason; scan your own public IP space before someone else does.

Slow is smooth, smooth is fast

A word of caution before you go tighten every rule in the building. Segmentation changes are production changes in a 24/7 environment, and the blast radius of a mistake isn’t a slow website; it can be a process that stops. Early in my career I took down a hospital IDF switch at midnight, an outage I caused all by myself, and my mentor Brian was kind enough to point out the arrogance that got me there. I think about that closet every time I see a change window for a boundary firewall.

So run the contract in monitor mode first where you can, compare what you see with what you wrote down, fix the surprises, then enforce. Change one conduit at a time and keep a rollback you have actually tested.

Hope isn’t a strategy. Neither is a flat network.

Your homework this week

Pick one conduit. Just one. Write its contract (who, to where, which port, which direction, and why), then go look at the firewall and see whether reality agrees with the paper. I’d bet a cup of black coffee it doesn’t match on the first try, and that gap is your roadmap.

If you’re working through IT/OT segmentation and want to compare notes, find me on LinkedIn or drop a comment below. And if you liked the firewall detective work, my SIP one-way audio troubleshooting guide is the same kind of “follow the packet until it vanishes” story from the voice side.

References

Keep reading

Projects. The SD-WAN and PRI to SIP work behind a lot of what I write here.
Automation Builds. The Python tools that watch the network so I don’t have to.
SIP One-Way Audio: The Doorbell Rang, So Where Did the Conversation Go? Firewalls, NAT and the half of the conversation that went missing.

IT/OT Network Segmentation: The Purdue Model Is the Map, IEC 62443 Zones and Conduits Are the Rules