The Vendor VPN You Forgot About: Why Third-Party Access Is OT's Least-Governed Attack Surface
A pump skid at a food processing plant trips offline. The on-shift technician calls the equipment vendor’s support line. Within twenty minutes, a support engineer in another country has connected via VPN, opened the engineering software, and started running diagnostics — all while the production line continues to process product. The issue is resolved in under an hour. The VPN session stays open for another eleven months.
Nobody in OT security knew about it. Nobody in IT tracked it. The vendor’s contract ended six months ago, but nobody told the support engineer — and nobody revoked the credentials.
This scenario plays out in industrial facilities every day. Not because anyone is negligent. Because the relationship between OT operators and equipment vendors creates a structural blind spot that authentication — no matter how sophisticated — cannot close.
The unavoidable reality: vendors need access
Industrial control systems are not like enterprise IT. When a PLC faults, a DCS node loses configuration, or a drive controller behaves erratically, the operator rarely has the expertise — or the proprietary software — to diagnose the problem. The equipment vendor does. And that vendor may need to connect remotely to the engineering workstation, the historian, or directly to the controller to troubleshoot.
This is not a failure of security posture. It is a feature of how industrial automation is procured, commissioned, and maintained. The vendor relationship often spans the entire lifecycle of the equipment — installation, commissioning, warranty support, upgrades, and decommissioning. Remote access is part of that relationship.
The problem is what happens between support sessions. The VPN credentials that were created during commissioning, the jump host account that was set up for a FAT (factory acceptance test), the RDP session that was never terminated — these access paths accumulate over years. They are rarely audited. They are almost never monitored after the initial connection.
Authentication tells you who connected. It doesn’t tell you what they did.
A well-governed facility might require multi-factor authentication for vendor access. It might restrict the vendor to a specific VLAN. It might log the connection timestamp and the IP address.
None of that answers the questions that matter to OT security:
- After the vendor connected, did they access only the controller they were supposed to troubleshoot — or did they browse to adjacent devices?
- Did they download a new configuration — or did they upload the existing one first, to study how the process works?
- Did the commands they issued look like routine diagnostics — or did they mirror the command sequence of a known attack technique?
- Was this session even initiated by the real support engineer — or by someone who phished their credentials three weeks ago?
Authentication is a door. Once the door is open, the room behind it is unobserved in most OT environments. And in that room sit the controllers, the HMIs, the historians — the devices that keep the process running.
What behavioral monitoring sees that access logs miss
This is where passive, behavioral network monitoring creates a detection surface that access governance alone cannot provide. A passive NDR system does not authenticate users. It doesn’t need to. It watches what happens on the network after the connection is already established.
It learns what normal vendor interaction looks like. The support engineer from Siemens typically connects around 14:00 UTC, accesses one specific engineering workstation, and issues Modbus function code 3 (read holding registers) to two PLCs. That pattern repeats across months of support sessions. It is the network’s baseline for that vendor.
Now consider a deviation. The same credentials connect at 03:00 UTC. They access not the engineering workstation but the HMI server. They issue function code 6 (write single register) — a write command — to a device the vendor has never written to before. They then move laterally to a historian and begin querying process tags that describe the plant’s safety interlocks.
An access log shows: “Vendor authenticated successfully at 03:00 UTC.” A behavioral monitor shows: this is not the vendor. Or, if it is, something has changed that warrants investigation.
Neither system needs to know about a specific vulnerability. Neither relies on a signature. The deviation from normal is the signal.
Three things every OT facility should do about vendor access this quarter
None of these require new hardware. None require a rip-and-replace of existing remote access infrastructure. They are process and visibility improvements that pay for themselves the first time they catch a session that shouldn’t be open.
1. Inventory every vendor VPN, jump host, and remote session that exists today. Not the ones in policy documents. The ones that are actually active. Ask each vendor to justify why they need persistent access versus on-demand, time-limited sessions. You will find at least one connection that nobody can explain.
2. Move from persistent to time-boxed access. Every vendor connection should have an explicit start time, an expected duration, and an automatic termination. If the support case takes longer than expected, the vendor can request an extension — but the default is that access expires. This alone eliminates the eleven-month ghost session.
3. Monitor what happens after authentication. This is the hardest step, but it is also where the detection value lives. Whether you deploy passive network monitoring, session recording, or both, you need visibility into what the vendor does once they are inside. The connection itself is not the threat. The commands issued over that connection are.
The attacker doesn’t need a zero-day if you gave them the password
The most discussed OT threat vectors — nation-state actors, custom malware, supply chain compromise — are real. They deserve the attention they receive. But an adversary does not need to burn a zero-day when a vendor VPN with valid credentials is already waiting, open and unmonitored, on the perimeter of the control network.
This is not a call for fear. It is an observation about where detection resources produce the highest return. Securing third-party access is not primarily a technology problem. It is a governance problem with a technology component. And that technology component — passive, behavioral monitoring of what happens inside the session — is the part most facilities are missing.
Maigadi — the OT/ICS network detection & response (NDR) platform that passively learns your network’s normal and detects the novel, signature-less attacks others miss. On-premise. Explainable. Sovereign by design.