The short answer
How to Configure Remote Access
To configure remote access, terminate a virtual private network with multi-factor authentication at a firewall in a demilitarized zone, not on the control network; put a jump host in that zone as the only destination remote users can reach, running the SCADA client and the engineering tools; give each person a named account with the least role that does the job, view-only for most; log every session with a recording where the platform supports it; enable vendor access per request for a limited time with an escort; block every other path, including cellular routers with public addresses and desktop remote tools; and test it from outside: the authorized path works, an account without the second factor fails, a session from the jump host cannot reach anything but what it should, and the audit log shows all of it. Then review the accounts quarterly and remove the ones that have left.
Key points
- A virtual private network with multi-factor authentication ending in a demilitarized zone; nothing terminates on the control network.
- A jump host is the only reachable destination; the SCADA client and the tools run there.
- Named accounts with least privilege; view-only by default; control for the few who need it.
- Session logging and, where possible, recording; vendor access per request with an escort and an expiry.
- Test the path and the blocks from outside, and review accounts on a schedule.
What you need
- A firewall with a virtual private network and a demilitarized zone interface
- A multi-factor authentication service
- A jump host, physical or virtual, hardened and patched, with the SCADA client and engineering tools
- The user list with roles from the security policy
- A laptop and a phone outside the plant network for testing
Procedure
- 1
Draw the path
Internet to the firewall virtual private network to the demilitarized zone to the jump host to the control network by the specific protocols the jump host needs. Nothing else. The drawing is the design and the test plan.
- 2
Configure the tunnel
A virtual private network on the firewall with strong encryption, certificate or key based, terminating in the demilitarized zone interface, with multi-factor authentication required for every user.
- 3
Build the jump host
A hardened machine in the demilitarized zone with the SCADA client and the engineering software, patched, with no local administrator for users, host firewall on, and session recording if available. Users log in with their named account and their second factor.
- 4
Write the firewall rules
Remote users to the jump host only, on the remote desktop protocol only. Jump host to the SCADA server on the client protocol; jump host to the engineering workstation or the controllers on the engineering protocols only where engineers need it. Deny everything else and log the denies.
- 5
Define the roles
View-only for operators who monitor from home, control for on-call operators who must act, engineering for the few who program, and a vendor role that is disabled by default. Map each to an account group.
- 6
Create accounts
Named accounts, no shared logins, in the directory with the multi-factor enrollment; the SCADA roles tied to the same identities; a removal process tied to departures.
- 7
Set up vendor access
A vendor account enabled per request by a named plant person for a set duration, with an escort watching the session, and disabled automatically afterward; every vendor session logged.
- 8
Block the bypasses
No cellular routers with public addresses, no desktop remote tools on control machines, no port forwards on the plant router, no modems on controllers. Scan for them and remove them.
- 9
Test from outside
The authorized user reaches the jump host and the SCADA client and can do their role and no more; a user without the second factor is refused; from the jump host, a ping or connection to anything outside the rules fails; the firewall log shows the denies; the session log shows the session.
- 10
Operate it
Quarterly account review, patching of the jump host and the firewall on the schedule, log review, and an annual test of the whole path.
| Layer | Control | Proves |
|---|---|---|
| Tunnel | Virtual private network with multi-factor authentication | Only enrolled people get in |
| Landing | Demilitarized zone, not the control network | A compromised tunnel lands outside the plant |
| Destination | Jump host only | One hardened machine to defend |
| Protocols | Firewall rules per role | A remote user cannot reach a controller directly |
| Identity | Named accounts, least privilege | Accountability and limited damage |
| Visibility | Session and firewall logs | Every action attributable |
| Vendors | Per-session enablement with escort | No standing back doors |
Frequently asked questions
- Can operators use the SCADA web client from home directly?
- Through the virtual private network and the demilitarized zone, yes; exposed to the internet, no, whatever the vendor says about its security. The web client is served from the demilitarized zone or reached through the jump host.
- Why a jump host instead of connecting the client straight through the tunnel?
- A laptop at home is not a hardened machine, and the tunnel would carry whatever is on it into the control network. The jump host is one machine the plant controls, patches, and records.
- What about the integrator who needs to program controllers from their office?
- The vendor role: enabled per request for a set time, through the same tunnel and jump host, with the engineering protocols permitted from the jump host to the specific controller, and a plant person watching. Standing vendor access is a back door.
- How do I know the bypasses are gone?
- An external scan of the plant public addresses, an inventory of every cellular device and modem, and a look at every router configuration for port forwards. Then a policy and a periodic repeat.
Related topics
- VPN DesignHow a VPN fits remote access for a control system: it terminates in the DMZ and lands on a jump host, never the control network; site-to-site tunnels carry telemetry; user tunnels require multi-factor and individual accounts; the concentrator is patched fast.
- Jump HostsThe one machine every remote session must pass through: what a jump host is, how it is hardened, what it may reach, session recording, the tools it carries, and why a vendor laptop never gets past it.
- Multi-Factor AuthenticationRequiring a second proof of identity beyond a password, where it matters most in a control system and how to do it without locking an operator out: the factor types, where it is mandatory, where it does not fit, enrollment and recovery, and vendor accounts.
- Vendor Remote AccessIntegrators and equipment vendors need to get in. How to let them without leaving a permanent door open: utility-controlled sessions, named accounts, MFA, a jump host, session recording, and what to do about the modem you did not know was there.
- Session LoggingRecording every remote session into the control system: who connected, from where, when, to what, and what they did, from the VPN log through jump host session recording to the SCADA audit trail and controller change log, stored off the systems and reviewed.
- Industrial DMZ DesignThe buffer zone between the business network and the control system: what goes in it, the no-direct-path rule, push-not-pull data flows, the firewall pair, and the services a utility actually needs to place there.
Direct contact
Have a controls question?
Reach Eric Sullivan directly about anything on this site, a controls or automation topic, or one of his personal projects.