When Level 4 Can Reach Level 1, the Diagram Is No Longer the Architecture

The Purdue diagram on the wall may still be correct ... The operation around it may no longer be.

It may show enterprise systems at Level 4, site operations below them, supervisory systems at Level 2, controllers at Level 1, and the physical process at Level 0. Firewalls and an industrial DMZ appear between the major boundaries.

Then reality enters the room.

An IIoT gateway sends field data directly to a cloud platform. A vendor maintains equipment through a remote-access service. An enterprise identity system authenticates an engineering user. A digital team connects an analytics platform to the historian. An AI application reads alarms, maintenance records, or process data.

Each connection may have a legitimate purpose.

Together, they can create a path from the enterprise or the internet toward the control layer that the original diagram does not fully explain.

This is not a reason to discard the Purdue Model.

It is a reason to stop treating the model as proof that the architecture is secure.

The model remains useful

The Purdue Model still provides industrial organizations with a useful way to organize functions and separate enterprise activities from industrial control.

It helps engineers, cybersecurity teams, integrators, and leaders discuss where systems belong and where stronger boundaries should be in place.

The problem begins when the levels become the assessment.

I have seen environments described as “Purdue compliant” because a diagram contained the expected layers. Yet the same environment included persistent vendor access, shared identities, dual-homed systems, unmanaged cellular connections, undocumented firewall rules, or cloud-managed devices communicating across those layers.

The levels were present ... The trust boundary was not.

A network architecture cannot be judged only by where a device appears on a diagram. We also need to understand what the device can reach, which connections it can initiate, which identities it trusts, what authority it holds, and what happens to the process if it is compromised or unavailable.

Modern OT no longer communicates only vertically

Traditional industrial architectures were easier to represent as controlled flows moving between adjacent levels.

Modern OT does not always behave that way.

Field devices may communicate directly with edge gateways. Gateways may publish data to external platforms. Remote experts may connect from another country. Enterprise applications may consume production data. Cloud services may support maintenance, optimization, asset performance, or energy management.

AI will further expand these paths because it relies on data from multiple systems.

The application relies on historical data, reviews alarms, compares engineering documents, accesses maintenance records, retrieves asset information, and initiates a workflow on another platform. Even when the AI has no direct connection to a controller, the systems it can influence may have one.

The path to physical consequence may therefore look like this:

Data source → AI platform → recommendation → workflow → authorized user or system → engineering action → physical process

None of those connections should be considered in isolation.

A read-only connection at one point can still contribute to an action elsewhere. A human approval step can still be weak if the approver lacks operating context. A cloud service can become an operational dependency even if it never sends a command directly to a PLC.

The relevant question is no longer only, “Which Purdue level is this system in?”

The better question is, “What operational authority can this system exercise, directly or indirectly?”

Northbound data must not imply southbound authority

Industrial organizations have good reasons to move data north.

Operations needs enterprise reporting. Engineering needs performance analysis. Leadership needs production visibility. Maintenance teams need equipment information. AI applications need data to generate useful conclusions.

The danger is allowing a northbound data requirement to create an uncontrolled southbound path.

An IIoT gateway may need to publish selected measurements. That doesn't mean the cloud-management service should be able to modify the field configuration without being separate from modifying the enterprise identity service, which may help manage users. That doesn't mean an enterprise administrator shouldn't automatically undermine authority in the control environment.

An AI assistant may summarize within arms. That does not mean it should inherit the operator’s ability to acknowledge, suppress, or act upon them.

For every connection crossing an OT boundary, leaders should require clear answers:

• What operational purpose justifies the connection?
• What data is permitted to cross?
• In which direction can communication occur?
• Which identity can initiate it?
• What actions can the receiving system perform?
• Can compromise create a return path?
• Can the connection be isolated without losing safe control?
• Who owns the operational consequence?

These are not firewall questions alone. They are governance and engineering questions.

Purdue needs additional overlays

The future is not a more complicated Purdue diagram with extra boxes for cloud and AI.

The stronger approach is to retain the functional levels while adding several operational overlays.

Connectivity

Document every network, wireless, cellular, vendor, cloud, and third-party path. This should include connections that are temporary, externally managed, or activated only during maintenance.

Identity

Identify which human, machine, service, and vendor identities are trusted at each boundary. Shared accounts and inherited enterprise privileges can undermine otherwise strong segmentation.

Authority

Define what each identity and system is permitted to observe, recommend, initiate, approve, or execute. Authority should become narrower as it approaches the physical process.

Dependency

Understand which external services the operation now depends upon. Loss of an identity provider, cloud service, remote-access platform, certificate authority, or data platform may affect the ability to operate or recover.

Failure and recovery

Determine how each connection can be isolated, how the process behaves when the service is unavailable, and how control can be restored without relying on the failed or compromised environment.

This is consistent with the direction of the current government and industry guidance.

The joint Secure Connectivity Principles for Operational Technology emphasize limiting exposure, centralizing connections, hardening OT boundaries, monitoring connectivity, limiting the impact of compromise, and establishing an isolation plan.

The international guidance on creating and maintaining a definitive view of OT architecture similarly calls for organizations to document assets, connectivity, and third-party risk as a maintained operational record.

ISA/IEC 62443 strengthens this further through risk-based zones and conduits. A zone is not simply another Purdue level. It groups assets with common security requirements, while conduits define and protect the communications permitted between zones.

These approaches complement Purdue. They turn a reference model into an architecture that can be governed and tested.

The architecture must reflect physical consequences

In my personal article, “The Future of OT Is IT, But OT Must Not Become IT.”, I argued that industrial IT operations increasingly depend on familiar IT technologies while remaining fundamentally different in consequence.

This is where that distinction becomes practical.

IT may operate the identity platform. A cloud provider may operate the analytics service. A vendor may maintain the gateway. Cybersecurity may manage the firewall. Engineering may own the controller. Operations remains accountable for the process.

If no one owns the entire path, accountability disappears between teams.

That is why every new connection should pass the Control Room Test:

Would we approve this architecture if we were personally accountable for keeping the process safe, available, and running when one of its dependencies fails or is compromised?

If the answer depends on an untested assumption, the architecture is not finished.

The OT CISO must govern the path

The OT CISO should not become the owner of every controller, network, cloud platform, or engineering decision.

The role is to ensure that the complete risk has an owner.

That means bringing IT, engineering, operations, safety, cybersecurity, vendors, and digital teams together into a single operating model. It means requiring evidence that, together, conditions are necessary, access is controlled, authority is limited, dependencies are understood, monitoring is effective, and isolation can be performed without creating an unsafe condition.

It also means challenging projects early.

• Not after the cloud service has been selected.
• Not after the IIoT gateway has been installed.
• Not after the vendor has created persistent remote access.
• Not after the AI platform has inherited credentials and operational data.

Architecture decisions become harder and more expensive to make once operational dependencies are established.

The next model is not another diagram

Purdue is not dead.

But Purdue alone cannot describe the full reality of a connected industrial environment.

The levels still help us understand where functions belong. Zones and conduits help us define security requirements and permitted communications. Identity and authority models tell us who or what may act. Dependency and recovery analysis indicates whether the operation can remain resilient in the event of a failure.

The objective is not to prevent IT, IIoT, or failure from supporting industrial operations.

It is to ensure that every connection has a purpose, every identity has a boundary, every system has defined authority, and every operational dependency has a tested failure mode.

When Level 4 can reach Level 1, directly or indirectly, the diagram is no longer enough.

The real architecture is the complete path from connection to authority to physical consequence.

That is the architecture OT leaders must govern.