OT Remote Access vs IT VPN: Why Plants Need a Different Access Model

An IT remote access VPN was built to put a trusted employee on the corporate network, and that is exactly the outcome a plant cannot afford when the person at the other end is a contractor connecting to a controller that moves valves. Many industrial sites still reach their control systems through the same VPN concentrator that serves office staff, with a few extra firewall rules and a vendor account bolted on. This guide compares that inherited IT model with a purpose-built OT remote access model: the assumptions each makes, the threats each is exposed to, how each fails, and how to decide which access path a given user, vendor or machine should get. It is written for OT security leads, control engineers, IT network teams who own the VPN, and assessors reviewing remote access under IEC 62443, NERC CIP or NIST SP 800-82. For the full reference architecture and rollout, read the OT Remote Access Guide; this page concentrates on the decision between the two models. Sources were checked on 14 November 2026.

Key takeaways

• A VPN grants a network, OT access should grant a task. The IT VPN places the remote device on a routed subnet; the OT model brokers one session to one named asset for one approved job, then ends it.
• The failure costs are different in kind. A compromised IT VPN leads to data theft and ransomware; the same foothold in a plant can reach safety and availability, which is why the 2026 joint secure connectivity principles call for outbound-only, brokered connections through a DMZ.
• The gateway itself is the target. Edge VPN appliances have been mass exploited, and CISA has told defenders to assume persistence can survive a factory reset; in OT, that appliance must never sit in front of controllers directly.
• Vendors are the main OT remote access population. Integrators, OEMs and service firms need per-job approval, live supervision and an off switch, which a standing VPN account does not give you.
• Keep the VPN where it fits. A VPN with phishing-resistant MFA can remain the transport into the IT side or the DMZ; the mistake is letting it terminate inside the control network.

The short answer

Use the IT VPN for what it does well: giving managed corporate devices encrypted access to office applications. Do not use it as the access path into Purdue Levels 0 to 3. For any human touching OT assets, require a brokered session that terminates in an OT DMZ (often called Level 3.5), is initiated outbound from the OT side, needs approval for each job, is recorded, and can be killed by the site. For machine-to-machine data, prefer one-way or brokered flows over a tunnel. If you can only fund one change this year, stop VPN sessions from routing directly into the control network.

Why the IT VPN model breaks in a plant

The VPN design rests on four assumptions that do not hold on the plant floor.

• Assumption 1: the endpoint is managed. Corporate VPNs check device posture because they expect a company laptop. OT remote users are frequently third parties on their own hardware. The joint principles stress "browse down": the device used to administer a system should be at least as trusted as the system itself. A contractor laptop fails that test by default.
• Assumption 2: the network beyond the tunnel can absorb a mistake. In IT, a remote user scanning a subnet is noisy but rarely dangerous. In OT, a broadcast storm, an unexpected protocol write or a misdirected firmware download can stop a line or trip a safety function.
• Assumption 3: access can be standing. IT VPN groups are granted once and reviewed annually. OT vendors connect a few times a year, so a standing account is dormant most of its life, which is when credentials get reused or leaked unnoticed.
• Assumption 4: the gateway can be patched promptly. CISA's Emergency Directive 24-01 on Ivanti Connect Secure required updates within 48 hours of release and a rebuild of affected devices. That cadence is normal for IT edge kit but alarming when the same appliance is the only door into a control system.

Split tunnelling is a fifth, quieter problem. MITRE ATT&CK for ICS notes under External Remote Services (T0822) that adversaries look for point-to-point VPNs at trusted third parties and remote support connections that use split tunnelling, which bridge the vendor's internet connection and your control network at the same moment.

Threat model for each

IT VPN in front of OT

Entry points: exploitation of the concentrator (ATT&CK T1190 Exploit Public-Facing Application), valid accounts (T1078, and T0859 in the ICS matrix) from phishing or infostealers, and session hijack after MFA. Movement: the routed tunnel allows Remote Services (T0886) straight to engineering workstations, HMIs and historians. Evidence: in the 2015 Ukraine power grid attack, MITRE records that Sandworm Team used valid accounts taken from a domain controller to reach the VPN that grid operators used. In 2024, the Ivanti Connect Secure exploitation showed that a compromised gateway harvests every credential typed into it and can hijack authenticated sessions, so MFA at the gateway does not protect what sits behind it.

Purpose-built OT remote access

