Securing OT Remote Access: VPN, ZTNA, and Jump Server Architecture for Industrial Networks

The Persistent Remote Access Problem

The 2020-2022 period forced rapid expansion of remote access into operational technology environments. Control engineers who had always worked on-site needed remote visibility. Equipment vendors who previously sent technicians on-site needed remote diagnostic access. Integrators maintaining automation systems needed to push configuration changes without travel. The access was stood up quickly, under operational pressure, and with limited security engineering.

In most organisations, that access was never systematically reviewed. What was installed as a temporary measure became permanent infrastructure. VPN accounts provisioned for specific projects were never deprovisioned. Vendor remote access credentials were shared among multiple technicians. Jump servers were added to DMZs without the surrounding network controls that make them effective.

CISA’s 2024 and 2025 advisories on internet-exposed ICS infrastructure consistently highlight remote access misconfiguration as a primary initial access vector across critical infrastructure sectors. The problem is not new and the defensive steps are well-understood — the obstacle is operational complexity and the reluctance to change access mechanisms that production teams depend on daily.

The Remote Access Risk Landscape

Direct VPN to OT Network

The most common and highest-risk pattern: a VPN endpoint that, when connected, places the remote user’s machine directly on the OT network (or a segment with broad access to it). This model was established when IT VPNs were extended into OT environments without OT-specific segmentation.

The primary risk is the remote machine. An engineer connecting from a home workstation that is compromised, or from a laptop with outdated patches, brings that compromise into the OT network the moment the VPN tunnel establishes. The VPN authenticates the user; it does not assess the health of the endpoint.

Secondary risks include credential theft (VPN credentials are high-value targets because they provide OT network access directly) and lateral movement (once on the OT network segment, an attacker has direct network access to PLCs, HMIs, historians, and engineering workstations without additional lateral movement required).

Site-to-Site VPN (IT/OT)

Permanent site-to-site VPNs between IT and OT networks, often established for data historian connections or integrated monitoring, are a stable lateral movement path. A threat actor who compromises the IT environment and discovers a site-to-site tunnel into the OT network has effectively bypassed the IT/OT boundary without any additional credential theft.

These tunnels are rarely configured with the minimum necessary access rules. Typically, they permit broad IP ranges on both sides rather than host-pair-specific rules for the specific applications the tunnel was built to support.

Vendor Remote Access

Vendor remote access — the channel through which equipment vendors (Siemens, Rockwell, Emerson, ABB, Schneider, and others) access equipment for remote diagnostics, firmware updates, and troubleshooting — is structurally different from employee remote access. The vendor access account is controlled by the vendor, not by the asset owner. The device being used to connect is a vendor device, not an organisational asset. The credentials may be shared among multiple vendor technicians.

Multiple ICS security incidents over the past decade involved initial access through vendor remote access credentials. In many cases, the access was not active during the incident — the credentials had been used legitimately in the past and remained valid long after the vendor engagement ended.

Jump Servers Without Surrounding Controls

A jump server (also called a bastion host or privileged access workstation) is the correct architectural approach for OT remote access: users connect to the jump server, and from the jump server connect to OT assets. The jump server is the only host in the DMZ with lateral access to the OT network, minimising the attack surface.

The problem is that jump servers are frequently misconfigured. The jump server itself runs a general-purpose OS with a wide software installation, direct internet access, broad network permissions into the OT zone, and no enhanced logging. This inverts the security benefit: instead of being a hardened choke point, the jump server becomes the highest-value target in the environment — if compromised, it provides direct access to OT assets without any further movement.

The Recommended Architecture

Layer 1: Network Segmentation

Before addressing remote access specifically, the network architecture needs to support it. The Purdue Model’s DMZ concept — a zone between the corporate IT network and the OT network that mediates all traffic between them — needs to be implemented and enforced, not just documented.

The DMZ should contain:

• The jump server(s) for remote access
• Data historians (one-way data flow from OT to historian, using unidirectional gateways or protocol break)
• Any IT/OT integration services (SCADA data feeds to ERP, for example)

Network access from the IT side should be limited to: specific hosts (the jump servers and integration servers), specific protocols, specific destination IPs in the OT DMZ. Network access from the DMZ to the OT network should be limited to: jump server to specific management interfaces (RDP/VNC/web console), historian to data source interfaces, integration servers to specific API endpoints.

Firewall rules should be host-pair and port-specific, reviewed at least annually, and any rule that permits any as a source or destination in either direction should be flagged for remediation.

Layer 2: Jump Server Hardening

The jump server is the chokepoint; it needs to be hardened accordingly.

