Industrial Network Security: Protecting OT and ICS Environments

Industrial network security protects the hardware and software directly monitoring and controlling physical processes and equipment, distinct from general IT systems. It centers on the Purdue Model’s level-based segmentation, with availability prioritized over confidentiality given the physical consequences of a compromised process.

If you keep hearing about the Purdue Model and want to actually understand what each level means, not just the name, this delivers exactly that.

Why OT and ICS Finally Get Their Own Full, Dedicated Treatment Here

This is the single most heavily deferred-to topic in this pillar. Perimeter security content already named industrial and OT environments as places where air-gapping and strict boundary control remain standard practice. Segmentation content already named physical segmentation as most relevant to industrial and air-gapped contexts covered here. IoT content already named a rise in ransomware targeting OT and lateral movement from compromised IoT into adjacent OT environments. Air-gapping content stated plainly this post applies that technique to its dominant, real-world context.

Operational Technology and Industrial Control Systems refer to the hardware and software directly monitoring and controlling physical processes and equipment, distinct from the general-purpose IT systems covered throughout the rest of this discussion.

The current motivation is stark. Manufacturing has been the single most-targeted industry sector by cyberattack volume for five consecutive years running, accounting for 27.7% of incidents in 2025 according to IBM’s X-Force research.

Availability, Not Confidentiality — Inverting the CIA Triad for Industrial Environments

Confidentiality, Integrity and Availability are network security’s three core goals, established generally elsewhere.

Here’s a genuinely important inversion worth stating directly. In OT and ICS environments specifically, Availability becomes the primary priority, Integrity a close second, and Confidentiality typically the lowest of the three. That’s the reverse emphasis most IT security guidance assumes by default.

This makes complete sense once stated plainly. A stopped production line, or worse, a genuinely uncontrolled physical process, an incorrectly opened valve, an overheating reactor, can mean direct financial loss, environmental harm or genuine physical danger. Meanwhile, few OT environments hold much data anyone would specifically want to keep confidential in the first place.

This matters practically for every decision that follows. Security controls introducing latency or requiring downtime to implement carry a genuinely different cost calculation in OT than in ordinary IT, where a brief service interruption rarely means a physical safety event.

The Purdue Model — the Industry-Standard Architecture, Level by Level

The Purdue Enterprise Reference Architecture, universally known as the Purdue Model, is a hierarchical framework segmenting an industrial network into distinct functional levels, from the physical process itself through to enterprise IT.

Level 0, the Physical Process, contains sensors, actuators, valves and motors performing the actual industrial work.

Level 1, Basic Control, contains Programmable Logic Controllers and Remote Terminal Units reading data from Level 0 and executing commands, often running older, resource-constrained hardware.

Level 2, Area Supervisory Control, contains Human-Machine Interfaces and SCADA software, where operators monitor and control a specific plant area.

Level 3, Site Operations, contains site-wide manufacturing operations management and historian data systems.

The Industrial DMZ, Level 3.5, is worth naming directly as a later addition specifically addressing modern IT/OT convergence: a dedicated buffer zone controlling and limiting communication between the OT environment and the enterprise IT network above it.

Levels 4 and 5, Enterprise IT, contain business systems, ERP and general corporate infrastructure.

This is the OT-specific, industry-standard expression of general zone architecture already established elsewhere, developed here to a level of precision that foundational content never needed to reach.

The Purdue Model Levels at a Glance

Level	What It Contains	Typical Systems	Primary Risk
Level 0	Physical process	Sensors, actuators, valves, motors	Direct physical manipulation
Level 1	Basic control	PLCs, RTUs	Outdated, resource-constrained hardware
Level 2	Area supervisory control	HMIs, SCADA	Operator interface compromise
Level 3	Site operations	Historian, MES	Data integrity, operational visibility
Industrial DMZ	Buffer zone	Firewalls, proxies	Misconfigured boundary services
Level 4-5	Enterprise IT	ERP, business systems	Common IT compromise vectors

A Worked Example — How Proper Segmentation Actually Contains a Real Attack

Here’s a concrete illustration worth walking through rather than leaving the model abstract. Ransomware enters at Level 4 through a compromised enterprise workstation, a common, realistic starting point.

A properly configured Industrial DMZ firewall blocks lateral movement from Level 4 into Level 3. The ransomware cannot reach site operations or historian systems at all. Even if a Level 3 system is somehow compromised through a misconfigured DMZ service, it holds no routable path down to Level 2 SCADA or Level 1 PLCs. The PLCs themselves continue executing their control logic entirely unaffected, meaning the physical process itself stays running throughout.

This concrete walkthrough matters more than an abstract level list. It demonstrates precisely how this architecture delivers on the availability-first priority established above, containing an IT-side compromise before it ever reaches the physical process itself.

Real-World Proof — Recurring Incidents with the Same Root Cause

