When an engineer or a vendor needs to reach an HMI or engineering workstation inside an OT network from outside, the wrong way to allow it is to expose the remote-desktop port to the internet, because that invites exactly the automated attacks that plague exposed RDP. A remote desktop gateway is the right way: a hardened intermediary that sits at the perimeter, accepts encrypted remote-desktop connections from authenticated users, and brokers them inward to the target machines, so the desktops themselves are never directly reachable from outside. This guide explains what an RD gateway does, why it beats port-forwarding, and how features like multi-factor authentication at the gateway and session recording make remote access to control systems safer. It focuses specifically on brokering desktop and RDP sessions, distinct from jump hosts, VPN tunnels, and protocol gateways.
Remote Desktop Gateway in one line: A remote desktop gateway is a hardened server that acts as a broker for remote-desktop connections, terminating encrypted sessions from remote users at the network perimeter and relaying them to internal machines without exposing those machines' remote-desktop ports directly to the internet. In an OT context it lets engineers and vendors reach HMIs and engineering workstations for support and configuration while keeping the actual remote-desktop endpoints hidden behind the gateway. The gateway is where authentication, multi-factor checks, access policy, and often session recording are enforced, concentrating remote-access security at one controlled, monitored point.
A remote desktop gateway works by being the only thing on the boundary that speaks the remote-desktop protocol to the outside world. A remote user connects to the gateway over an encrypted channel, the gateway authenticates them and checks policy, and only then does it open a connection inward to the specific internal machine the user is allowed to reach, relaying the desktop session between the two. The internal HMI or workstation is never contacted directly from the internet; as far as the outside is concerned, only the gateway exists, and everything behind it is reachable solely through the gateway on the gateway's terms. This is the brokering pattern: one controlled, hardened door instead of many exposed ones.
Terminating the session at the perimeter is what makes this valuable in OT, where the internal machines are exactly the ones you least want reachable from outside. Because the gateway stands between the internet and the control network, it becomes the single place where you enforce who may connect, from where, to which machines, and under what conditions, and the single place you monitor for remote access. The internal desktops keep doing their job without carrying any internet-facing exposure of their own, and the security effort concentrates on hardening and watching one gateway rather than trying to secure many individual endpoints against direct external attack. Concentrating the risk at one deliberately fortified point is the whole design philosophy.
The tempting shortcut a gateway replaces is port-forwarding: opening the remote-desktop port on the firewall and pointing it straight at an internal machine so someone outside can connect directly. This is dangerous because it puts the raw remote-desktop service of a control-system machine directly on the internet, where automated scanners find exposed remote-desktop ports within minutes and hammer them with credential-guessing and exploit attempts around the clock. An exposed remote-desktop endpoint on an OT network is one of the most reliably attacked configurations there is, and it offers an attacker who succeeds a direct foothold on a machine inside the control environment, which is close to a worst case.
A remote desktop gateway removes that exposure while still permitting the access people legitimately need. Nothing on the internal network is directly reachable; the only externally facing service is the hardened gateway, which is built and maintained specifically to withstand exposure and to enforce strong authentication before any inward connection is made. On top of eliminating direct exposure, the gateway lets you require multi-factor authentication at the point of entry, so a stolen password alone is not enough to get in, and it gives you a single choke point at which to apply access policy, allowing a given vendor to reach only a specific machine during a specific window rather than roaming the network. Many gateways also record sessions, capturing what a remote user actually did on a control-system machine, which is invaluable for accountability, incident investigation, and reviewing third-party vendor work. Port-forwarding offers none of this; it simply drills a hole and hopes.
The practical driver for an RD gateway in industrial operations is that support has to happen remotely, whether that is an in-house engineer diagnosing an HMI at a remote site at two in the morning or an equipment vendor logging in to update the software on a machine they supplied. The desire to grant that access collides with the imperative not to expose control-system desktops to the internet, and the gateway is the reconciliation: it lets the engineer or vendor reach the exact machine they need through an encrypted, authenticated, policy-controlled, and often recorded session, without any control-system desktop ever being directly reachable from outside. Vendor access in particular benefits from the gateway's ability to scope and record, since a third party can be confined to just the machine and window they require and their actions kept on record.
It is worth being clear about how this differs from adjacent tools, because OT networks often use several together. A VPN tunnel builds an encrypted network path into the environment but by itself may place a remote user broadly onto the network; a jump host is a hardened intermediary machine that a user first logs into and then moves onward from, often reached across such a tunnel; a protocol or SCADA gateway translates industrial protocols between devices and systems. A remote desktop gateway is specifically about brokering interactive desktop and RDP sessions to graphical machines, and it is frequently layered with the others, for instance requiring a VPN and multi-factor authentication before the gateway will even accept a connection. For operators running a cloud SCADA platform such as Merobix, the platform itself already removes much of the need to remote-desktop into on-site machines for routine monitoring, because operators reach the hosted system securely through the browser from anywhere; the RD gateway then covers the narrower remaining case of hands-on maintenance of the local HMIs and engineering workstations that still live inside the plant, keeping even that access brokered, authenticated, and observed.
A VPN builds an encrypted network tunnel that places a remote user onto the network, after which they can reach whatever that network position allows, which can be broad. A remote desktop gateway is narrower and more controlled: it brokers specific remote-desktop sessions to specific machines, terminating them at the perimeter so the desktops are never directly reachable and enforcing authentication and policy per connection. The two are often layered, with a VPN and multi-factor authentication required before the gateway will accept a session.
Because exposing a remote-desktop port directly to the internet puts a control-system machine's raw remote-desktop service in front of automated scanners that find and attack exposed RDP within minutes, using credential-guessing and exploits continuously. A successful attacker lands directly on a machine inside your OT network. A remote desktop gateway removes that direct exposure entirely, presents only a hardened broker to the outside, requires strong authentication before any inward connection, and can record sessions, none of which port-forwarding provides.
It lets a vendor reach only the specific machine they need to service, over an encrypted and authenticated session, during a controlled window, without exposing any control-system desktop to the internet. Multi-factor authentication at the gateway ensures a stolen password alone will not admit them, and session recording captures exactly what the vendor did on the machine. That combination gives operators safe, scoped, accountable third-party access instead of the all-or-nothing risk of opening a port or handing over broad network access.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.