Vendor Remote Access in OT: Incident Response When Third-Party Access Is Compromised

Vendor remote access exists in almost every OT environment for a good reason — specialized equipment needs specialized support, and requiring a vendor engineer to travel onsite for every configuration change isn't realistic. That same access is also one of the most common paths attackers use to reach operational technology, precisely because it's a trusted, often persistent connection that bypasses much of the perimeter an organization otherwise controls.

Why Vendor Access Is a Common Entry Point

Vendor connections are frequently long-lived, less closely monitored than internal access, and sometimes configured years ago by someone no longer at the organization. They're also, by design, a bridge across network boundaries that would otherwise segment an attacker's path — which is exactly what makes them valuable to compromise.

VPNs and Jump Hosts

Identify every VPN and jump host that provides vendor access into the OT environment, including ones that may not be actively documented. When a compromise is suspected, these are among the first things to review — both for evidence of unusual activity and as a candidate for immediate containment, weighed against what legitimate access would be disrupted.

Shared and Vendor-Managed Credentials

Vendor accounts are disproportionately likely to be shared among multiple people at the vendor, use generic or default naming, and go unrotated for long periods. If a vendor access path is implicated, assume the associated credentials are compromised and treat rotation as a priority — not just for that vendor's primary account, but for any secondary accounts or service credentials tied to the same access.

Multi-Factor Authentication Gaps

Vendor remote access is a common place to find MFA either missing or inconsistently enforced, sometimes because it was never extended to third parties, sometimes because a legacy connection predates the MFA rollout. Confirming MFA status on every vendor access path — not just internal ones — is a basic but frequently skipped check.

Remote Engineering Access

Beyond general remote access, many vendors have direct engineering-level access to configure PLCs, HMIs, or other control system components. This level of access carries proportionally higher risk if compromised, since it can potentially be used to alter control logic — which is exactly the scenario OT incident response has to treat with the most urgency.

Scoping the Compromise

Determine what the vendor access path could actually reach — not just what it's intended for, but what it's technically capable of touching given current network configuration. Review session logs, connection history, and any available network telemetry to establish whether the access was actually used maliciously or only potentially exposed.

Credential Rotation

Once scope is understood, rotate credentials for the implicated vendor access — and communicate directly with the vendor about the process, since re-provisioning access often requires their cooperation. Avoid restoring vendor access with the same credentials under time pressure just to resume normal support operations faster.

Evidence and Session Review

Where session recording or detailed connection logging exists for vendor access, review it specifically for the period in question — what was accessed, what commands or changes were made, and whether activity matches known, legitimate vendor work. Where this logging doesn't exist, that gap is itself worth noting for future readiness work.

Containment Without Disrupting Legitimate Vendor Support

Cutting off vendor access entirely is sometimes necessary, but it can also disrupt legitimate support for equipment you may need functioning normally. Where possible, contain surgically — disabling the specific compromised path or credential rather than every vendor connection into the environment — informed by what the scoping work actually established.

Re-Enabling Access Safely

Before restoring vendor access, confirm credentials are rotated, MFA is enforced, and — where feasible — access is scoped more tightly than before the incident, limited to what's actually needed rather than standing broad access. This is also the point to establish or improve session logging if it didn't exist previously, so the next review doesn't start from the same gap.

Vendor remote access isn't something most organizations can eliminate, and it shouldn't need to be — the goal is making it visible, scoped, and monitored well enough that a compromise is contained quickly rather than discovered late. If a vendor access path is implicated in a current incident, or if you want a clear picture of your vendor remote access exposure before it becomes an incident, our OT Incident Response and Incident Readiness Assessment teams can help.