Beyond Purdue: When the Supplier Marks Its Own Cybersecurity Homework

The Purdue model is still useful.

It gives us language. It gives us layers. It helps people understand why a control system should not be treated like an office network.

But the Purdue model is not a cybersecurity programme.

It does not tell you who owns the router exposed to the Internet. It does not tell you whether the firewall firmware is ten years behind. It does not tell you whether the operator station can be restored at 02:00 without calling the OEM. It does not tell the board whether the residual risk is acceptable.

For that, we need to go beyond Purdue.

A diagram is not visibility

In many industrial environments, the first surprise is not inside the plant.

It is outside.

External search engines, threat-intelligence feeds, vulnerability databases and basic open-source intelligence can reveal assets, services and product fingerprints that were never meant to become part of the public attack surface.

To use tools such as shodan is not hacking. It is observation.

And that is exactly why it is uncomfortable.

If an external observer can see a remote-access portal, an exposed industrial router, an old VPN endpoint, a management interface, a staging server or a device banner, the first question is not technical.

The first question is governance.

• Who owns it?
• Who monitors it?
• Who has authority to disconnect it?
• Who signs off the residual risk?

A Purdue diagram may show a clean separation between levels. Reality often shows something else: old remote-access paths, exceptions that became permanent, temporary links nobody removed, and supplier-managed infrastructure that the asset owner does not fully see.

Compliance is not the same as assurance

Industrial cybersecurity discussions often become trapped in standards language.

IEC 62443. ISO 27001. NIST. NESA. Policies. Certificates. Audits.

All of these can help. None of them can replace judgement.

The practical question is not whether a supplier can produce a certificate or a product security statement. The practical question is whether the actual plant architecture, actual exposure, actual firmware, actual recovery capability and actual operational constraints have been assessed independently.

There is a difference between evidence and judgement.

The OEM should provide evidence:

• product documentation
• firmware history
• patch statements
• hardening guides
• remote-access requirements
• end-of-support information
• known vulnerabilities
• recovery procedures

But the OEM should not own the final cybersecurity assurance conclusion for its own equipment.

Why? Because goat is not good garderner.

Because the same party may have designed it, supplied it, installed it, maintained it, upgraded it and commercially benefit from replacing it.

That is not a moral accusation. It is a conflict-of-interest problem.

Do not confuse OEM knowledge with independent assurance

OEM knowledge is valuable.

In some cases, it is essential. Nobody understands certain product internals better than the manufacturer. The OEM may know undocumented dependencies, firmware limitations, lifecycle constraints and recovery traps that an external assessor would otherwise miss.

So the OEM belongs in the assessment process. But not as the owner of the final risk judgement.

The distinction matters.

In conformity assessment, impartiality is not a cosmetic requirement. ISO/IEC 17065 treats impartiality as fundamental and explicitly separates certification from parties that design, manufacture, install, distribute or maintain the product, process or service being certified.

That principle is directly relevant to industrial control systems.

If a party benefits from one specific remediation path, especially a large upgrade, that party’s recommendation should be treated as input, not as independent assurance.

The board should not be asked to choose between “trust the OEM” and “ignore the OEM”.

The correct model is:

• OEM evidence plus independent assessment plus asset-owner accountability.
• Old does not automatically mean unsafe
• There is another trap in these discussions.
• Old system equals unsafe.
• New system equals secure.
• This is too simple.

An old but isolated, monitored and recoverable system may present less practical risk than a new system with remote access, weak governance and poor visibility.

• A supported operating system does not protect you from a bad architecture.
• A certificate does not remove an exposed attack path.
• A patch does not help if nobody knows the asset exists.
• An upgrade may be the correct decision. Sometimes it is unavoidable.

But it should be evaluated against other risk treatments:

• Virtualisation
• Isolation
• One-way data transfer using data diodes
• network segmentation
• passive monitoring
• tested backup and recovery
• strategic spares
• operator and engineer training
• documentation that people can actually use - not a Rubber Stamping

This is where the conversation moves beyond Purdue. The issue is not only where the system sits in a diagram.

The issue is whether the system can be seen, understood, isolated, monitored and recovered.

The missing control is often education

Many managers focus on technology first. Firewalls. Sensors. Data diodes. Monitoring platforms. Asset inventories. Dashboards. All useful.

But the control that makes the programme sustainable is education.

• Can the site engineer trace a signal from field device to logic to HMI?
• Can the maintenance team explain the difference between a network zone, a conduit and a remote-support exception?
• Can the operator recognise when a cybersecurity control creates an operational safety problem?
• Can the plant restore a critical station from backup without waiting for a supplier?
• Can the organisation convert raw data into information, information into knowledge, and knowledge into action?

If not, the programme will not survive the consultants leaving.

Training is not a side activity. Training is a control.

The better board question

The board does not need to become a firewall engineering team. But the board does need to ask better questions.

Not: “Are we compliant?”

Better: “Can we prove what is exposed?”

Not: “Has the OEM assessed it?”

Better: “Who independently owns the residual-risk judgement?”

Not: “Is the system old?”

Better: “Is the system exposed, unmonitored or unrecoverable?”

Not: “Do we need an upgrade?”

Better: “Have we compared upgrade, virtualisation, isolation and monitoring as risk-treatment options?”

Not: “Do we have a cybersecurity dashboard?”

Better: “Who acts when the dashboard shows something important?”

Beyond Purdue means accountability

The Purdue model helps us describe industrial architecture. But cybersecurity maturity begins when the organisation can answer these questions:

• What do we actually have?
• What is visible from outside?
• What is reachable from inside?
• What is obsolete but isolated?
• What is modern but exposed?
• What is monitored?
• What can be restored?
• Who owns the risk?
• Who is trained to respond?
• Who has authority to decide?

That is the real architecture.

Not only levels. Ownership.

Not only zones. Assurance.

Not only conduits. Accountability.

The future of OT cybersecurity is not another drawing of the Purdue model. It is the discipline to prove that the real plant behaves as the drawing claims.

And when it does not, to fix the exposure before the attacker, the auditor or the board finds it first.

• OEM input is necessary.
• OEM-owned assurance is conflicted.
• Old is not automatically unsafe.
• Exposed, unmonitored and unrecoverable is unsafe.
• Virtualise. Isolate. Monitor. Educate.

That is where the conversation goes beyond Purdue.