ISO Compliance Insights & Best Practices
CART
ISO Compliance Insights & Best Practices
OT secure remote access is the control that gets tightened after an incident and loosened again the first time a vendor cannot reach a machine at 2am. It is also the single most common initial access route into industrial networks, which is why IEC 62443 treats it as its own set of requirements rather than a subset of network security.
This guide covers the architecture that works, the identity and authentication rules that go with it, how to handle vendor access specifically, and the failure modes that undo an otherwise good design.
Remote access into an industrial control system differs from corporate remote access in three ways that matter.
First, the target is a physical process. A remote session that reaches a controller can change a setpoint, force an output or stop a plant. Second, most of the sessions are not yours — they belong to integrators, OEMs and maintenance contractors whose own security posture you do not control. Third, the connections are frequently installed by the equipment supplier as part of a delivery, without anyone in security ever seeing them.
That last point is the one that catches most sites out. An OT secure remote access programme that only governs the paths IT knows about governs a fraction of the paths that exist.
The requirement is that remote sessions terminate at an intermediate system, not on the target. That intermediate system — the jump host, or remote access broker — sits in the demilitarised zone between the plant and the outside world.
| Element | What it does |
|---|---|
| External enforcement point | Terminates the inbound connection from the internet or corporate network |
| Jump host in the DMZ | Where the remote session actually lands. Hardened, patched, logged, session-recorded |
| Internal enforcement point | Permits only the jump host to reach named targets on named ports |
| Target zone | Accepts connections from the jump host only, never from outside |
The test of an OT secure remote access design is simple: can any packet originating outside the plant arrive at a control device? If yes, you have a tunnel, not OT secure remote access. A site-to-site VPN that lands a vendor on the control network is the commonest version of this failure, and the encryption on it is irrelevant to the point.
Only what the OT secure remote access work actually needs: the engineering software, the HMI client, the diagnostic tools. No general internet browsing, no email, no file shares from the corporate network. Clipboard and file transfer are disabled by default and enabled per session where genuinely required, with the transferred files scanned.
Treat the jump host as a component in a high-consequence zone, because that is what it is. It gets the same hardening, patching, backup and monitoring as anything else in that zone.
Architecture without identity is half a control. Four OT secure remote access rules, and the first is the one most often broken.
Where a legacy device genuinely cannot support individual identities, the identity is enforced at the jump host instead and the shared device credential never leaves it. Record that as a compensating measure.
Most industrial remote access is third-party access, so govern it explicitly.
| Practice | Position |
|---|---|
| Always-on vendor tunnel | Not acceptable. Connectivity is enabled per request and disabled afterwards |
| Vendor-supplied cellular modem or router | Not acceptable as an independent path. Remove it or bring it inside the controlled architecture |
| Vendor’s own remote access platform | Only where it terminates at your jump host and you retain the logs |
| Unsupervised vendor session | Only for defined low-risk work. Anything touching a control device is supervised |
| Vendor session recording | Retained by you, not by the vendor |
Put your OT secure remote access terms in the contract, not just the procedure. The requirement to enforce security obligations on service providers is a separate requirement in its own right, and a vendor who agreed to nothing has agreed to nothing when the incident review happens.
Before designing OT secure remote access, find what already exists. The reliable methods are physical and procedural rather than technical: walk down the panels looking for cellular modems, ADSL lines and unexplained antennae; ask the maintenance planners which suppliers connect remotely and how; review outbound firewall logs for persistent connections to remote-support providers; and read the support contracts, which usually describe the connectivity the supplier expects.
Every path you find gets an OT secure remote access decision — remove it, or bring it inside the architecture. There is no third option.
Three operational controls turn the architecture into a working process.
Supervision. A named person in the plant is aware the session is happening, knows what work is authorised, and can terminate it. For anything that changes a control device, supervision is active — someone is watching the session or is with the equipment.
Monitoring. Sessions are logged and, for high-consequence targets, recorded. The log records who, when, from where, to what, and for how long. It is reviewed rather than merely retained.
Verified termination. The session is confirmed closed, not assumed closed. Connectivity is disabled, temporary permissions removed, and any change made during the session recorded under change control. Sessions left open because a vendor closed a laptop lid are a well-established finding.
Every OT secure remote access design needs an answer for the 2am case, or the answer becomes an undocumented modem. Define a break-glass route in advance: a specific procedure, a named approver reachable out of hours, credentials held securely and issued on approval, mandatory supervision, and a full review afterwards. The point is not to prevent emergency access. It is to ensure the emergency route is designed, logged and closed rather than improvised and left open.
The requirement covers remote access to the IACS, not remote access over your network. Dial-up modems on legacy controllers, cellular routers in vendor packages, satellite links at remote sites and wireless maintenance interfaces all fall in scope.
These paths are frequently outside firewall visibility entirely, which is exactly what makes them attractive. Each one is either removed, or brought under the same architecture, identity, monitoring and termination controls as everything else — and recorded either way.
No. A VPN provides an encrypted transport, which solves confidentiality in transit and nothing else. If the VPN terminates on the control network, an attacker with valid credentials or a compromised vendor laptop is on the control network. The VPN is one component; the jump host, individual identity, MFA, least privilege, supervision and verified termination are the rest.
Common, and workable. Accept it where their platform terminates at your jump host rather than on your control network, you hold your own session logs, and connectivity is enabled per request. Where the vendor requires an always-on inbound path they control, that is a contractual negotiation, not a technical constraint — and it is a question worth asking before the purchase order rather than after.
It is a risk decision, not an absolute. Where the consequence is high, the sensible position is that remote sessions are read-only for diagnosis and any change requires either an on-site person or an actively supervised session with change control. Blanket remote write access to safety-related equipment is very difficult to justify.
Hold this to the highest standard in the programme. Safety systems are segregated from basic control as a requirement, and that segregation should extend to remote paths. Where remote access to a safety system is genuinely necessary, it is separately authorised, actively supervised, fully recorded and time-bounded — never part of a general engineering access route.
The architecture depends on the boundaries you have already drawn, so do zones and conduits first — a remote access conduit is a conduit like any other, with its own target security level. The DMZ the jump host sits in is covered in the Purdue model guide.
Vendor obligations sit alongside the service provider requirements described in IEC 62443 parts explained. The asset owner requirements themselves are in IEC 62443-2-1:2024.
Our IEC 62443 Toolkit includes the remote access policy and procedure, the remote access register covering every path including out-of-band ones, the session authorisation and log template, and the third-party security requirements schedule for contracts. The register is usually the document that pays for itself first, because filling it in is how most sites discover how many paths they actually have.
August 26, 2026
August 26, 2026
August 26, 2026
August 26, 2026
August 26, 2026