When a web HMI or historian portal inside the OT network needs to be reachable from the enterprise or the internet, the crude way is to forward a port straight to the internal server, exposing it directly. A reverse proxy in the industrial DMZ does the same job far more safely: it sits in front, accepts the outside connection, and passes only vetted requests through to the hidden internal application. This guide explains the reverse-proxy role in a SCADA DMZ - terminating encryption, checking authentication before anything reaches the back end, and concealing internal hosts - and why it is a stronger design than a raw port-forward.
Reverse proxy (SCADA DMZ) in one line: A reverse proxy in a SCADA DMZ is an application-layer intermediary that publishes an internal web HMI or historian portal to the enterprise or internet on behalf of the hidden back-end server. It accepts the outside connection, terminates TLS, can pre-check authentication, and forwards only permitted requests to the internal application, which is never exposed directly. This is safer than a raw port-forward because the proxy inspects and controls traffic at the application layer instead of blindly passing packets through to the internal host.
A reverse proxy works by standing in front of an internal service and presenting itself to the outside world as the destination. When a user in the enterprise or on the internet requests the web HMI, they connect to the reverse proxy in the DMZ, not to the internal server; the proxy receives the request, decides whether to honour it, and if so makes its own connection to the internal application and relays the response back. From the user's perspective they are talking to the HMI, but they are actually only ever talking to the proxy, which mediates every exchange.
This indirection is what keeps the internal server off the exposed edge. The back-end HMI or historian portal sits inside the OT network with no direct path from outside; the only thing the outside world can reach is the proxy in the DMZ, which is deliberately positioned as a controlled intermediary between zones. The DMZ itself is the buffer network between the enterprise and OT sides, and placing the proxy there means external traffic terminates in that buffer rather than penetrating to the internal application, keeping the actual server one controlled hop removed from anything untrusted.
Hiding the internal host is a security benefit in its own right. Because outside parties never connect to the internal server and never learn its address or details directly, they cannot probe or attack it as they could a directly-exposed service - they can only reach the proxy, which reveals nothing about the internal topology beyond what it chooses to. This concealment shrinks the attack surface to the hardened proxy itself, rather than leaving the back-end application, with all its own surface area, sitting open to the world.
Terminating TLS at the proxy means the encrypted connection from the outside user ends at the reverse proxy, which decrypts the traffic there before deciding what to do with it. This gives the DMZ edge a single, well-managed place to handle certificates and enforce strong encryption for every external connection, rather than relying on each internal application to do so correctly. It also means the proxy can actually see the requests it is handling, which is the prerequisite for inspecting and controlling them at the application layer - something impossible if the traffic were passed through still encrypted and opaque.
Authentication pre-check is the higher-value function that termination enables. Because the proxy sees the request, it can require the user to authenticate before any traffic is allowed to reach the internal application at all, acting as a gate that unauthenticated requests never pass. This means the internal HMI or portal is only ever contacted by requests that have already proven themselves at the edge, so an attacker cannot even begin to interact with the back-end application without first getting past the proxy's authentication. The internal server is shielded not just by being hidden but by being reachable only through a checkpoint that vets who is asking.
Together, termination and pre-check turn the proxy into an active guardian rather than a passive relay. It enforces encryption, it demands identity, and it decides request by request what is allowed through, all before the internal application is involved. That application-layer control is the essence of the reverse-proxy role: it does not merely move traffic, it understands and governs it, applying policy at the level of requests and sessions rather than at the level of raw network packets.
A raw port-forward is the alternative the reverse proxy improves upon, and the contrast is stark. Port-forwarding simply maps an external port to the internal server's port, so an outside connection is passed straight through to the internal application with no inspection - whatever arrives on that port is delivered to the back end as-is. The internal server is effectively exposed directly, just at a different address, and the firewall doing the forwarding operates at the packet level, deciding only whether to pass the traffic, not what the traffic actually contains or whether the sender is authorised.
The reverse proxy differs precisely because it works at the application layer. It does not blindly forward; it terminates, inspects, authenticates, and then relays only what passes its checks, so the internal application is never in direct contact with unvetted outside traffic. This is a fundamentally different security model from packet filtering: the DMZ firewall controls which flows are allowed at the network level, while the reverse proxy controls what those flows are permitted to do at the level of requests and identity. The two are complementary layers, and the proxy adds the application-aware control that a firewall's packet filtering cannot provide on its own.
In a cloud SCADA architecture, much of this publishing concern is handled by the platform rather than assembled per site. Merobix already delivers its web HMI to browsers over encrypted, authenticated connections from managed infrastructure, so the pattern a reverse proxy provides - TLS termination, authentication before the application is reached, and internal assets kept off the exposed edge - is built into how the platform serves remote oil and gas sites rather than being a proxy each operator must stand up in their own DMZ. For a distributed field operation, that means the safe-publishing role a reverse proxy plays for an on-premises portal is inherent in a cloud SCADA that was designed from the start to present screens securely to the outside world.
A DMZ firewall filters at the network level, deciding which packets and flows are allowed between zones based on addresses and ports. A reverse proxy works at the application layer, terminating the connection, inspecting the actual requests, authenticating the user, and forwarding only what passes its checks to the hidden internal server. They are complementary: the firewall controls which traffic may flow, while the proxy controls what that traffic is permitted to do once allowed.
Port-forwarding maps an external port straight to the internal server, exposing it directly and passing traffic through with no inspection - the firewall only decides whether to pass packets, not what they contain or who sent them. A reverse proxy instead terminates the connection, can require authentication before anything reaches the back end, and hides the internal host so it is never contacted directly. That application-layer vetting is control a raw port-forward simply cannot provide.
It ends the encrypted connection at the reverse proxy, so encryption is managed in one hardened place at the DMZ edge for every external connection rather than left to each internal application. Decrypting there also lets the proxy actually see the requests, which is what makes application-layer inspection and authentication pre-checks possible. Without termination the traffic would remain opaque and the proxy could not enforce identity or policy on it before it reached the internal HMI or portal.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.