Entry points: the broker or gateway in the DMZ (still internet-reachable for the vendor side), stolen vendor credentials, and a compromised vendor laptop. Movement: limited to the assets a session is approved for, through an intermediate system that the attacker must also beat. Residual risks: the broker becomes tier zero; approvals can be rubber-stamped; and recorded sessions are only useful if someone watches high-risk ones live. The model shrinks blast radius, it does not remove the need to harden and monitor the broker itself. See the guidance on Securing the OT remote access platform itself.

Architecture in words

IT VPN pattern. A remote client authenticates to a concentrator at the corporate edge, receives an address from a VPN pool, and routes through firewalls into the corporate network. To reach OT, an extra rule permits that pool to the OT subnet or an OT jump host. The OT firewall sees corporate addresses, not individual vendors, and the session ends whenever the client disconnects.

OT model pattern. The remote user reaches a broker in the IT/OT DMZ, authenticates with phishing-resistant MFA, and requests a specific asset. A connector inside the OT zone has already opened an outbound connection to that broker, so no inbound port on the OT firewall is listening. An approver at the site, usually the shift lead or control engineer, releases the session for a time window. The broker relays a protocol session (RDP, SSH, HTTPS to an HMI, or a vendor engineering protocol) to an intermediate system in the DMZ or a second jump host inside OT, with clipboard and file transfer restricted. The session is recorded and the site can terminate it. This matches the joint principles' instruction to centralise remote access through a hardened DMZ gateway rather than building a VPN endpoint per third party, and NERC CIP-005-7 R2, which requires an Intermediate System, encryption that terminates there, and multi-factor authentication for Interactive Remote Access.

Both patterns may use a VPN as transport. The difference is where trust ends: in the OT model the VPN, if used, lands in the DMZ and the broker decides what happens next. Data diodes and unidirectional gateways can carry historian and telemetry data out without any inbound path; see the Data Diodes and Unidirectional Gateways Guide.

Decision criteria

Decide per access population and per asset, not once for the whole site.

Small sites (a water utility or a single plant with no OT team) often cannot run a full broker stack. The minimum viable version is: no VPN termination inside OT, a single hardened jump host in a DMZ, phishing-resistant MFA, vendor accounts disabled by default and enabled per call, and screen sharing supervised by a local operator. CISA, FBI, EPA and DOE's Primary Mitigations to Reduce Cyber Threats to OT accept a VPN over a private IP connection with strong authentication where remote access is essential, combined with least privilege and disabling dormant accounts. Large estates with dozens of sites and hundreds of vendors should centralise on one brokered platform, integrate approvals with the maintenance work order system, and feed session logs to the OT SOC.

Failure modes of each model

• VPN: the forgotten account. The Colonial Pipeline attack started from a legacy VPN profile that was no longer used, had never been disabled and lacked MFA. The pipeline stopped as a precaution because the company could not be sure how far the intrusion reached, which is the OT cost of a flat trust model.
• VPN: gateway compromise treated as an IT ticket. ED 24-01 required factory reset, rebuild, and revocation of certificates, keys and passwords, and told agencies to assume domain accounts tied to the product were compromised. If that gateway also fronted OT, every OT credential that crossed it needs the same treatment.
• VPN: the vendor's own tunnel. An OEM installs a cellular router or permanent site-to-site VPN for "support", bypassing the corporate path entirely.
• OT model: broker as single point of failure. If the broker is down during an incident and no tested fallback exists, engineers improvise an unmanaged path. The joint principles ask for an isolation plan, including contract terms that let you switch a vendor from remote to on-site support.
• OT model: approval fatigue. Approvers who release every request without checking the work order give the appearance of control with none of the substance.
• OT model: recordings nobody reviews. Recording is evidence after the fact; it does not stop a harmful command unless high-risk sessions are monitored live.

Controls that close the gap

• Brokered, outbound-only sessions: the joint principles state that connections with the OT environment should be initiated outbound from within it, so the OT perimeter has no inbound exposure.
• Per-job approval and time windows: tie each session to a work order, asset list and end time; expire access automatically. This is just-in-time access in OT terms.
• Determine and disable vendor sessions: NERC CIP-005-7 R2.4 and R2.5 require methods to determine active vendor remote access and to disable it, for both interactive and system-to-system access. Treat this as good practice even outside the electricity sector.
• Recording and live supervision: record every third-party session and require a local observer for writes to controllers or safety systems.
• Credential injection: vendors authenticate as themselves to the broker; the broker injects vaulted credentials to the target so vendors never learn shared OT passwords. See the Privileged Access Management Guide.
• Gateway hardening and replaceability: treat the broker and any residual VPN as tier zero, patch within days, and keep a rebuild runbook. ED 24-01 is a useful model for what a rebuild involves.
• Manual operation fallback: CISA's primary mitigations include practising and maintaining the ability to operate OT systems manually, which removes the pressure to keep a risky remote path alive during an incident.

