Your governance is only as strong as your weakest connection
An organisation can build a genuinely mature OT security programme, with a well-structured CSMS, clean zone and conduit segmentation, and asset-level governance, and still be exposed through a party it does not directly control. Original equipment manufacturers, system integrators, and third-party service providers routinely have remote access into OT environments to support the equipment they supply, and the security posture of that access is frequently governed by the vendor’s practices rather than the operator’s.
This is not a hypothetical concern. A meaningful proportion of significant OT security incidents have involved a third-party access path as the initial point of entry, rather than a direct attack against the operator’s own perimeter. An environment can have excellent internal controls and still inherit risk from a vendor whose remote access credentials are shared across multiple clients, whose laptop used for support visits is not itself well secured, or whose own network has been compromised.
Why this risk is easy to underestimate
Vendor relationships in OT tend to be long-standing and built on operational trust. The engineer from the OEM who has supported a specific control system for a decade is, reasonably, seen as a known and trusted party. That trust is often justified in terms of competence and intent. It says very little about the security of the specific laptop, credentials, or network that engineer is using on any given visit, and OT security programmes that rely on relationship trust as a substitute for verified technical controls are extending their attack surface without necessarily realising it.
There is also a structural asymmetry: the operator carries the consequence if a vendor’s access is compromised, but the vendor often carries little direct accountability for the security of that access, particularly where the relationship was established before formal security requirements were part of the vendor management process.
What holding vendors to a consistent standard looks like
The starting point is treating third-party access as a defined conduit under the same IEC 62443 logic applied to internal zones and conduits, rather than as a special case managed informally outside the CSMS. That means every vendor connection has a defined purpose, a defined scope of what it can reach, and a defined security level appropriate to what it connects to.
From there, a small number of practical controls do most of the work. Remote access should route through a controlled jump point rather than a direct connection into the OT network, with session recording and time-limited access rather than standing credentials that remain valid indefinitely. Vendor accounts should be unique to the individual and the engagement, not shared generic credentials used across multiple sites or multiple engineers. Access should be requested and approved for a specific purpose and window, then explicitly disabled afterwards, rather than left active on the assumption it might be needed again. And new vendor relationships should include security requirements in the contract itself, covering expectations around credential handling, incident notification, and the security baseline of any equipment the vendor connects to the environment.
Assessment cannot stop at the contract
A signed contract with security clauses is a starting position, not a guarantee. Organisations that manage third-party OT risk well build some form of ongoing verification into the relationship, whether through periodic review of vendor access logs, requiring evidence of the vendor’s own security practices for engagements involving higher-risk systems, or including vendor-related scenarios in incident response testing so that the organisation has actually practised what happens if a vendor connection is the source of an incident, rather than discovering the gaps in that process during a real event.
This does not need to be adversarial. Most OEMs and service providers operating in mature industrial sectors are used to security requirements from other clients and can meet them without difficulty once they are made explicit. The organisations that struggle here are usually the ones that never formalised the requirement in the first place, and are trying to introduce it retroactively into a relationship built on informal trust.
Consistency is the point
The underlying principle across all of this is consistency. An OT security programme that applies rigorous standards to its own assets and infrastructure, while allowing vendor access to operate outside that same standard, has not actually closed the risk it set out to address. It has simply moved the weakest point in the chain from somewhere internal to somewhere external, where it is often harder to see and slower to detect. Bringing third-party access under the same governance, segmentation, and monitoring standard applied everywhere else in the environment is not an additional layer of work so much as the completion of the governance model already being built.
