Why OT security is a supply-chain problem

The uncomfortable diagram

Draw the real network diagram of any large industrial site in the region and a pattern appears. The asset owner controls the perimeter, the DMZ and the enterprise IT stack above it. Below Purdue level 3, control quietly shifts. The DCS is maintained by the OEM. The safety instrumented system is under a service contract with a different OEM. Historians and MES sit with a systems integrator. Remote support tunnels — often always-on — terminate on laptops owned by vendors, on jurisdictions the asset owner has never listed. The organisation whose name is on the incident report does not, in practice, control the environment the incident happened in.

Why the usual playbook falls short

Most OT security programmes in the region start with visibility — an asset inventory, passive monitoring, a segmentation project. Those are necessary and we run them. They are not sufficient. Visibility tells you what is on the network; it does not tell you who can change it. A patched PLC, a segmented cell and a mature SOC do not close the exposure introduced by a vendor engineer with domain-admin equivalent on the engineering workstation and an RDP tunnel from a co-working space three countries away.

“Visibility tells you what is on the network. It does not tell you who, outside your organisation, can quietly change it.”

A supply-chain framing that works

We work with asset owners to reframe OT security around four questions asked of every third party with operational reach. Who can they touch — which assets, which zones, at which Purdue levels? What can they do — read, engineer, download, change safety logic? How do they get in — jump host, VPN, always-on tunnel, out-of-band cellular, physical laptop on site? And who watches — is the session recorded, alerted, approved by the asset owner in real time? When those four answers are documented per vendor, the actual OT attack surface becomes visible, usually for the first time.

Contracts are a control

The most under-used OT security control in the GCC is contractual. Master service agreements and maintenance contracts written five to fifteen years ago rarely specify who owns the credentials on the engineering workstation, who owns the audit log, or what happens to remote access when a contract lapses. Rewriting those clauses — with legal, procurement and OT engineering in the same room — has a larger effect on real-world risk than most tool deployments. It is also, unlike most controls, permanent.

How we start

Our OT engagements begin with a two-part diagnostic: a technical assessment against IEC 62443, NCA OTCC and the client's national obligations, run in parallel with a supply-chain and contract review of every third party with operational reach. The two views are reconciled into one prioritised programme — segmentation and monitoring where visibility is the gap, and vendor governance where control is the gap. In most cases the second list is longer than the first.