TroutTrout
Back to Blog
OT SecurityRemote AccessHMISCADA

How to Secure Remote Access to an HMI

Trout Team7 min read

Summary

Remote access to an HMI gives remote control of the process. From the HMI, a person can start a pump, change a setpoint or silence an alarm. Any remote path that reaches the HMI gives the same control.

Most people who ask for HMI remote access only need to see the screens. A smaller group needs to act, for a specific job. Give the first group view-only access or, where possible, a copy of the data. Give the second group a named session to the one HMI they work on, with a time limit and a recording. Make sure the internet cannot reach the HMI's built-in VNC or web server.

How HMI remote access is usually set up

Three methods cover most plants.

  1. The panel's own remote viewer. Many HMI panels include a VNC server or a web server, so someone can see the operator screens from a browser or viewer on another machine. The feature is built in, it is convenient, and it is often turned on during commissioning and never turned off.
  2. Remote desktop to a PC-based HMI. When the HMI is software on a Windows PC, or a SCADA client, people reach it with RDP, VNC or a commercial remote support tool.
  3. A VPN or vendor gateway, then the viewer. A VPN or a vendor gateway puts the user on the machine network, and the user opens the panel's viewer from there. Most machine-builder remote access works this way. We cover it in secure remote access to a PLC and how Ewon remote access and Talk2M work.

With all three methods, the HMI treats a remote user exactly like a local one. Its own login, if it has one, is usually a shared operator account with no second factor.

Why CISA warns about internet-facing VNC on HMIs

In December 2025, CISA, the FBI and partner agencies published an advisory on pro-Russia hacktivist groups attacking critical infrastructure. The groups searched public IP ranges for open VNC, typically on the default port 5900 or nearby ports. They got in with default, weak or no passwords, and used brute-force tools where needed.

According to the advisory, once on the HMI, the groups changed usernames and passwords, modified parameters and setpoints, disabled alarms, and created loss-of-view conditions that forced operators to intervene manually. The advisory also notes that these groups often misunderstand the processes they disrupt. As a result, the damage they cause is unplanned.

The attacks needed no vulnerability. The HMI's own remote viewing feature was reachable from the internet with a weak password in front of it.

Why the HMI's own login is not enough

Set the HMI login and change it from the default. It still cannot decide who gets in, for three reasons.

First, HMI logins protect the application and not the network service. A panel's VNC or web server answers anyone who can reach it, and only the password prompt stops them. Anyone who can reach it can try as many passwords as they like. The brute-force tools in the CISA advisory do exactly this.

Second, HMI accounts are usually shared. Every shift uses the operator account, and the password is often on a label near the panel. A shared account does not show who did what.

Third, HMIs rarely support MFA, and many cannot. The second factor has to be checked in front of the HMI.

Keep the HMI login, and add a check on the access path that decides which named person may reach this HMI, at what time, and for what task.

Who needs view-only access and who needs control

Write down who asks for HMI remote access and what they do with it.

WhoWhat they doAccess they need
Plant managerChecks output and statusView-only, or a dashboard from a copy of the data
On-call operatorChecks alarms at night, sometimes acknowledges or restartsView-only by default, control for their own area when needed
Control engineerChanges screens, tags or setpoints on one machineControl of that HMI, for the task
OEM or integratorDiagnoses a fault, updates the HMI projectControl of that HMI, for a scheduled window
Quality or maintenance plannerReads counters and trendsView-only, or data from a historian

Most rows need view-only access. View-only access can often be delivered with no path to the HMI. Counters, trends and alarms can be pushed to a historian or reporting system outside the control network, and people read them there.

Sometimes a person needs the live screen but only to watch. In that case, make the session view-only on the access path if you can, in addition to the settings inside the HMI application. For a web-based HMI, you can allow reads and block writes at the protocol level, for example by allowing HTTP GET and denying POST. The result depends on how the HMI's web application is built, so test it with the real client before you rely on it.

Rules for control access to an HMI

