Getting a technician onto an OT asset the traditional way means either a VPN into the network or a hole punched in the firewall for inbound connections - both of which expand what an attacker can reach. A remote access broker takes a different route: an agent inside the OT network reaches out to a cloud relay, and the technician meets it there, so nothing ever has to connect inward to the plant. This guide explains the brokered remote-access architecture: how an outbound-only agent and a cloud broker replace inbound firewall rules and VPNs, and how session recording and just-in-time access make brokered access auditable and time-bound.
Remote access broker in one line: A remote access broker is a service, usually cloud-hosted, that mediates remote connections into OT assets without any inbound path into the plant network. A lightweight agent inside the OT network makes an outbound-only connection to the broker, and technicians connect to the same broker from outside, which relays the session between them. Because the plant only ever connects outward, there are no inbound firewall holes or VPN into the OT network to expose, and the broker can enforce session recording and just-in-time, time-limited access.
The core idea of a broker is that both sides reach a neutral meeting point in the middle rather than one side reaching directly into the other. An agent running inside the OT network opens an outbound connection to the cloud broker and keeps it open, waiting. When a technician needs access, they authenticate to the broker from the outside, and the broker relays traffic between the technician and the agent over the connection the agent already established. At no point does anything from outside connect inward to the plant; the plant reached out, and the broker simply joins the two outbound-facing ends.
This outbound-only property is what changes the security picture. Firewalls and OT networks are generally configured to permit outbound connections while blocking unsolicited inbound ones, so an agent that only ever connects out fits cleanly within a restrictive posture without any inbound rule being added. There is no listening service on the plant side exposed to the internet, no inbound port to scan or attack, and no route from the outside into the OT network - the only path is the one the agent itself initiated and the broker itself mediates, both of which the plant controls.
The broker in the middle is more than a passive relay; it is where identity, authorisation, and policy are enforced. Because every session passes through it, the broker is the natural place to require strong authentication of the technician, to decide which agents and assets a given person may reach, and to apply the rules governing how and when access is granted. That central mediation point is what turns a simple relay into a controlled gateway, one that can be governed and observed in a way that a direct connection cannot.
A VPN grants a remote user a presence on the network - once connected, they are effectively inside, able to reach whatever the VPN policy allows, often at a broad network level. That places a lot of trust in the VPN's segmentation and in the endpoint that connected, because a compromised VPN client or an overly permissive policy exposes a wide swath of the OT network. A broker, by contrast, does not put the technician on the network at all; it relays access to specific brokered assets through a mediated session, so the technician reaches only what the broker permits and gains no general network foothold.
A reverse tunnel is closer in spirit, since it also uses an outbound connection from inside to establish a path, but a broker adds the mediation and control layer on top of that transport idea. Where a bare reverse tunnel is essentially a pipe that someone on the outside can use, a broker sits in the middle enforcing who may use it, for which asset, and under what policy, and it records what happens. The broker is therefore best understood not as a different transport trick but as a managed access model built around the outbound-only principle, with governance where a raw tunnel has none.
The practical consequence is a smaller blast radius and clearer control. With a VPN or an unmanaged tunnel, the question after an incident is what the connected party could have reached, which is often uncomfortably broad. With a broker, access is scoped to specific assets through a mediated, recorded session, so both the exposure during access and the record of what was done are far more contained. That containment is the reason brokered access has become an attractive model specifically for OT, where the cost of an over-broad remote foothold is high.
Because every session flows through the broker, it can record what happens during remote access - capturing the session for later review, so there is an auditable account of who connected, to which asset, and what they did. For OT, where third-party vendors and integrators often need to reach equipment they support, this recording turns a previously opaque event into a reviewable one, which matters both for security investigation and for accountability. The broker's central position makes this observation natural, whereas a direct VPN or tunnel connection typically leaves no comparable record of the session's content.
Just-in-time access is the other governance feature the broker enables: rather than standing access that persists whether or not it is needed, access is granted only when required and only for a bounded window, then withdrawn. A technician requests access, it is authorised for a specific asset and a limited time, and when the window closes the path is gone. This shrinks the exposure dramatically compared with always-on remote paths, because there is simply no open door most of the time - the door exists only during the approved, recorded session and closes again afterward, which fits the principle of minimising standing access into critical systems.
For distributed field operations this model is a strong fit, and it complements how cloud SCADA already works. A platform such as Merobix collects data from remote oil and gas sites over outbound connections, and a remote access broker applies the same outbound-only, no-inbound-holes philosophy to the interactive access technicians occasionally need to those sites. Rather than provisioning VPNs or opening firewall rules at every remote wellpad or station, brokered access lets vendors and engineers reach specific assets through a mediated, recorded, time-limited session, so the operational need for occasional hands-on access does not force the plant to weaken the very isolation that keeps its OT network safe.
An agent inside the OT network makes an outbound-only connection to the cloud broker and keeps it open, and technicians connect to the same broker from outside. The broker relays traffic between them over the connection the agent already established, so nothing from outside ever connects inward to the plant. Because firewalls generally allow outbound while blocking unsolicited inbound traffic, no inbound rule or exposed listening service is needed on the OT side.
A VPN puts the remote user onto the network, giving them a presence and often broad reach governed by segmentation and policy. A broker does not place the technician on the network at all; it relays access to specific brokered assets through a mediated session, so the technician reaches only what the broker permits and gains no general network foothold. That scoping keeps the blast radius of any compromise far smaller than an over-broad VPN connection.
Just-in-time access means a technician is granted access only when it is actually needed and only for a limited, approved window, after which the path is withdrawn. Instead of a standing remote connection that exists whether or not anyone is using it, the door opens for a specific asset and a bounded time and then closes again. This minimises standing access into critical OT systems, so there is no open path most of the time, only during the approved, recorded session.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.