← Home
Secure Remote Access
Remote connectivity to Industrial Automation and Control Systems (IACS) can run over LANs,
WANs and the internet, dial-up or serial paths to controllers, and many remote-support tools.
It brings clear operational benefits — central management, vendor support, remote
maintenance — and equally clear risk: if a legitimate person or device can reach the system
remotely, an unauthorised one may be able to do the same.
Teaching note: Paraphrased for learning from IACS cybersecurity course
material and industry practice. Not a substitute for ISA/IEC 62443 normative requirements
(especially Part 2-1 NET 3) or organisation-specific remote-access policy.
Related:
IEC 62443-3-1 Clause 5 Authentication
|
IEC 62443-3-1 Clause 7.3 VPN
|
Jump Host
|
Multi-Factor Authentication (MFA)
|
IEC 62443-2-1 NET 3 – Secure Remote Access
|
Network Segmentation
|
IEC 62443-3-1 Clause 8.3 IDS
|
Unified Threat Management (UTM)
|
Zone and Conduit Security Strategy
|
Network Security Devices
Design challenges
Secure remote-access design is hard because organisations must reconcile:
- Varied control-system architectures (plant vs enterprise paths)
- Different needs and types of remote users
- Technology and service limitations (including geography)
- IT policies and regulatory constraints
- Vendor requirements and device capabilities
Larger organisations typically face more complexity — more user types, more entry points and
more systems to monitor.
Typical remote users
- System operators and engineers (local and remote sites)
- Vendors and system integrators
- System support specialists and maintenance engineers
- Reporting or regulatory entities
- Business partners, field technicians and customers
- Supply-chain representatives and managed service providers
Remote access technologies
Common options include:
- WAN services (for example dedicated circuits, DSL, MPLS)
- Wireless WAN/LAN (cellular, microwave, satellite, 802.11 and similar)
- Remote access software and remote desktop / terminal services
- Remote access servers
- Virtual Private Networks (VPN) — site-to-site and remote-access
- Desktop and application virtualisation
- Legacy dial-up / serial paths to engineering ports (still present on some plants)
Choose technology for the business need and risk posture — not familiarity alone. For VPN
appliances, protocols (IPSec, TLS/SSL, and related), site-to-site vs remote-access
architectures, and industrial deployment tips, see the
VPN page. Terminate remote-access VPN gateways in an industrial
DMZ where practical.
Design factors
When designing remote access, consider at least:
- Types, roles and quantity of users requiring remote access
- IACS assets that may be reached remotely
- Target security level (SL-T) of each remotely accessible asset
- Threats and likely attack vectors
- Estimated frequency and duration of remote sessions
- Performance requirements
- Availability of local personnel to permit and monitor sessions
- Available local and remote services
- Regulatory, policy, technology and vendor restrictions
- Budget
Part 2-1 expects interactive remote sessions to be authorised, authenticated, encrypted,
documented, logged and monitored
(NET 3.2),
with automatic termination after inactivity
(NET 3.3).
Jump host
A jump host concentrates interactive remote work on a controlled workstation
(KVM-style access) instead of granting broad IACS network membership. Place it in the DMZ,
limit reachability and file transfer, and harden it as a high-value endpoint.
See Jump Host for architecture, benefits and placement guidance.
Remote access best practices
- Require corporate-managed laptops (under organisational security policy) or provide a secure bootable image for remote users.
- Contractually require third parties with remote access to accept and comply with organisational security policies.
- Require two-factor (or stronger) authentication for remote sessions
(MFA); use separate authentication mechanisms for internal vs external users where appropriate.
- Change default TCP ports for well-known remote-access protocols away from defaults where that reduces opportunistic scanning (combined with stronger controls, not instead of them).
- Configure VPN so split tunneling is not allowed.
- Monitor and log remote sessions (user ID, time and duration as a minimum).
- Provide on-demand and automatic session termination.
- Encrypt all communication over untrusted networks.
- Harden modem and remote-access software configurations.
- Restrict remote connections to special machines in the IACS DMZ (for example a
jump host) that then reach only selected control-system resources.
- After VPN traffic is decrypted, force it through a firewall and an
IDS before it enters deeper zones.
Preferred access patterns
- Read-only or one-way reporting — prefer unidirectional /
data diode paths when write access is unnecessary.
- Limited data exchange with suppliers and customers — connect only when needed.
- Controlled vendor / employee remote maintenance — minimise access windows; know who is connected and when.
- Full remote operations — a business decision that requires explicit management acceptance; generally not recommended for IACS.
Additional sector guidance is available from bodies such as national infrastructure
protection organisations, NERC (for applicable electric entities), and national public-safety
cybersecurity programs — always start with the vendor and with ISA/IEC 62443 requirements
for your role.
Key takeaways
- Remote access is operationally valuable and a high-risk path into the IACS.
- Design from users, assets, SL-T, threats and monitoring capability — not technology fashion.
- Prefer VPN termination in a DMZ, jump hosts for interactive work, MFA, logging and no split tunneling.
- After decryption, inspect remote-access traffic with firewall and IDS before deeper zones.
- Favour least-privilege patterns (read-only, diodes, time-bounded maintenance) over full remote operations.