Right now, thousands of human-machine interfaces - pump station screens, tank farm overviews, chlorine dosing panels - are reachable from the public internet through VNC, RDP, and embedded web servers. Nobody planned it that way. A port forward for remote support here, a cellular modem with a public IP there, and a control screen that was designed for a locked control room is suddenly indexed by search engines built for exactly this purpose. This guide explains how HMI exposure actually happens, what internet scanners see, how to audit your own sites defensively, and the remote access patterns that give operators the visibility they wanted without leaving anything listening on the open internet.
Part of the Merobix OT security guide collection - vendor vetting to industry compliance.
No engineer sets out to publish a wastewater plant's HMI to the world. Exposure is almost always the residue of a reasonable operational decision made under time pressure. The operator on call needed to check a lift station at 2 AM without driving forty minutes. A vendor needed remote access to commission a panel and asked for "a port opened temporarily." A remote well site got a cellular modem, and the carrier shipped it with a publicly routable IP address and every port open by default.
The pattern repeats across industries: the demand for remote visibility is legitimate, and when the SCADA architecture doesn't provide a safe way to meet it, someone meets it unsafely. That is the honest root cause. Telling field staff "no remote access" without offering an alternative doesn't remove the demand - it just pushes the workaround somewhere you can't see it. This is why the fix for exposed HMIs is architectural, not disciplinary, a theme we develop across our secure SCADA buyer's guide.
The most common exposure paths, roughly in order of frequency:
The mental model that keeps exposed HMIs online is "nobody knows this IP address." That model died more than a decade ago. Services such as Shodan, Censys, and ZoomEye continuously scan the entire public IPv4 space and index everything that answers - banners, screenshots of VNC sessions, product names, firmware versions, and industrial protocol responses. A new service on a public IP is typically discovered and indexed within hours to days, and anyone - researcher, journalist, or attacker - can then find it with a keyword search rather than a scan.
Security researchers have repeatedly published surveys of internet-exposed industrial systems - and CISA and EPA issued a joint fact sheet warning that internet-exposed HMIs pose cybersecurity risks to water and wastewater systems: water treatment screens with tank levels and pump controls visible, building automation panels, pipeline metering displays. The recurring findings are sobering - many exposed VNC services are configured with no authentication or view-only passwords, and many web HMIs still present default vendor credentials. Exact counts move around from year to year and by methodology, but the direction has been consistent: industrial services remain a visible, searchable population on the public internet.
Two properties make this different from ordinary IT exposure. First, an HMI screenshot tells an attacker what the facility does - a login page for a generic server reveals little, but a screen labeled "Chlorine Feed - Pump 2" reveals everything about what's at stake. Second, HMIs sit one step from physical process. The 2021 Oldsmar water treatment incident - where, per the joint federal advisory AA21-042A, an intruder reportedly used remote access software to briefly manipulate sodium hydroxide dosing before an operator noticed - showed how short the distance is between "remote desktop reachable" and "setpoint changed." An alert operator and downstream safeguards prevented harm, which is exactly the point: exposure puts your last line of defense in play far too early.
Each remote-viewing shortcut fails in its own way. Understanding the failure modes helps you prioritize what to remove first:
| Exposure Path | How It Typically Happens | Why It Fails | Priority |
|---|---|---|---|
| VNC (port 5900) | Enabled on HMI PC for vendor or on-call access; forwarded through site router | Frequently deployed with weak or no authentication; screen content indexed by scanners; traffic often unencrypted | Remove first |
| RDP (port 3389) | Windows HMI or SCADA server exposed for remote administration | Constant brute-force and credential-stuffing pressure; history of pre-auth vulnerabilities (BlueKeep-class); full desktop control once breached | Remove first |
| Embedded web HMI | Panel's built-in web server forwarded or on a public cellular IP | Default credentials common; embedded web stacks patched rarely; often reveals process detail on login page | Remove or broker |
| Remote-support tools | TeamViewer-class software installed permanently instead of per-session | Standing access with shared credentials; outside IT's visibility; account compromise at the provider inherits your risk | Restrict to attended sessions |
| Direct PLC protocol | Modbus TCP or similar forwarded to the controller for a remote poller | Industrial protocols have no native authentication - anyone who can reach the port can read and write | Remove immediately |
Note the last row. Exposed HMIs at least put a screen between the internet and the process. An exposed industrial protocol port removes even that. If your remote data collection currently depends on a forwarded Modbus port, treat it as the most urgent item on this page - the gateway pattern described below exists precisely to replace it.
You cannot fix exposure you haven't found, and most operators genuinely don't know what is reachable at their remote sites. A defensive self-audit takes an afternoon per region, requires no exotic tooling, and echoes the first recommendation of the NSA/CISA joint alert AA20-205A: know and reduce your internet-exposed OT footprint. The scope rule is absolute: examine only IP addresses and equipment you own or are contractually authorized to assess.
Removing exposure without replacing the capability just restarts the cycle. The good news: the safe patterns are mature, and the safest one is also the least work to operate. We compare the options in depth in our guide to secure remote access for SCADA; the short version follows.
A VPN concentrator with multi-factor authentication is a large improvement over raw VNC or RDP - but it is still a listening service on a public IP, and VPN appliances have been among the most exploited devices on the internet in recent years. If you run one, you own its patch cadence, its certificate hygiene, and its user lifecycle. A VPN also typically grants network-level access: one stolen credential can reach far more than one screen.
Placing remote desktop access behind an authenticated broker in a DMZ - with MFA, session recording, and per-user authorization - is the classic enterprise answer, and it works. It also requires a properly designed industrial DMZ and someone to run it, which is realistic for large operators and rarely realistic for a three-person team.
The pattern that removes the problem at its root is an outbound-only gateway: a device inside the OT network polls PLCs, RTUs, and flow computers locally, then initiates encrypted TLS connections outward to a monitoring platform. Nothing listens on a public IP. The site firewall - or the cellular modem - can deny all inbound traffic permanently, and the site behaves identically on a static IP, dynamic IP, or carrier-grade NAT. Operators get live screens, trends, and alarms through an authenticated web platform instead of a raw desktop session.
This is how Merobix is built. The gateway makes outbound TLS connections only - no inbound ports, no VPN concentrator to patch. Every device registers with unique credentials and signs its telemetry with a device-held Ed25519 identity, so the platform can detect replayed or forged data. On the human side, every user has a named account with TOTP or passkey MFA, roles scoped from viewer to admin, and site-level authorization - and any control action goes through writable-tag allowlisting and setpoint bounds checking rather than a shared desktop. Store-and-forward buffering at the gateway rides out connectivity outages. The full architecture is documented on our security page.
Key takeaway: An exposed HMI is a symptom, not the disease. The disease is an architecture that offers no safe path to remote visibility, so people build unsafe ones. Kill the port forwards - but in the same change window, deploy an outbound-only access pattern that gives operators a better remote view than the VNC session ever did. Exposure that isn't replaced comes back.
Real remediation takes time - budget cycles, vendor coordination, change windows. If an exposed service must survive a transition period, reduce its blast radius now:
And keep perspective on where this fits: exposure removal is one layer. Named accounts, MFA, audit trails, and segmentation still matter once the ports are closed - the checklist in our small-operator security guide sequences all of it for teams without dedicated security staff, and our cloud vs on-premise comparison covers how deployment choice changes the exposure question entirely.
If you are evaluating monitoring platforms, five questions separate architectures that create exposure from architectures that remove it:
Almost never on purpose. The common paths are a port-forwarding rule added to a site router so someone could check the plant from home, a cellular modem shipped with a public IP address and no firewall, a VNC or RDP service enabled on the HMI PC for vendor support and never removed, and web-based HMI panels installed with remote access enabled by default. Each shortcut solves a real operational problem - remote visibility - which is why the fix has to be a safe remote access pattern, not just a policy that says no.
Shodan and similar services (Censys, ZoomEye) continuously scan the entire public internet and index every responding service - including VNC screens, RDP endpoints, web HMIs, and industrial protocols such as Modbus TCP. Anyone can search these indexes by port, product banner, or country. It matters because obscurity is gone: if your HMI answers on a public IP address, it is discoverable by anyone within hours to days of going online, without the attacker scanning anything themselves.
Start by listing every public IP address your operation uses, including cellular modems at remote sites - your ISP and cellular carrier can confirm which are publicly reachable. Then, from a network outside your own, scan those addresses for open ports, and search Shodan or Censys for them. Review every router and firewall at every site for port-forwarding and NAT rules, and check HMI PCs for enabled VNC, RDP, or remote-desktop tools. This is a defensive audit of your own assets only - never scan addresses you do not own.
No. A strong password does not fix the underlying exposure. Internet-facing VNC and RDP endpoints are hammered continuously by credential-stuffing and brute-force campaigns, both protocols have a long history of exploitable vulnerabilities that need no password at all, and many industrial VNC deployments are misconfigured with view-only protection or no authentication. If remote desktop access is genuinely required, it should sit behind an authenticated broker or VPN with multi-factor authentication - never directly on a public IP.
The safest widely deployable pattern is an outbound-only gateway: a device inside the OT network polls the PLCs and RTUs locally and pushes encrypted data out over TLS, so the firewall can deny all inbound traffic and nothing is listening on a public IP. Operators then view live data and trends through an authenticated cloud platform with MFA, named accounts, and role-based control permissions. Merobix works exactly this way - no inbound ports, no VPN concentrator, with per-device credentials and signed telemetry - which removes the reason the port-forward existed in the first place.
Outbound-only gateway, zero inbound firewall rules, MFA and named accounts on every login - see how Merobix replaces the port forward for good.