On this page
Short answer: OT remote access means letting someone reach a PLC, HMI, SCADA server or other industrial control system from outside the control network, and it carries a safety dimension that office remote access does not. NIST and CISA both say a remote session should be justified, scoped to the business need, and routed through a jump host or broker outside the control zone, never tunneled straight into it. Electric utilities and pipeline operators face a harder floor: NERC and TSA make multi-factor authentication a compliance requirement, not a recommendation.
Key takeaways
- NIST SP 800-82r3 (section 6.2.10, September 2023) says OT remote access should be provided only if justified and limited to the business need, should never circumvent or negate safety or security controls, and that multi-factor authentication should be considered.
- CISA, the FBI, EPA and DOE's joint fact sheet (May 6, 2025) tells OT owners to move control assets off the public internet, use a VPN with phishing-resistant MFA, apply least privilege to remote access configuration, and put a demilitarized zone between OT and enterprise IT.
- IEC 62443's zone-and-conduit model treats remote access as one of the conduits most often left overly permissive; a conduit is the only sanctioned path between zones, and vendors that claim IEC 62443 alignment are describing where they terminate that conduit (Dragos, January 8, 2025).
- NERC CIP-005-7 makes this a hard requirement for electric utilities: interactive remote access to high- and medium-impact BES Cyber Systems must route through an Intermediate System outside the Electronic Security Perimeter, with two-factor authentication.
- The 2021 Oldsmar, Florida water treatment incident (CISA advisory AA21-042A) is the reference case for unmanaged OT remote access: CISA says actors likely exploited poor password security and an outdated operating system, and that desktop-sharing software such as TeamViewer may have been used to gain access, a detail CISA states it could not confirm.
Why OT remote access is a different problem than IT remote access
An IT remote access failure usually costs data or uptime. An OT remote access failure can change what a physical process does, which is why NIST addresses it separately from general remote access in SP 800-82r3, its Guide to Operational Technology Security (NIST SP 800-82r3, section 6.2.10, September 2023). The guidance is narrower than a typical IT policy: remote access should be provided only if justified and limited to what the business need requires, and it should not circumvent or negate the safety and security controls already built into the environment.
That second point does real work. Many OT architectures use hierarchical levels, commonly described through the Purdue model, to separate the process control network from the enterprise network above it (NIST SP 800-82r3, section 6.2.10). A remote access design that tunnels straight from the internet to a lower Purdue level gives up that separation regardless of how strong the encryption is. Claroty's own guide to OT secure remote access makes the same point about conventional VPN deployments: they create direct connectivity to lower levels of the control hierarchy and "break the Purdue Model of control hierarchy" the segmentation was built to preserve (Claroty, ultimate guide to OT secure remote access, revised July 1, 2026).
Vendor and integrator maintenance access is its own case inside this problem. NIST lists RDP, SSH, screen sharing, modems and VPNs as the usual techniques for temporary vendor access, and says the same secure-connection procedures still apply, backed by a documented request and approval process rather than a standing connection (NIST SP 800-82r3, section 6.2.10). Standing access is the thing an incident review finds afterward, not the thing anyone approved for that day.
Regulations and standards that shape OT remote access
No single framework governs OT remote access end to end. Four different bodies set requirements that apply depending on your sector and how strictly you want to be held to them.
| Framework | Applies to | What it requires for remote access |
|---|---|---|
| NIST SP 800-82r3 | Any OT/ICS environment (guidance, not a legal mandate outside federal systems) | Remote access must be justified and limited to business need, must not circumvent safety or security controls, and MFA should be considered; vendor maintenance access follows a documented request and approval process (NIST SP 800-82r3, section 6.2.10, September 2023) |
| CISA, FBI, EPA and DOE joint fact sheet | Any OT owner or operator (guidance) | Move OT assets off the public internet onto a private IP network, use VPN with a strong password and phishing-resistant MFA, apply least privilege to remote access configuration, disable dormant accounts, and separate OT from enterprise IT with a DMZ (CISA joint fact sheet, May 6, 2025) |
| IEC 62443 zones and conduits | Any industrial automation and control system (international standard; many products build to it) | Every asset belongs to a security zone; a conduit is the only sanctioned communication channel between zones, and remote access is one of the conduits organizations most often leave too permissive if it is not deliberately scoped (Dragos analysis of ISA/IEC 62443, January 8, 2025) |
| NERC CIP-005-7 | Electric utilities' high- and medium-impact BES Cyber Systems (mandatory, enforceable) | Interactive remote access must route through an Intermediate System outside the Electronic Security Perimeter; two-factor authentication is required for all interactive remote access sessions; a newer requirement (R3) covers detecting and terminating vendor-initiated remote connections (NERC CIP-005-7, verified via ConsoleWorks and LoginTC compliance summaries, 2022 and current) |
| TSA pipeline security directives | Pipeline owners and operators (mandatory, enforceable) | Multi-factor authentication and access control for OT remote access, under a performance-based approach that allows compensating controls where legacy equipment genuinely cannot support MFA (Dragos analysis of Security Directive Pipeline-2021-02C, August 1, 2022; the directive has since been reissued, and current versions keep the MFA requirement) |
Watch out: TSA's allowance for "compensating controls" on legacy OT equipment is not a blanket exemption. It requires the equipment to genuinely be unable to support MFA and expects an alternative control in its place, not a written justification for skipping access control altogether.
What OT remote access requires
These requirements come from the OT and ICS criterion group in our remote access evaluation criteria, plus the general access-model, third-party-access and session-control groups that apply to any remote access product (content-plan/criteria/remote-access.yaml).
| Requirement | Why it matters in OT |
|---|---|
| DMZ or jump-host deployment, not a direct tunnel to the control network | Keeps the remote session outside the Purdue levels that run the process; a flat tunnel gives a compromised credential the same reach an operator has |
| Legacy and serial protocol support (Modbus, DNP3, OPC, serial-to-Ethernet) | Many PLCs and RTUs predate IP networking; a tool that only speaks HTTP or RDP cannot reach them without a protocol gateway |
| Air-gapped or low-bandwidth site handling | Plants and substations are often offline or on satellite links; a cloud-only broker does not work without a local component |
| Resource-level, not network-level, access | Named-asset access to one HMI or PLC, instead of a route onto the OT subnet, limits what a compromised vendor credential can reach |
| Vendor access without a directory account | Contractors and equipment vendors should not need an Active Directory account to reach a control system for a single maintenance window |
| Time-bound, pre-approved vendor sessions | Standing vendor access is what an incident review finds afterward; a request-and-approval workflow matches NIST's guidance on vendor maintenance access |
| Session recording and live termination | Security and operations teams need to see what a remote session did to a control system, and stop it mid-session if something looks wrong |
| MFA that works with legacy identity setups | Regulator language (NERC, TSA) treats MFA as close to non-negotiable, with compensating controls reserved for equipment that genuinely cannot support it |
Deployment patterns: jump host, identity broker or hardware-enforced gateway
Three architecture patterns show up repeatedly in how OT remote access vendors describe their own products, and each answers the Purdue-level question differently.
Conventional: DMZ, VPN and jump host. Waterfall Security describes the standard IT/OT remote access stack plainly: "two-factor authentication, a demilitarized zone, a virtual private network, a jump host, and a next-gen firewall" (Waterfall Security, secure remote access guide, June 16, 2025). The jump host is the control point; the user connects to it, and only the jump host reaches into the OT network. Waterfall's own critique of this pattern is that the jump host itself is an internet-facing target, what it calls a "server pivot" risk once an adversary compromises it. NERC's CIP-005-7 requirement effectively mandates a version of this pattern for electric utilities, calling the control point an Intermediate System rather than a jump host, with two-factor authentication required at that boundary.
Zero-trust identity broker. Several OT-specific vendors replace the jump host with a broker that authenticates the user and authorizes access to one named asset rather than a network segment. Cisco's Secure Equipment Access, part of Cyber Vision, is built for deployment "in the lowest Purdue levels" and supports assets behind NAT boundaries without exposing their private IPs upward, while enforcing MFA through Cisco or third-party identity providers and recording sessions for audit (Cisco Secure Equipment Access solution brief, November 21, 2025). Claroty's xDome Secure Access applies what it calls "continuously assessed, explicitly calculated adaptive trust," isolating sessions to specific assets such as HMIs and PLCs to prevent lateral movement (Claroty, revised July 1, 2026). Cyolo takes an agentless approach for third-party access and can deploy fully offline, keeping "sensitive data and assets secure inside your trusted boundaries at all times," which matters for sites with no reliable path to a cloud broker (Cyolo, ot-ics remote access page, fetched September 2026). Xage runs a distributed security fabric that it says "distributes credentials across nodes, preventing attackers from deriving usernames or passwords even if a node is compromised," and extends access control down to Layer 1 and 2 assets like PLCs and RTUs rather than stopping at the DMZ (Xage, OT remote access page, fetched September 2026).
Hardware-enforced unidirectional. Waterfall's own product, HERA, uses paired inbound and outbound gateways specifically to prevent an attack from pivoting from the internet into OT systems, which it positions as the answer to the server-pivot risk it identifies in the conventional pattern (Waterfall Security, June 16, 2025). This pattern trades flexibility for a narrower, hardware-defined attack surface, and tends to show up at sites where safety requirements rule out anything that could be reconfigured remotely.
Admin tip: Whichever pattern you run, test what happens to the OT process if the remote access path itself fails. NIST's OT security guidance and the CISA fact sheet both assume the plant can be operated manually if remote or even local IT connectivity goes down; that capability has to be rehearsed, not assumed.
What OT remote access vendors look like
These are illustrations of the requirement categories above, not a ranking; a scored comparison against these criteria is planned once the category's reviews are indexed. Vendors that build specifically for OT tend to name at least one of: Purdue-level awareness, protocol coverage down to serial and legacy devices, and named compliance frameworks.
| Vendor | Access model | What it names specifically |
|---|---|---|
| Claroty (xDome Secure Access) | Zero-trust identity broker, session isolated to named assets | Purdue-model segmentation preserved; full session logging and real-time termination |
| Cisco (Secure Equipment Access) | ZTNA broker deployed at the lowest Purdue levels | MFA via Cisco or third-party IdPs, session recording, NAT-aware deployment behind industrial assets |
| Waterfall Security (HERA) | Hardware-enforced unidirectional gateway pair | No named IEC 62443 discussion in the guide text, but explicit NERC CIP framing for medium-impact sites |
| Cyolo | Agentless, identity-based, offline-capable broker | Deployable fully on-prem or offline; retrofits MFA onto legacy systems without forced upgrades |
| Xage | Distributed security fabric with per-node credential distribution | Explicitly names NERC-CIP, IEC 62443 and TSA compliance on its own product page |
Vendor privileged access platforms built primarily for IT, such as BeyondTrust Privileged Remote Access and Imprivata Vendor Privileged Access Management, are also used to govern contractor access in some OT environments where the vendor population overlaps with IT vendor management; our privileged access management best practices guide covers the equivalent controls for that IT-side case. Check protocol and Purdue-level support explicitly before assuming an IT-first product extends cleanly into the control network.
Questions to ask vendors
- Where does the session terminate: at a jump host, a broker outside the control network, or does it tunnel to the endpoint directly?
- Which Purdue levels does the product support without an on-site gateway or collector?
- What legacy or serial protocols does it speak natively, and what requires a separate protocol gateway?
- Can it deploy and operate fully offline, and for how long, if the site loses internet connectivity?
- Does a vendor or contractor need a directory account, or can access be scoped and time-boxed without one?
- Is session recording continuous, and who can watch a live session or terminate it?
- What MFA methods does it support on OT-adjacent identity systems that cannot run a modern authenticator?
- Does the vendor name IEC 62443, NERC CIP or TSA compliance directly, or only general "regulatory compliance" language?
- What happens to an active session if the broker or gateway itself loses connectivity: does access fail open or fail closed?
- How is a vendor's access reviewed and revoked at the end of an engagement?
Mistakes to avoid
- Treating OT vendor access like an employee VPN account. NIST's vendor maintenance guidance calls for a documented request and approval process for each engagement, not a standing credential (NIST SP 800-82r3, section 6.2.10).
- Letting the remote access tunnel bypass Purdue-level segmentation. Both Claroty and Waterfall describe this as the core weakness of conventional VPN access to OT: the tunnel reaches lower levels the segmentation was built to protect.
- Skipping MFA because the environment is "too legacy." TSA's own directive allows compensating controls, not an exemption; it still expects an equivalent control in place (Dragos analysis of SD Pipeline-2021-02C, August 1, 2022).
- Sharing one remote access credential across a team. CISA's advisory on the Oldsmar incident names poor password security among the weaknesses the actors likely exploited (CISA advisory AA21-042A, February 11, 2021). Treat every remote access credential, shared or not, as a standing risk that needs rotation and review, not a one-time setup step.
- Assuming a jump host is the end of the work. Waterfall's critique of the conventional pattern is that the jump host itself becomes an internet-facing target; it still needs its own hardening and monitoring.
- Picking a broker with no offline mode for a site that cannot reliably reach the cloud. Several vendors in this space, including Cyolo and Xage, build explicitly for on-prem or offline operation because plant connectivity cannot be assumed.
FAQ
What is OT remote access?
OT remote access is remote access to operational technology: PLCs, HMIs, SCADA servers, RTUs and similar industrial control systems, rather than office IT servers and applications. It carries a safety dimension general remote access tools are not designed around, which is why NIST addresses it in its own section of SP 800-82r3.
Is a VPN safe enough for OT remote access?
A VPN alone authenticates a user to a network, not to a specific asset, and several OT vendors describe conventional VPN access as breaking the Purdue-model segmentation between IT and the control network. CISA's May 2025 fact sheet still recommends VPN as part of a secure design, but only with phishing-resistant MFA, a private IP network instead of a public-internet-facing device, and a DMZ separating OT from enterprise IT.
Does OT remote access need multi-factor authentication?
NIST SP 800-82r3 says MFA should be considered for OT remote access, which is guidance rather than a mandate. NERC CIP-005-7 and TSA's pipeline security directives make it a compliance requirement for electric utilities and pipeline operators respectively, with TSA allowing compensating controls only where equipment genuinely cannot support MFA.
What is the IEC 62443 zone-and-conduit model?
IEC 62443 groups industrial assets into security zones that share common security requirements, and defines a conduit as the only sanctioned communication channel between two zones. Remote access is one of the conduits organizations most often leave too permissive, so IEC-aligned designs treat it as a controlled pathway with its own access rules rather than a general-purpose network route.
How should vendors and contractors get remote access to OT systems?
NIST's guidance calls for a documented request and approval process for each vendor maintenance session rather than a standing connection, using techniques such as RDP, SSH, screen sharing or VPN under the same secure-connection procedures as any other remote access. Vendor-specific platforms add identity verification at onboarding, access scoped to named systems and time windows, and session recording, which a shared directory account does not provide on its own.
Does NERC CIP require remote access controls?
Yes, for electric utilities' high- and medium-impact BES Cyber Systems. CIP-005-7 requires interactive remote access to route through an Intermediate System outside the Electronic Security Perimeter, with two-factor authentication on every session, and a newer requirement covers detecting and terminating vendor-initiated remote connections.
What happened in the Oldsmar water treatment incident?
In February 2021, unidentified actors gained unauthorized access to the SCADA system at a Florida water treatment facility and briefly increased the sodium hydroxide dosing setpoint before an operator caught and reversed it. CISA's advisory says the actors likely exploited poor password security and an outdated operating system, and that desktop-sharing software such as TeamViewer may have been used to gain access, though CISA states that detail could not be confirmed (CISA advisory AA21-042A, February 11, 2021).
Bottom line
Start from where the remote session terminates, not from the product name: a design that stops at a jump host or broker outside the Purdue level it protects meets the spirit of NIST's guidance, and a design that tunnels straight to the control network does not, regardless of the encryption in between. If you operate under NERC CIP or a TSA pipeline directive, MFA and a documented control point are not optional, so start the shortlist with products that name those frameworks directly rather than general "regulatory compliance" language.
Next step: compare general-purpose remote access products against the same criteria on the remote access software hub, or filter by size and constraints on the shortlist.
Sources (11)
- Guide to Operational Technology (OT) Security, NIST SP 800-82r3, September 2023, https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-82r3.pdf (section 6.2.10)
- Primary Mitigations to Reduce Cyber Threats to Operational Technology, joint fact sheet, CISA, FBI, EPA and DOE, May 6, 2025, https://www.cisa.gov/resources-tools/resources/primary-mitigations-reduce-cyber-threats-operational-technology (accessed September 28, 2026)
- ISA/IEC 62443 Explained: OT Cybersecurity Standards, Dragos, January 8, 2025, https://www.dragos.com/blog/isa-iec-62443-concepts (accessed September 28, 2026)
- CIP-005-7, Cyber Security - Electronic Security Perimeter(s), NERC, https://www.nerc.com/globalassets/standards/reliability-standards/cip/cip-005-7.pdf; requirement content verified via https://consoleworks.com/2022/08/10/interactive-remote-access-meeting-nerc-cip-005-7-r3-compliance/ and https://www.logintc.com/mfa-compliance/nerc-cip/ (accessed September 28, 2026)
- How to Implement the Revised TSA Pipeline Security Directive, Dragos, August 1, 2022, https://www.dragos.com/blog/industry-news/how-to-implement-the-revised-tsa-pipeline-security-directive/ (accessed September 28, 2026)
- The Ultimate Guide to OT Secure Remote Access, Claroty, published July 11, 2023, revised July 1, 2026, https://claroty.com/blog/ultimate-guide-to-ot-remote-access-in-cyber-security (accessed September 28, 2026)
- Secure Remote Access Guide, Waterfall Security, June 16, 2025, https://waterfall-security.com/ot-insights-center/ot-cybersecurity-insights-center/secure-remote-access-complete-guide/ (accessed September 28, 2026)
- Remote Privileged OT Access, Cyolo, https://cyolo.io/remote-privileged-access-for-ot-ics (accessed September 28, 2026)
- OT Remote Access Solution, Xage, https://xage.com/ot-remote-access/ (accessed September 28, 2026)
- Secure Remote Access for Industrial Operations Solution Brief, Cisco, November 21, 2025, https://www.cisco.com/c/en/us/products/collateral/security/industrial-security/secure-remote-access-for-ot-sb.html (accessed September 28, 2026)
- Compromise of U.S. Water Treatment Facility, advisory AA21-042A, CISA/FBI/EPA/MS-ISAC, February 11, 2021, https://www.cisa.gov/news-events/cybersecurity-advisories/aa21-042a (accessed September 28, 2026)