How to retire the always-on vendor VPN

A press-line vendor needs SSH access to one PLC, twice a quarter, for firmware updates. An imaging vendor needs RDP to one MRI controller during a service call. A robotics integrator needs remote diagnostics access to a cell on the shop floor during commissioning.

In each case, the actual scope is one machine for one task. The way the access is delivered is almost always larger — a vendor account on the OT VPN with a route into the whole subnet, scoped by firewall rules that everyone agrees are 'roughly right' and nobody has audited in a year.

OT segmentation projects assume the vendor's home network is trustworthy. It usually is — until it isn't. The pattern that drove most of the OT-targeted ransomware events of the last several years is the same: integrator's laptop gets a foothold from a phishing email; their VPN client to the customer's OT subnet now serves as a pivot; the attacker walks across the subnet at their leisure.

On-site escort solves this — one technician, one device, one closed door. But escort doesn't scale. A multi-site operator with fifteen plants and a quarterly maintenance cadence cannot physically watch each window, and the integrators cannot fly an engineer to each visit. So the operational pressure is always toward leaving the path up.

A physical switch on the line to the one device the vendor needs gives you a way out. The line is broken by default. The operator opens a window for the duration of the planned work — manually via SMS, or on a recurring schedule that matches the vendor's contract — and the line closes itself when the timer expires.

The vendor's home network can be exactly as trustworthy or untrustworthy as it was; for the 89 hours a week outside the window, none of that matters, because there is no path. The pivot route does not exist as a route.

A multi-site operator running this pattern across 15 plants ends up with a per-device map of which lines exist during which windows. The number of always-on vendor paths drops from 'whatever segmentation drift left behind' to 'zero'. Annual audits stop arguing about whether the vendor account on PLC-04 should be there, because the line to PLC-04 only exists during scheduled work — and the relay state log says so.

This is not a replacement for vendor identity controls. The vendor still needs an account, still needs MFA, still gets the same scoped access they had inside the window. What changes is that outside the window, the access discussion is moot — there is no network to gate access on.