Third-Party and Remote Vendor Access Risk

A large share of real-world OT incidents trace back to vendor or third-party access, not a direct external attack on the perimeter -- because vendor remote access is frequently the path of least resistance into an otherwise well-segmented environment. The core problem is trust asymmetry: an operator's own network is defended according to the operator's security standards, but the vendor's laptop, the integrator's support tunnel, or the maintenance contractor's remote session is defended according to whatever standard that third party happens to maintain -- which the operator usually cannot verify and often cannot even see. A defensible vendor access program treats every third-party connection as untrusted by default and enforces it structurally, not just contractually: access should be time-bound (enabled only for the duration of the approved work, not left standing), scoped to the specific systems the work requires (not a flat VPN into the whole OT network), monitored and logged independently of the vendor's own systems, and require multi-factor authentication at minimum. It is also worth explicitly separating 'remote access for monitoring/support' from 'remote access for engineering change' -- these carry very different risk profiles and should not share the same access path or approval process. A vendor who only needs to view diagnostic data does not need the same access as a vendor who is authorized to push firmware or configuration changes, and conflating the two is a common and avoidable source of excess privilege.