For OT remote support, ZTNA limits an authenticated user to a named application or host, a jump server concentrates work on a managed Windows or Linux intermediary, and a VPN provides routed access to selected private subnets.
The three methods are not mutually exclusive: a VPN may reach a hardened jump server, a jump server may reach one engineering workstation, and local rules may permit that workstation to reach only the required PLC.
Decision Model: Network, Host, or Resource
A VPN answers how an endpoint joins or routes into a private network, a jump server answers where managed remote work takes place, and ZTNA answers which identified subject may reach a specific resource under policy [S3].
This distinction matters because a read-only dashboard viewer and a vendor downloading PLC logic do not require the same reach. A dashboard can be published as a specific web resource, while PLC changes can remain confined to an engineering workstation and a controlled maintenance procedure [S3].
A jump server is a hardened intermediary between a less-trusted network and a protected OT zone. The usual sequence is authentication to the bastion, launch of RDP, SSH, or VNC, then a second connection to an HMI, PLC, or engineering workstation [S2]. The security value is centralization, but the host becomes a critical dependency [S3].
Criterion-Based Comparison
VPN, jump server, and ZTNA differ materially in reachable scope, protocol compatibility, and administrative dependency. The practical comparison below uses the access object and operational consequence as the decision criteria [S3].
For cost, administration, and failure exposure, ZTNA usually removes the shared gateway dependency but may require more application-specific integration. A jump server consolidates tooling and session control but creates a single operational bottleneck. A VPN is familiar and flexible for multiple protocols, yet it shifts the control burden to network segmentation and firewall policy [S3].
Where Each Method Fits
Use ZTNA for web HMIs, defined services, remote desktop targets, and repeatable user-to-resource policies [S3]. ZTNA for OT can provide resource-specific access for authorized administrators [S3].
Use a jump server when engineers need PLC programming software, vendor utilities, RDP, SSH, or controlled file handling on a managed computer [S3]. A serial server can also form part of a controlled engineering path when the support task depends on serial-connected equipment, provided local access rules restrict its destinations.
Use a VPN when one support session genuinely requires several legacy protocols, vendor discovery tools, or multiple controlled services, especially where mature segmentation, managed endpoints, strong identity controls, and maintained firewall policy already exist [S3]. A VPN may still be the practical transport for reaching a jump server rather than a direct route into the production cell [S3].
Identity, Visibility, and Accountability
ZTNA evaluates every access request using identity and policy rather than granting broad network membership after one successful login [S5].
Jump servers can create blind spots, over-permissioned sessions, and friction because all reachable systems must be reachable from the intermediary [S2]. Shared accounts on a bastion reduce accountability and traceability, while limited visibility makes individual remote actions harder to attribute [S2]. Named accounts, per-session authorization, and retained command or session records address a different control objective from network encryption.
VPNs can contain vulnerabilities and can permit lateral movement when stolen credentials provide broad routed access [S1]. They also become harder to configure and manage as users and applications grow, and performance can deteriorate as concurrent connections increase [S5]. Encryption protects the transport path, but it does not by itself restrict reachable OT resources.
OT Failure Modes and Engineering Constraints
Remote-access design must preserve safety and local operation if the connection or remote action fails [S3]. The access path is therefore an engineering dependency, not merely an IT convenience. CISA guidance cited in 2022 recommended isolating OT from IT and the internet while also warning that VPN software can contain vulnerabilities [S1].
Jump-server failure modes include a single unavailable bastion, accidental downstream exposure, shared-account ambiguity, and session capacity constraints [S2]. VPN failure modes include credential theft, excessive routed reach, dependency on remote tunnel capacity, and policy drift across sites [S1][S5]. ZTNA failure modes include unsupported legacy protocols, application integration gaps, and misconfigured resource policies, so product support for non-web OT protocols must be validated before selection [S3].
A fourth design question is required: what happens to the physical process when the path or remote action fails [S3]. Remote support should therefore be paired with local fallback, named maintenance windows for disruptive work, and an approval step for commands or downloads that can affect production.
Implementation and Procurement Controls
A layered OT remote-access specification should state the subject, resource, protocol, approved hours, recording requirement, and local enforcement point for every path [S3]. For example: read-only HMI access through ZTNA, PLC program changes through a named jump host, and no general subnet route from either path to unrelated controllers.
Procurement should test compatibility with the actual protocol mix: web HTTPS, RDP, SSH, VNC, vendor discovery, and serial or fieldbus access [S2][S3]. Confirm whether the product supports agentless access, session recording, identity-provider integration, centralized policy, and local enforcement [S1]. Product claims are not substitutes for plant testing.
When remote operations become routine, evaluate the supporting edge server or workstation hardware against the target plant environment and the approved protocol set. The access architecture must not add an untested dependency between the operator and the controlled process.
The cleanest migration path is incremental: protect the highest-value HMI with resource-level ZTNA, retain a hardened jump server for proprietary engineering tools, and remove broad VPN routes after firewall rules, identities, and local recovery procedures have been tested [S1][S3].
Track two measurable signals after implementation: the percentage of remote OT sessions bound to named users and specific resources, and the percentage of jump-host accounts shared outside approved administrative workflows [S2]. A third control point is the number of routed VPN subnets still permitted to reach production assets.