Key takeaways
- WirelessHART extends the same HART command set over a wireless mesh instead of a wired loop, aimed at process measurement points where running new cable is expensive or impractical.
- The documented failures sit exactly where the comparison above suggests: in implementation code and configuration, not in WirelessHART's AES-128 design.
- Treat wired HART loop wiring as the actual security boundary.
HART (Highway Addressable Remote Transducer) is the protocol most process-plant transmitters, positioners and valve controllers speak over a 4-20mA current loop, and it has no authentication at all — anyone electrically connected to the loop can read and write a device's configuration — while its wireless sibling WirelessHART, standardized as IEC 62591, was built with mandatory AES-128 encryption and key management from the start, which means the real security gap in a HART deployment usually sits in physical loop access, gateway configuration and asset-management software, not in the wireless protocol's cryptography itself.
What HART actually is, and why the wired version has no security layer
HART started in 1986 when Rosemount (now part of Emerson) found a way to add two-way digital communication on top of the existing 4-20mA analog current loop that process instrumentation already used, by superimposing a low-amplitude frequency-shift-keyed (FSK) digital signal that doesn't disturb the analog reading. FieldComm Group, the industry body that now owns and maintains the protocol, still registers HART-compliant devices today, and the protocol remains the dominant way to configure and diagnose process transmitters, positioners and valve controllers without pulling them off the loop. Because the entire design goal was convenient configuration and diagnostics for a technician standing at a terminal box or holding a handheld communicator, classic wired HART has no field for a credential, token or signature: any HART master — a legitimate handheld, asset-management software, or a device clipped onto the loop by someone who shouldn't be there — can issue read and write commands a device will accept. The only real control over classic wired HART is physical: who can reach the loop wiring and junction boxes.
How is WirelessHART (IEC 62591) different?
WirelessHART extends the same HART command set over a wireless mesh instead of a wired loop, aimed at process measurement points where running new cable is expensive or impractical. The HART Communication Foundation released it in September 2007, and it was standardized internationally as IEC 62591 — first edition 2010, current second edition IEC 62591:2016, maintained by IEC Technical Committee 65/Subcommittee 65C. Unlike classic wired HART, FieldComm Group's own published security materials describe WirelessHART security as mandatory and always-on rather than a configuration option: a two-layer defense pairs hop-by-hop authentication at the data-link layer with end-to-end encryption and authentication at the network layer, both built on AES-128. A dedicated Security Manager role tracks keys and network security status across the mesh, and the join key a new device uses to authenticate to the network — provisioned out of band with a handheld or commissioning tool before the device is ever powered up at the plant — is treated as the single most important credential in the system, with FieldComm Group recommending unique per-device join keys over one key shared across an entire network.
| Property | Wired HART (4-20mA loop) | WirelessHART (IEC 62591) |
|---|---|---|
| Authentication | None — any loop-connected master is trusted | Mandatory; join key + per-session keys managed by a Security Manager |
| Encryption | None | AES-128, hop-by-hop (data-link) and end-to-end (network layer) |
| Can security be disabled? | N/A — none exists to disable | No, per FieldComm Group's own description — always-on by design |
| Primary residual risk | Physical access to loop wiring and junction boxes | Gateway/firmware implementation bugs, join-key provisioning and management practice |
| Governing body | FieldComm Group (HART protocol owner) | FieldComm Group; standardized as IEC 62591 |
What do real CISA advisories against HART products actually show?
The documented failures sit exactly where the comparison above suggests: in implementation code and configuration, not in WirelessHART's AES-128 design.
| Advisory | Product | CVE | CVSS | What it actually allowed |
|---|---|---|---|---|
| ICSA-15-008-01A (2015, rev. 2018) | CodeWrights HART DTM library, used across Emerson Rosemount/Fisher HART field devices | CVE-2014-9191 | 1.8 (v2) | Crafted response over the 4-20mA loop crashed the DTM/FDT Frame software (no control disruption) |
| ICSA-20-287-04 (2020) | FieldComm Group HART-IP Developer Kit and hipserver reference software | CVE-2020-16209 | 9.8 (v3) | Oversized HART-IP message caused a stack-based buffer overflow; could crash the device or allow code execution |
| ICSA-20-135-02 (2020) | Emerson Wireless 1410/1420/1552WU WirelessHART Gateways | CVE-2020-12030 | 10.0 (v3) | Enabling the VLAN feature silently disabled the gateway's internal firewall, exposing all ports to connected wireless field devices |
The 2015 Emerson finding is a parsing bug reachable over the physical wired loop itself — a reminder that "no authentication" cuts both ways, since a compromised or rogue field device can target the engineering software reading it, not just the other way around. The 2020 HART-IP finding is in FieldComm Group's own reference implementation of the Ethernet-based HART-IP extension, the layer that lets HART traffic ride a plant's IP network rather than a dedicated loop. The Emerson gateway finding is the most serious for WirelessHART specifically: it didn't touch the AES-128 security model at all, it broke the network-level firewall that was supposed to be a second layer of defense around a WirelessHART gateway, through an unrelated feature interaction. None of the three required breaking WirelessHART's cryptography to succeed.
What should an asset owner check first?
Inventory every HART-capable device, including transmitters, positioners and valve controllers, plus the handhelds, asset-management software (DTM/FDT-based tools) and WirelessHART gateways that talk to them — none of the advisories above, or any future one, can be assessed without model and firmware/version detail. Treat wired HART loop wiring as the actual security boundarySince classic HART has no authentication, physical access to loop terminals and junction boxes is the control that exists; restrict and monitor who can reach them. Verify WirelessHART security is configured as intended, not just presentConfirm unique per-device join keys are in use rather than one key shared network-wide, and that a Security Manager is actively monitoring network security status, per FieldComm Group's own recommendations. Patch gateways and asset-management/DTM softwareagainst the CVEs above and any newer CISA ICS advisory matching the exact vendor and model in use — the documented failures are in this layer, not the wireless protocol's encryption. Keep WirelessHART gateways off the internet and segmented from business networks, and re-verify firewall and VLAN configuration after any update — the Emerson gateway case shows a single feature interaction can silently disable a gateway's protections.
A passive pcap capture is a practical way to build the inventory in step 1 and check for exposed gateways without touching a running loop or wireless network: SoftWSP's OT Snapshot works from a mirror-port recording to identify devices and the protocols they speak, map them against published CISA ICS advisories, and flag risky behavior such as unencrypted traffic or unexpected remote access — with an engineer reviewing every finding and the AI-assisted report citing the traffic each finding is based on (MCP access for your own AI agents is on the roadmap, not available yet) — see OT Snapshot.
This guide draws on FieldComm Group's published WirelessHART security overview, the IEC Webstore's catalogue record for IEC 62591:2016, three CISA ICS advisories fetched directly, and NIST SP 800-82 Revision 3. FieldComm Group's detailed WirelessHART security white paper PDF could not be rendered as extractable text by this guide's fetch tooling, so mechanism-level claims drawn from it should be checked against that primary document. This guide is general information, not a substitute for FieldComm Group's own specifications, a vendor's product-specific security guidance, or a current CISA ICS advisory search for your exact hardware and firmware version.
Sources
- FieldComm Group: WirelessHART Security overview
- IEC 62591:2016, Industrial networks — Wireless communication network and communication profiles — WirelessHART (IEC Webstore catalogue record)
- CISA ICS Advisory ICSA-15-008-01A: Emerson HART DTM Vulnerability, Update A (last revised 29 August 2018; CVE-2014-9191)
- CISA ICS Advisory ICSA-20-287-04: FieldComm Group HART-IP and hipserver (last revised 13 October 2020; CVE-2020-16209)
- CISA ICS Advisory ICSA-20-135-02: Emerson WirelessHART Gateway (14 May 2020; CVE-2020-12030)
- NIST Special Publication 800-82 Revision 3, Guide to Operational Technology (OT) Security (September 2023)
Frequently asked questions
Does the wired HART protocol have any authentication or encryption?
No. Classic wired HART — the Highway Addressable Remote Transducer protocol that Rosemount introduced in 1986 and that FieldComm Group now maintains — layers a low-rate digital FSK signal on top of the same two wires carrying a 4-20mA analog current loop, and it was designed purely for device configuration and diagnostics in an era when the only way to reach a transmitter was to physically connect a handheld or modem to that loop. The protocol has no concept of a credential, session key or message signature: any HART master (a handheld communicator, asset management software, or a rogue device clipped onto the loop) that can electrically reach a field device can read and write its configuration. Physical access to the loop wiring is effectively the only control that exists for classic wired HART.
Is WirelessHART (IEC 62591) actually more secure than wired HART?
Yes, by design, and this is the one part of the HART family where security was built in from the start rather than bolted on. WirelessHART was released by the HART Communication Foundation in 2007 and standardized as IEC 62591 (first edition 2010, current second edition IEC 62591:2016), and FieldComm Group's own published security materials describe its security as always-on and not something a user can disable: data is authenticated hop-by-hop at the data-link layer and encrypted and authenticated end-to-end at the network layer, both using AES-128. A dedicated Security Manager role in the network tracks keys and network security status, and a device's join key — provisioned out of band with a handheld or commissioning tool before the device is powered up at site — is treated as the most security-critical credential in the system. Note that this guide's tooling could not render FieldComm Group's WirelessHART security white paper PDF as extractable text, so the mechanism-level description above is drawn from FieldComm Group's own public security overview page and search-indexed summaries of that white paper, and should be checked against the primary PDF for exact wording if you need it for a compliance document.
What have real CISA advisories found in HART-speaking products?
Three, each a different kind of problem, and none of them break WirelessHART's cryptography. CISA's ICSA-15-008-01A (originally published January 2015, last revised 29 August 2018) assigned CVE-2014-9191 to an improper-input-validation flaw in the CodeWrights HART Device Type Manager library Emerson used across dozens of Rosemount and Fisher HART field devices — a specially crafted response sent over the 4-20mA loop itself could crash the DTM software, discovered by Alexander Bolshev of Digital Security. CISA's ICSA-20-287-04 (last revised 13 October 2020) assigned CVE-2020-16209 (CVSS v3 9.8) to a stack-based buffer overflow in FieldComm Group's own HART-IP Developer Kit and hipserver reference software, discovered by Reid Wightman of Dragos — oversized HART-IP messages could crash the device or allow code execution. CISA's ICSA-20-135-02 (14 May 2020) assigned CVE-2020-12030 (CVSS v3 10.0) to an improper-access-control bug Emerson found internally in its Wireless 1410, 1420 and 1552WU WirelessHART gateways: enabling the VLAN feature on an affected gateway silently disabled its internal firewall, exposing every gateway port and allowing commands to reach connected wireless field devices. All three are implementation bugs in specific vendor software or reference code, not failures of the WirelessHART AES-128 security model itself.
What should a plant running HART or WirelessHART instruments check first?
Inventory every HART-capable transmitter, positioner and valve controller along with the handhelds, asset-management software and WirelessHART gateways that talk to them, since none of these advisories can be assessed without knowing model and firmware version. Physically secure 4-20mA loop wiring and junction boxes, because classic wired HART has no electronic substitute for that control. Confirm WirelessHART security is actually configured as intended — unique per-device join keys rather than one join key shared across a network, and a Security Manager that is actually monitoring network status — rather than assuming the protocol's mandatory encryption means nothing else needs checking. Patch gateways and asset-management software against the specific CVEs above and any newer CISA ICS advisory for the exact model in use, and keep WirelessHART gateways off the internet and segmented from business networks, the same standing recommendation CISA attaches to the Emerson gateway advisory and to OT protocols generally.
In this cluster
