Secure Remote Access to ICS - Security Principles

In May 2021, Colonial Pipeline’s operator paid USD 4.4 million in ransom to the DarkSide group. The entry vector? A single compromised VPN password without multi-factor authentication. In December 2025, a coordinated attack on Polish renewable energy infrastructure exploited vulnerable edge devices with internet access, damaging RTU controller firmware in over 30 installations (CISA Alert, February 2026). Both incidents share a common denominator - poorly secured remote access to OT networks.

Remote access is essential - maintenance, diagnostics, firmware updates, and process monitoring all require connectivity. But every remote connection is an additional attack surface. Below we present 17 principles of secure remote access to industrial control systems (ICS), developed based on IEC 62443, NIST SP 800-82 Rev. 3, CISA recommendations, and experience from critical infrastructure projects.

Foundations - architecture and threats

Why remote access to OT is harder than IT

In IT networks, remote access via VPN has been standard for years - and a natural reaction of many organizations is to transfer the same patterns to operational technology (OT). This is where problems originate: PLCs exposed to the internet, simple VPN + RDP as the only protection, shared service accounts without MFA. OT environments have different priorities and constraints:

Aspect	IT	OT
Priority	Data confidentiality	Availability and physical safety
Downtime tolerance	Minutes to hours	Seconds (continuous processes cannot be interrupted)
Updates	Regular, automatic	Rare, requiring maintenance windows and testing
Protocols	HTTP/S, SSH, RDP (with authentication)	Modbus, OPC, S7comm (often without authentication)
Lifecycle	3-5 years	15-25 years
Attack impact	Data loss, service disruption	Equipment damage, threat to life, environmental disaster

These differences mean that simply transferring IT solutions (VPN + RDP + password) is not sufficient. In OT you cannot terminate a session at any moment, you cannot automatically update devices on the other end of the connection, and control protocols (Modbus, S7comm) do not offer their own authentication mechanisms. Protections must be implemented at the network architecture level - hence the 17 principles described below.

Incidents related to remote access

Poorly secured remote access is one of the most common attack vectors against OT systems. The following incidents illustrate different scenarios and their consequences.

Incident	Year	Remote access vector	Consequences
Colonial Pipeline	2021	VPN without MFA, compromised password	Pipeline shutdown for 6 days, USD 4.4 million ransom
Oldsmar Water	2021	TeamViewer on HMI station - internet accessible	Attempt to increase NaOH concentration from 100 to 11,100 ppm
Dharma ransomware	2019-2020	RDP exposed to the internet	Encryption of SCADA systems via compromised terminal server
Attack on renewables in Poland	2025	Vulnerable edge devices	Wiper malware, RTU firmware damage, loss of connectivity
Volt Typhoon	2024	VPN and edge device exploits (Fortinet, Ivanti)	Pre-positioning in US critical infrastructure

Sources: CISA advisories, FBI/DOE joint fact sheet, CERT Polska, Mandiant Threat Research.

Segmentation as the foundation of remote access

Every remote access solution for OT must be built on proper network segmentation. According to IEC 62443-3-2, an industrial network is divided into zones with common security requirements, connected by conduits with controlled communication.

Remote access is a conduit in the standard’s definition - and must be treated with the same rigor as any other data flow between zones. The remote access point should be located in a dedicated DMZ zone, not directly in the OT network.

---

17 principles of secure remote access to OT

The principles are grouped into five categories corresponding to the main risk areas:

Category	Principles	What it covers
Architecture	1-4	How to build the access path - DMZ, two-hop architecture, connection direction
Authentication and authorization	5-8	Who can enter and under what conditions - MFA, accounts, permissions
Monitoring and logging	9-12	What is visible in active sessions - logs, recording, OT protocol inspection
Activity restriction	13-15	What should be remotely accessible at all - SIS, file transfer, time windows
Hardening	16-17	Protection of the access infrastructure itself and incident readiness

Architecture

Principle 1: Avoid cascading risk transfer NIST SP 800-53: SC-7 (Boundary Protection), SC-7(5) (Deny by Default)

The remote access architecture should not allow traversal with a single protocol from the internet through the DMZ to the OT network. If the access chain is: VPN -> terminal server (RDP) -> engineering workstation (RDP), then compromising a single RDP vulnerability opens a path to OT. Dharma ransomware (2019-2020) exploited exactly this scenario - propagating through compromised RDP terminal servers to SCADA systems.