Worked scenario: a packaging plant with three access populations

A mid-sized food packaging plant has a corporate VPN with MFA. Today, a VPN group called OT-Support routes to the plant's engineering workstation subnet. Its members are four internal control engineers, a PLC integrator, a robot OEM and a historian vendor.

1. Internal engineers keep the corporate VPN to reach the IT network, then launch a brokered session from a privileged access workstation to the DMZ jump host and onward to the engineering workstation. Writes to PLCs need shift lead approval.
2. PLC integrator loses VPN membership. They request sessions through the broker against a work order, with a two-hour window, credential injection and live observation by an engineer when downloading logic.
3. Robot OEM had a cellular router in the robot cell. It is removed; the OEM uses the same broker, restricted to the robot controller's engineering interface. The contract is amended to allow on-site attendance if the broker is unavailable.
4. Historian vendor needs data, not control. Telemetry is replicated to a DMZ historian through a one-way flow; the vendor reaches the DMZ copy only.
5. The OT-Support VPN group is deleted, and the firewall rule from the VPN pool to the OT subnet is removed and alarmed if it reappears.

The result: the corporate VPN still exists, but no VPN session terminates inside OT, every vendor action is attributable, and the plant can stop any session itself.

Where identity fits

Most VPN-to-OT exposure is an identity problem: shared vendor logins, accounts that outlive contracts, OT domain trusts with IT, and service accounts used by remote support tools. Give every remote person a named identity at the broker, keep OT target credentials in a vault, and give machine-to-machine flows their own scoped identities rather than a human VPN account. The Identity for OT Environments Guide covers OT directory design, and the Remote Access Identity Guide covers MFA and session identity across remote access generally.

Migration plan from VPN to brokered OT access

1. Discover every path. Export VPN group memberships and firewall rules from VPN pools to OT, and walk the plant for cellular routers, modems and vendor tools on HMIs. Use OT network monitoring to spot unexpected remote protocols.
2. Remove the worst exposure first. Disable dormant VPN accounts, remove internet-exposed OT devices, and require phishing-resistant MFA on whatever remains.
3. Stand up the broker in the DMZ with outbound-only connectors and recording, and pilot it with internal engineers on non-critical assets.
4. Migrate vendors one at a time, starting with those touching safety-relevant assets. Run old and new paths in parallel for one maintenance cycle, then remove the VPN route for that vendor.
5. Test rollback and isolation. Prove that the site can terminate all remote sessions and operate without them, and that a documented emergency path exists that is still logged.
6. Close the VPN-to-OT rule and add a detection that alerts if any VPN pool address appears on an OT segment.

Detection and measurement

Log broker authentications, approvals, session start and end, and commands where the protocol allows; log VPN pool addresses seen on OT firewalls; and alert on any break-glass use, which the joint principles describe as the highest-criticality alert.

Framework mapping

Practitioner checklist

• List every VPN group and firewall rule that routes into an OT zone, and name an owner for each.
• Make sure no VPN, vendor router or remote tool terminates inside Levels 0 to 3.
• Put a broker or intermediate system in the OT DMZ with outbound-only connectors.
• Require phishing-resistant MFA at the broker for every human, including vendors.
• Tie each third-party session to a work order, asset scope and expiry time.
• Record third-party sessions and observe writes to controllers live.
• Prove the site can identify and terminate all active vendor sessions in minutes.
• Keep a rebuild runbook for the broker and any VPN gateway, including credential revocation.
• Amend vendor contracts to allow on-site support when remote access is suspended.

Standards and references

• ASD ACSC, NCSC and partners: Secure connectivity principles for operational technology
• NIST: SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security
• CISA, FBI, EPA and DOE: Primary Mitigations to Reduce Cyber Threats to Operational Technology
• NERC: CIP-005-7 Cyber Security, Electronic Security Perimeter(s)
• CISA: ED 24-01, Mitigate Ivanti Connect Secure and Ivanti Policy Secure Vulnerabilities
• MITRE ATT&CK for ICS: T0822 External Remote Services

Related NHI Mgmt Group resources: OT Remote Access Guide · Secure Remote Access Beyond VPN Guide · OT Network Segmentation, Purdue Model and IEC 62443 Zones and Conduits Guide · Remote Access Policy Template · Security Service Edge for OT Remote Access Buyers Guide