Most OT remote access and historian projects fail at rollout, not design: the brokered path gets built, but the old vendor VPNs, modems and direct historian queries stay open beside it because nobody planned how to move each user, vendor and data consumer across without stopping production. This playbook is for OT security leads, plant engineering and project managers who are replacing ad hoc remote connections with a brokered remote access service and moving enterprise reporting onto a replicated historian in the IT/OT DMZ. It covers the work in order: discovery, operations agreement, the historian replica, the access service, vendor waves, cutover, closing legacy paths and proving the isolation plan works. It is vendor-neutral. The target architecture (two jumps, session controls, vendor access) is explained in the OT Remote Access Guide; this page is about getting there safely.
Key takeaways
- Move the data consumers before the people. Once reports and dashboards read a historian replica in the DMZ, most IT-to-OT connections have no reason to exist, and the remote access project shrinks to the users who genuinely need interactive access.
- Every legacy path gets an owner and a closure date. A new broker beside an open vendor VPN adds a path; it does not remove risk.
- Roll out by site and by vendor, never everywhere at once. Each wave has an operations sign-off, a parallel period and a documented way back.
- Connections start from inside OT where possible. The NCSC-led secure connectivity principles favour outbound-initiated, brokered and just-in-time connections over open inbound ports.
- The project is not done until isolation is tested. Disconnecting remote access on demand, and running the plant without it, is an acceptance test, not a later exercise.
Phase 0: discovery and the operations agreement
You cannot close what you have not found. Combine firewall rule review, passive network monitoring, external exposure checks and site walk-downs to list every remote path: site-to-site and client VPNs, remote desktop and remote support tools on HMIs and engineering workstations, cellular routers, dial-up modems, vendor cloud connections and any direct database or OPC connection from the corporate network into the control network. CISA's primary mitigations for OT start in the same place: inventory internet-reachable assets, remove unintended exposure, and disable dormant accounts. See the OT Asset Visibility Guide.
| Discovery record | What to capture | Why |
|---|---|---|
| Remote path | Type, endpoints, who initiates, ports, encryption, authentication | Basis for the closure list |
| Users of the path | Named staff, vendor company, integrator, service accounts | Each becomes an onboarding task or a removal |
| Purpose and frequency | Support, monitoring, patching, emergency only | Decides interactive access versus a data feed versus nothing |
| Contractual basis | Support contract clause, response time, remote versus on-site obligations | Vendor waves depend on what the contract allows |
| Data consumers | Reports, dashboards, ERP or MES interfaces that read OT data | Candidates to move to the historian replica |
| Safety and production dependency | What stops if the path closes | Sets the order of waves and the rollback need |
Before any change, agree the rules with operations in writing: change windows per site, who can stop a cutover, how changes go through the site's management of change process, and what "remote support not available" means for each critical asset. NCSC's first principle asks for a documented business case and a named senior risk owner for each connection; use that to decide which paths are re-provided at all.
Phase 1: the historian replica in the DMZ
The NCSC secure connectivity guidance is direct about this: do not let IT systems reach into OT; replicate the OT historian to a copy in the DMZ using one-way secure transfer, and have IT systems query that copy through an authenticated interface, keeping industrial protocols inside isolated OT segments. CISA's primary mitigations likewise call for a DMZ between IT and OT to pass control data to enterprise systems.
- Size the replica: list the tags and time ranges each consumer actually uses. Replicate those, not the whole plant, at a rate the business needs.
- Choose the transfer mechanism: see the table below. Whichever you choose, the source historian pushes outward; nothing in IT initiates a connection inward.
- Build and test in parallel: run the replica alongside existing direct connections and compare values and timestamps for a defined period, usually one full production cycle.
- Move consumers one by one: repoint each report and interface to the replica, with the consumer's owner signing off that results match.
- Close the direct paths: remove the firewall rules and accounts that let IT query the control network historian. Record the closures.
| Replication option | Direction enforced by | Choose it when | Trade-off |
|---|---|---|---|
| Hardware one-way device (data diode or unidirectional gateway) | Physics: no return path | High consequence sites, or regulation that expects one-way flow | No inbound path at all, so remote write and some acknowledgements need separate design |
| Firewall with outbound-only rules from the OT historian | Rule set and its change control | Most sites; two-way remote access is also needed through the broker | A misconfigured rule reopens the inbound path; review rules on a schedule |
| Store-and-forward relay in the DMZ | Relay design: OT side pushes, IT side pulls from the relay | Several consumers need different subsets of data | The relay is a new system to harden, patch and monitor |
NIST SP 800-53 control AC-4(7) One-way Flow Mechanisms describes hardware-based enforcement of one-way flows. The design choices are covered in the Data Diodes and Unidirectional Gateways Guide.
Phase 2: build the access service
Build the brokered path to the target design before moving anyone onto it. The checks that matter during the build are about the service itself, because it becomes the highest-value system between the enterprise and the plant.
- Outbound-initiated where the product supports it: NCSC advises that connections are initiated from inside OT, with no inbound ports opened at the perimeter or between internal zones.
- Two authentications into OT: ASD's guidance calls for at least two jumps, each with its own account, passphrase and MFA. CISA asks for phishing-resistant MFA on remote access. See the Phishing-Resistant MFA Guide.
- Just-in-time enablement: NCSC recommends enabling connectivity only when it is needed and disabling it afterwards. Design the approval step now, before vendors arrive.
- No file transfer over the session: ASD advises disabling clipboard and drive redirection into OT and bringing patches in through a controlled on-site path.
- Logging from day one: forward broker, jump host and approval logs to the SOC before the first live session. ASD recommends centralised remote access logs and daily reports of abnormal logins.
- Break-glass designed and alarmed: NCSC reserves emergency bypass accounts for genuine safety incidents and says any use should raise the SOC's highest-priority alert.
Protecting the service itself is covered in Securing the OT remote access platform itself.
Where identity fits
Remote access into OT is an identity problem dressed as a network one. Every vendor engineer, integrator and internal user becomes a named account in the broker and in the OT domain, and every legacy shared vendor account, modem password and remote tool credential needs retiring.
- Named accounts only: no shared vendor logins. Tie each vendor account to a contract and a sponsor, with an expiry.
- Disable, then delete: CISA's mitigations include disabling dormant accounts. Disable legacy accounts at closure and delete them after the rollback window.
- Service accounts for data flows: the historian replication and any API consumer use dedicated service identities, scoped to one direction and one dataset, with credentials held in a vault. See the Secrets Management Guide.
- Privileged sessions: treat OT engineering access as privileged access. See the Vendor Privileged Access Management (VPAM) Guide.
A single forgotten account can undo the whole project: Colonial Pipeline's 2021 shutdown followed the use of a legacy VPN account without MFA. See Colonial Pipeline Ransomware Attack 2021: How One Unused VPN Account Shut Down a Fuel Pipeline.
Phase 3: rollout waves and cutover
- Pilot: one site, internal engineers only, during a planned maintenance window. Run old and new paths together and record every task attempted and whether the new path supported it.
- First vendors: two or three vendors with modern tools and a cooperative contract. Onboard named accounts, run approved sessions through the broker, then disable their legacy paths.
- Site waves: repeat site by site. Each wave needs the operations sign-off agreed in phase 0 and a cutover outside production peaks and turnarounds.
- Hard cases last: obsolete systems, vendors whose tools need direct connectivity, and safety systems. NCSC treats obsolete products as untrusted and limits their exposure through segmentation, protocol gateways and hardened jump hosts, as a temporary measure with a replacement date.
- Rollback per wave: keep the old path configured but disabled (physically disconnected for modems and cellular routers) for a short window; two weeks is our recommendation. Rollback is re-enabling one path for one named vendor with an approval and an expiry, not reopening everything.
- Closure: after the window, remove legacy firewall rules, remote tools, modems and accounts, and update the discovery record to "closed" with evidence.
Acceptance tests per site
| Test | Pass condition |
|---|---|
| Vendor session end to end | Request, approval, MFA at each jump, recording, session ends at the approved time |
| Session termination | An operator can see and terminate an active vendor session (NERC CIP-005-7 Parts 2.4 and 2.5 require this for in-scope systems) |
| Legacy path closed | External check and firewall review show no remaining inbound path; old accounts disabled |
| Historian replica | Reports match source values; no IT-initiated connection reaches the control network |
| Isolation | Remote access disconnected on demand within the target time; plant runs without it |
| Break-glass | Use raises the top-priority alert in the SOC |
Prove the isolation plan
ASD recommends a plan able to disconnect remote access within 24 hours of detecting malicious activity. NCSC's eighth principle asks for tested isolation plans for single sites, single services and a shared component being compromised, including whether vendors can switch from remote to on-site support, with critical flows kept alive through hardware-enforced controls where needed. CISA asks operators to keep and test the ability to run systems manually. Run the test at the end of each site wave with operations present: disconnect, confirm the historian replica fails safe without affecting control, confirm manual operation, reconnect.
Choosing the approach
- NERC CIP in scope: CIP-005-7 R2 requires an Intermediate System, encryption to it and MFA for Interactive Remote Access, plus methods to identify and disable active vendor sessions. Build the acceptance tests around those parts. See the NERC CIP Guide.
- Single small site: one broker in the DMZ with a firewall-enforced outbound historian feed is usually enough; a hardware one-way device may be disproportionate unless the consequence of compromise is high.
- Many sites: centralise and standardise, as NCSC's third principle puts it: a few hardened access paths reused across sites, not a design per plant. Expect the vendor waves, not the technology, to set the timeline.
- Heavy vendor dependency: renegotiate contracts during phase 0 so support can be delivered through the broker, and so on-site support is available when remote access is cut.
Detection and measurement
- Legacy paths closed: share of discovered remote paths closed with evidence. The headline project metric.
- Sessions through the broker: share of remote sessions that used the brokered path, against firewall and network monitoring evidence of any other remote traffic. Target 100 percent.
- Direct IT-to-OT queries: count of connections from the corporate network into the control network outside the broker, from network monitoring. Should fall to zero after phase 1.
- Accounts: number of shared or unnamed vendor accounts remaining, and dormant accounts disabled.
- Isolation time: measured time to disconnect remote access in the site test.
- Break-glass uses: each one reviewed; any routine use is a failure of the access service.
Detection content for these signals is covered in the OT Network Security Monitoring Guide.
Common failure patterns
- Build and forget: the broker goes live but the closure list is never worked, so attackers keep the old routes. ATT&CK for ICS tracks this as T0822 External Remote Services and T0859 Valid Accounts.
- Historian replica that talks back: a "read-only" replica whose firewall rules also allow the IT side to initiate connections into the source historian.
- Exception that never expires: a vendor kept on its own tool "until the next outage", with no date.
- Break-glass as a convenience: emergency accounts used for routine work because the approval flow is too slow.
- Cellular routers and modems missed: devices fitted by integrators that do not appear in firewall logs; only walk-downs find them. ATT&CK for ICS T0883 Internet Accessible Device covers exposed devices.
Framework mapping
| Rollout activity | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 | ATT&CK for ICS |
|---|---|---|---|
| Discovery of paths and data flows | CM-8 | ID.AM-03 | T0883 Internet Accessible Device |
| Brokered remote access with MFA | AC-17(1), AC-17(3), IA-2, MA-4 Nonlocal Maintenance | PR.AA-03, PR.IR-01 | T0822 External Remote Services, T0886 Remote Services |
| Historian replica and one-way flows | AC-4(7) One-way Flow Mechanisms, SC-7 | PR.IR-01 | n/a |
| Vendor and dormant accounts | AC-2, AC-2(3) Disable Accounts | PR.AA-01, PR.AA-05, GV.SC-07 | T0859 Valid Accounts |
| Session recording and logs | AU-14 Session Audit | PR.PS-04, DE.CM-01 | n/a |
| Isolation test | n/a | RS.MI-01 | n/a |
In IEC 62443 terms the broker and replica sit in a DMZ zone with defined conduits to the control zones. See the OT Network Segmentation, Purdue Model and IEC 62443 Zones and Conduits Guide.
Practitioner checklist
- Every remote path and IT-to-OT data consumer discovered, with an owner, a purpose and a closure date.
- Operations agreement in place: change windows, stop authority, management of change, on-site fallback per critical asset.
- Historian replica in the DMZ, outbound-only, validated against source before consumers move.
- Access service built with two authenticated jumps, phishing-resistant MFA, just-in-time approval and logging before the first user.
- Vendors on named, expiring accounts tied to contracts; shared logins removed.
- Waves run site by site with parallel periods and a per-vendor rollback record.
- Legacy firewall rules, remote tools, modems and accounts removed with evidence after each window.
- Isolation tested per site with operations present, including manual operation.
Standards and references
- NCSC: Secure connectivity principles for operational technology (OT)
- ASD's ACSC: Remote access to operational technology environments
- CISA: Primary Mitigations to Reduce Cyber Threats to Operational Technology
- NERC: CIP-005-7 Cyber Security, Electronic Security Perimeter(s)
- NIST: SP 800-82 Rev. 3 Guide to Operational Technology (OT) Security
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
- MITRE ATT&CK for ICS: External Remote Services
- NIST: Cybersecurity Framework 2.0
Related NHI Mgmt Group resources: OT Remote Access Guide, OT remote access and historian health check, OT remote access and historian integration security guide, OT Remote Access Request Form Template.