Principle 2: Connections initiated from the protected side NIST SP 800-53: SC-7(5) (Deny by Default, Allow by Exception)

Firewall rules should block all incoming connections to the OT network. Instead, the connection should be initiated from the OT network outward (to the DMZ zone). This way, inbound ports are not constantly exposed, and the session is available only temporarily.

Principle 3: DMZ zone as a buffer NIST SP 800-53: SC-7(4) (External Telecommunications Services - DMZ)

A DMZ zone with firewalls on both sides must exist between the corporate network and OT. Intermediary servers (jump servers, terminals) should be located in the DMZ, not in the OT network. No production data should be stored on DMZ servers.

Principle 4: No direct internet access to OT NIST SP 800-53: AC-17 (Remote Access), SC-7 (Boundary Protection)

No OT device should be directly accessible from the internet - neither through port forwarding nor by exposing a VPN endpoint directly on an OT device. This also applies to edge devices, VPN concentrators, and LTE modems. In its May 2025 recommendations, CISA explicitly prohibits exposing OT management interfaces to the internet, even indirectly.

Authentication and authorization

Architecture creates the framework - authentication determines who can enter and under what conditions.

Principle 5: Multi-factor authentication (MFA) NIST SP 800-53: IA-2(1) (MFA - Network Access), IA-2(2) (MFA - Non-privileged Access)

Every remote access to the OT network must require multi-factor authentication. MFA should be required at each hop: when logging into the VPN, when accessing the jump server, and when accessing the engineering workstation.

IEC 62443-3-3 SR 1.1 RE 2 requires MFA for access through untrusted networks from SL 3. In practice, every remote access traverses an untrusted network.

The choice of MFA method for OT environments has specific constraints:

MFA method	OT advantages	Limitations	When to use
Hardware TOTP (YubiKey, Token2)	No smartphone required (often prohibited in factories), works offline, OATH RFC 6238 standard	Requires physical token distribution	Most OT environments
FIDO2 / WebAuthn (YubiKey 5)	Strongest protection, phishing-resistant, no connectivity required	Not compatible with legacy VPN clients	High-security environments (SL 3-4)
Smart card / PIV	Standard in the energy sector (NERC CIP)	Requires card reader on the workstation	Utilities, critical infrastructure
TOTP app (Google Auth, MS Authenticator)	Low cost, easy distribution	Requires smartphone	Only when smartphones are permitted on site
SMS OTP	-	NIST SP 800-63B does not recommend, telecom dependency	Do not use

Principle 6: Connection acceptance on the protected side NIST SP 800-53: AC-17(1) (Monitoring and Control of Remote Access)

A remote connection should not be established automatically. A person with permissions on the OT side (e.g., a maintenance engineer) should consciously accept the session - e.g., by generating a one-time link or approving a request in an application. Dedicated SRA systems implement this as a workflow: the service technician submits a request, the OT-side engineer approves it, and the system generates a one-time token with a time window.

In unmanned installations (subsea, unattended, remote farms), acceptance can be implemented through technical means - e.g., a dedicated out-of-band communication channel, approval via a mobile application, or a pre-authorized maintenance window schedule.

Principle 7: Individual accounts, not shared NIST SP 800-53: IA-2 (Identification and Authentication), AC-2 (Account Management)

Every remote user must have an individual account. Shared accounts (“service_vendor1”) make auditing and accountability impossible. IEC 62443-3-3 SR 1.1 RE 1 requires unique identification of every user from SL 2 - this also applies to machine accounts and automation scripts.

Vendor service accounts should be tied to a specific work order - see Principle 15 on JIT access. CISA recommends locking accounts after multiple failed login attempts and removing inactive service accounts.

Principle 8: Principle of least privilege NIST SP 800-53: AC-6 (Least Privilege), AC-6(1) (Authorize Access to Security Functions)

A remote user should have access only to those systems and functions that are necessary for the specific task. IEC 62443-3-3 SR 2.1 RE 1 requires role-based authorization (RBAC) - a service engineer has a different set of permissions than an operator, network administrator, or auditor.

In practice, this means separating the role “can read PLC parameters” from “can modify PLC program” and “can start/stop the process.” SR 2.1 RE 3 (from SL 4) requires dual approval - critical operations require approval by two people.

Monitoring and logging

Even correct architecture and strong authentication are not sufficient if you cannot see what is happening in active sessions.

