An operational technology (OT) remote access platform is the gateway that lets engineers, integrators and equipment vendors reach controllers, engineering workstations and historians from outside the plant, so whoever controls the gateway, its policies or its vendor accounts can reach the control system. The platform is often an internet-facing appliance or service, it is trusted by every OT zone it brokers into, and it is often owned by an engineering team rather than the security team. This guide covers how to secure the remote access platform itself: administrator roles, vendor and user accounts, the gateway's own service accounts and keys, exposure and patching, logging and lifecycle. It is vendor-neutral and based on the 2026 NCSC-led Secure connectivity principles for OT, CISA's guide to securing remote access software, NIST SP 800-82 Rev. 3 and NIST SP 800-53. It is written for OT security engineers, plant network owners and security teams. For how to design OT remote access patterns, see the OT Remote Access Guide.
Key takeaways
- The gateway is a boundary device and a privileged system at once. Harden and patch it like an internet-facing edge device, and govern its administrators like a PAM vault's.
- Separate who administers the platform from who uses it. Engineers and vendors who connect through the gateway should not be able to change its policies, approval rules or recordings.
- Vendor accounts are the biggest population to govern. Named, time-bound, approved per session, limited to specific assets and removed when contracts end.
- Outbound-only, brokered and just-in-time. NCSC-led guidance says OT connections should be initiated outbound from within the OT environment, brokered through a secure gateway in a separate segment, and enabled only when required.
- Plan to cut it off. The remote access path should be the first thing you can isolate in an incident, without losing local operation.
What makes up the platform's attack surface
A typical deployment has an external access point or cloud broker, a gateway or jump server in an OT demilitarised zone (DMZ), optional site agents inside OT zones, a policy and approval engine, a credential store for target logons and session recording storage. The table below sets out each component.
| Component | What it can do | What an attacker gains |
|---|---|---|
| External portal or cloud broker | Accept connections from users and vendors on the internet | An entry point if exposed services are unpatched or misconfigured |
| Platform administrator roles | Change users, policies, approvals, target lists and recording settings | Grant themselves or others access to any OT asset, and remove evidence |
| Vendor and engineer accounts | Open sessions to approved OT assets | Interactive access to controllers and engineering workstations |
| Site agents and DMZ gateways | Relay sessions into OT zones | A trusted foothold inside the OT network |
| Stored target credentials | Inject logons to engineering workstations, HMIs and servers | Credentials for OT systems that are rarely rotated |
| Platform service accounts and API keys | Connect to the directory, SIEM, ticketing and identity provider | Directory reads, log tampering or approval bypass via integrations |
| Session recordings and logs | Hold a record of every remote action | Screens showing passwords, process data and network layout |
The ATT&CK for ICS techniques this enables include T0822 External Remote Services, T0859 Valid Accounts and T0886 Remote Services. CISA's guide to securing remote access software notes that threat actors increasingly co-opt legitimate remote access tools to reach victim systems, which is why unmanaged tools alongside the approved platform are a risk in their own right (T1219 Remote Access Tools).
Exposure, placement and hardening
- Brokered and outbound: place the gateway in a separate, security-controlled segment such as an OT DMZ, and have site agents initiate outbound connections, so no inbound port into OT zones is needed. NCSC-led principle 2 says all connections with the OT environment should be initiated as outbound connections from within it, and external access should use brokered connections through a secure gateway. See the OT Network Segmentation, Purdue Model and IEC 62443 Zones and Conduits Guide.
- Minimal exposed services: expose only the user-facing access service to the internet. Keep the management interface on a management network, never on the public side. Principle 5 advises exposing only required services and having no default passwords on any device.
- Patch as an edge device: principle 5 says boundary devices should be routinely updated with the latest firmware and replaced before end of life, and notes edge devices are especially exposed when known vulnerabilities are present. Set a patch target for the gateway that is shorter than for equipment inside the OT zones (our recommendation), and subscribe to the vendor's security advisories. See the OT Patch Management Guide.
- Just-in-time connectivity: where possible, enable the path only when a session is approved and disable it otherwise (principle 2). Disable site agents or vendor routes that have no planned use.
- External attack surface checks: regularly confirm that only the intended gateway is visible from the internet, and investigate any other OT-facing service that appears. Principle 2 says to treat internet-visible OT devices as at risk.
- One sanctioned path: block and detect unapproved remote access tools, modems and cellular routers on OT networks, so the hardened platform is the only route in. See the Secure Remote Access Beyond VPN Guide.
Administrative roles and separation of duties
- Split platform roles: separate platform configuration, user and vendor onboarding, session approval, recording review and audit reading. Users who connect through the gateway should hold none of these roles (NIST SP 800-53 AC-5).
- Dedicated admin accounts with phishing-resistant MFA: NCSC-led principle 5 says human-to-machine access should require MFA, preferably phishing-resistant, and be user-aware so actions create an employee-specific audit trail. Apply this to administrators first (CIS safeguards 5.4 and 6.5).
- Administer from a privileged workstation: principle 2 recommends routing administration through privileged access workstations. See the Privileged Access Workstations Guide.
- Local admin accounts: keep one or two local break-glass accounts for when the identity provider is unreachable, vaulted and alerted on. Principle 7 says break-glass access is for emergencies only and any use should raise the highest criticality alarm. See the Break-Glass Account Guide.
- Platform supplier access: the gateway vendor's own support access should be off by default, enabled per case and recorded. Treat the platform's supplier as a tier-zero supplier; see Remote access and PAM vendors as tier-zero suppliers.
Vendor, engineer and service identities
NIST SP 800-53 MA-4 (Nonlocal Maintenance) expects remote maintenance to be approved, monitored, strongly authenticated and terminated when done. The controls below put that into the platform. The specific limits are our recommendation.
| Identity | How to govern it |
|---|---|
| Vendor technician | Named account per person, never shared per company; sponsor inside your organisation; access to listed assets only; per-session approval; expiry no later than the contract or work order end |
| Internal engineer | Provisioned from the identity provider through joiners, movers and leavers; role-based asset groups; MFA every session |
| Site agent identity | Unique certificate or key per agent, enrolled through an approved process, revoked when the site or agent is retired |
| Integration accounts (directory, SIEM, ticketing) | Read-only where possible, one per integration, inventoried and rotated (CIS safeguard 5.5) |
| Stored target credentials | Held in the platform vault or a PAM vault, injected rather than shown to the user, rotated after vendor sessions where the target allows it |
- Least privilege by asset and protocol: a vendor supporting one drive or skid should reach those assets on the protocols they need, not the whole zone. NCSC-led principle 2 recommends brokered access for vendor support; limiting each vendor to the assets and protocols they need is our recommendation.
- Approval tied to work: link session approval to a work order or change, approved by the asset owner or control room, so access requests have an operational reason. See the OT Remote Access Request Form Template.
- Shared and default OT accounts: many targets still use shared local logons. Keep those credentials in the vault, inject them through the platform, and record sessions so actions remain attributable to a person. See the Identity for OT Environments Guide.
- File transfer: control file transfer through the gateway separately from interactive access, with scanning and a record of what was moved to engineering workstations. See the Engineering Workstation Security Guide.
Keys, recordings and data protection
- TLS and agent keys: know where the gateway's certificates and agent keys are stored, who can export them and when they expire, following NIST SP 800-57 practice. Use certificates from an enterprise PKI rather than self-signed defaults where the platform allows it.
- Recording storage: session recordings can show passwords typed into legacy applications, process values and network details. Restrict who can view them, encrypt them at rest, and set a retention period agreed with the plant and legal teams.
- Configuration export: treat policy and target exports as sensitive: they are a map of your OT assets and who can reach them.
Logging and detection
Send gateway logs to a SIEM or OT security monitoring platform that platform administrators cannot change (AU-9). Principle 7 of the NCSC-led guidance says all connectivity should be logged and monitored, and that alerts muted for maintenance windows must be turned back on afterwards.
| Event | Why it matters |
|---|---|
| Admin role assignment, policy or target list change | New paths into OT |
| Vendor account created, extended or reactivated | Standing third-party access |
| Session outside an approved window or without a linked work order | Access without an operational reason |
| Recording disabled or recordings deleted | Evidence removed |
| Break-glass or local admin logon | Highest criticality alarm |
| New site agent enrolled or agent connecting from an unexpected network | Rogue relay into OT |
| Remote sessions to OT assets that did not pass through the gateway | An unsanctioned path is in use |
Correlate gateway sessions with network monitoring in the OT zones: traffic to a controller from a jump server with no matching session record should alert. See the OT Network Security Monitoring Guide.
Lifecycle, isolation and recovery
- Isolation plan: NCSC-led principle 8 asks operators to establish an isolation plan. Document how to disable the external access point, all vendor accounts and all site agents quickly, and test that local operations continue.
- Review accounts: review administrators, vendor accounts and integration accounts at least quarterly (our recommendation), with the reviewer outside the team that runs the platform (AC-6(7)).
- Backup and restore: back up platform configuration and keys, protect the backups as sensitive, and keep a tested rebuild procedure so the gateway can be restored from a known-good state rather than from a possibly compromised one. See the OT Backup, Recovery and Golden Image Guide.
- End of life: replace the gateway before vendor support ends (principle 5), and revoke agent certificates and stored credentials when sites or assets are retired.
Framework mapping
| Control area | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 | CIS Controls v8.1 |
|---|---|---|---|
| Platform admin accounts | AC-6(5) Privileged Accounts, IA-2(1) Multi-factor Authentication to Privileged Accounts | PR.AA-05, PR.AA-03 | 5.4, 6.5 |
| Remote and vendor maintenance | AC-17 Remote Access, MA-4 Nonlocal Maintenance | PR.AA-05, GV.SC-07 | 6.4 |
| Boundary placement | SC-7 Boundary Protection | PR.IR-01 | 12.2 |
| Patching the gateway | SI-2 Flaw Remediation | PR.PS-02 | 7.1 |
| Logging and monitoring | AU-9 Protection of Audit Information, AC-17(1) Monitoring and Control | PR.PS-04, DE.CM-03 | 8.2 |
| Service and integration accounts | AC-2 Account Management, IA-5 Authenticator Management | PR.AA-01 | 5.5 |
Common failure patterns
- Management interface on the internet: the admin console reachable from the same address as the user portal.
- Gateway patched on the plant outage cycle: an internet-facing device left for months because it sits in the OT change process.
- One account per vendor company: shared by every technician, never expiring, with a password known to people who have since left.
- Engineers who can approve their own sessions: the platform's approval step is a formality.
- A second, forgotten path: a vendor-installed remote access tool or cellular router that bypasses the gateway entirely.
- No tested isolation: the team cannot say how quickly every remote path could be closed.
Practitioner checklist
- Place the gateway in an OT DMZ with outbound-only site agents and no inbound ports into OT zones.
- Keep the management interface off the internet and patch the gateway as an edge device.
- Separate platform administration from platform use, with phishing-resistant MFA for both.
- Give every vendor technician a named, sponsored, expiring account limited to listed assets.
- Tie session approval to work orders and record sessions.
- Vault and inject target credentials; rotate after vendor sessions where possible.
- Inventory agent certificates and integration accounts; revoke on retirement.
- Forward gateway logs to an independent SIEM and alert on admin, vendor and recording changes.
- Detect remote access tools and paths that bypass the gateway.
- Write and test an isolation plan for the whole remote access path.
Standards and references
- NCSC and partners: Secure connectivity principles for operational technology (January 2026)
- NCSC: Principle 2, Limit the exposure of your connectivity
- NCSC: Principle 5, Harden your OT boundary
- NCSC: Principle 7, Ensure all connectivity is logged and monitored
- CISA and partners: Guide to Securing Remote Access Software
- NIST: SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
- NIST: Cybersecurity Framework 2.0
- NIST: SP 800-57 Part 1 Rev. 5, Recommendation for Key Management
- CIS: Controls v8.1 Assessment Specification, Control 6 Access Control Management
- MITRE ATT&CK for ICS: T0822 External Remote Services
Related NHI Mgmt Group resources: OT Remote Access Guide · Security Service Edge for OT Remote Access Buyers Guide · Securing the PAM Vault Itself · Identity for OT Environments Guide