Zero Trust in OT Should Mediate Authority, Not Modernise Every PLC

The resource is the control action, not the subnet

NIST SP 800-207 defines Zero Trust around removing implicit trust based on network location or ownership and focusing policy on users, assets and resources. That principle is useful in OT, but a literal implementation can fail when controllers cannot support modern identity, certificates or agents.

NIST SP 800-82 simultaneously warns that OT security controls have to respect performance, reliability and safety constraints. The implication is that Zero Trust should not become a programme to force cloud-era controls into every twenty-year-old PLC.

Instead, the policy boundary can move outward: broker access through hardened jump services, protocol-aware gateways, privileged-access workflows and engineering stations that can authenticate users and devices before a control session is allowed.

Legacy does not require standing trust

A PLC may continue speaking an unauthenticated industrial protocol while the architecture around it ensures that only an approved session can reach that protocol, from an approved device, for a bounded purpose and time window.

This is materially different from a permanent VPN route into an OT subnet. The control becomes transactional: who is requesting authority, to which engineering function, against which asset, under what work order, and what is recorded for later review.

The goal is not perfect identity at Level 0. The goal is to eliminate unnecessary standing paths and ensure that the inability of a legacy endpoint to authenticate does not force the entire plant to trust the network around it.