Principle 9: Traffic monitoring and identification NIST SP 800-53: SI-4 (System Monitoring), AU-2 (Event Logging)

All remote access traffic should be monitored and logged - with timestamp, user identifier, source and destination address, protocol, and result (success/failure). The system should generate alerts for: connections at unusual hours, connections from unknown locations, anomalies in OT protocols (unusual Modbus function codes, PLC register write attempts, program changes), and access attempts outside the scope of permissions.

Deep packet inspection (DPI) requires firewalls that understand industrial protocols - not just IP addresses and ports, but the content of control commands. Modbus TCP (port 502) is the most widely used control protocol in industrial installations. Every command has a function code (FC) - the table below classifies them by risk:

Function code	Operation	Risk	Recommendation
FC 01-04	Read Coils / Discrete Inputs / Holding Registers / Input Registers	Low (reconnaissance)	Permitted from SCADA/HMI, logged
FC 05, 06	Write Single Coil / Single Register	High (state change)	Only from authorized engineering workstations, with time window
FC 15, 16 (0x0F, 0x10)	Write Multiple Coils / Multiple Registers	High	Same as FC 05/06 - restrict to maintenance windows
FC 08	Diagnostics (loopback, reset counters)	Medium	Block from untrusted networks
FC 43 (0x2B)	Read Device Identification	Medium (discloses information)	Block from untrusted networks

Firewalls with DPI support for OT protocols: Fortinet FortiGate (80+ OT protocols, 3,000+ command types), Palo Alto Networks NGFW (App-ID for Modbus, DNP3, IEC 104, OPC), Cisco IE4010/IR8340 (native Modbus TCP filtering), Moxa EDR-G9010 (DPI for Modbus, EtherNet/IP, PROFINET, OPC UA). Passive monitoring (no risk of process impact): Claroty, Nozomi Networks, Dragos - operating in tap/span port mode.

Principle 10: Terminate traffic in the DMZ, do not tunnel to OT NIST SP 800-53: SC-7(7) (Prevent Split Tunneling), SI-4 (System Monitoring)

An end-to-end encrypted tunnel between the remote server and the OT device prevents traffic inspection. Traffic should be terminated at the firewall or intermediary device in the DMZ, where it can be inspected (DPI), and then forwarded to OT in a separate session.

Principle 11: Session recording NIST SP 800-53: AU-3 (Content of Audit Records), AU-12 (Audit Record Generation)

Remote access sessions to OT systems should be recorded (screen recording, keystroke logging). Recordings serve as evidence in case of an incident and as an audit tool.

Session recording tools in the OT context:

Tool	Protocols	Key features	OT specifics
CyberArk PSM	RDP, SSH, VNC	Transparent proxy, keystroke indexing, Zero Standing Privileges	Integrations with Rockwell, Schneider Electric
BeyondTrust PRA	RDP, SSH, VNC, HTTPS	Command allowlist/blocklist in SSH, ruggedized appliance	Jump technology without direct IP connectivity
Wallix Bastion PAM4OT	RDP, SSH, VNC	OCR on recordings (searchable text), agentless	Dedicated OT version, IEC 62443-2-4 compliant
ManageEngine PAM360	RDP, SSH, Telnet, VNC, SQL	Session shadowing, live takeover	Routing through jump server to PLC/SCADA

Key requirement: recordings must be stored in a location inaccessible to the recorded users (immutable audit log).

Principle 12: Session management NIST SP 800-53: SC-10 (Network Disconnect), AC-12 (Session Termination)

The OT-side administrator should have the ability to view active sessions in real time, terminate sessions when irregularities are detected, and set time limits (auto-disconnect after timeout - NIST recommends 15-30 minutes of inactivity).

Activity restriction

Principles 1-12 address how to build and control access. Principles 13-15 answer the question: what and when should be remotely accessible at all.

Principle 13: Restrict access to OT components NIST SP 800-53: AC-3 (Access Enforcement), PE-3 (Physical Access Control)

Systems performing safety functions (SIS - Safety Instrumented Systems) should not be accessible via remote access. Remote modification of SIS logic is an unacceptable risk in most environments - IEC 62443-3-3 SR 5.1 requires separation of SIS from the rest of the OT network. NIST SP 800-82 Rev. 3 Section 5.5 explicitly addresses protection of safety systems.

Principle 14: File transfer control NIST SP 800-53: SI-3 (Malware Protection), MA-4 (Nonlocal Maintenance)

