OT remote access is not one product category. A VPN provides network connectivity, a jump server concentrates remote work on a controlled host, and zero trust network access (ZTNA) usually grants access to a named resource rather than a subnet. In industrial environments, the strongest design often combines methods: narrow connectivity, an intermediary access zone, explicit identity and authorization, and controls matched to the PLC, HMI, or engineering task.
That distinction matters because a controls engineer opening a read-only dashboard is not doing the same job as a vendor downloading PLC logic. Giving both users the same network path may be convenient, but it ignores the different consequences, protocols, and recovery needs.
What is the practical difference between VPN, jump server, and ZTNA?
A VPN answers, “How can this endpoint join or route into a private network?” A jump server answers, “On which managed computer should remote work take place?” ZTNA answers, “Which identified subject may reach this specific resource under this policy?” An OT remote access architecture must answer all three questions and add a fourth: “What happens to the physical process if the access path or remote action fails?”
The NIST Guide to Operational Technology Security emphasizes that OT security has to respect performance, reliability, and safety requirements. That makes a feature-only comparison incomplete. The useful choice is the one that supports the required work while limiting the reachable systems and preserving safe local operation.
| Approach | What the user typically reaches | Main strength | Main limitation | Strongest fit |
|---|---|---|---|---|
| Remote-access VPN | A routed network or selected subnets | Broad protocol compatibility and familiar administration | Reach can become wider than the actual task | Managed engineers who need several legacy tools and protocols |
| Jump server or bastion | A controlled Windows or Linux host, then downstream targets | Keeps engineering tools and files on a managed intermediary | Becomes a high-value dependency and still needs a secure transport path | PLC programming, vendor software, RDP, SSH, and controlled file handling |
| ZTNA or resource-level access | A named application, host, or service | Separates resource access from broad network membership | Product support for legacy and non-web OT protocols varies | Web HMIs, specific services, remote desktop targets, and repeatable user-to-resource policy |
| Layered OT remote access | A defined path combining transport, access zone, identity, and target controls | Can match controls to operational consequence | More design and ownership work | Production environments with mixed users, protocols, and criticality |
The rows are not mutually exclusive. A team might use a VPN only to reach a hardened jump server, then allow that server to communicate with one engineering workstation. Another team might publish a web HMI through resource-level access while requiring PLC changes to occur through a separate jump host and maintenance procedure.
When does a VPN still make sense for OT?
A VPN remains useful when an engineer genuinely needs multiple network protocols, vendor discovery tools, or access to several controlled services during one support task. It can also fit sites that already operate mature network segmentation, managed endpoints, strong identity controls, and well-maintained firewall policy.
The key is not to confuse successful authentication with permission to reach everything routed through the tunnel. Restrict routes and firewall rules to the smallest practical destinations and ports; keep user and administrative identities separate; define who owns each rule; and remove access that no longer has a business purpose. CISA’s guidance on modern network access security specifically calls attention to risks from traditional remote access and VPN misconfiguration while encouraging organizations to evaluate more granular approaches.
A VPN is a weaker fit when the job needs only one web page or one remote desktop but the tunnel exposes a whole operations subnet. It is also difficult to govern when unmanaged vendor laptops connect directly, split tunneling is poorly understood, or many sites have accumulated unique rules that nobody can confidently explain.
What does a jump server solve, and what does it not solve?
A jump server gives the remote worker a controlled place to run engineering software. Instead of installing a PLC suite and project files on every vendor laptop, the organization can maintain the toolchain on a workstation near the OT environment. Downstream firewall policy can then allow that host—not every remote endpoint—to reach selected devices.
This can simplify compatibility and keep sensitive project material in the site environment, but it creates a critical system. The jump host needs hardened configuration, patch planning that respects production, malware protection compatible with the engineering tools, protected backups, capacity planning, and recovery instructions. Privileged accounts on it should not be shared casually.
A jump server also does not provide transport by itself. Users still need a protected way to reach it, such as a constrained VPN or a resource-specific remote desktop path. Nor does it automatically make every action safe: a user with programming privileges can still send an unsafe change through a perfectly secured jump host.
Is ZTNA the same as secure OT remote access?
No. ZTNA is an architectural approach, not proof that a particular OT deployment is secure. NIST SP 800-207 describes zero trust as removing implicit trust based on network location and focusing protection on resources. That principle is useful in OT, where membership in a plant subnet should not automatically authorize access to every controller or application.
Resource-level policy can be a good fit for a web HMI, SSH service, remote desktop workstation, historian interface, or a precisely defined TCP service. However, products differ in protocol support, endpoint requirements, dependency on external identity or policy services, device-posture capabilities, and behavior during site connectivity loss. Some engineering tools use broadcast discovery, dynamic ports, proprietary drivers, or latency-sensitive exchanges that do not map cleanly to an application proxy.
Therefore, “ZTNA” on a proposal should start a technical review, not end it. Ask the supplier to demonstrate the exact PLC suite, firmware utility, RDP or SSH workflow, file transfer, and failure mode at the intended site. Do not infer zero-trust compliance from a resource-oriented user interface; compliance depends on the wider architecture and operating controls.
What should a layered OT remote access design contain?
Start with zones and conduits rather than one trusted plant network. The ISA/IEC 62443 series provides a lifecycle-oriented framework for industrial automation and control system security, including risk-based system design. In practice, the remote access path should cross deliberate boundaries with documented allowed flows.
A practical pattern is:
- An identified person uses a managed or otherwise assessed remote endpoint.
- An identity and access layer authenticates the person and evaluates the requested resource.
- A constrained transport carries the connection to an OT access zone or site gateway.
- A jump host, application proxy, or protocol-specific rule exposes only the required service.
- A downstream firewall permits the minimum flow to the HMI, engineering workstation, application, or PLC.
- The operating procedure controls when process-affecting work may begin and how local staff recover if it goes wrong.
NIST’s 2026 OT remote access build architecture is useful because it treats secure remote access as an architecture assembled around operational needs, not as a single appliance purchase. Although its demonstrations focus on water and wastewater utilities, the questions about authentication, authorization, segmentation, and practical implementation transfer to many industrial settings.
How should you choose for a real support job?
Use the task as the unit of design. Write down the exact target, protocols, expected actions, business owner, consequence of error, and recovery method before selecting technology.
- For viewing a web HMI, prefer a resource-specific application path with no route to unrelated assets.
- For RDP to a managed engineering workstation, publish only that desktop service and restrict what the workstation can reach.
- For PLC programming across several proprietary ports, a constrained VPN to a jump host may be more realistic than forcing the protocol through an unsupported proxy.
- For an OEM supporting many customer machines, use a repeatable per-machine or per-resource policy instead of a shared site-wide account.
- For emergency changes to consequential processes, require local coordination and a tested fallback; connectivity alone is not authorization to proceed.
If equipment sits behind carrier-grade or double NAT, read the companion guide on accessing industrial equipment behind NAT without port forwarding. For controller-specific boundaries, use the secure remote PLC and HMI support architecture.
Once the team selects a method, use the industrial remote-access rollout checklist as the implementation hub for ownership, segmentation, pilot tests, and recurring review.
What belongs in an evaluation checklist?
Before approving an approach, verify:
- named users and separate privileged roles rather than shared credentials
- multifactor authentication appropriate to the risk
- exact targets, protocols, ports, and direction of every allowed flow
- endpoint management expectations for employees and vendors
- behavior when identity, broker, DNS, internet, or site services are unavailable
- fast access removal and a periodic review owner
- jump-host hardening, backup, patch, and recovery responsibilities
- compatibility with real engineering tools, including discovery and file transfer
- performance during realistic latency and packet loss
- local authorization, maintenance-window, backup, and rollback procedures for changes
Run the pilot on a representative cell or test environment. A successful login is not a successful pilot; the team should also prove that an unauthorized resource cannot be reached, access can be removed, a failed connection does not disturb control, and local staff can restore the expected state.
When is each approach a poor fit?
Avoid broad VPN access when a narrow resource path meets the requirement. Avoid making a jump server the sole recovery path when the site cannot tolerate its failure. Avoid ZTNA for a protocol until its behavior is demonstrated rather than assumed. For genuinely air-gapped systems, or processes where remote change creates unacceptable consequence, a supervised local procedure may be the correct answer.
None of these technologies certifies an organization to IEC 62443, proves zero-trust compliance, or replaces process-safety analysis. Product telemetry and retention also vary, so teams that require detailed per-human audit evidence or session recording must validate those capabilities separately.
Where might Orenda fit?
Orenda Connect is worth evaluating when the goal is to give users a private path to approved resources without broad network-level access. For outside support, Orenda vendor access can be scoped to a target, revoked, and optionally configured to expire; it should sit inside the organization’s own request, authorization, change-control, and evidence processes.
That makes Orenda a possible resource-access layer, not a claim that every legacy protocol or critical workflow should bypass a jump host or VPN. In a pilot, validate the actual target, protocol, site egress, resilience, identity, and evidence requirements. The vendor access solution provides useful product context, while the final architecture decision should remain with the asset owner and the people responsible for safe operation.
