Almost every industrial site depends on outside engineers: the PLC integrator, the turbine OEM, the SCADA vendor, the chiller service company. Their access is necessary, and it is also one of the most common ways attackers and mistakes reach the control network. This article describes a remote access design that keeps vendors productive without leaving permanent doors into OT.
The problem in real environments
When we assess an OT site, remote access is rarely one thing. It is an accumulation of decisions made over ten or fifteen years by different people under time pressure. A typical inventory of remote paths looks something like this:
- A remote desktop tool installed on an engineering workstation, set to start with Windows and accept unattended connections, because the integrator asked for it during commissioning.
- A site-to-site or client VPN from the vendor directly into the control network, with a shared account that several of the vendor's engineers use.
- A cellular router or modem inside a control panel, installed by the OEM so their support team can reach the controller "if something goes wrong".
- A firewall rule allowing inbound connections from a vendor's IP range to a historian or HMI, created years ago and never reviewed.
Each was reasonable when set up. Together they mean nobody can answer the basic questions: who can connect right now, to what, and how would we know?
The threat is not hypothetical. MITRE ATT&CK for ICS lists External Remote Services (T0822) and Remote Services (T0886) as techniques for initial access and lateral movement, and compromised remote access software and shared vendor credentials keep appearing in public incident reporting on industrial intrusions. The vendor does not need to be malicious. Their laptop, their identity provider, or their own support platform only needs to be compromised once.
Why common approaches fail
"We have a VPN, so it is secure"
A VPN encrypts the transport and authenticates the tunnel. It does not decide what the user can reach once inside. A vendor VPN that terminates in the control network, or in a flat DMZ with routes into the control network, gives the vendor network-level reach to every device the routing allows. If the vendor's endpoint is compromised, the attacker inherits that reach.
Shared accounts and permanent access
Shared vendor accounts make attribution impossible. Permanent access means the account is valid at 03:00 on a Sunday when nobody from the vendor should be connecting. Both conditions turn a credential leak into an open-ended exposure rather than a short, contained one.
Remote desktop tools on OT hosts
Commercial remote support tools are convenient, but when installed directly on HMIs or engineering workstations they create an outbound channel that bypasses the site's firewall design entirely. The trust decision moves to a third-party cloud service and to whoever holds the account there.
Recommended architecture
The goal is simple to state: every remote session into OT passes through one controlled path, is tied to a named person, is approved for a specific purpose and time window, is recorded, and ends cleanly. IEC 62443-3-3 frames this through requirements on human user identification and authentication (SR 1.1), multifactor authentication for untrusted networks (SR 1.1 RE 2), remote session termination (SR 2.6), audit logging (SR 2.8), and zone boundary protection (SR 5.2). NIST SP 800-82r3 gives similar guidance on remote access to OT.
1. No direct inbound to OT
No connection from the internet, from a vendor network, or from the corporate IT network should terminate directly on an OT asset. Inbound remote access terminates in an OT DMZ (often described as Level 3.5 in Purdue-style models), and from there a controlled, separately authenticated hop is made into the operations zone. Firewall rules between the DMZ and the control zone allow only the specific protocols needed, only from the jump host or broker, and only to the specific target assets.
2. Jump hosts in the OT DMZ
A jump host (or a pool of them) is a hardened server in the DMZ where remote users land before reaching OT. It should be treated as a high-value asset:
- Dedicated to remote access, with no email, no web browsing, and no general-purpose software.
- Joined to a separate OT or DMZ identity domain, never to the corporate Active Directory.
- Hosting only the engineering tools vendors actually need, in licensed and controlled versions, so vendors do not bring their own tool installs.
- Configured to block clipboard, drive mapping and file transfer by default, with a separate, scanned file transfer path for the cases where files must move.
3. Brokered sessions instead of network access
Better than a VPN to a jump host is a session broker: a privileged access or secure remote access platform that exposes specific applications or protocols (RDP, SSH, HTTPS, or vendor engineering protocols) to the user, without giving their endpoint an IP-level route into the site. This is the zero trust network access (ZTNA) pattern applied to OT. The user authenticates to the broker, the broker checks policy, and the broker opens a proxied session to the one asset they are approved for.
The vendor's device never joins the OT network, so malware on it cannot scan or spread. The broker also becomes the natural point for approval, recording and termination.
4. Just-in-time approval
Vendor accounts should be disabled by default. Access is requested for a specific job, a specific asset set, and a specific window, and an internal owner approves it. A workable flow looks like this:
- The vendor engineer requests access through the broker or a ticket, referencing a work order or change number.
- The asset owner or the operations shift lead approves, ideally with a check that the plant state allows the work.
- The account is enabled for the approved window only (for example four hours), scoped to the approved targets.
- When the window expires, the session is terminated and the account returns to disabled.
5. Strong authentication with named identities
Every vendor engineer gets a personal account. Shared accounts are not acceptable for remote access, even if the vendor insists. MFA is required at the broker or jump host, preferably phishing-resistant (FIDO2 security keys or platform authenticators) where the vendor's workforce can support it. Where the broker supports it, federating with the vendor's identity provider can work, but only if the site keeps local control over which vendor identities are authorized and can revoke them instantly. Credentials for the target OT systems themselves should be held by the broker or a vault and injected into the session, so the vendor never knows the controller or HMI password.
6. Session recording and monitoring
Record remote sessions: video for graphical sessions, keystrokes and command logs for SSH and terminal sessions. Recordings also resolve disputes about what changed during a maintenance visit. Pair recording with live monitoring for sensitive work, so an internal engineer can watch and, if necessary, terminate the session. Send broker and jump host logs to the security monitoring platform and alert on access outside approved windows, failed MFA, and connections to targets outside the approved scope.
7. Handling vendor-installed modems and cellular routers
Cellular devices need specific attention because they sit outside every other control in this design. The default position should be that no cellular or dial-up path into OT exists unless it is documented, owned and controlled. In practice:
- Find them. Physically inspect control panels, skids and packaged equipment. Look for antennas, SIM slots and unfamiliar devices on the OT switch. Passive network monitoring can reveal unexpected gateways and traffic to carrier ranges.
- Decide per device. Remove it, or keep it powered off with a physical switch or disconnected antenna that operations enables on request, or bring it under control.
- If it must stay, treat it as its own zone: change default credentials, disable management services on the cellular interface, use a private APN where the carrier offers it, place a firewall between it and the control network, and log its connections.
- Write it into contracts. Procurement terms should forbid vendors from installing remote access devices or software without written approval from the asset owner, and require disclosure of any remote connectivity built into delivered equipment.
Implementation checklist
| Area | Control |
|---|---|
| Discovery | Inventory every remote path: VPNs, remote desktop tools, firewall rules, cellular devices, cloud gateways. |
| Architecture | All inbound access terminates in the OT DMZ; no direct inbound rules to control zones. |
| Access path | Brokered sessions or hardened jump hosts, with protocol and target restrictions per user. |
| Identity | Named accounts for each vendor engineer, separate from corporate AD, MFA enforced. |
| Approval | Accounts disabled by default; time-boxed, ticket-linked approval by the asset owner. |
| Credentials | Target system passwords vaulted and injected; vendors never hold OT credentials. |
| Recording | All sessions recorded and retained per policy; live shadowing for high-risk work. |
| Monitoring | Broker and jump host logs forwarded to security monitoring with alerting on out-of-window or out-of-scope access. |
| Cellular | Every modem and router found, removed or controlled, documented and owned. |
| Contracts | Remote access terms in vendor agreements; access reviews at least quarterly. |
Common mistakes
- Building the broker and leaving the old paths open. The new path only reduces risk when the VPNs, remote tools and inbound rules it replaces are actually removed. Plan decommissioning as part of the project, with dates.
- Joining the jump host to corporate AD. This links OT access to the security of the whole IT identity estate. A compromised IT domain admin then has a direct path to OT.
- Approving access for weeks at a time. Long windows turn just-in-time access back into standing access. If a project needs repeated access, approve repeated short windows.
- Recording without anyone looking. Recordings that are never reviewed provide evidence after the fact but no detection. Sample and review sessions, especially those that involved configuration changes.
- Forgetting internal remote users. Your own engineers working from home need the same path, the same MFA and the same recording. A design that applies only to vendors leaves the largest group of users uncovered.
Where to start
Start with discovery. List every way someone outside the plant can reach a device inside it, including the ones nobody wants to admit exist, and assign each path an owner. Then pick the highest-risk paths, usually direct inbound rules and unattended remote desktop tools on HMIs, and move them behind a single DMZ access point with named accounts and MFA. Add just-in-time approval and recording next, and close with cellular devices and contract terms. The result is not perfect security, but it turns remote access from a set of unknown doors into one door that you watch.