Files transferred to the OT network (firmware, configurations, patches) must undergo malware scanning in the DMZ zone. NIST MA-4 requires authorization and monitoring of remote maintenance, including file transfers. Dedicated SRA systems offer on-the-fly scanning.

Principle 15: Time-limited access (JIT) NIST SP 800-53: AC-2(2) (Automated Temporary and Emergency Account Management)

Remote access should be active only for the duration of work - the Just-In-Time (JIT) model. The account is activated upon request, with a defined time window, and automatically deactivated when time expires. NIST AC-2(2) requires automated management of temporary and emergency accounts - including automatic deactivation.

A forgotten service account active months after work completion is a typical attack vector. JIT eliminates this risk structurally - tools such as CyberArk Alero or BeyondTrust JIT access generate credentials on demand and revoke them automatically.

Hardening and access infrastructure protection

Every device in the remote access chain is a potential target - from the VPN concentrator to the jump server.

Principle 16: Hardening of access devices NIST SP 800-53: CM-7 (Least Functionality), SI-2 (Flaw Remediation)

Terminal servers, jump servers, VPN concentrators - every device in the remote access chain must be hardened according to CIS Benchmarks. NIST CM-7 requires limiting functionality to the necessary minimum - which in practice means:

Principle 17: Contingency plan and disconnection procedure NIST SP 800-53: IR-4 (Incident Handling), IR-8 (Incident Response Plan)

A documented and rehearsed procedure for immediate disconnection of remote access upon incident detection must exist. NIST IR-4 breaks incident handling into six phases - from preparation to recovery. The disconnection procedure should be defined for each of them.

Decision matrix - choosing a remote access solution

The choice of solution depends on the required Security Level (SL) according to IEC 62443, budget, and environment specifics. The matrix below helps evaluate available options.

Criterion	VPN + RDP (typical IT)	Dedicated SRA (Honeywell, Claroty, Dispel)	Zero Trust OT (Zscaler, Secomea)
IEC 62443 compliance	Partial - requires additional configuration	Full - designed for OT	Full - built-in zones and conduits
MFA	Needs to be added	Built-in	Built-in
Session recording	Needs to be added (e.g., CyberArk)	Native	Native
OT protocol inspection	None	DPI Modbus, OPC, S7	Depends on the solution
JIT access	Manual	Built-in workflow	Built-in
Initiation from protected side	Difficult to implement	Standard feature	Standard feature
File scanning	Needs to be added	Built-in	Depends
Cost	Low (existing infrastructure)	Medium-high (license + deployment)	Medium-high (subscription)
Deployment complexity	Low	Medium	Medium-high
Recommendation	Temporary, low SL	SL 2-3, production, energy	SL 3-4, critical infrastructure

SL = Security Level per IEC 62443. SL 1: protection against accidental violations. SL 2: protection against intentional attack with simple means. SL 3: protection against sophisticated attack. SL 4: protection against APT attack.

Remote access audit checklist for OT

The following checklist allows you to assess the current state of security controls and identify gaps requiring remediation. It can be used as a starting point for a quarterly review or as the scope of an IEC 62443 audit. If you need assistance designing a remote access architecture for OT - contact us.

Category	Element	Description	Status
Architecture	DMZ	Remote access passes through a DMZ zone with firewalls on both sides
	No direct access	No OT device is directly reachable from the internet
	Different protocols at each hop	Connection to DMZ and from DMZ to OT uses different protocols
	Initiation from protected side	Connections initiated from OT to DMZ, not the reverse
Authentication	MFA at each hop	Multi-factor authentication on VPN, jump server, and target workstation
	Individual accounts	Each user has a unique account with assigned identity
	JIT access	Service accounts active only for the duration of work
	OT-side acceptance	A person on the protected side approves each session
Monitoring	Session logs	All sessions logged with timestamp, user, source
	Screen recording	Sessions to critical systems are recorded
	Anomaly alerting	Alerts for unusual hours, locations, actions
	OT traffic inspection	Traffic terminated at firewall/DPI, not tunneled end-to-end
Restrictions	SIS not remotely accessible	Safety Instrumented Systems not accessible via remote access
	File scanning	Files transferred to OT scanned for malware
	Time limits	Sessions with auto-disconnect after timeout
	Minimum privileges	Users have access only to necessary systems
