Should organisations treat remote vendor access as part of OT governance or separate IT access?

Why remote vendor access belongs in OT governance

Remote vendor access should be governed as an OT control surface, not treated as a normal IT helpdesk channel, because the access path can reach production systems, engineering workstations, historians, PLCs, HMI consoles, or jump hosts that affect physical process outcomes. The practical question is not who owns the ticket, but whether the session can change operating state, safety conditions, or recovery options.

That means the governance model has to account for the full path of access, including sponsor approval, authentication strength, device trust, session scope, and the assets reachable from the remote connection. If the same vendor account can touch both office systems and production systems, the OT side should set the stricter rule set, because the blast radius is determined by the production reach, not the support arrangement.

When organisations separate vendor access into “IT” by default, they often miss the fact that remote support frequently becomes a control dependency for maintenance windows, incident response, firmware work, or emergency troubleshooting. A process that looks administrative on paper can become operationally material the moment it can alter setpoints, bypass alarms, or expose engineering interfaces.

Where the boundary usually fails in practice

OT governance fails when remote access is treated as a convenience layer rather than a production dependency. That failure usually shows up as over-broad vendor accounts, shared credentials, weak session visibility, and unsupported remote tools that bypass normal change control. Third-Party, B2B and Contractor Access Guide is a useful reference point for governing sponsorship, time limits, least privilege, and external identities in a way that maps to actual business exposure.

A second common failure is assuming that vendor access is “just remote access” and therefore belongs with standard IT controls. In OT environments, remote support often lands on systems that bridge into process networks or privileged operational tooling. The OT and ICS Identity and Access Guide is directly relevant because it ties vendor remote access to shared accounts, segmentation, and privileged governance rather than leaving it as a generic access problem.

Attackers also value remote vendor paths because they concentrate trust. A single stolen credential, compromised support portal, abused RMM tool, or over-privileged remote session can become the fastest route from outside the plant to systems that affect production. The lesson from BeyondTrust breach 2024 is that privileged remote access products are not neutral conduits, they are security-critical dependencies that need explicit governance and monitoring.

What good control looks like for vendor sessions

Good OT governance treats remote vendor access as a privileged operational path with clear owners, narrow scope, and recorded evidence. That includes named sponsorship, MFA, device posture checks where feasible, approval tied to a work order or change request, and session controls that limit what the vendor can do once connected. Privileged Session Management Guide is a strong match when the requirement is to broker, record, and constrain high-impact sessions rather than merely authenticate them.

It also means lifecycle discipline. Vendor access should expire, be re-approved when the relationship changes, and be removed when the work ends. If access remains active between maintenance events, it has effectively become standing privilege, even if the original intent was temporary support. The Remote Access Identity Guide helps frame that difference by connecting VPN and remote entry points to MFA, ZTNA, and dormant-account cleanup.

For organisations that want a broader governance pattern, the IAM and IGA Basics guide is useful because it distinguishes authentication, authorization, entitlement review, and access governance, all of which matter when external users can influence production. The key judgement is that OT does not need a separate identity model from first principles, it needs a stricter application of identity governance to operational impact.

Risk and Threat Considerations

Remote vendor access creates exposure because it can collapse the separation between external support and production authority. If the path is over-permissive, poorly monitored, or shared across environments, a compromise of the vendor account can become a compromise of operational systems, with consequences that extend beyond data theft into process disruption or unsafe change.

Failure mechanism: Weak authentication, excessive privilege, poor session control, or an unsegmented support path lets a remote vendor session reach systems that can modify production behaviour or provide a pivot into OT infrastructure.

Impact: The result can be unauthorized configuration changes, unplanned downtime, delayed recovery, or attacker persistence inside an environment where response options are constrained by uptime and safety requirements.

Practitioner Guidance

What to verify: Confirm whether each vendor path can reach a production-impacting asset, not just whether it can log in. If a remote session can alter alarms, recipes, setpoints, firmware, or privileged administrative functions, it belongs in OT governance and should be reviewed with the same seriousness as any other operational control path.

Decision rule: If the vendor session can affect production state, treat it as operational access with OT oversight; if it only supports non-production IT tasks, keep it under IT access governance but preserve evidence that the boundary is real and enforced. The mistake to avoid is classifying access by supplier category instead of by reachable consequence.

Practitioner takeaway: The governance boundary should follow the system the access can influence, not the team that issues the account. When remote vendor access can touch production, it is an OT risk decision first and an IT convenience decision second.

Related resources from NHI Mgmt Group

• When should organisations treat agent output integrations as part of access governance?
• What breaks when organisations treat remote desktop infrastructure like a replacement for proper access governance?
• Should organisations treat PAM as part of IAM governance or as a separate control?
• When should organisations treat third-party cyber ratings as part of vendor risk governance?