OT Secure Remote Access Buyer's Guide: SSE and ZTNA

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

How NHI Mgmt Group can help

We provide independent requirements, RFP and evaluation support. Browse vendors in our products directory or contact us.

Security Service Edge for OT Remote Access Buyers Guide: Evaluating Brokered Access to Industrial Sites