ICS Cybersecurity 101: Is The Purdue Model Still Enough?
By Justin Fimlaid
Modern utilities are built on legacy. Pumps, relays, and controllers that once operated in isolation now talk to cloud dashboards, mobile tablets, and vendor service portals. This new reality makes a strong focus on industrial control systems (ICS) cybersecurity absolutely essential. The result is both remarkable efficiency and remarkable exposure, making ICS cybersecurity essential.
For decades, the Purdue Model has been the North Star of ICS design. It was never meant to be a security model, but its clean separation of process control from business systems gave engineers a natural place to draw security boundaries long before most utilities had a security program. The trouble is that model was drawn for a world that was closed.
Today’s ICS environments are anything but. Water authorities now operate through interconnected, data-driven systems that never sleep. The question for leaders is simple: does the Purdue Model still hold up or has the industry moved on?
The Purdue Model: The Original Blueprint
Developed between 1989-1994 at Purdue University, the Purdue Enterprise Reference Architecture (PERA), laid out six layers for industrial systems, from field devices to enterprise IT. It was built as a reference for computer integrated manufacturing rather than as a security model, and it is usually drawn as six levels, from Level 0 (the physical process) to Level 5 (the enterprise network). Security practitioners later added an Industrial DMZ, often labeled Level 3.5, between operations and the business network.
- Level 0, The Physical Process: Sensors and actuators
- Level 1, Basic Control: PLCs and controllers
- Level 2, Local Control: HMIs and SCADA interfaces that supervise the process
- Level 3, Site Operations: Historians, scheduling, and batch management
- Level 3.5, Industrial DMZ (added later): A controlled buffer between OT and IT
- Levels 4 and 5, Enterprise Systems: Corporate IT, analytics, billing, and management networks
Its purpose was simple: segmentation equals safety. By separating control networks from corporate systems, the Purdue Model limited cascading failures and helped operators trust that what happened on the business network stayed there. That philosophy still matters, but the assumptions underneath it have aged.
Where The Purdue Model Still Holds Up
Even today, the Purdue Model remains the Rosetta Stone of ICS architecture.
- It organizes chaos. Everyone from CIO to plant operator can visualize risk in the same structure.
- Segmentation still saves the day. A firewall and DMZ between OT and IT won’t stop every attack, but it gives ransomware a much harder road from the front office to the pump house.
- Standards borrow from it. NIST SP 800-82 cites Purdue as one way to organize OT segmentation, IEC 62443 zones are often drawn along Purdue levels, and NERC CIP enforces perimeters that map naturally onto the same boundaries. It anchors conversations. Executives can see, on paper, which layer of the business could take down operations.
Purdue still belongs on every network diagram, but it’s no longer the entire diagram.
Why Modern Utilities Are Outgrowing It
Utilities have evolved beyond Purdue’s static boundaries.
- Flat networks: Decades of incremental growth blurred layer separation.
- Legacy devices: Many older controllers and protocols have no built-in authentication, so they depend on the network around them for protection.
- Always-on connectivity: Cloud analytics, vendor access and cellular modems have quietly eroded many air gaps that were once assumed to be solid.
- Adversaries adapted: Nation-state actors now target OT directly and ransomware that hits the business side can still shut down operations.
- Operational constraints: You can’t patch a pump while it’s supplying a city, and OT puts safety and availability ahead of confidentiality.
The Purdue Model didn’t fail; it just stopped being enough.
Modern ICS Cybersecurity Models That Build On Purdue
IEC 62443 – Zones and Conduits
IEC 62443 builds on Purdue’s structure by adding zones and conduits, which are logical groupings of assets that share security requirements and the controlled communication paths between them. Zones are sized by risk assessment, and each one is assigned a target security level, which makes the standard flexible and recognized worldwide. A water utility might group treatment-plant controllers into one zone, remote pumping stations into another, and strictly define what data moves between them. Many mature organizations use Purdue to sketch their architecture and IEC 62443 to decide how tightly each part of it needs to be secured.
Zero Trust for ICS
Zero Trust challenges the habit of treating everything inside the network as safe. Every connection, human or machine, has to prove its legitimacy continuously, and that includes the vendor who has been dialing into the same pump station for ten years. Federal guidance now supports a phased approach for OT. CISA’s April 2026 joint guide on adapting Zero Trust principles to operational technology warns that applying IT-style Zero Trust tools across the board is neither reasonable nor feasible in OT environments. Identity-based vendor access, MFA on remote sessions, and micro-segmentation within control zones are the kind of practical first steps that fit that guidance. Zero Trust is a mindset rather than a product, and it comes down to trusting nothing by default and monitoring everything by design.
“Purdue 2.0” — Layered Segmentation Meets Continuous Verification
Some vendors call this blended approach “Purdue 2.0.” It is not a formal standard and you won’t find the term in NIST, ISA/IEC, or CISA documents, but it works as shorthand for what is recommended. Purdue’s layered architecture provides the structure, IEC 62443’s zones and risk levels provide the rigor, and Zero Trust’s continuous verification provides day-to-day assurance. The goal is no longer to wall the plant off from the world, but to keep operating when something inevitably gets through.
Overlaying Cybersecurity Frameworks — From Architecture To Accountability
Frameworks give the Purdue structure purpose and measurement. Together they define what to manage, how to manage it, and who enforces it.
NIST Cybersecurity Framework (CSF)
The CSF 2.0, released in February 2024, organizes cybersecurity outcomes into six functions: Govern, Identify, Protect, Detect, Respond, and Recover. It describes what good looks like rather than prescribing architecture, so it demands awareness and control without telling which firewall to buy. Purdue shows where your systems sit, the CSF defines the outcomes you are working toward, and guides like NIST SP 800-82 explain how to get there.
NIST SP 800-82 — The ICS Field Manual
NIST SP 800-82 Rev. 3, the Guide to Operational Technology (OT) Security, was published in September 2023 and is the most comprehensive free U.S. reference for securing industrial systems. It names the Purdue model as one recognized way to organize network segmentation, recommends a DMZ architecture with firewalls so traffic never passes directly between corporate and OT networks, and walks through how to apply the CSF to OT environments. Because it was written before CSF 2.0, it follows the original five-function structure, so Govern is the one function needed to layer on yourself. For municipal utilities, it offers detailed guidance written for the people who actually run these systems, and it costs nothing to download.
NERC CIP — Regulation with Teeth
For owners and operators of the bulk electric system, NERC CIP turns those boundaries into enforceable requirements. CIP-005 calls for Electronic Security Perimeters and Electronic Access Points, CIP-007 covers system hardening and monitoring, and CIP-015, Internal Network Security Monitoring, requires high and medium impact entities to watch traffic inside those perimeters. FERC approved CIP-015-1 in June 2025, with compliance beginning October 1, 2028, and approved an expanded CIP-015-2 in August 2026 that extends monitoring to supporting systems such as access control and physical security. NERC CIP does not apply to water or wastewater utilities, and many smaller municipal electric systems fall under only the low impact requirements, so check your registration status before assuming these rules are yours.
IEC 62443 — The Technical Global Standard
Defines security levels, zones, conduits, and lifecycle requirements that apply to asset owners, system integrators, and product suppliers. It gives Purdue’s architecture a way to be measured, because each zone gets a target security level that can be tested against what is actually deployed.
API 1164 — Pipeline and Midstream Security
API Standard 1164, Pipeline Control Systems Cybersecurity (3rd Edition, 2021), is the pipeline industry’s go-to standard, covering natural gas and hazardous liquid transmission, gas distribution, and LNG facilities. After Colonial Pipeline, TSA issued mandatory Security Directives for designated critical pipelines and has since moved to a performance-based approach in which operators document their own measures in a TSA-approved plan. Many operators use API 1164 to build those plans, though TSA does not name it as a required baseline. Any municipal gas utility or organization with fuel or midstream connections should treat it as essential reading.
The Combined View
It’s easy to feel buried under frameworks like Purdue, NIST, IEC, CIP, and API. Each has value, but most public-sector teams don’t have the time or staff to implement all of them in full. If you have to start somewhere, start with CISA’s Cross-Sector Cybersecurity Performance Goals, a voluntary and prioritized baseline built for organizations that are just getting traction, then lean on NIST SP 800-82 when you need OT-specific depth. Water utilities serving more than 3,300 people also have a legal reason to move early, since America’s Water Infrastructure Act requires a risk and resilience assessment that covers cybersecurity, reviewed every five years.
Practical Roadmap For Public Utilities
- Map Your Network. Use Purdue as a baseline to identify every asset and connection.
- Define Zones and Conduits. Apply IEC 62443 to group systems by function and risk.
- Adopt Zero Trust Tactically. Secure vendor access and cloud links with identity and MFA.
- Align Governance. Use NIST CSF and SP 800-82 to measure maturity, and map CIP or API 1164 controls to your architecture if you are a registered electric entity or a pipeline operator.
- Add Visibility. Deploy monitoring inside your OT networks, following SP 800-82 and, for high and medium impact electric entities, CIP-015..
- Design for Resilience. Backup controller logic, test fail-safe operations, and run incident drills.
- Make It Cultural. Train engineers and operators to see cybersecurity as part of safety culture.
Do these consistently and you’ll move from compliance to control, and from a checklist to true cyber resilience.
From Purdue To Practice
The Purdue Model isn’t obsolete, it’s incomplete. It gave us order, and modern frameworks give us agility. Strong programs now blend the following:
- Purdue for structure
- IEC 62443 for technical rigor
- NIST CSF 2.0 and SP 800-82 for governance
- NERC CIP, API 1164, or AWIA for compliance, depending on your sector.
- Zero Trust for continuous assurance
A modern ICS cybersecurity strategy protects more than systems, because it protects public confidence. When ransomware stops pumps or grid telemetry, the cause is rarely a single technical flaw and more often a governance gap, such as exposed devices, default credentials, or recovery plans nobody has tested.
Justin Fimlaid is CEO and founder of nuHarbor and may be reached at justin@nuharborsecurity.com. NuHarbor is a U.S.-based cybersecurity firm delivering continuous security operations, compliance, testing, and strategic consulting tailored to clients’ needs; turning complex security data into clear, actionable improvements that reduce risk and strengthen the systems on which communities rely. Learn more at nuharbor.com.