OT Remote Access Guide: Vendor Access, Jump Hosts and Session Control

Remote access is the most common way attackers reach operational technology, and in many plants it has grown one exception at a time: a vendor modem here, a remote desktop tool there, a VPN account nobody disabled. Each path is a door into systems that move physical equipment. Government guidance from CISA, the Australian Signals Directorate, NERC and an eight-nation group of agencies now converges on the same model: few paths, brokered through a DMZ, strongly authenticated, time-limited, recorded and able to be cut off quickly. This guide turns that model into architecture, vendor access rules, session controls and metrics. It is for OT security leads, control engineers and the IT teams who run the access infrastructure.

Key takeaways

• First ask whether remote access is needed. CISA's OT mitigations tell operators to reassess the risk trade-offs of remote access before securing it; some tasks are better done on site or from an alternate control room.
• Never connect directly to an OT asset. Route every interactive session through an intermediate system in a DMZ, then a second jump inside the OT zone, as NERC CIP-005-7 and ASD guidance describe.
• Authenticate every hop. Named accounts, phishing-resistant MFA and separate OT credentials at the internal jump host stop one stolen password from reaching a controller.
• Vendor access is off by default. Enable it per job, for a fixed window, through your own gateway, and disable it automatically when the window closes.
• If you cannot see it, you cannot stop it. Record sessions, monitor in real time for high-risk work, and keep a tested plan to disconnect all remote access quickly.

Why OT remote access is high risk

Remote access in OT serves operators on call, engineers adjusting logic, integrators commissioning systems and equipment makers supporting their machines. Each group has different tools and different reasons to want a persistent connection. The outcome is often many unmanaged paths that bypass the IT/OT boundary.

• Valid accounts are enough: ATT&CK for ICS records T0822 External Remote Services and T0859 Valid Accounts as initial access and persistence routes. No exploit is needed when a VPN account has no MFA. The Colonial Pipeline ransomware attack began with a single unused VPN account and led to a precautionary shutdown of fuel distribution.
• Remote access software is a favoured tool: CISA, the FBI, NSA, MS-ISAC and the Israel National Cyber Directorate warned in their 2023 joint guide that legitimate remote access software, widely used for OT and ICS support, gives attackers easy and broad access to victim systems.
• Exposed devices get found: T0883 Internet Accessible Device covers controllers and HMIs reachable from the internet. CISA's 2023 alert on Unitronics PLCs in water systems told operators to require MFA for all remote access to the OT network, including access from the IT network.
• Remote services enable lateral movement: T0886 Remote Services (RDP, VNC, SSH and vendor tools) lets an attacker who reaches one OT host move to engineering workstations and servers.

For identities in OT more broadly, see the OT and ICS Identity and Access Guide; this guide focuses on the remote path itself.

Reference architecture: two jumps and a DMZ

ASD's guidance on remote access to OT environments (updated March 2023) and the SANS ICS remote access practices describe the same layered design. NERC CIP-005-7 R2 makes the core of it mandatory for in-scope North American power systems: all Interactive Remote Access through an Intermediate System (Part 2.1), encryption to that system (2.2) and MFA (2.3).

1. Managed endpoint: the session starts on an organisation-supplied device or a corporate VDI if personal devices are allowed. ASD advises disabling VPN split tunnelling.
2. VPN or access broker with MFA: the user authenticates with a dedicated remote access account and MFA. CISA recommends phishing-resistant MFA and a private IP connection rather than public exposure.
3. First jump host in the IT/OT DMZ: bound to its own security domain, outside the OT zone, with least privilege. Pre-install the tools the role needs so nothing is downloaded during the session.
4. Second jump host inside the OT zone: the user authenticates again with OT domain credentials and MFA. ASD notes this means two account names, two passphrases and two MFA tokens to reach the OT environment.
5. Role-restricted targets: each jump host reaches only the assets its role manages, enforced by OT domain groups and firewall rules (IEC 62443 zones and conduits).

