HMI security: protecting human-machine interfaces from cyber threats

HMI security protects the operator-facing system against unauthorized access, credential misuse, malware, lateral movement and tampering while preserving safe visibility and operational continuity. In PC-based deployments, the OEM-managed application and the Windows or Linux workstation beneath it require separate controls.

This guide is for OT and automation engineers, SCADA administrators and plant leaders responsible for HMI availability. These workstations are often long-lived, connectivity-restricted and difficult to change. Failure or compromise can remove visibility and interrupt production.

Quick definition: HMI securityHMI security combines OEM application controls with host-level identity, hardening, monitoring, backup and recovery. Controls differ for PC-based, embedded and browser-based HMIs.

Key takeawaysThe OEM application and the underlying workstation are separate security and recovery layers.A compromised host can remove visibility or provide a route deeper into OT without infecting a PLC.Host images and OEM project backups are complementary, not interchangeable.Protection must combine prevention with tested recovery and validated return to service.

An HMI is the hardware or software through which an operator interacts with a controller. In PC-based architectures, it is also an operating-system host with accounts, services, remote-access paths and software dependencies.

Losing that host can create partial or complete loss of view, delay alarm response and force a controlled shutdown even when controllers continue to execute. CISA documented that pattern at a natural gas compression facility where ransomware affected Windows-based HMIs and other supervisory assets while the PLCs remained unaffected.

A compromised host may also expose trusted communications or credentials. Human machine interface security therefore has two linked objectives: prevent untrusted use and restore trusted operator visibility within the required recovery time. The HMI must remain trustworthy during normal operation and recoverable after malware, hardware failure or configuration error.

Five common threats are unauthorized access, credential misuse, lateral pivoting, host ransomware and tampering with configuration or displayed data. This is a practical synthesis, not a universal taxonomy.

Unauthorized access. Remote-control software, exposed services and weak authentication can produce an operator-equivalent session. CISA’s Oldsmar advisory reported unauthorized SCADA access and an attempted setpoint change, although initial access remained unconfirmed.

Credential theft or misuse. Shared engineering or administrative accounts can collapse trust boundaries and give a valid user access across systems or zones.

Lateral pivot toward PLCs. Nozomi Networks demonstrated that browser-based HMI flaws could permit code execution and access to other facility systems. This was research, not an observed intrusion.

Ransomware on the Windows host. CISA documented ransomware affecting HMIs, historians and polling servers. PLCs were unaffected, yet operators lost partial visibility and shut down for about two days.

Configuration or display tampering. A 2026 CISA advisory described malicious PLC project-file activity and manipulation of HMI and SCADA display data. It did not establish that a Windows HMI project file was changed.

The OEM layer and workstation layer should be secured as separate but dependent systems. This is an operational responsibility model, not a formal standards taxonomy.

The OEM layer covers application authentication, patches, project structures, runtime packages, graphics, tags, recipes, alarms and platform-specific restore procedures. AVEVA InTouch, Rockwell FactoryTalk View, Siemens WinCC and GE iFIX each define their own project formats and recovery methods.

The workstation layer covers the operating system, accounts, remote access, host firewall, storage, drivers, services and endpoint telemetry. Material changes still require OEM compatibility testing and operational approval.

Acronis Cyber Protect for OT operates at this workstation layer. It protects the PC or server running the OT application with host-level cyber protection and recoverable system images. It does not replace OEM controls or validate proprietary HMI graphics, tags, recipes, alarm logic or PLC control logic.

HMI workstation hardening should reduce software, privileges and access paths without creating an unsafe or unsupported operating state.

Build an OEM-validated host baseline. Remove unnecessary software and services, restrict communications and document dependencies. Patch the operating system and supporting components through change control, testing against the HMI version, drivers and redundancy design.

Use unique, auditable accounts. Restrict administrator rights and make engineering or vendor access approved, time-bound and logged. Route remote access through a controlled path with strong authentication.

Application allowlisting suits fixed-function hosts. Build the policy from a known-clean system, include approved OEM services and maintenance tools and test it in audit mode before enforcement.

