Secure Remote Access Architecture for OT Environments

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. The Oldsmar water treatment incident exploited a remote desktop tool with shared credentials. Dragos's annual threat intelligence reports consistently identify remote access exploitation as a leading OT attack entry point.

The solution is not to eliminate remote access — that 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.

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
Provides access to OT systems from which it can make authorized connections to OT network hosts
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 for the remote access gateway and reaches the jump server is still constrained by the jump server's access controls, session recording, and monitoring. They cannot pivot directly from the internet to OT devices — they must go through the recorded, monitored session environment.

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 after a defined period (15-30 minutes for most use cases)
Time-limited access grants: the access credential or session token expires after the maximum expected session duration
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. Appropriate technology options include:

Purpose-built OT Remote Access Platforms: Solutions designed specifically for OT remote access management include:

Claroty xDome Secure Access (formerly Medigate): Provides 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: Provides 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. These 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
Audit logging at sufficient detail for forensic use
Ability to restrict access to specific destination systems
Vendor notification capability (ability to send vendor connection invitations rather than providing persistent credentials)

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.

Operating system: Windows Server (current supported version). The jump server should be maintained with current security patches — it is not subject to the same patching constraints as process-side OT systems because it does not run certified process control software.

Remote desktop services: Configure Remote Desktop Services (RDS) with:

Certificate-based server authentication (prevent MITM against the jump server connection)
Network Level Authentication (NLA) enabled
Clipboard redirection disabled or restricted to prevent data exfiltration via clipboard paste
Drive mapping disabled to prevent mapping the user's local drives into the jump server session
Printer mapping disabled unless specifically required

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.

Network isolation: The jump server should have:

Inbound connections only from the remote access gateway (the VPN or ZTNA platform)
Outbound connections permitted to specific OT network hosts on specific ports
No direct internet access from the jump server itself
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. There should be no exceptions for any user, any vendor, or any emergency scenario (emergency access uses pre-provisioned accounts with enhanced monitoring, not MFA bypass).

MFA technology options for OT remote access:

Hardware TOTP tokens (RSA SecurID, OATH tokens): Physical tokens that generate 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. Requires PKI infrastructure.

Avoid SMS OTP (one-time passwords delivered via SMS) 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 MFA method.

MFA for vendor access: Many vendors resist MFA requirements, citing the inconvenience of managing tokens for a large field workforce. The position must be firm: no exceptions to MFA for vendor remote access. Purpose-built OT remote access platforms typically include vendor MFA enrollment workflows that make this practical.

Vendor Access Management

Vendor access to OT systems represents the highest-risk category of remote access because:

Vendor credentials are frequently shared across large teams ("use the Site A account")
Vendors have broad access requirements to the systems they support
Vendor security practices are outside the asset owner's direct control
Vendor personnel change frequently, and revocation of former employee credentials is often delayed

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 for all remote access; shared accounts prohibited
MFA required for all remote access connections
Session recording by the asset owner; vendor access logs available to the asset owner on request
Notification required when a named individual who held access credentials leaves the vendor organization
Prohibition on transferring access credentials to third parties
Right to audit vendor remote access activity

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 techniques:

Reduce color depth to 16-bit for low-bandwidth connections
Disable visual effects and animation in the remote desktop session
Enable RDP compression (enabled by default in recent Windows versions)
For extremely low bandwidth, evaluate text-based remote access (SSH to Windows with OpenSSH, or PowerShell remoting) for administrative tasks that do not require GUI

Session recording bandwidth: If session recording occurs at the jump server rather than the gateway, it does not add to the WAN bandwidth required for the remote session. Session recording at the gateway may add overhead — verify with the platform vendor.

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.

IEC 62443 Remote Access Alignment

IEC 62443 Part 3-3 (SR 1.1 through SR 1.13) 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, requiring devices with valid certificates to establish connections.

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.9 Strength of Public Key Authentication: For certificate-based remote access, key length and algorithm requirements.

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 (the internet, vendor networks) transit the access gateway and jump server with authentication and monitoring.

Operational Processes

Architecture provides the framework; operational processes make it function:

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: the session recordings for the session 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 (no scope creep over time)?
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
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.