Remote Access: A Critical Risk Vector in OT
Remote access to OT environments has become an operational necessity. Control system vendors need access for maintenance and support. Engineering teams require connectivity for monitoring and troubleshooting from centralized locations. Operational staff increasingly need access from off-site during nights, weekends, and emergencies.
At the same time, remote access is consistently one of the highest-risk attack vectors in industrial cybersecurity. Multiple major OT security incidents have involved compromised remote access as the initial entry point or a key enabler of lateral movement. The 2021 Oldsmar water treatment incident, where an attacker accessed a plant's HMI through a remote desktop tool and attempted to increase sodium hydroxide levels to dangerous concentrations, demonstrated the potential consequences with stark clarity.
The challenge is balancing operational need with security. Simply blocking all remote access is rarely feasible. Instead, organizations must implement remote access architectures and controls that enable authorized access while preventing unauthorized use and providing full accountability.
The Dangers of Persistent VPN Connections
Many OT environments rely on persistent site-to-site VPN connections or always-on client VPN tunnels to provide remote access. This approach carries significant risks:
Expanded attack surface. A persistent VPN connection is a permanent bridge between the remote network (which may be a vendor's corporate network, a home network, or a public internet connection) and the OT environment. Any compromise of the remote endpoint can potentially be leveraged to reach OT systems.
Lack of granular control. Traditional VPNs typically provide network-level access. Once connected, the remote user has visibility into and potentially access to the entire OT network segment, rather than only the specific systems they need to reach.
Limited monitoring. Many VPN solutions provide minimal visibility into what the remote user is actually doing once connected. Logging may be limited to connection and disconnection events without capturing the specific actions taken during the session.
Credential exposure. VPN credentials are a high-value target. If a vendor's credentials are compromised through phishing, credential stuffing, or a breach of the vendor's own network, the attacker gains the same access the vendor had.
Unmanaged endpoints. The security posture of the connecting device is often outside the organization's control, especially for vendor access. An unpatched laptop with malware connecting through a VPN can introduce threats directly into the OT environment.
Vendor Remote Access: A Special Challenge
Third-party vendor access deserves particular attention because it combines high privileges with limited organizational control. Control system vendors often require deep access to OT systems, including the ability to modify PLC logic, update firmware, and reconfigure safety systems. At the same time, the organization has limited ability to enforce security standards on vendor personnel, devices, and networks.
Common issues with vendor remote access include:
- Shared credentials where multiple vendor engineers use the same username and password, making it impossible to attribute actions to individuals.
- Persistent access that remains enabled 24/7 even when the vendor only needs occasional connectivity for scheduled maintenance.
- Unmonitored sessions where the vendor performs actions that are neither recorded nor reviewed.
- Daisy-chaining where a vendor connects to one system and then pivots to others that were not part of the original access request.
- Outdated access where former vendor employees or discontinued contracts still have active credentials.
Each of these issues represents both a security vulnerability and a compliance gap against standards such as IEC 62443 and NIST SP 800-82.
Jump Server Architecture
A jump server (also called a bastion host) architecture is the recommended approach for controlling and monitoring remote access to OT environments. In this model, remote users do not connect directly to OT systems. Instead, they connect to a hardened intermediary server in a DMZ, and from that server they access OT systems through controlled and monitored connections.
The jump server architecture provides several critical security benefits:
Single point of control. All remote access to OT passes through the jump server, creating a single enforcement point for access policies, authentication, and monitoring.
Session isolation. The remote user's device never has direct network connectivity to OT systems. The jump server maintains the OT-side connection, and the remote user interacts through a remote desktop or application session on the jump server.
Full session recording. Every action taken through the jump server can be recorded, including screen captures, keystrokes, and file transfers. This provides complete accountability and a forensic record.
Granular access control. Access through the jump server can be restricted to specific target systems, protocols, and time windows. A vendor who needs to access a specific PLC can be granted access to only that PLC and nothing else.
Endpoint posture checking. The jump server can enforce requirements on the connecting device, such as up-to-date antivirus, encrypted disk, and organizational certificate, before allowing the session to proceed.
When implementing a jump server architecture, key design considerations include:
- Place the jump server in a DMZ between the IT and OT networks, not directly on the OT network.
- Harden the jump server by removing unnecessary services, enforcing strong authentication, and keeping it fully patched.
- Implement redundancy if remote access is operationally critical, so that a single server failure does not eliminate all remote connectivity.
- Ensure that the jump server itself is monitored and that its logs are forwarded to a centralized security monitoring system.
Multi-Factor Authentication Requirements
MFA is a non-negotiable requirement for remote access to OT environments. The compromise of a single password should never be sufficient to gain access to industrial control systems.
Effective MFA for OT remote access should:
- Require a second factor for every session. MFA should be enforced at the point of entry to the remote access system, not just at initial enrollment.
- Use phishing-resistant methods. Hardware security keys (FIDO2/WebAuthn) or certificate-based authentication are preferred over SMS or email-based one-time codes, which are vulnerable to interception and social engineering.
- Apply to all users, including vendors. Vendor resistance to MFA requirements should not be accepted. If a vendor cannot support MFA, that vendor's access architecture needs additional compensating controls.
- Integrate with access governance. MFA events should be logged and correlated with session activity for complete audit trails.
Session Recording and Monitoring
Recording and monitoring remote access sessions provides accountability, supports incident investigation, and deters misuse. Effective session monitoring includes:
Video recording of the remote desktop session, capturing everything the remote user sees and does. This is particularly important for vendor sessions where the organization needs to verify that only authorized changes were made.
Keystroke logging to capture commands entered during the session, providing a searchable text record that complements video recording.
File transfer monitoring to detect and log any files moved to or from the OT environment during the session. Unauthorized file transfers are a common indicator of both malicious activity and policy violations.
Real-time alerting on high-risk actions such as attempts to access systems outside the authorized scope, execution of unauthorized commands, or connections during unexpected hours.
Retention and review policies that define how long session recordings are kept and under what circumstances they are reviewed. At minimum, sessions involving changes to safety systems or control logic should be reviewed by a qualified engineer.
On-Demand vs. Persistent Access Models
The access model itself is a critical design decision. Two primary approaches exist:
Persistent access keeps the remote access pathway available at all times. The user can connect whenever they choose, subject to authentication and authorization. This model is simpler to operate but maintains a constant attack surface.
On-demand access requires that the remote access pathway be explicitly activated for a specific user, purpose, and time window. Outside of approved windows, the connection path does not exist. This model significantly reduces the attack surface but requires a process for requesting and approving access.
For OT environments, on-demand access is strongly preferred, especially for vendor access. The process typically works as follows:
- The vendor or remote user submits an access request specifying the target systems, purpose, and required time window.
- An authorized operator or security team member reviews and approves the request.
- The remote access pathway is activated for the approved duration.
- The session is monitored and recorded.
- At the end of the approved window, the access pathway is automatically deactivated.
This approach ensures that remote access exists only when it is needed and that every session is associated with a documented purpose and approval.
Zero Trust Principles for OT Remote Access
Zero trust is a security model based on the principle that no user, device, or network connection should be implicitly trusted. While full zero trust implementation in OT environments faces practical constraints due to legacy devices and real-time requirements, the core principles can and should be applied to remote access:
Verify explicitly. Authenticate and authorize every access request based on all available data points, including user identity, device health, location, and the specific resource being requested.
Use least-privilege access. Grant remote users access only to the specific systems they need for the specific task at hand. Broad network-level access should be replaced with application-level or device-level access controls.
Assume breach. Design the remote access architecture with the assumption that a remote session could be compromised. Implement monitoring, segmentation, and session controls that limit the blast radius of a compromised session.
Continuously validate. Do not treat authentication as a one-time event at the start of a session. Monitor the session for anomalous behavior and be prepared to terminate sessions that deviate from expected patterns.
Applying these principles to OT remote access results in an architecture where every session is authenticated with strong MFA, authorized for specific systems and time windows, monitored in real time, recorded for audit, and automatically terminated when the approved window expires.
Building a Secure Remote Access Program
Implementing secure remote access for OT is not a single project but an ongoing program. Key elements include:
- Policy and governance: Define clear policies for who can access OT remotely, under what conditions, and with what approvals.
- Architecture and technology: Implement a jump server architecture with MFA, session recording, and on-demand access capabilities.
- Vendor management: Include remote access security requirements in vendor contracts and service agreements. Conduct periodic audits of vendor access patterns.
- Training and awareness: Ensure that operations and engineering teams understand the remote access procedures and the security rationale behind them.
- Continuous improvement: Review remote access logs, session recordings, and incident data to identify opportunities to tighten controls and improve processes.
Beacon Security designs and implements secure remote access solutions for OT environments, including jump server architecture, vendor access management, and session monitoring. Contact us to evaluate and strengthen your remote access security posture.
