Securing Vendor Remote Access to OT Systems: A Practical Guide

Ask an OT security team where their least-controlled network path is, and the honest answer is almost always the same: the vendors. The compressor OEM has a cellular gateway wired into the cabinet. The integrator has a TeamViewer install on an engineering workstation. The controls contractor who still has VPN credentials from a project that ended two years ago.

Third-party remote access is not an edge case in industrial environments; it is the majority of remote sessions at many sites. It is also a recurring theme in industrial incident reports; the Target breach began with an HVAC vendor's credentials, and supply chain attacks like Kaseya showed how trusted vendor channels cascade. When an attacker wants to get into your OT network, the vendor's laptop is often the easiest door.

This guide, part of our OT secure remote access series, covers why vendor remote access is uniquely risky, what a defensible program looks like, and how BlastWave customers implement it without turning vendor support into a bureaucratic ordeal.

Why Vendor Remote Access Is Your Biggest OT Exposure

You don't control the endpoint. The technician's laptop belongs to another company. You can't verify its patch level, its exposure to malware, or who else uses it.

Credentials outlive relationships. Contractors change staff, projects end, and shared "vendor" accounts persist. Every stale credential is a standing invitation.

Access is granted at the wrong granularity. The typical accommodation, a VPN account or a shared jump server login, gives a pump vendor the same network reach as a controls engineer. One phished technician exposes the whole segment.

Nobody is watching the session. Without session-level visibility, you can't distinguish a legitimate firmware update from an attacker exploring your HMI screens with stolen vendor credentials.

OEM gateways bypass your perimeter entirely. Cellular and cloud-connected access boxes shipped inside machine cabinets create network paths your firewall never sees.

The Five Requirements of Defensible Vendor Access

1. Identity, not accounts

Every technician gets an individual, verified identity. Shared vendor logins are eliminated. With BlastShield, this identity is passwordless and device-bound, so there is nothing for a phisher to steal and nothing to persist after offboarding.

2. Least privilege by default

A vendor's access policy names the specific devices and protocols they support, one machine, one PLC, one HMI, not a subnet. This is the zones-and-conduits model that IEC 62443 formalizes, applied to people. (Background: OT Network Segmentation.)

3. Time-bound sessions

Access is granted for a maintenance window, not in perpetuity. When the ticket closes, the path closes. Standing access should be a deliberate exception with an owner and a review date, never the default.

4. Full session visibility

Who connected, to what, when, and what they did. Session-level records turn vendor access from a blind spot into an auditable activity, which is precisely what NERC CIP, TSA directives, and cyber insurers increasingly demand.

5. Invisibility to everyone else

The access infrastructure itself must not become the attack surface. Internet-facing VPN portals and jump servers advertise themselves to scanners. BlastShield's network cloaking means that unauthorized parties, including attackers armed with automated reconnaissance tools, see nothing at all.

What This Looks Like in Practice

A typical BlastWave vendor-access deployment works like this. The plant defines a policy per vendor relationship: "Acme Compressor Services may reach the three compressors they maintain, over the two protocols their tooling uses." Each Acme technician enrolls with passwordless MFA in minutes, no client VPN configuration, no password resets. When a support ticket triggers a session, the technician authenticates biometrically, sees exactly three devices, and everything else in the plant remains dark. The session is visible to plant staff in real time and available for audit later. When Acme's contract ends, revoking the policy removes every path, including any they'd forgotten they had.

Because BlastShield deploys as a software overlay, this model also wraps around existing OEM gateways: the Ewon in the cabinet keeps working, but its traffic now flows through a policy layer the plant controls.

Vendor Access Checklist

Use this to audit your current state:

• Inventory every third-party access path, including OEM gateways and desktop-sharing tools installed on workstations
• Eliminate shared accounts; one identity per technician
• Replace passwords with phishing-resistant authentication
• Scope each vendor to named devices and protocols
• Default all access to time-bound sessions
• Record and review session activity
• Verify offboarding actually revokes access, then test it
• Confirm your access infrastructure is not discoverable from the internet

If more than two items fail, vendor access is your most likely breach path.