Remote access is the most common way into operational technology networks, yet many industrial sites still rely on a patchwork of vendor VPNs, remote desktop tools installed by integrators and shared engineering accounts. Security service edge (SSE) and zero trust network access (ZTNA) products, along with OT-specific secure remote access platforms, promise to replace that patchwork with brokered, identity-checked and recorded sessions. This vendor-neutral buyer's guide is for OT security leads, plant engineering managers and procurement teams choosing a remote access solution for industrial control systems. It covers requirements, capability areas, evaluation criteria, questions to ask, red flags and a proof of concept that is safe to run near production. It builds on the joint NCSC-led secure connectivity principles for OT and NIST SP 800-82 Rev. 3. For broader OT platform selection see the OT Security Platform Buyer's Guide.
Key takeaways
- Broker every session. External users should connect to an intermediary in a DMZ that relays the session to the asset, so no OT device is ever reachable directly from outside.
- Connections should start from inside OT. Outbound-initiated connectors avoid inbound firewall rules on the OT perimeter, which is the single biggest difference between modern brokers and a vendor VPN.
- Access should exist only while work is happening. Just-in-time approval tied to a work order, with access switched off afterwards, shrinks the window an attacker can use.
- Identity is the control plane. Named accounts for every vendor technician, phishing-resistant MFA and per-asset authorisation replace shared accounts and long-lived passwords.
- Safety constraints change the evaluation. Latency, offline operation, support for legacy engineering tools and the ability to cut all external access in one action matter as much as security features.
Define requirements
Begin with an inventory of who connects, to what, why and how often. In most plants the list includes OEM support engineers, system integrators, internal control engineers working from home, remote monitoring centres and the vendors of individual skids or packaged units. Record which assets each party needs (an engineering workstation, an HMI, a historian, a PLC through its engineering software), the protocols involved and whether the work is read-only monitoring or can change the process.
| Access pattern | How it works | Fit for OT |
|---|---|---|
| Site-to-site or vendor VPN into OT | Network-level tunnel, often terminated inside the OT network | Poor: broad network reach, inbound rules, hard to see which person did what. The Colonial Pipeline attack began with a legacy VPN account that had never been disabled and had no MFA. |
| Remote desktop or remote support tool installed on an OT host | Agent on the asset calls out to the vendor's cloud | Poor to fair: often unmanaged, shared credentials, no central approval. Inventory and remove unapproved tools. |
| Jump host in the DMZ | Users connect to a hardened host, then onward to OT | Fair: works with legacy tools, but needs strong identity, session recording and patching of the jump host itself |
| SSE or ZTNA broker with OT connector | Identity-aware cloud or on-premises broker; connector inside OT or DMZ makes outbound connections | Good when the connector sits in the DMZ and the broker enforces per-asset policy; check data path and dependence on cloud availability |
| OT-specific secure remote access platform | Broker plus approval workflow, session recording, protocol awareness, often deployable fully on premises | Good for vendor-heavy sites; check scale, identity integration and how it fits enterprise SSE |
- Cloud or on premises: a cloud-delivered SSE broker simplifies operations and gives consistent policy with IT, but the plant then depends on internet connectivity and the provider's availability for remote support. Sites with strict isolation requirements, or regulated critical infrastructure, often need an on-premises broker or a hybrid with a local fallback.
- Small vs large estates: a single site with a handful of vendors may need only a hardened DMZ broker with recording and approvals. A multi-site operator needs central policy, delegated administration per site, and integration with the enterprise identity provider and SOC.
- Who owns it: agree whether IT, OT engineering or a joint team owns the broker. Ownership gaps lead to unpatched brokers and unreviewed vendor accounts.
Capability areas
| Capability area | What good looks like | Illustrative weight |
|---|---|---|
| Architecture and exposure | Outbound-only connectors, broker components in the DMZ, no inbound ports to OT, support for the zone and conduit model in ISA/IEC 62443-3-2 | 15% |
| Identity and authentication | SSO with the enterprise identity provider and vendor identity federation, phishing-resistant MFA (FIDO2 or smart card), named accounts only, automatic disablement of dormant accounts | 15% |
| Authorisation and just-in-time access | Per-asset and per-protocol policy, time-boxed access tied to an approved request or work order, approval by the site owner, optional dual control for high-impact actions | 15% |
| Session control and recording | Live monitoring, the ability to terminate a session, video or keystroke recording for RDP and VNC, file transfer controls with malware scanning | 15% |
| OT compatibility | Works with vendor engineering software, legacy operating systems and industrial protocols without agents on controllers; acceptable latency for HMI use | 10% |
| Logging and SOC integration | All connections logged with user, asset, time and approval reference; export to SIEM and OT monitoring; high-priority alert for break-glass use | 10% |
| Resilience and isolation | One-action kill switch for all external access per site, local operation if the cloud service is unreachable, documented break-glass path | 10% |
| Product security of the broker | Published vulnerability handling, rapid patches, hardened appliance or service, ISA/IEC 62443-4-1 or 4-2 certification where offered | 10% |
Fitting OT access into enterprise SSE
Many organisations already run an SSE or ZTNA service for IT users and want to extend it to plants. That can work, but check four things before assuming the IT platform is enough.
- Connector placement: the connector must sit in the OT DMZ, not on the enterprise network with a route into control zones, and it must only reach the specific assets in its policy.
- Policy granularity: IT policies are usually per application; OT needs per asset, per protocol and per time window, with approvals by people who understand the process.
- Change control: a policy change in the cloud console can open a path into a plant, so treat OT access policy changes as engineering changes with review and rollback.
- Separation of failure: an outage or compromise of the enterprise SSE tenant should not take away the plant's ability to isolate itself or to get urgent local support. NCSC's secure connectivity principles call for an isolation plan and for logging and monitoring of all connectivity.
Where identity fits
OT remote access fails most often through identity: shared vendor accounts, passwords written on a support contract, dormant accounts for engineers who left years ago, and service accounts used by remote monitoring tools. ATT&CK for ICS tracks these paths as T0822 External Remote Services, T0886 Remote Services and T0859 Valid Accounts. Require the vendor to show how each technician is individually identified, how their employer's leavers process reaches your broker, and how machine credentials used by connectors and monitoring tools are stored and rotated. See the Identity for OT Environments Guide and the OT Third-Party and Integrator Access Guide.
Evaluation criteria
| Criterion | Evidence to request | Example pass threshold |
|---|---|---|
| No inbound exposure | Network diagram and firewall rules for the reference deployment | Zero inbound rules from the internet or enterprise network into OT zones |
| MFA strength | Supported factors for staff and third parties | Phishing-resistant MFA available and enforceable for every external user, as joint CISA, FBI, EPA and DOE guidance recommends for OT remote access |
| Just-in-time workflow | Demonstration of request, approval, expiry and audit | Access expires automatically; approver is the asset owner or shift lead, not the requester |
| Session evidence | Sample recording and log export | Recording searchable by user, asset and time; logs carry the approval reference |
| Isolation | Demonstration of a site-wide external access cut-off | All external sessions to a site terminated and blocked in one action, within minutes |
| Legacy support | Compatibility list for engineering tools and operating systems on site | Required tools work through the broker without installing agents on controllers or unsupported hosts |
| Broker security | Vulnerability disclosure history, patch cadence, secure development evidence | Critical fixes available promptly with advisories; broker update does not require plant downtime |
For a reusable scoring sheet, see the Buyer's Guide Methodology and Scoring Template. For IT-side remote access patterns, see the Secure Remote Access Beyond VPN Guide.
Questions to ask vendors
- Where does each component sit in a Purdue or zone and conduit design, and which direction does every connection go?
- What happens to remote support if your cloud service or our internet link is down, and what is the local fallback?
- How do third-party technicians authenticate? Can we federate with their employer's identity provider and still enforce our own MFA and expiry?
- How is access tied to a work order or change ticket, and can approval be restricted to the site owner?
- Which protocols and tools are supported natively (RDP, VNC, SSH, HTTPS, vendor engineering software), and which need a jump host?
- Can we stop all external access to a site in one action, and how is that tested?
- How are files transferred into OT through the platform, and are they scanned and logged?
- What are the broker's own security credentials, such as connector keys and certificates, and how are they rotated?
- What is your vulnerability history for the broker and connectors, and do you hold ISA/IEC 62443-4-1 or 4-2 certification?
- How do you handle obsolete assets? NCSC guidance says obsolete products should be treated as untrusted and reached only through compensating controls such as a hardened jump host.
Red flags
- A design that needs inbound firewall rules into OT or places the broker inside a control zone.
- Shared or group vendor accounts presented as a convenience feature.
- Agents required on PLCs, safety systems or unsupported hosts to make the product work.
- No session termination or recording for interactive sessions to HMIs and engineering workstations.
- Total dependence on a cloud service with no tested local fallback for urgent support.
- A per-vendor tunnel model that recreates the VPN sprawl the NCSC guidance warns against, instead of one hardened path in the DMZ.
- Silence on the broker's own vulnerabilities: remote access products are prime targets; see the Edge Device Security Guide.
Proof of concept
Run the pilot in a test or non-critical zone first, with OT engineering present and a change approved under your management of change process. Never test new access paths directly against safety instrumented systems.
- Agree scope and success criteria: choose one site, two or three vendors, and representative assets such as an engineering workstation, an HMI and a historian.
- Deploy in the DMZ: place the connector or broker in the OT DMZ, confirm only outbound connections are needed, and document every firewall change. Keep the existing access path available but monitored.
- Onboard named users: federate or create individual accounts for each vendor technician, enforce phishing-resistant MFA, and set access to expire.
- Run real maintenance tasks: have vendors carry out routine, approved work through the broker. Measure latency, tool compatibility and how often engineers need workarounds.
- Test controls: request and approve a just-in-time session, terminate a live session, transfer a test file, and confirm recordings and logs reach the SIEM or OT monitoring platform.
- Test isolation and rollback: trigger the site-wide cut-off and confirm every session drops, then restore. Confirm you can revert to the previous access method within an agreed time if the pilot affects operations.
- Decommission the old path: for each vendor that passes, remove their VPN account or installed remote tool, and confirm with a network scan and log review that it is gone.
Measure after go-live: percentage of remote sessions brokered and recorded, number of inbound rules into OT zones (target zero), number of active vendor accounts versus approved work orders, accounts unused for 90 days and disabled, median time to approve an urgent request, and time to complete a site-wide isolation drill. Review recordings for a sample of high-impact sessions each month, and alert the SOC at the highest priority on any use of a break-glass account, as the NCSC principles recommend.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev. 5 | AC-17, AC-17(1), AC-17(3), AC-17(4), MA-4, MA-4(1) | Remote access, monitoring, managed access control points, privileged remote commands, non-local maintenance and its logging |
| NIST SP 800-53 Rev. 5 | IA-2(1), IA-2(2), AC-2(3), AU-14, SC-7 | MFA, disabling accounts, session audit, boundary protection |
| NIST CSF 2.0 | PR.AA-03, PR.AA-05, PR.IR-01 | Authentication, managed permissions, protection from unauthorised logical access |
| ATT&CK for ICS v20 | T0822, T0886, T0859, T0883 | External remote services, remote services, valid accounts, internet accessible devices |
| ISA/IEC 62443 | 3-2 zones and conduits; 3-3 system requirements; 4-1 and 4-2 product security | Placing the broker as a conduit control and assessing the product's own security |
Standards and references
- NCSC: Secure connectivity principles for operational technology
- NIST: SP 800-82 Rev. 3 Guide to Operational Technology (OT) Security
- CISA: Primary Mitigations to Reduce Cyber Threats to Operational Technology
- ISA: ISA/IEC 62443 Series of Standards
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
- MITRE ATT&CK for ICS: T0822 External Remote Services
How NHI Mgmt Group can help
We provide independent requirements, RFP and evaluation support. Browse vendors in our products directory or contact us.
Related NHI Mgmt Group resources: OT Security Platform Buyer's Guide · Identity for OT Environments Guide · OT Network Segmentation, Purdue Model and IEC 62443 Zones and Conduits Guide · Secure Remote Access Beyond VPN Guide · OT Security Guide