Host monitoring and EDR can add process, file and account telemetry where compatible. Tune detections, test response actions and avoid automatic containment that could remove critical visibility without operational coordination. The broader endpoint-protection guidance for HMI and SCADA workstations covers this layer in more detail.

An HMI backup should preserve both a recoverable host and the OEM-defined application state. A host image should capture the operating system, drivers, network settings, installed components, policies and licensing dependencies. It preserves OEM files only when they are included and captured consistently.

Keep a separate OEM-supported project export or application backup. Rockwell provides FactoryTalk View HMI Server Backup and Restore procedures, while Siemens documents WinCC-specific project backups. Alarm history, recipes, historian data and external databases may need separate treatment. Rockwell’s documentation, for example, warns that some external and historical data sources are not included in the application archive.

A complete recovery set should include the host image, OEM project export, external databases, alarm or historian records, licenses, drivers, installation media, network settings and recovery documentation.

Version host images and OEM project backups independently. Keep at least one recovery copy beyond the credentials and incident that could damage production systems.

Test recovery in isolation. Confirm that the host boots, the project opens, licenses and drivers are available and required services start. The OT backup and recovery guide covers the wider industrial recovery strategy.

Recover a compromised HMI workstation through an operations-led sequence that preserves safety, evidence and trust.

First, establish a safe process state and alternate visibility. Isolate the host with operations approval, preserve required evidence and determine whether the incident extends beyond the workstation.

Second, restore trust in the host. Rebuild or restore from a known-good image, rotate exposed credentials and remediate the original access path.

Third, restore the OEM application state. Use the vendor-supported method for the project, runtime package and related databases. In CISA’s pipeline case, the organization acquired replacement equipment and loaded last-known-good configurations.

Fourth, validate in a segmented test state. Check operating-system integrity, licenses, drivers, application version, project identity, alarm behavior, communications and displayed process values against approved engineering records.

Finally, reconnect in stages. Obtain operations, automation, safety and security approval, keep a rollback path and monitor closely. The objective is a trusted HMI that behaves correctly in the live process. The OT ransomware recovery guide expands on coordinated plant recovery.

Acronis Cyber Protect for OT protects the host beneath the HMI application so plant teams can restore visibility and reduce downtime without claiming control over proprietary project semantics or PLC logic. On-premises and air-gapped deployments use Acronis Cyber Protect Local.

This differs from generic endpoint recovery because an HMI may run on legacy, disconnected hardware and must return to an OEM-validated state. For supported Windows and Linux systems, it provides image-based backup, legacy OS support and Universal Restore to dissimilar hardware. The same agent can combine backup with anti-ransomware, anti-malware and EDR, while backup scanning can identify and remediate threats before restoration.

Acronis One-Click Recovery lets authorized local personnel restore failed OT systems in minutes with a few clicks and without direct IT intervention. Engineering teams still validate the OEM application, communications and displayed values before reconnection.

A public Sasol case study reports reliable recovery to dissimilar hardware, resolution of compatibility problems and support for migration between physical and virtual systems.

HMI security action planApply OEM-supported application controls, harden the host, protect host images and OEM artifacts separately, test recovery in isolation and document who can initiate restoration.

Next step: Talk to an OT expert about protecting and recovering PC-based HMI systems.

No. Redundancy preserves availability, but it is not an isolated recovery point for ransomware, corruption or a configuration overwritten on both nodes. Rockwell documents backup of the active server in a redundant FactoryTalk View SE environment.

Set cadence from the recovery point objective and change rate. Capture an OEM-supported project backup around material changes, then schedule copies according to acceptable data loss. NIST does not prescribe one interval.

Yes. Preserve a host image and OEM-supported project export before changing the application, operating system, drivers or licensing components. Confirm the rollback procedure first.

Record recovery time, image and project versions, required media, licensing steps, driver gaps, validation results and approval. This creates a repeatable procedure.

Document the license, machine-binding criteria and OEM rehosting process. A successful image restore may still fail operationally if the license cannot move to replacement hardware.

Check the OEM backup scope and external database or historian connections. Some archives exclude alarm history or other data stores, which need separate recovery procedures.

No. Embedded and browser-based devices depend more on OEM firmware, device configuration and network controls. This host-hardening and image-recovery guidance applies to PC-based systems.