Remote access approaches for machines, compared
Last updated: October 20, 2026
There are several common approaches to connecting remotely to a machine, each with a different shape of trade-off. None of them is universally the right answer; which one fits depends on what the connection needs to reach, how often it's used, and what the customer's own network already looks like.
VPN into the customer network
How it works
A virtual private network creates an encrypted tunnel from the service engineer's device onto the customer's own network, broadly as though it were plugged in on site.
Where it fits
Fits a customer who already runs VPN infrastructure and wants to extend their existing network boundary to a remote vendor rather than set up something separate.
Trade-offs
Once connected, what the session can reach depends entirely on how the customer has segmented their own network, which can be considerably more than the one machine being serviced. Its security also depends on how well the customer maintains the VPN infrastructure itself, not just on the connection being encrypted.
What to ask
What does this connection actually reach once established? Is access scoped per visit, or left available continuously? Does connecting require more than a password? CISA's guidance recommends routing necessary remote access through a secure gateway or centrally managed access solution, rather than connecting directly to a controller, HMI or RTU.
Remote support tools
How it works
Screen-sharing or remote-desktop style software lets a technician view and control a specific device or interface for a session, usually started from the device being supported rather than from a standing network connection.
Where it fits
Fits occasional, software or interface-level troubleshooting where the issue is visible on a screen rather than something that needs deep network-level access.
Trade-offs
Session-based tools are often easier to bound, since a session has a clear start and end, but they vary widely in whether the session is logged, whether it requires the customer to approve each connection, and whether the underlying traffic is still routed over the open internet.
What to ask
Is each session customer-initiated, or can a connection be made unprompted? Is the session logged, and for how long is that log kept? Does the tool require explicit approval for each connection, or once granted does it stay open?
Jump hosts
How it works
Also called a bastion host, a jump host is a single hardened system placed between the outside connection and the OT network. Anyone connecting remotely reaches the jump host first, and only from there can reach specific systems behind it.
Where it fits
Fits a customer with several vendors or systems needing occasional access, who wants one controlled, logged point of entry rather than many separate direct connections.
Trade-offs
Centralizing access and logging in one place is the main strength, but it also makes that single host the one thing standing between the outside and the OT network, so it has to be kept current and tightly configured itself.
What to ask
Is access to the jump host itself behind multi-factor authentication? Are sessions through it logged and reviewed? Who else uses the same jump host to reach the same systems?
Cloud zero-trust access
How it works
Rather than extending a network perimeter the way a VPN does, this approach verifies the identity of the specific user and device for each individual connection to a specific resource, without treating any network location as automatically trusted. NIST SP 800-207 describes this general model, “Zero Trust Architecture,” in detail.
Where it fits
Fits a customer managing access for several vendors who wants one managed service brokering tightly scoped access to each specific machine or task, rather than operating separate VPN tunnels or jump hosts per vendor.
Trade-offs
Scoping access this precisely usually depends on a cloud-hosted broker sitting outside the customer's own network, which some customers are comfortable with and others are not, depending on their own policies about where access-control decisions happen.
What to ask
Where does the access-control decision actually happen, and who operates that service? Can access be scoped to exactly one machine, or does a connection still reach more of the network once established?
OT gateway-based access
How it works
A dedicated gateway device sits at the edge of the OT network, terminating the remote connection there rather than letting it continue onto the OT network itself, often as part of a segmented architecture of the kind NIST SP 800-82 Revision 3 describes for operational technology environments generally.
Where it fits
Fits a machine builder or integrator who wants a purpose-built device dedicated to this one job, installed at the machine itself, rather than relying on the customer's general-purpose network infrastructure.
Trade-offs
Having a device the machine builder specifically controls can give clearer certainty about scope, but it also adds a device the customer has to accept installing, and that the builder has to keep patched and maintained over the machine's life.
What to ask
What exactly can this gateway reach once connected, just this one machine, or more of the surrounding network? Who is responsible for patching and maintaining the gateway device itself, for how long?
Hardware-enforced access
How it works
Access is gated by a physical control rather than a purely software one, such as a switch or key that must be deliberately engaged on-site before a remote connection can reach the machine at all, sometimes paired with a one-directional gateway for a monitoring-only path, a pattern NIST SP 800-82 Revision 3 also describes.
Where it fits
Fits the highest-sensitivity machines or processes, where the customer wants a physical, not just logical, guarantee that remote access cannot reach the equipment unless someone on site has deliberately allowed it.
Trade-offs
A physical control is harder to bypass through a purely software compromise, which is its main strength, but it also means remote access depends on someone being physically present to enable it, which can add to the cost of delay during an urgent incident.
What to ask
Who on site is responsible for engaging the physical control, and what happens if they're not available when access is needed? Does monitoring continue even while the two-way connection is disabled?
Related guides
IEC 62443 and remote access for machine builders and the remote access situation check, which walks through how you connect today without naming or favoring any of the approaches above.
It takes about 2 minutes and covers NIS2, the Cyber Resilience Act, and the Machinery Regulation for machine builders, factory operators, and system integrators in the Netherlands, Belgium, and Luxembourg.
This is a general guide, not legal or security advice, and does not name or recommend any specific product. Confirm what fits your own situation with a qualified advisor.