Is the Purdue Model Still Relevant? Cloud, IIoT and Remote Monitoring
Every few months, someone declares the Purdue Model dead. Sensors now send data straight to the cloud, vendors monitor equipment from another continent, and operators expect to check a dashboard from their phone. So is a layered model from the early 1990s still useful, or has it become a diagram nobody's network actually matches?
What has changed
The critics have a point. Industrial environments look very different from the ones the model was originally built to describe.
IIoT sensors that bypass the stack. Wireless vibration, temperature and corrosion sensors can send readings over cellular networks directly to a cloud platform, skipping Levels 1 through 4 entirely.
Vendor cloud analytics. Equipment manufacturers increasingly offer predictive maintenance and performance monitoring services that need a steady stream of data from turbines, compressors, drives or analyzers.
Remote operations. Pipelines, water utilities and remote production sites have long been run from central control centres, and since 2020 many organizations have expanded remote access for technical support, troubleshooting and monitoring.
Edge computing. Small industrial computers now sit near the process, collecting data, running analytics and forwarding results upward, sometimes blurring the line between Level 2 and Level 3.
Converged infrastructure. Virtualized servers, shared storage and common identity systems can span IT and OT, making clean physical separation harder.
In practice, few real sites ever matched the textbook diagram perfectly. Today the gap can be even wider.
Why the model still matters
None of those changes alters the basic reason the Purdue Model exists. Some systems directly control physical equipment, and a failure or compromise in those systems has physical consequences. Other systems handle business information, where the consequences are financial or reputational. Those two groups still need to be separated, and the connections between them still need to be controlled.
The model remains valuable because it provides:
A shared vocabulary. When an operator, an IT manager and a vendor all talk about "Level 2," they mean roughly the same thing. That saves time in every architecture discussion.
A trust gradient. Systems closer to the process deserve more protection and less exposure. That principle holds whether data leaves the site over fibre or a cellular modem.
A starting point for segmentation. Even modern architectures need boundaries, and the Purdue levels are a sensible first cut at where they belong.
A way to spot exceptions. When a new cloud connection is proposed, the model makes it obvious that it's crossing several levels at once, and that it deserves scrutiny.
The model works best as a reference, not a rulebook. It describes intent, and it helps you notice when a proposed change departs from it.
How to adapt Purdue for cloud and IIoT
Adapting the model is mostly about treating every new connection as a deliberate, controlled path rather than an exception nobody tracks.
Treat cloud connections as conduits. Any link from the OT environment to a cloud service should be documented, owned and governed like any other boundary crossing, with a clear purpose, defined data flows and someone accountable for it.
Prefer outbound, data-only paths. Where the goal is monitoring or analytics, data should flow out of the control environment, not commands back into it. Where the risk justifies it, a data diode or other one-way gateway can physically enforce that direction.
Route data through a controlled point. Rather than letting dozens of devices connect to the internet independently, collect data at a gateway or replicated historian in the industrial DMZ, then send it onward from there.
Broker all remote access. Vendors and remote staff should connect through a remote access gateway in the DMZ, with strong authentication, session approval, time limits and recording where practical. No direct inbound connections to controllers or HMIs.
Keep IIoT sensors in their own zone. If wireless sensors bypass the site network entirely, treat them as a separate zone, review the vendor's security controls, and make sure they can't become a path into control systems.
Check contracts, not just firewalls. For vendor cloud services, ask what data is collected, where it's stored, who can access it and whether the service can ever send changes back to your equipment.
IEC 62443 zones and conduits as a complement
The IEC 62443 series offers a flexible way to handle exactly these situations. Instead of forcing every asset into a fixed level, you group assets into zones with similar security requirements and define conduits for the communication paths between them.
A cloud analytics service becomes a zone outside your site. The path to it becomes a conduit with a documented security level, permitted protocols and an owner. A fleet of IIoT sensors becomes its own zone with its own risk assessment. The Purdue levels still inform where zones sit and how much trust each one deserves, but zones and conduits let you model architectures the original diagram never anticipated.
Used together, Purdue answers "where does this belong?" and IEC 62443 answers "how strongly should this boundary be protected?"
Key takeaways
Cloud, IIoT, edge computing and remote operations have made real networks look less like the textbook Purdue diagram.
The model's core idea, separating systems that control physical processes from business systems, is still sound.
Treat every cloud and IIoT connection as a documented, owned conduit, and prefer outbound, data-only paths.
Broker all remote access through the industrial DMZ, with strong authentication and session controls.
IEC 62443 zones and conduits complement Purdue by letting you size each boundary to its risk.
How QBits Networks can help
If your organization is adding cloud analytics, IIoT or more remote access, it's worth checking how those connections fit your segmentation before they multiply. A secure remote access review or a network segmentation review can map where data and access actually flow and show where controls should tighten. Tell us what you need through our contact page and we'll scope it with you.