Human-Machine Interfaces (HMIs) are the primary point of contact between industrial operations and their digital infrastructure. For plant managers and OT engineers, these screens are critical for monitoring process variables, adjusting setpoints, and maintaining situational awareness. However, for a threat actor, an HMI is often the most valuable entry point into the operational technology (OT) environment.
The complexity arises because HMIs face two distinct worlds: the real-time demands of operators in the control room and the connectivity requirements of networked systems, including engineering workstations, historians, and remote access gateways. When an HMI is configured to serve both masters effectively without strict isolation, it becomes a bridge that can undermine your entire defense-in-depth strategy.
In assessments we have run across manufacturing and critical infrastructure sectors, the configuration of these boundary devices frequently reveals gaps that are not just technical, but procedural. We recently observed a specific instance in one engagement where a single OT remote-operation workstation had two active default routes while Internet Connection Sharing was running. This created a scenario where traffic intended for the control network could inadvertently leak to the corporate internet, and vice versa, effectively bypassing your perimeter firewalls.
The Dual-Nature Risk of Modern HMIs
Traditionally, HMIs were isolated devices connected directly to PLCs or RTUs via serial links or local Ethernet. Today, they are Windows-based (or Linux-based) computers running complex client software. They need to communicate with OPC UA servers, fetch trend data from SQL databases, and allow engineers to upload logic changes remotely.
This connectivity is necessary for efficiency, but it introduces significant risk if the HMI is not treated as a boundary device rather than just a display terminal.
Unintended Transit Traffic
One of the most dangerous configurations we encounter is when an HMI acts as an unintended router. If an operator connects a laptop to the HMI’s USB port for configuration, or if the HMI itself has multiple network interfaces enabled for different purposes (e.g., one for engineering, one for production), routing rules can become ambiguous.
As noted in our internal engagement findings, having two simultaneously active network interfaces on separate networks with a default gateway on each interface while services like Internet Connection Sharing are running creates a direct path for lateral movement. An attacker who compromises the HMI does not just get access to one screen; they gain a foothold that can pivot between the OT and IT domains if the routing table allows it.
The “Open Window” Problem
HMIs often run legacy versions of Windows Server or Workstation because application vendors certify their software only on specific, older operating systems. These older OSes lack modern endpoint protection capabilities and receive security updates less frequently. When these machines are connected to the network for remote access, they become low-hanging fruit for ransomware and credential harvesting.
Architectural Segmentation: Zoning the HMI
To mitigate these risks, you must move beyond “hardening” the operating system alone and focus on how the HMI fits into your IEC 62443 architecture. The HMI should not exist in a vacuum; it should reside in a defined security zone with clearly marked conduits.
Define the Security Zone
Classify your HMI based on its function. Is it a safety-critical interface for shutdown systems? Is it a monitoring-only panel for auxiliary processes? This classification dictates the level of protection required. For high-risk HMIs, the zone should be strictly limited to devices that absolutely require communication with that specific process.
Implement Protocol-Aware Boundaries
Firewalls between the HMI zone and other zones (such as the Engineering Zone or DMZ) must be protocol-aware. Generic port blocking is insufficient. For example, if your HMI uses OPC UA for data retrieval, the firewall rule should explicitly allow only the specific IP addresses of the authorized historian servers and the exact TCP port used by the OPC UA endpoint.
Similarly, for DNP3 or Modbus communications, ensure that the HMI is not inadvertently allowed to initiate connections to devices outside its designated zone. The principle of least privilege applies here: the HMI should only have the permissions necessary to read/write the specific tags it displays or controls.
Harden With Industrial Context
Hardening an HMI requires balancing security with operational reliability. You cannot apply standard IT hardening scripts blindly, as they may disable services required for real-time performance or crash legacy applications. Instead, use a layered approach that respects the industrial context.
Endpoint Hardening
While patching may be limited by vendor certification, you can still apply configuration baselines:
- Disable unused services: Turn off Bluetooth, USB storage (if not needed for engineering), and unnecessary network protocols like NetBIOS.
- Enforce local account policies: Ensure the local administrator password is complex and rotated regularly. Disable local administrative rights for operators who do not need them.
- Install application whitelisting: If possible, use tools that prevent unauthorized executables from running on the HMI, even if the OS is outdated.
Network Hardening
Since you cannot always patch the HMI’s operating system, you must rely on network controls to protect it. This is where defense-in-depth becomes critical. If the HMI is compromised due to a zero-day vulnerability in its legacy OS, your network segmentation should prevent the attacker from moving laterally.
Ensure that any remote access to the HMI is routed through a secure jump box or bastion host, never directly from the corporate internet. Use multi-factor authentication (MFA) for all remote sessions, and ensure that the credentials used for remote connectivity are unique to that HMI and not shared with domain-wide admin accounts.
Validating After Implementation
Hardening is not a one-time event. It requires continuous validation to ensure that changes do not degrade operational performance or create new vulnerabilities.
Regular Vulnerability Assessments
Conduct regular vulnerability assessments of your HMI fleet. However, be cautious with scanning methodologies. Aggressive network scans can disrupt real-time communications or crash legacy applications. Use passive monitoring tools to identify anomalies in traffic patterns and active scanning only during approved maintenance windows with vendor-approved profiles.
Review Access Logs
Monitor who is accessing the HMI and what actions they are taking. Look for unusual login times, failed authentication attempts, or changes to configuration files. If your HMI supports logging, ensure that logs are forwarded to a secure SIEM or log management system in real-time.
The Role of Personnel and Policy
Technology alone cannot secure the HMI. The people who interact with it daily play a crucial role in its security posture. Incomplete asset inventories, missing security policies, and undefined roles are common gaps that undermine even the best technical controls.
Clear Roles and Responsibilities
Define who is responsible for HMI patching, configuration changes, and access management. Is it the OT team, the IT team, or a third-party vendor? Ensure there is no ambiguity. Ambiguity leads to gaps in coverage.
Training and Awareness
Train operators and engineers on the importance of HMI security. Explain why USB drives are restricted, why remote access requires MFA, and what to look for if they suspect a compromise. Security awareness is not just about preventing clicks on phishing links; it is about understanding the physical and digital consequences of their actions in an OT environment.
Conclusion
Hardening HMIs that face both operators and the network is a delicate balancing act. It requires a deep understanding of industrial protocols, a robust segmentation strategy, and a commitment to continuous monitoring. By treating the HMI as a critical boundary device rather than just a display terminal, you can significantly reduce your attack surface and protect your operational technology from evolving threats.
At Red Trident, we specialize in helping industrial operators secure their OT environments. We provide expert assessments, remediation guidance, and training to help you build a resilient security posture. If you are looking to strengthen your HMI security or assess your overall OT risk, we offer a free consultation to discuss your specific needs.