Dedicated hardware or isolated VM. The jump server should not run general-purpose workloads. If virtualised, it should be on a hypervisor physically located in a controlled environment.

Minimal software installation. Only the tools needed for OT access: the HMI clients, vendor diagnostic tools, remote desktop clients. No web browsers with general internet access, no email clients, no development tools.

No direct internet access. The jump server should have no outbound internet connectivity. Software updates should be applied from an internal patch server or via a change management process that pushes updates from a managed source.

Full session recording. Every session on the jump server should be recorded at the screen level. This is both a security control (supporting forensic investigation) and a compliance requirement under many regulatory frameworks. Session recordings should be stored off the jump server, in storage that is not accessible from the OT network.

Privileged Access Management integration. Integrate the jump server with a PAM solution (CyberArk, BeyondTrust, Delinea, or equivalent). PAM provides: credential vaulting (users check out credentials for each session rather than knowing static passwords), session management (PAM intermediates the session, recording it and providing just-in-time access), and audit trails (full log of who accessed what, when, and for how long).

Layer 3: Zero Trust Network Access for Remote Users

ZTNA (Zero Trust Network Access) replaces the VPN-to-OT-network model with a model that provides application-level access rather than network-level access. A ZTNA agent on the remote endpoint establishes an encrypted tunnel to the ZTNA access proxy, which controls access to specific applications (the jump server, specific HMI web consoles) based on identity and device posture.

The key differences from traditional VPN:

• Device posture assessment. The ZTNA agent verifies the endpoint’s patch level, OS version, EDR status, and disk encryption state before granting access. A home machine with an outdated OS cannot connect, even with valid credentials.
• Application-level access. The user gets access to the jump server, not to the OT network subnet. They cannot scan the network or reach other hosts.
• Continuous verification. Posture is assessed continuously, not just at connection time. If the device state changes mid-session (antivirus disabled, VPN split tunnel detected), the session can be terminated.

ZTNA solutions with OT-specific support or partner integrations include Zscaler Private Access, Cloudflare Access, and Cisco Secure Access. For environments where deploying ZTNA agents on remote devices is impractical, a web-based ZTNA approach (HTML5 remote desktop proxy) can provide browser-based access to the jump server without any client agent.

Layer 4: Vendor Access Management

Vendor remote access requires a separate process from employee remote access because the asset owner does not control the vendor’s devices or credentials.

Just-in-time access. Vendor access should be provisioned only for the duration of a specific engagement, with automatic expiry. The vendor’s credential (or shared secret for the PAM session) should be valid for the scheduled maintenance window and automatically disabled when the window closes.

Vendor session monitoring. Vendor sessions should be recorded at the same level as employee sessions, with the vendor informed of this in the access agreement.

Vendor-specific network segmentation. Vendor access should reach only the specific assets the vendor supports — a Rockwell automation vendor should not be able to see the Siemens DCS segment, and neither should reach corporate IT systems.

Review periodically. Audit all vendor access accounts quarterly. Any account that hasn’t been used in 90 days should be disabled pending review. Any account associated with a vendor engagement that has concluded should be deprovisioned.

Practical Hardening Priorities

For OT teams that cannot implement a full ZTNA deployment in the near term, the following steps address the highest-risk conditions:

1. Audit and revoke unused vendor VPN accounts. Pull a list of all VPN accounts with OT network access. Identify accounts associated with completed projects or vendors no longer actively engaged. Revoke them. This is zero-cost, reversible, and addresses a common initial access vector.

2. Enable MFA on all remote access. Any remote access mechanism that doesn’t require MFA is a single credential compromise away from OT network access. Implement MFA for VPN, jump server login, and vendor access portals. TOTP-based MFA is sufficient; hardware tokens are better for critical environments.

3. Restrict site-to-site VPN rules. Review the firewall rules governing IT/OT tunnels. Identify rules that permit broader access than the specific applications the tunnel was built for and tighten them to host-pair and port-specific rules.

4. Enable session logging on the jump server. Even without a full PAM deployment, configuring the jump server to record RDP sessions via Windows event logging and screen recording (using tools like Pomerium or OpenPAM, or Windows RDS logging) provides forensic capability that is otherwise absent.

Remote access hardening in OT environments is operationally sensitive — changes to access mechanisms need to be tested and communicated to operations teams to avoid disrupting maintenance workflows. A phased approach, starting with audit and deprovisioning, then MFA, then jump server hardening, then ZTNA over a 6-12 month timeline, is practical for most organisations and substantially reduces the attack surface without requiring simultaneous disruption to multiple systems.