• Disable redirection: turn off clipboard, drive and printer redirection on remote desktop sessions into the OT zone (ASD and SANS both call this out).
• File transfer through a controlled path: ASD advises downloading patches on site through corporate systems, verifying them and moving them from within the OT environment, not over the remote session. Monitor any file transfer that is allowed.
• Separate jump hosts by population: Dragos recommends different jump hosts for internal staff and external parties so each can be controlled and monitored on its own.
• Idle timeouts: ASD recommends suspending or disconnecting idle jump host sessions after 15 minutes.
• Treat the access stack as tier zero: the broker, jump hosts and their directory are as sensitive as the controllers behind them. Patch them first; ASD lists remote access systems as a patching priority.

Choosing an access pattern

• Small sites: a single VPN with phishing-resistant MFA into one hardened jump host, vendor accounts disabled by default and logs sent off site is a realistic minimum. CISA's primary mitigations put removing internet exposure and default passwords first.
• Large or multi-site estates: centralise and standardise connections (a principle in the 2026 secure connectivity guidance), use a broker with approval and recording, and run a single inventory of every remote path. See the ZTNA Guide for identity-aware access options.

Vendor and third-party access

Vendors and integrators need access to support equipment under warranty, but standing vendor connections are the hardest path to govern. IEC 62443-2-4 sets security programme requirements for IACS service providers and can be written into contracts. NERC CIP-005-7 adds Parts 2.4 and 2.5: entities must have methods to determine active vendor remote access sessions, including system-to-system access, and to disable them.

• Use your gateway, not theirs: require vendors to connect through the organisation's remote access path, not tools they install themselves (Dragos). Monitor traffic for unauthorised vendor tools and inspect sites for cellular hotspots and modems (SANS).
• Named individuals: one account per vendor engineer, never a shared company login, so every action is attributable. Tie accounts to a sponsor and an end date.
• Request and approve per job: the vendor requests access for a ticket, an asset list and a time window; operations approves; the account is enabled for that window and disabled automatically. SANS recommends vendor connections stay disabled until needed.
• Least privilege by asset: CISA recommends least privilege by asset and user role. A vendor supporting one compressor reaches that compressor's HMI, not the whole zone.
• Dedicated devices and source restrictions: where the vendor connects directly, SANS suggests dedicated devices, static addresses and firewall allowlisting as a last resort.
• System-to-system access: machine connections from vendor clouds (telemetry, predictive maintenance) count as remote access too. Inventory them, restrict them to the minimum data flow, and make sure you can disable them, as CIP-005-7 Part 2.5 expects.

See the Third-Party Access Guide for contract and lifecycle controls, and the Remote Access Policy Template for policy wording.

Session control: approval, recording and termination

NIST SP 800-53 Rev. 5 frames the controls: AC-17 Remote Access with enhancements for monitoring and control (AC-17(1)), encryption (AC-17(2)), managed access control points (AC-17(3)) and authorising privileged commands remotely only for documented needs (AC-17(4)); MA-4 Nonlocal Maintenance for vendor maintenance sessions; and AU-14 Session Audit for recording.

• Live monitoring: for work that can change logic or safety settings, a site engineer watches the session and can terminate it. See the Privileged Session Management Guide.
• Just-in-time elevation: grant engineering rights only for the window, linked to the change ticket. See the JIT Access Guide.
• Emergency access: plan break-glass access for incidents where the normal broker is down, with its own logging, so staff do not install ad hoc tools under pressure. See the Break-Glass Account Guide.

Where identity fits

Remote access in OT is an identity problem as much as a network one: dormant accounts, shared vendor logins and service accounts used for system-to-system links are the weak points. CISA tells operators to disable dormant accounts. Vault shared device credentials and inject them into sessions so vendors never learn them. See the Identity for OT Environments Guide.

Implementing it in phases