Apply these rules to the people who need to press buttons:

  • A named person. Each user signs in with their own identity and MFA, and never with the shared operator account. Staff use your corporate directory, such as Active Directory or Entra ID. Vendors use a separate directory: a second Active Directory or the directory built into the gate.
  • One HMI. The session reaches the panel or PC for the machine being worked on, over the protocol it needs (VNC, RDP or HTTP), and nothing else on the network.
  • A time limit. Access opens for the maintenance window and closes automatically.
  • A recording. The log shows who connected to which HMI and when, and a recording shows the session.

How Trout Access Gate controls HMI sessions

Access Gate is an on-premise appliance. It keeps your VPN or 4G link and adds micro-segmentation of the LAN and a bastion. The user signs in through the browser with MFA. Access Gate connects several directories at once, so staff and vendors can sign in against separate directories. Each session goes through the gate to one authorised asset over one authorised protocol, and the user never gets an IP address on your network. Access Gate supports VNC, RDP and HTTP, among other protocols, and inspects them at the application layer. For HTTP, you can allow a method such as GET and deny POST. Access is limited to a time window and ends automatically. Every session is recorded, indexed and can be replayed. Nothing is installed on the HMI.

The HMI's own VNC or web server stays on the machine network. The gate can reach it, and nothing else can. This change closes the path described in the hacktivist advisory.

The SCADA system above the HMI needs the same separation of monitoring and control. We cover it in secure remote access to SCADA. To isolate HMIs on the local network as well, see HMI network isolation strategies.

Five steps to take this week

  1. Check whether any HMI is reachable from the internet, through its VNC or web server, directly or through a port forward. If it is, disconnect it today.
  2. List every HMI with remote viewing turned on. Include panel VNC servers, web servers and remote desktop on HMI PCs. Turn off the ones nobody uses.
  3. Change default and shared passwords on every HMI and remote viewer, including the ones that are not exposed.
  4. Sort the people into two groups: those who need to see and those who need to act. Where you can, give the first group data outside the control network.
  5. Give the second group named sessions to the HMI they work on, with a time limit and a recording, and no access to anything else.
FAQ

Frequently Asked Questions

How does HMI remote access usually work?
Three methods are common. The first is the HMI panel's own remote viewing feature, often a built-in VNC server or web server. The second is a remote desktop connection to a PC-based HMI or SCADA client. The third is a VPN or vendor gateway onto the machine network, after which the user opens the panel's viewer. With each method, a person off site sees the operator screen and can press its buttons unless something prevents it.
Is it safe to expose an HMI's VNC server to the internet?
No. In December 2025 CISA and partner agencies warned that hacktivist groups were finding internet-facing VNC connections to HMIs. The groups got in with default, weak or missing passwords, changed setpoints and credentials, disabled alarms and caused loss of view. The advisory recommends removing OT from the internet, strong authentication and segmentation.
What is the difference between view-only and control access to an HMI?
View-only access lets the user see screens, values, trends and alarms. Control access lets the user press buttons, change setpoints, acknowledge alarms and change configuration. Most people who ask for HMI remote access only need to see: managers, on-call staff checking status, or a vendor diagnosing a fault. Fewer people need control, and they should get it for a specific task and a set time.
Can I make HMI remote access view-only?
Sometimes, depending on the product. Some HMI remote viewers support a separate view-only login. For web-based HMIs, you can sometimes separate reads and writes at the protocol level, for example by allowing HTTP GET and denying POST. The result depends on how the application uses HTTP, so test it with the real client. If neither option works, deliver monitoring from a copy of the data instead of the live screen.
Does the HMI's own password protect remote access?
Only partly. HMI logins are often shared operator accounts and rarely have MFA. They protect the application, and they do not protect the network service. If the panel's VNC or web server is reachable, an attacker can try the password as often as they like. Put a login in front of the access path, tied to a named person with MFA.
Who should have control access to an HMI remotely?
Give control access to a short list of named people with a current reason: the on-call operator for the area they cover, the control engineer for the machine they are working on, and a vendor for a scheduled maintenance window. Each session should reach only that HMI, close when the task or window ends, and be recorded.