Secure Remote Access: Don’t Let a Vendor VPN Become Your Back Door

Remote access in OT exists for one reason: speed—vendors can troubleshoot and engineers can support operations without traveling. But convenience is expensive in security. Attackers love remote access because it often bypasses internal controls: weak authentication, permanent accounts, no MFA, no session recording, no approval workflow.

A chilling scenario: a vendor uses the same shared credentials across multiple sites. MFA is not enforced. Those credentials leak through a compromised email account or a breached endpoint at the vendor. The attacker logs into the plant at night. Nobody notices because logs aren’t collected and sessions aren’t monitored. The attacker doesn’t “turn off the plant.” They do something smarter: they make process changes that degrade performance while appearing normal. Days later, production quality collapses, equipment wear accelerates, and the root cause is misdiagnosed as “process instability.”

Secure remote access should follow strict principles:

• Bastion/jump host mandatory: no direct RDP/VNC/SSH into OT. One controlled gate.

• MFA and strong identity: password alone is not enough. MFA, preferably device/certificate backed.

• Time-boxed access: no permanent 24/7 vendor accounts. Request → approve → limited duration.

• Session recording: screen recording and/or command auditing, tied to identity.

• Least privilege: vendor access should be scoped to the necessary systems and actions—not full admin.

• Network isolation: a dedicated vendor zone with strict conduits into required OT zones.

• Policy and contracts: vendor security requirements, credential handling rules, incident notification obligations.

This model may feel “slower,” but it prevents disasters. When an incident happens, remote access controls determine whether you can contain the event or whether you hand the attacker a highway into the control network.