1. Discover every path: combine firewall rule review, passive network monitoring, external exposure scans and site walk-downs to list VPNs, remote tools, modems, cellular routers and vendor cloud links. See the OT Asset Visibility Guide.
2. Remove exposure and dormant access: take OT devices off the internet, disable unused and dormant accounts and remove unapproved remote tools, as CISA's primary mitigations direct. Agree each removal with operations so a needed support path is replaced, not just cut.
3. Stand up the brokered path: build the DMZ and internal jump hosts with MFA, migrate one site or one vendor first, and run old and new paths in parallel for a defined period.
4. Move vendors: migrate vendors to named accounts and per-job approval, then close their legacy connections. Keep the previous path documented but disabled for a short rollback window.
5. Add recording and monitoring: enable session recording, forward logs centrally, and tune alerts with the SOC.
6. Test the kill switch: ASD recommends a plan able to disconnect remote access within 24 hours of detecting malicious activity; many operators aim for minutes. Exercise it with operations and confirm the plant can run without remote support, including manual operation where CISA's guidance calls for it.
7. Assess independently: ASD advises independent assessment of the remote access solution, because penetration tests often stop at the OT boundary. See the OT Penetration Testing Guide.

Detection and measurement

• What to log: VPN and broker authentications (success and failure, source, device); jump host logons at both tiers; session start, end and duration; file transfers; vendor account enablement and disablement; new outbound connections from OT to the internet; remote access protocols (RDP, VNC, SSH, vendor tools) seen on OT segments outside the brokered path.
• What to alert on: remote sessions outside an approved window; logons to OT assets that did not come through the jump host; vendor accounts active without a ticket; remote access tools on OT hosts; honeytoken account use (Dragos suggests honeytokens that alert when used). ASD also recommends a daily report of abnormal logins.

Common failure patterns

• Dormant VPN account without MFA: the single most repeated lesson, as at Colonial Pipeline.
• Vendor tools installed outside change control: always-on remote desktop software or a cellular router on a control panel creates a path nobody monitors.
• One jump, one password: a DMZ jump host that uses the same domain credentials as the IT network lets an IT compromise walk straight into OT.
• Clipboard and drive redirection left on: the jump host becomes a file transfer route for malware.
• System-to-system links forgotten: vendor cloud telemetry and remote monitoring connections are left out of the inventory and cannot be disabled quickly.
• No tested disconnect: when an incident starts, teams discover they do not know every path or what breaks if they cut it. See the OT Incident Response Guide.

Framework mapping

NIST SP 800-82 Rev. 3 (September 2023) is the main US guide to OT security, and NIST has opened a draft Revision 4 for comment. The January 2026 joint secure connectivity principles for OT, led by Canada's Cyber Centre and the UK NCSC with CISA, the FBI and Australian, German, Dutch and New Zealand agencies, set eight goals: balance the risks and opportunities; limit the exposure of your connectivity; centralise and standardise network connections; use standardised and secure protocols; harden your OT boundary; limit the impact of compromise; ensure all connectivity is logged and monitored; and establish an isolation plan. See the NIST SP 800-82 OT Security Guide.

Practitioner checklist

• Inventory every remote path into OT, including modems, cellular routers, remote tools and vendor cloud links.
• Remove internet exposure of OT devices and disable dormant remote access accounts.
• Route all interactive access through a DMZ jump host and a second jump inside the OT zone.
• Require phishing-resistant MFA and separate OT credentials at each hop.
• Give every vendor engineer a named account, disabled by default and enabled per approved job and window.
• Disable clipboard, drive and printer redirection, and control file transfer separately.
• Record privileged sessions and monitor high-risk work live with the ability to terminate.
• Make sure you can see and disable system-to-system vendor connections.
• Exercise a full remote access disconnect with operations at least annually.
• Have the remote access design independently assessed.

Standards and references

• CISA: Primary Mitigations to Reduce Cyber Threats to Operational Technology
• Australian Signals Directorate: Remote access to operational technology environments
• NIST: SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security
• Canadian Centre for Cyber Security: Joint guidance on secure connectivity principles for operational technology
• NERC: CIP-005-7 Summary of Changes (vendor remote access)
• ISA: ISA/IEC 62443 Series of Standards
• CISA: CISA and Partners Release Joint Guide to Securing Remote Access Software
• MITRE ATT&CK: External Remote Services (ICS)

Related NHI Mgmt Group resources: Remote Access Identity Guide · Privileged Access Management Guide · OT Security Guide · Manufacturing Identity and OT Access Guide