Hardening	Access device updates	Jump servers, VPN, edge devices up to date
	Disconnection procedure	Documented emergency remote access shutdown procedure
	Quarterly review	Regular review of accounts, permissions, and firewall rules

Mapping principles to IEC 62443 and NIST SP 800-82

Each of the 17 principles maps to specific standard requirements. The table below allows demonstrating compliance with regulatory requirements.

Principle	IEC 62443	NIST SP 800-82 Rev. 3	NIST SP 800-53
1. No cascading risk	62443-3-3 SR 5.1 (segmentation)	Section 5.1 (architecture)	SC-7 (boundary protection)
2. Initiation from protected side	62443-3-3 SR 5.2 (zone control)	Section 5.3 (firewall)	SC-7(5) (deny by default)
3. DMZ	62443-3-3 SR 5.1	Section 5.1, 5.3	SC-7(4) (DMZ)
4. No direct access	62443-3-3 SR 5.1, SR 5.2	Section 5.3	SC-7, AC-17
5. MFA	62443-3-3 SR 1.1, SR 1.2	Section 6.2 (authentication)	IA-2(1), IA-2(2)
6. OT-side acceptance	62443-3-3 SR 2.1	Section 6.2	AC-17(1)
7. Individual accounts	62443-3-3 SR 1.1	Section 6.2	IA-2, AC-2
8. Least privilege	62443-3-3 SR 2.1	Section 6.2	AC-6 (least privilege)
9. Traffic monitoring	62443-3-3 SR 6.1	Section 6.4 (monitoring)	SI-4, AU-2
10. No end-to-end tunnels	62443-3-3 SR 5.2, SR 3.1	Section 5.3	SC-7, SI-4
11. Session recording	62443-3-3 SR 6.1, SR 6.2	Section 6.4	AU-3, AU-12
12. Session management	62443-3-3 SR 2.5	Section 6.2	SC-10, AC-12
13. SIS access restriction	62443-3-3 SR 5.1	Section 5.5 (safety)	PE-3, AC-3
14. File control	62443-3-3 SR 3.2	Section 6.3	SI-3 (malware protection)
15. JIT access	62443-3-3 SR 2.1	Section 6.2	AC-2(2) (temporary accounts)
16. Hardening	62443-3-3 SR 7.1, SR 7.2	Section 6.5	CM-7, SI-2
17. Disconnection procedure	62443-3-3 SR 6.2	Section 6.6 (IR)	IR-4, IR-8

NIST SP 800-53 controls mapping

Key NIST SP 800-53 Rev. 5 controls for secure remote access to OT:

Control	Name	Significance for remote access
AC-17	Remote Access	Remote access policy, authorization, encryption, monitoring
IA-2	Identification and Authentication	User authentication with MFA
SC-7	Boundary Protection	Firewall, DMZ, zone flow control
SC-10	Network Disconnect	Automatic disconnection after session timeout
AU-2	Event Logging	Remote access event logging
AU-12	Audit Record Generation	Session recording, keystroke logging
AC-6	Least Privilege	Minimum privileges for remote users
SI-4	System Monitoring	Network traffic anomaly monitoring
IR-4	Incident Handling	Remote access incident response procedures

Source: NIST SP 800-53 Rev. 5, NIST SP 800-82 Rev. 3, IEC 62443-3-3.

Reference architecture

The following text diagram illustrates the recommended remote access architecture for OT networks:

Internet
    |
[External firewall]
    |
=== DMZ Zone ===
    |-- VPN Gateway (MFA, tunnel termination)
    |-- Jump Server / SRA Portal (session recording, DPI)
    |-- File kiosk (malware scanning)
    |
[Internal firewall] (connections initiated from OT)
    |
=== OT Network ===
    |-- Engineering workstation (session acceptance)
    |-- HMI / SCADA
    |-- PLC / RTU
    |
=== SIS Network === (no remote access)
    |-- Safety PLC
    |-- Emergency Shutdown

Sources

• NIST SP 800-82 Rev. 3 “Guide to OT Security” (2023)
• IEC 62443-3-3 “System Security Requirements and Security Levels”
• NIST SP 800-53 Rev. 5 “Security and Privacy Controls”
• CISA “Configuring and Managing Remote Access for ICS” (2023)
• CISA/FBI/DOE “Primary Mitigations to Reduce Cyber Threats to OT” (May 2025)
• CISA Alert “Poland Energy Sector Cyber Incident” (February 2026)