From Purdue to modern OT security: why the traditional model is no longer enough

Many industrial organisations have invested heavily in segmentation, firewalls, and network architecture.

Yet when we ask a simple question — “Would you detect an attacker moving between your OT systems today?” — the answer is often less certain.

The Purdue model remains one of the most important frameworks in industrial cybersecurity. But modern OT environments have evolved far beyond what the model was originally designed to protect.

Here is why that matters — and what modern OT security requires today.

What is the Purdue model?

The Purdue model, also known as the Purdue Enterprise Reference Architecture (PERA), was developed in the early 1990s and remains embedded in international standards such as IEC 62443.

The model divides industrial environments into hierarchical levels:

Level 0 – Physical processes Pumps, valves, motors, sensors, and other physical assets.

Level 1 – Basic control PLCs, RTUs, instrumentation, and local controllers.

Level 2 – Supervisory control SCADA systems, HMIs, and process supervision.

Level 3 – Operations management Site operations, production management, historians, and operational applications.

Level 4 – Enterprise IT ERP systems, business applications, and corporate networks.

Between levels 3 and 4 sits the industrial DMZ (demilitarized zone), designed to prevent direct communication between IT and OT environments.

The logic was elegant: isolate industrial systems, segment networks with firewalls, and assume that systems inside the boundary could be trusted.

In 1992, this was a highly effective approach.

Is the Purdue model still relevant?

Yes — as a foundation.

No — as a complete security strategy.

The principles of segmentation and separation between field devices, control systems, and enterprise networks remain valuable. However, several fundamental shifts have changed the assumptions on which the Purdue model was built.

What OT environments look like today

Ask an OT manager in manufacturing, energy, utilities, maritime operations, or critical infrastructure what their environment actually looks like, and the answer rarely matches a textbook Purdue architecture.

A typical environment often includes:

• Historian servers sending production data directly to cloud platforms such as Azure
• Third-party vendors connecting remotely for maintenance and troubleshooting
• Engineering workstations being connected when needed, often with inconsistent patch levels
• Shared services such as Active Directory and DNS spanning both IT and OT
• Operational teams requiring real-time dashboards and analytics for decision-making

This is not poor security practice.

It is operational reality.

And it is a reality the original Purdue model was never designed to address.

Why traditional OT security assumptions no longer hold

1. The air gap no longer exists

Traditional Purdue implementations assumed physical isolation between OT and external networks.

Today, that assumption rarely holds true.

Remote vendor access, cloud connectivity, IIoT devices, remote monitoring, and business requirements for data sharing have effectively eliminated the air gap in most industrial environments.

Many organisations still believe they operate isolated networks.

In practice, very few do.

2. Attackers move freely between IT and OT

Perhaps the most significant change is how cyberattacks unfold.

Major ransomware incidents over recent years — including the Colonial Pipeline attack and numerous attacks against European industrial organisations — have demonstrated a common pattern: attackers gain access through IT systems and then move laterally into OT environments.

They exploit trusted relationships, shared services, and insufficient visibility between domains.

Traditional segmentation alone cannot stop an attacker who already has a foothold inside the environment.

This is why modern security strategies must focus not only on separation but also on detection and monitoring across both IT and OT domains.

3. Visibility has become mission-critical

The Purdue model was designed to support availability and stability.

It was never designed to provide threat detection.

The model offers little guidance on how to detect lateral movement between PLCs, unauthorised configuration changes, manipulation of process values, long-term data exfiltration, or insider threats.

At the same time, regulations such as NIS2 and emerging national cybersecurity legislation increasingly require organisations to detect, investigate, and report incidents.

An architecture without built-in visibility is no longer sufficient.

What modern OT security requires

The answer is not to replace Purdue.

The answer is to build modern security capabilities on top of it.

Step 1: Visibility – you cannot protect what you cannot see

Everything starts with visibility.

Organisations need a complete inventory of assets, communications, and dependencies within their industrial networks.

Passive monitoring technologies allow security teams to identify unknown devices, communication patterns, protocol anomalies, and unauthorised connections — all without disrupting operations.

Step 2: Segmentation based on actual traffic

Segmentation should reflect actual communication requirements — not assumptions made years ago during system design.

Organisations should continuously validate which systems communicate with each other, which connections are genuinely required, and which legacy connections exist simply because nobody has questioned them.

Effective segmentation is driven by observed behaviour, not architecture diagrams.

Step 3: Detection inside the OT environment

Perimeter security alone is no longer enough.

Modern OT security requires continuous monitoring for lateral movement, protocol anomalies, changes in device behaviour, unauthorised commands, and process deviations.

The goal is to detect threats before they impact operations.

Step 4: Integrated IT and OT security operations

The traditional separation between IT security and OT security is rapidly disappearing.

Attackers do not respect organisational boundaries.

Defenders should not either.

A modern security operations center (SOC) with OT expertise can correlate events across both domains, improve response times, and provide a unified view of organisational risk.

Step 5: Zero trust for industrial environments

Zero trust in OT is not about deploying advanced identity controls on 20-year-old field devices.

It is about limiting trust relationships: restricting which systems can communicate, controlling and monitoring remote access, enforcing least-privilege principles, and reducing opportunities for lateral movement.

The principle remains the same as in IT.

The implementation must be adapted to OT realities.

Purdue and zero trust: competitors or complements?

They are complementary.

The Purdue model defines zones and boundaries. Zero trust ensures that traffic inside those zones is not automatically trusted.

Purdue provides the structure. Zero trust provides the security mindset.

Organisations need both.

How does Purdue fit into IEC 62443?

IEC 62443 builds upon Purdue’s zoning principles but extends them significantly with security levels, risk-based security requirements, secure architecture principles, supply-chain security requirements, and lifecycle governance.

Purdue provides the framework. IEC 62443 provides the security requirements.

Three questions every organisation should ask

1. Do you have complete visibility of every asset in your OT environment — including devices that were never intended to be network-connected?
2. Would you detect an attacker moving laterally between industrial systems before operations are affected?
3. Are OT incidents handled by the same security operations team as IT incidents — or do separate teams operate with different tools, processes, and visibility?

If the answer to any of these questions is “no” or “I’m not sure,” it may be time to reassess your OT security architecture.

This is part 1 of 3: OT control in practice

Network design and security architecture are the foundation — but real control in OT requires more than the right architecture. The next two articles in this series address what is often missing:

Part 2 – OT control is about more than security: How to establish visibility, governance, and structured processes around assets, vendor access, and change management.

Part 3 – From assessment to compliance: How to conduct an OT maturity assessment, build a prioritised roadmap, and what NIS2 and cybersecurity legislation actually require of OT environments.

[Read part 2] | [Read part 3]

NetNordic helps organisations design and implement modern OT security architectures — from asset discovery and network segmentation to SOC integration, governance, and continuous monitoring.