Four well-documented, historical incidents show this isn’t theoretical. The 2015 Ukraine power grid attack cut power to hundreds of thousands of customers. The 2021 Oldsmar water treatment incident involved unauthorized remote access to a facility’s control system. Colonial Pipeline’s ransomware event forced a major fuel pipeline offline. NotPetya spread rapidly across both IT and OT environments alike in affected organizations.

Industry analysis consistently attributes each of these, in different specific ways, to insufficient segmentation between IT and OT environments, precisely the gap the Purdue Model exists to close.

Naming this as a pattern, not four unrelated stories, matters. It demonstrates this is a genuine, recurring architectural failure mode rather than a series of unrelated, unlucky events.

Purdue Model vs ISA-95 — a Precise, Honest Distinction

The Purdue Model and ISA-95 are frequently mentioned together and easily conflated. Here’s the precise disambiguation.

The Purdue Model is primarily a network and systems architecture framework, describing where each class of system sits within the industrial hierarchy. ISA-95, also published as IEC 62264, is a distinct data and integration standard, defining the specific data structures and interfaces for passing information between levels, most relevantly at the Level 3-to-4, Manufacturing Execution System to Enterprise Resource Planning, boundary specifically.

This precision matters. A vendor or colleague referencing “ISA-95 compliance” is discussing something genuinely different from Purdue Model segmentation, even though the two frequently appear in the same conversation.

Purdue Model vs ISA-95

Criteria	Purdue Model (PERA)	ISA-95/IEC 62264
What it defines	Where systems sit in the hierarchy	How data structures pass between levels
Primary focus	Network and systems architecture	Data and integration standard
Key boundary addressed	Every level, especially Industrial DMZ	Level 3-to-4 MES-to-ERP boundary specifically

Why OT Patching Is Even Harder Than What Post 46 and Post 47 Already Established

Patching a medical device can void its own FDA certification, a distinct constraint already established elsewhere. The constraint here is different again.

An OT system frequently cannot be patched or even rebooted without halting the physical process it controls entirely. Genuine patch windows align specifically with scheduled production outages rather than being available at any convenient time.

Here’s the direct connection worth stating plainly. This is precisely the same period already identified as the highest-risk window for boundary and air-gap erosion. The one time OT systems can genuinely be patched is also the one time security controls are most likely to be temporarily relaxed for vendor or engineering access.

Zero Trust and Remote Access — the Modern Complement to Strict Purdue Segmentation

Purdue’s own strict, level-based segmentation remains the foundational, industry-standard approach. Modern OT security increasingly layers zero trust principles on top of it specifically for remote access scenarios.

This matters directly given the maintenance-window risk just named. A vendor technician’s remote connection for scheduled maintenance is precisely the scenario where zero trust’s own per-session, per-resource verification adds genuine value, rather than assuming a maintenance connection is automatically, implicitly trusted for its full duration.

Private 5G and IoT Convergence — Where Two Prior Posts Meet OT Directly

Custom, purpose-built 5G network slices are an increasingly common connectivity option specifically for factory automation and other latency-sensitive industrial applications, already established elsewhere.

Connected IoT devices increasingly sit adjacent to OT environments, and lateral movement from a compromised IoT device into OT specifically has already been named as a genuine, growing risk.

Both connect directly to this post’s own architecture. Any new connectivity technology extending into or adjacent to an OT environment should be mapped explicitly onto the appropriate Purdue level and Industrial DMZ boundary, rather than treated as existing outside that established architecture. Cyber Security Solutions Ltd routinely finds manufacturers deploying new IoT sensors or private 5G connectivity without ever formally placing that technology within their existing Purdue mapping, quietly creating a connection nobody’s segmentation policy accounts for.

How Do You Secure an OT/ICS Network Step by Step?

1. Map your existing environment against the Purdue Model’s own levels, identifying exactly what currently sits where.
2. Establish or properly harden the Industrial DMZ specifically, since this is the single most critical boundary between IT and OT.
3. Confirm segmentation between every level is genuinely enforced through real security controls, not simply VLANs with unrestricted routing between them.
4. Apply zero trust verification specifically to remote maintenance and vendor access, rather than granting standing, implicit trust for the duration of any maintenance window.
5. Identify genuine patch windows aligned with scheduled production outages, and treat any temporary security relaxation during those windows as a named, documented, time-bound exception.
6. Map any private 5G or IoT connectivity explicitly onto the appropriate Purdue level rather than allowing it to exist outside the established architecture.
7. Prioritize security attention specifically toward Level 1 and Level 2 systems, given documented industry research finding the majority of OT vulnerabilities concentrate there.

Conclusion

Industrial network security comes down to one architecture doing most of the work: get your Purdue levels and Industrial DMZ genuinely enforced, and a compromise on the IT side stays contained before it ever touches the physical process. Map what you have, harden that boundary, and treat every new connectivity project as something that belongs inside this structure, not outside it. If you want help mapping your own environment against the Purdue Model properly, Cyber Security Solutions Ltd can walk through it with you.