Introduction
Remote access to operational technology environments is simultaneously one of the highest operational necessities and one of the highest cybersecurity risks in industrial settings. Vendors need remote access to support and maintain control systems they supplied. Operations teams need remote access during off-hours process events. Engineering staff need access from project offices during commissioning. The remote operational demands that drove widespread adoption of OT remote access have not decreased -- if anything, they have accelerated.
The consequence is that remote access vulnerabilities are consistently among the primary initial access vectors in OT incidents. The Colonial Pipeline attack began with compromised VPN credentials on a shared gateway. The Oldsmar water treatment incident exploited a remote desktop tool with shared credentials. Dragos's annual threat intelligence reports have identified remote access exploitation as a leading OT attack entry point year after year. When we review OT incidents at Beacon Security, remote access is where the story starts more often than not -- a compromised credential, a persistent VPN tunnel, a vendor account that was never deactivated after a project closed.
The solution is not to eliminate remote access, which is operationally impractical. It is to build a remote access architecture that provides the necessary connectivity while implementing the controls needed to detect and prevent unauthorized use.
This guide provides a complete technical architecture for secure OT remote access, designed around IEC 62443 principles and grounded in the threat vectors that real-world attackers use. It covers infrastructure design, multi-factor authentication, session recording, vendor access management, and the operational processes required to keep the architecture secure over time.
Architecture Principles
Principle 1: Dedicated OT Remote Access Infrastructure
The most fundamental architectural requirement is that OT remote access uses completely separate infrastructure from corporate remote access. This means:
- A separate VPN gateway or remote access platform dedicated to OT, not shared with the enterprise VPN
- Separate authentication infrastructure: a separate Active Directory or identity provider, not the same corporate AD used for IT systems
- Separate monitoring and logging: OT remote access logs processed independently and reviewed by OT-aware security staff
The rationale for separation is direct: the Colonial Pipeline attack compromised corporate VPN credentials and gained access to a VPN gateway that was shared between corporate and OT connectivity. If OT remote access had been on completely separate infrastructure with separate credentials, the compromise of corporate VPN credentials would not have provided any path to OT systems. Separation is not architectural elegance -- it is a concrete barrier against the most common attack pattern we see.
Principle 2: The Jump Server as the Single Entry Point
All remote access to OT systems should route through a single, hardened jump server (also called a bastion host or jump host) located in the OT DMZ. The jump server:
- Is the only endpoint remotely accessible from outside the OT network
- Makes authorized connections to OT network hosts on behalf of the remote user
- Records all sessions conducted through it
- Has no connections to IT systems or the internet other than the remote access gateway
- Is managed and monitored as a critical security asset
The jump server model limits what a compromised remote access session can do. An attacker who obtains valid credentials and reaches the jump server is still constrained by its access controls, session recording, and monitoring. They cannot pivot directly from the internet to OT devices -- they must operate within the recorded, monitored session environment. That constraint is often enough to detect and interrupt an intrusion before serious damage occurs.
Principle 3: Zero Standing Access
No remote access connection to OT systems should be persistent. Access should be on-demand: established when the authorized user requests it for a specific purpose, and terminated when the session ends.
Standing access -- a persistent VPN tunnel that maintains connectivity indefinitely -- means that a compromised credential provides persistent access without any additional action by the attacker. On-demand access limits the window of exposure to the duration of authorized sessions.
Implement this through session timeouts that terminate idle connections (15-30 minutes for most use cases), time-limited access grants that expire after the maximum expected session duration, and automatic session termination on disconnect.
Infrastructure Components
Remote Access Gateway
The remote access gateway is the internet-facing component that accepts authenticated connections and routes them to the jump server.
Purpose-built OT Remote Access Platforms designed specifically for OT remote access management include:
- Claroty xDome Secure Access (formerly Medigate): Vendor access management with individual credentials, session recording, and time-limited access
- Secomea: Purpose-built for OT vendor remote access, widely used in manufacturing and utilities
- Tosibox: Secure remote access for industrial environments with strong OT vendor ecosystem integration
- Cyolo: Zero Trust Network Access with OT-specific features and session recording
- TeamViewer Tensor with OT mode: Secured remote access with enhanced logging when properly configured
General-purpose SSL VPN / ZTNA platforms adapted for OT use -- Fortinet FortiGate with FortiClient, Palo Alto Networks GlobalProtect, Cisco AnyConnect with Duo MFA -- require more configuration to meet OT remote access requirements but leverage existing infrastructure investment.
Selection criteria: individual credential assignment per user (not per vendor organization), native MFA support, session recording with tamper-proof storage, access request and approval workflow, time-limited access grants, and the ability to restrict access to specific destination systems.
Jump Server Design
The jump server sits in the OT DMZ and is the point of origin for all remote sessions to OT network hosts. It is the most sensitive asset in the remote access architecture -- treat it accordingly.
Operating system: Windows Server (current supported version). The jump server should be maintained with current security patches. Unlike process-side OT systems, the jump server does not run certified process control software, so there is no patching constraint.
Remote desktop services: Configure RDS with certificate-based server authentication, Network Level Authentication (NLA) enabled, clipboard redirection disabled or restricted, and drive mapping disabled to prevent mapping local drives into the jump server session.
Application whitelisting: Only the remote access tools (RDP clients, VNC clients, vendor engineering software for specific authorized use cases) and system management tools should be executable on the jump server. Application whitelisting prevents the jump server from being used as a general-purpose execution environment if compromised.
Network isolation: The jump server should have inbound connections only from the remote access gateway, outbound connections permitted to specific OT network hosts on specific ports, no direct internet access, and no connections to IT network resources except as explicitly required for authentication services.
Session recording: All sessions initiated from the jump server should be recorded with video and keystroke logging. Session recordings should be stored on a tamper-proof storage system accessible only to security administrators. Retention should meet regulatory requirements (minimum 90 days; longer for environments subject to NERC CIP or similar requirements).
MFA Infrastructure
Multi-factor authentication is a hard requirement for OT remote access. No exceptions -- not for any user, any vendor, or any emergency scenario. Emergency access uses pre-provisioned accounts with enhanced monitoring, not MFA bypass.
Beacon Security has reviewed OT environments where MFA was waived for "convenience" -- for a senior engineer who found the token inconvenient, for a vendor who complained about managing tokens for their team, for an emergency procedure that became a permanent exception. Every one of these exceptions is a standing vulnerability. The position must be firm.
MFA technology options for OT remote access:
Hardware TOTP tokens (RSA SecurID, OATH tokens): Physical tokens generating time-based one-time passwords. Appropriate for environments where mobile phones are not permitted or where offline MFA capability is required. Tokens are issued to named individuals.
Authenticator app TOTP (Microsoft Authenticator, Google Authenticator, Duo): Software tokens on the user's smartphone. Most common for workforce users. Requires smartphone availability.
FIDO2 hardware keys (YubiKey, FEITIAN): USB or NFC hardware authenticators with phishing-resistant authentication. More secure than TOTP against credential phishing. Appropriate for high-security environments.
PKI smart cards: Certificate-based authentication using hardware smart cards. Common in government and critical infrastructure environments.
Avoid SMS OTP for OT remote access. SMS OTP is vulnerable to SIM-swapping attacks and is increasingly recognized as insufficient for high-risk access scenarios. If SMS OTP is currently deployed, plan to migrate to a more secure method.
Vendor Access Management
Vendor access to OT systems represents the highest-risk category of remote access. The specific failure patterns we see repeatedly at Beacon Security: credentials shared across large field teams under a single "site account," vendor engineers with far broader access than their current task requires, accounts for former employees that were never revoked because nobody was notified when the engineer left the company. These are not hypothetical risks -- they are the actual conditions we find in the field.
Individual Credentials Per Vendor Engineer
Every vendor engineer who accesses OT systems must have an individual credential assigned to them personally. Shared vendor accounts must be eliminated.
Implementation: provision individual accounts in the OT remote access platform for each named vendor contact. Require vendors to notify you when an engineer who held an account departs -- establish contractual requirements for this. Set account expiration dates aligned with the expected project timeline or support contract period. Conduct quarterly reviews to identify and revoke stale accounts.
Access Scope Restriction
Vendor accounts should be scoped to the specific systems the vendor is authorized to access. A Siemens SCADA support engineer should not be able to connect to Rockwell PLCs in a different process area. A pump vendor's service engineer should be able to reach the pump control panel HMI but not the central SCADA server.
Use the jump server's access control lists and session routing capabilities to enforce destination-specific access per user. Modern OT remote access platforms support policy definitions that link specific users to specific destination hosts.
On-Demand Connection Model
The preferred model for vendor access is on-demand: the vendor contacts the facility to request a remote session for a specific maintenance task. The operations team or security team activates the vendor's access for the duration of the task and deactivates it when complete.
This model prevents standing vendor access pathways that can be exploited without the facility's awareness. It does require that the facility be reachable to activate access -- for urgent after-hours support, establish an emergency contact procedure that reaches the on-call operations or security team.
Vendor Access Agreements
Remote access requirements should be specified in vendor contracts: individual credentials required and shared accounts prohibited, MFA required for all connections, session recording by the asset owner, notification required when a named individual who held access credentials leaves the vendor organization, prohibition on transferring credentials to third parties, and the right to audit vendor remote access activity.
IEC 62443 Remote Access Alignment
IEC 62443 Part 3-3 provides specific security requirements for access control in OT environments that directly apply to remote access architecture.
SR 1.1 Account Management: Individual credentials per user, regular account review, formal provisioning and revocation processes. Directly addressed by the individual credential model above.
SR 1.2 Software Process and Device Identification and Authentication: Devices connecting to OT systems should be authenticated, not just users. Enforce this through certificate-based authentication on the remote access gateway.
SR 1.3 Account Management for Software Processes: Machine-to-machine connections should use service accounts with restricted permissions, not interactive user accounts.
SR 1.7 Strength of Password-Based Authentication: Password complexity and rotation requirements for remote access accounts.
SR 1.11 Unsuccessful Login Attempts: Account lockout after a defined number of failed authentication attempts, implemented on the remote access gateway.
SR 1.13 Access via Untrusted Networks: The remote access architecture addresses this SR directly -- all connections from untrusted networks transit the access gateway and jump server with authentication and monitoring.
Bandwidth Optimization for Constrained OT Connections
Many OT remote access scenarios -- remote sites on cellular connections, offshore platforms on satellite links, geographically distributed SCADA systems -- operate on bandwidth-constrained connections. Remote desktop sessions over low-bandwidth connections become unusable without optimization.
RDP optimization: Reduce color depth to 16-bit for low-bandwidth connections. Disable visual effects and animation. Enable RDP compression. For extremely low bandwidth, evaluate text-based remote access (SSH with OpenSSH, or PowerShell remoting) for administrative tasks that do not require GUI.
Traffic prioritization: For sites with shared internet connections, mark OT remote access traffic for QoS prioritization. Operational remote access should not compete with bulk transfers on the same connection.
Operational Processes
Architecture provides the framework; operational processes make it function. The best jump server design in the world does not help if credentials are being provisioned informally by email, vendor accounts are never reviewed, and session recordings are stored but never checked.
Access Request and Approval Workflow
Define a formal process for requesting remote access:
- Requestor submits access request specifying purpose, destination systems, and expected duration
- System owner (or operations team) approves or denies
- Security team provisions the access grant for the approved duration
- Access is activated at the requested time and automatically expires at the end of the approved window
- Post-access review: session recordings are reviewed within 24 hours of completion for sensitive access, within one week for routine access
Regular Access Review
Monthly review of active remote access accounts: Are all active accounts for current employees or active vendor relationships? Are access scopes still appropriate? Are there any accounts that have not been used in the past 30 days? Review and revoke if no ongoing need.
Incident Response for Remote Access Incidents
If unauthorized remote access is suspected: immediately revoke all active remote access sessions, reset all remote access credentials pending investigation, preserve session recordings and access logs for forensic analysis, determine the scope of access (which systems were accessed, what actions were taken), and restore access only after the investigation has determined the entry point and closed it.
Conclusion
Secure OT remote access is achievable without eliminating the operational flexibility that remote access provides. The architecture described in this guide -- dedicated infrastructure, jump server with session recording, MFA without exception, individual vendor credentials, on-demand access -- addresses the specific vulnerabilities that attackers exploit while preserving the remote access capabilities that vendors and operations teams require.
The investment required is modest relative to the risk reduction achieved. Remote access vulnerabilities have been the entry point for some of the most consequential OT incidents in history. Closing those entry points with a properly designed remote access architecture is among the highest-return security investments available to industrial organizations.
Beacon Security provides OT remote access architecture design, implementation, and configuration services for industrial environments. We help organizations replace legacy VPN and remote desktop solutions with secure, auditable, and operationally appropriate remote access infrastructure. Contact us to assess and redesign your OT remote access architecture.
