WirelessHART and ISA100.11a Explained: Mesh, Join Keys and Security

WirelessHART and ISA100.11a are the two open wireless standards built for process plants. Both run time-scheduled, channel hopping mesh networks on IEEE 802.15.4 radios in the 2.4 GHz band, both put a central manager in charge of routes and schedules, and both protect traffic with AES-128 keys handed out by a security manager after a device proves it holds a join key. WirelessHART (IEC 62591, maintained by FieldComm Group) extends the HART instrument protocol; ISA100.11a (IEC 62734, certified by the ISA100 Wireless Compliance Institute) is IPv6 based and tunnels other protocols. The radio layer is well designed. The weak point in most plants is the gateway, which bridges the mesh to Ethernet, runs a web interface and firmware, and speaks HART-IP, Modbus or OPC UA upstream.

This post sits beside our other one protocol per post explainers for operational technology: Modbus, PROFINET, OPC UA, and the wireless siblings Zigbee, Thread and Matter and LoRaWAN. For the zone and conduit model itself, read IEC 62443 roles, zones, conduits and safety. Here we stay on industrial wireless mesh: managers, keys, what each key protects, and how to run these networks defensively.

Safety note before anything else. Wireless field devices in a process plant report pressures, levels, temperatures, gas concentrations and valve positions, and some ISA100 deployments carry safety related data. Rejoining a network, rotating keys at the wrong moment or reflashing a gateway can orphan devices and leave operators blind to a process variable. Every hands on step in this post is either passive or belongs in a planned maintenance window with the instrument, operations and safety owners for that unit. Never test key changes, firmware or firewall rules on a live unit without written approval.

Key takeaways

• HART sends a digital signal on top of the 4 to 20 mA current loop using Bell 202 frequency shift keying at 1200 bits per second. FieldComm Group says more than 40 million installed instruments support it.
• WirelessHART came with HART 7, which FieldComm Group dates to 2007. The IEC published it as IEC PAS 62591 on 22 January 2009, as IEC 62591 edition 1.0 on 27 April 2010 and as edition 2.0 on 30 March 2016, with a corrigendum in March 2021.
• ISA100.11a-2011 was approved by ISA in May 2011 and published by ANSI in December 2011. The ISA100 Wireless Compliance Institute says the IEC approved it as IEC 62734 in October 2014.
• WirelessHART networks have field devices and adapters, access points, a gateway, a network manager and a security manager. ISA100 adds an IP backbone with access points, a system manager and a security manager, and tunnels other protocols.
• Both use AES-128. WirelessHART uses CCM mode with session keys, a shared network key and a separate join key. ISA100 defines join, master, data link and session keys, with key lifetimes that the WCI guide says can be renewed up to a maximum of 48.5 days.
• Join keys authenticate a device to the security manager. A unique join key per device turns the gateway's list of keys into an access control list. One plant wide join key turns every device into a copy of the network's front door key.
• The radio layer is rarely the easiest way in. The gateway's firmware, web interface, accounts and upstream protocols (HART-IP, Modbus TCP, OPC UA) deserve the most attention. Put each gateway in its own IEC 62443 zone and allow only the conduits it needs.

What is HART, and why was WirelessHART created?

HART on a 4 to 20 mA loop

HART stands for Highway Addressable Remote Transducer. FieldComm Group, which owns the HART specifications today, describes it as a bidirectional protocol between intelligent field instruments and host systems. The host might be a handheld communicator, a laptop, a distributed control system, an asset management tool or a safety system.

The clever part is that HART does not replace the analog loop. A transmitter still sends its primary measured value as a current between 4 and 20 mA on the same two wires that power it. On top of that analog signal, HART superimposes a low level digital signal using frequency shift keying based on the Bell 202 standard. FieldComm Group gives the digital rate as 1200 bits per second and says that is typically enough for two to three primary variable updates per second. Because the FSK signal is phase continuous, it does not disturb the analog reading.

The digital channel carries the extras: device status, diagnostics, secondary variables and configuration. HART is request and reply by design, so a field device speaks only when a host asks, with an optional burst mode in which the device keeps publishing after one command. Devices can be wired point to point or in multidrop configurations.

HART commands come in three classes. Universal commands must be supported by every HART device (for example, reading the primary variable and units). Common practice commands are implemented by many devices but not all. Device specific commands cover functions unique to a product and are described to hosts through a Device Description (DD) file. FieldComm Group sells the HART protocol specification as a kit of 17 documents.

Why go wireless?

Wires are the expensive part of instrumentation. Every new measurement point needs cable, tray, junction boxes and I/O, and plants could not justify a cable run to every steam trap or vibration point.

FieldComm Group positions WirelessHART as "HART without the wires": it keeps HART commands, Device Descriptions and tools, so a technician who knows HART can work with a wireless transmitter the same way. The organisation cites 30 to 60 percent lower installation cost than wired instruments in its user case studies; that is the standards body's own figure, not an independent measurement.

Timeline of the two standards

Two dates in that table deserve care. FieldComm Group's HART-IP page says HART-IP was developed in 2012, while its HART-IP security paper says WirelessHART gateways and remote I/O have supported HART-IP "since 2009". Both are FieldComm Group documents; the likeliest reading is that gateway support came first and the protocol was formalised later, but we could not confirm that from a primary source. Also, the ISA100 WCI's own "About" page writes the IEC number as "IEC 62743", which appears to be a typo: its own guide, and the ISA record, use IEC 62734.

How is a WirelessHART network built?

The three elements, plus adapters

FieldComm Group describes every WirelessHART network as three main elements.

1. Wireless field devices. Transmitters, positioners and other instruments with WirelessHART built in, or existing wired HART devices fitted with a WirelessHART adapter. One adapter can serve several wired devices on a loop, which is how many plants add wireless diagnostics to old instruments without touching the control wiring.
2. Gateways. The gateway connects the wireless mesh to host applications on a wired backbone or another plant network. FieldComm Group's brochure lists the gateway as containing the access point, the network manager and the security manager, with integration through HART-IP, Modbus RTU and Modbus TCP, Wi-Fi backhaul and other options.
3. A Network Manager. It configures the network, schedules communication between devices, manages message routes and monitors network health. FieldComm Group notes it can live in the gateway, the host application or the process controller.

The fourth role is the Security Manager, which generates, stores and manages keys. FieldComm Group's security page says there is one security manager per WirelessHART network, that it can be centralised to serve several networks, and that field devices "are not authorized to be network key servers or wireless network managers". In most products the security manager is embedded in the gateway.

Mesh, time slots and channel hopping

WirelessHART uses IEEE 802.15.4 radios (the brochure cites IEEE 802.15.4-2006 at 250 kbit/s) in the 2.4 GHz ISM band. Each device can route messages for others, so a transmitter that cannot hear the gateway directly forwards through a neighbour. That mesh gives redundant paths around pipe racks, tanks and parked vehicles.

The network is not a free for all. FieldComm Group's security paper explains that each network runs on a strict overall timing schedule and each instrument is assigned a time to communicate. The network manager builds that schedule. Devices also follow a pseudo-random channel hopping sequence and can blacklist channels, which reduces interference with IEEE 802.11 Wi-Fi in the same band. Clear channel assessment is used before transmitting. The 2016 edition of IEC 62591 extended the clear channel assessment modes to align more closely with IEEE 802.15.4.

The standard supports several messaging modes: periodic publishing of process values, notification by exception, ad hoc request and response, and segmented block transfers for large data sets. Choosing the mode per device is how engineers balance update rate against battery life.

What the 2016 edition added

The IEC's abstract for IEC 62591:2016 lists the main technical changes over the 2010 edition. Several matter for operations and security:

• Key performance indicators for performance statistics.
• "Stale data" detection, with services to set thresholds and timers.
• New gateway commands.
• A Quarantined State for devices.
• Clarifications on whitelist and blacklist management.
• Clarifications on joining (for example, that a device needs only a single neighbour to join) and on join links, table management and defaults.

Use stale data detection: a transmitter that stops reporting should raise an alarm, not leave its last value frozen on screen.

What is ISA100.11a?

Origins and standardisation

ISA100 Wireless grew out of a 2002 US Department of Energy study, according to the ISA100 Wireless Compliance Institute (WCI), which estimated large savings from open, standards based wireless at industrial sites. ISA formed the ISA100 committee in 2005, with input that the WCI puts at more than 250 organisations. The revised ISA100.11a-2011 was approved by ISA in May 2011 and published by ANSI in December 2011, then proposed to IEC TC65/SC65C and approved as IEC 62734 in October 2014.

ISA's own standards page describes ISA-100.11a-2011 as specifying "secure, reliable wireless communication" for applications from non-critical monitoring to closed loop control, with system management and gateway specifications, security and interference resistance, and support for fixed, portable and mobile devices.

The WCI, an ISA affiliate, writes implementation specifications on top of the standard so that devices from different suppliers interoperate, runs compliance testing, and certifies products.

IPv6 all the way to the sensor

The headline difference from WirelessHART is the network layer. ISA100 uses IPv6 addressing, with 6LoWPAN compression (the IETF scheme from RFC 4944 for carrying IPv6 over IEEE 802.15.4) and UDP above it. The WCI says ISA100 is the only industrial wireless protocol to build IPv6 into its network and transport layers, and that it supports multiple subnets so sensors can be grouped and separated much like VLANs. That is the WCI's characterisation; the practical point is that ISA100 devices have IPv6 addresses and can be routed and managed with familiar IP tools.

The architecture

The WCI guide describes these components:

• Field devices. A routing device relays messages for neighbours and uses more power. An I/O device (non-routing) only senses or actuates, which gives longer battery life.
• Access points, which route between the wireless subnet and an IP backbone network. Adding an access point to the backbone adds a subnet, and each subnet can be managed separately. The backbone can run over fibre, which lets access points sit in remote or explosion proof areas.
• Gateway. Translates ISA100 traffic into higher level control network protocols for control systems and device management tools. The WCI's application framework defines an OPC UA interface in the gateway and has adopted the PA-DIM information model, with wireless extensions, so different suppliers' gateways expose the same data model.
• System manager. Handles join and leave, reports network abnormalities, assigns communication resources such as channels, distributes system time, monitors devices and optimises performance. When a device asks to join, the system manager and security manager decide whether to admit it and then allocate bandwidth and settings.
• Security manager. Generates, distributes and updates keys, authenticates devices and authenticates messages.

ISA100 supports mesh, star and hybrid topologies, TDMA and CSMA modes, channel hopping and channel blacklisting. A feature called duocast lets a device transmit to two access points simultaneously, so a lost frame on one path does not force a delayed retry; with dual gateways it supports a fully redundant system. The specification allows up to 65,535 devices per access point (a 16 bit address space), though the WCI guide notes that real products support far fewer because of memory and implementation limits.

Tunnelling and safety data

ISA100 was designed to carry other protocols. The WCI lists PROFIBUS, FOUNDATION Fieldbus, HART, Modbus and OPC among those it supports through tunnelling, and its guide includes a gas detection case in which ISA100.11a carries PROFIsafe safety data, meeting IEC 61784-3 requirements through mechanisms including the tunnelling of safe data. Tunnelling helps brownfield integration, but the wireless layer protects only the radio hop, not a Modbus write once it leaves the gateway.

Provisioning: getting the join key into the device

Before an ISA100 device can join, it needs a network ID and a join key. The WCI guide describes two provisioning methods. Over the air (OTA) provisioning uses the ISA100 radio itself and is required by the standard. Out of band (OOB) provisioning uses a separate short range interface such as infrared, Bluetooth Low Energy or USB; it is optional in the standard, but the WCI notes that many products use it to improve security because the key never crosses the open radio channel. The provisioning tool also produces a provisioning file that is registered with the gateway, so the system and security managers know which devices may join.

How does security work in WirelessHART and ISA100.11a?

The cipher

Both standards use AES with 128-bit keys. WirelessHART specifies AES-128 in CCM mode. CCM, defined by NIST in SP 800-38C, combines counter mode encryption with a CBC-MAC so a single key and nonce give both confidentiality and an authentication tag. The point to remember is that CCM depends on never reusing a nonce under the same key, which is one reason both standards tie keys to time and rotate them.

FieldComm Group says WirelessHART security "is built in and cannot be disabled". The ISA100 WCI guide frames ISA100 security around availability (channel hopping, mesh, retries, duocast), integrity (device and message authentication) and confidentiality (AES-128 encryption).

WirelessHART keys

FieldComm Group's security page and its "Intrinsically Secure WirelessHART" paper describe three kinds of key, plus integrity checks at two layers.

Two details from FieldComm Group are worth repeating. First, a field device that routes your data does not hold the session keys for it and cannot read it. Second, the security manager automatically handles every key except the join key. In FieldComm Group's words, that leaves the user "only one type of key to control". Some implementations manage join keys automatically too.

Devices also report anomalies: failed join attempts that may indicate a rogue device, message integrity and authentication failures, and counters such as retransmissions that can point to jamming or other denial of service.

ISA100 keys

The ISA100 WCI guide lists a slightly different set.

The master, DL and session keys have expiry dates and are renewed automatically. The WCI guide gives a maximum renewal period of 48.5 days. Note that the WCI guide states that each device has a different join key; that is how the WCI describes ISA100 practice, while some products also allow a shared join key for convenience.

What wireless security does not cover

It helps to be blunt about the edges:

• The gateway decrypts everything. End-to-end in both standards means device to gateway (or device to manager). Once data leaves the gateway as HART-IP, Modbus or OPC UA, the wireless keys play no part.
• Availability is physics. Channel hopping, mesh paths and duocast make interference survivable, but anyone with a transmitter can degrade a 2.4 GHz network. NIST SP 800-82 Rev. 3 notes that wireless field networks are inherently less reliable than wired ones because of jamming, distance and line of sight.
• A stolen or default join key is a valid credential. The cryptography cannot tell the difference between a technician's provisioning tool and someone else's if both hold the key.
• Physical access to a device or adapter may expose its configuration. FieldComm Group's paper lists physical security as a separate control for that reason.
• Engineering laptops and provisioning tools hold key material and provisioning files. They are part of the security boundary.

How do these networks coexist with Wi-Fi, and how does data go upstream?

Sharing 2.4 GHz

Wi-Fi, Bluetooth, WirelessHART and ISA100 all use the 2.4 GHz ISM band. IEEE 802.15.4 channels are narrow, while each Wi-Fi channel is much wider, so a Wi-Fi access point overlaps several 802.15.4 channels. Both industrial standards handle this with channel blacklisting (marking channels that overlap busy Wi-Fi channels as unused) and channel hopping across the rest. The WCI guide illustrates ISA100 blacklisting the 802.15.4 channels under a Wi-Fi channel.

In practice coexistence is a planning task. NIST SP 800-82 Rev. 3 recommends a wireless survey before installation to choose antenna locations, confirm coverage and reduce exposure to interference and eavesdropping, and it notes that attackers use directional antennas to reach beyond the normal range. Coordinate the Wi-Fi channel plan for the unit with the blacklist on the industrial gateway, and document both.

The upstream side

Gateways hand data to the control and business layers in several ways:

• HART-IP. FieldComm Group's HART-IP runs the HART application layer over UDP and TCP on Ethernet, Wi-Fi and other IP links, on default port 5094. WirelessHART gateways and HART multiplexers use it to pass HART commands through to asset management tools. HART-IP servers support at least five clients at once.
• Modbus RTU and Modbus TCP. Common for mapping process values into a PLC or DCS register table. Modbus itself has no authentication; see our Modbus explainer.
• OPC UA. Standard in the ISA100 application framework and offered by many WirelessHART gateways. OPC UA has its own security modes and certificates; see our OPC UA explainer.
• Wi-Fi or other backhaul, when the gateway itself sits at the edge of the unit.

HART-IP security in brief

FieldComm Group's "Introduction to HART-IP Security" (edition 2.0, 15 March 2023) is the best primary description of what the upstream protocol offers.

• Version 2 of HART-IP mandates TLS (over TCP) and DTLS (over UDP), version 1.2 or later. Servers must support four specified cipher suites.
• Authentication uses either a pre-shared key (PSK) or Secure Remote Password (SRP). Servers must support both, and the user can choose.
• Servers must hold credentials for at least five users. Slot 0 belongs to the security manager, which is the only user that can change credentials. Users can be marked read only, and a read only client that tries to change configuration is disconnected.
• Servers keep audit logs (which clients connected, which one changed configuration) and support syslog.
• The very first connection matters. A fresh or factory reset server defaults to IP address 192.168.0.42 for bench provisioning. If a version 1 client connects first, the server locks into version 1 with no security and protection must come from the network, for example a VPN. If a version 2 client connects first, it must set the security manager credentials in that session; otherwise the server randomises them and needs a factory reset.
• All HART-IP products must be field upgradable so security mechanisms can be improved later.

Treat the first HART-IP session on a new gateway as a security event, done on an isolated bench network with a version 2 client.

WirelessHART, ISA100.11a, Zigbee and LoRaWAN compared

This table compares approaches, not products. Zigbee facts come from the Connectivity Standards Alliance and LoRaWAN facts from the LoRa Alliance; our dedicated posts go deeper.

We left out latency figures on purpose: both industrial standards let engineers trade update rate against battery life, so numbers vary by configuration.

Why is the gateway the weak point?

Look at the radio layer and the gateway side by side. The radio uses mandatory AES-128, per message integrity checks, scheduled access and a security manager. The gateway is a small embedded computer with an Ethernet port, a web management interface, user accounts, a firmware image, upstream servers for Modbus TCP, HART-IP and OPC UA, and often remote access for the supplier. It also holds every key for the mesh.

Several reasons make the gateway the place to focus:

• It is the decryption point. Whoever controls the gateway sees and can inject everything the mesh carries.
• It runs general purpose software. Web servers, TLS libraries, embedded databases and operating system components in gateway firmware get vulnerabilities like any other software. Updates come only from the manufacturer.
• It speaks weakly protected protocols upstream. Modbus TCP has no authentication, HART-IP version 1 has no transport security, and OPC UA is only as strong as the security mode configured.
• It is often placed for convenience. A gateway on a flat control network or, worse, reachable from the corporate LAN, inherits every path into that network.
• Its credentials are often defaults. CISA's May 2025 fact sheet on primary OT mitigations lists changing default passwords and removing OT connections to the public internet among its first actions, noting that targeted systems used default or easily guessed passwords.

Zones and conduits for wireless

ISA/IEC 62443 groups assets with similar security requirements into zones and controls traffic between them through conduits. CISA's August 2025 asset inventory guidance uses the same model: a conduit connects zones under strict rules so only authorised traffic passes, and conduits are found by mapping communication paths, protocols and Layer 2 and Layer 3 details.

For an industrial wireless network, a sound pattern is:

• Wireless field zone. The mesh itself, the access points and (for ISA100) the backbone routers. Treat the RF boundary as the zone edge.
• Gateway zone. The gateway, or redundant pair, on its own segment behind a firewall. NIST SP 800-82 Rev. 3 recommends that wireless devices sit in a separate network segment and that access points establish independent segments with boundary protection, rather than extending an existing segment.
• Conduits. One to the control system (Modbus TCP or OPC UA from named controller or historian addresses only), one to asset management (HART-IP from the asset management server only), one for engineering and maintenance (from a jump host, during approved windows). Nothing to the corporate network directly; data for business users goes through a DMZ historian or broker.

NIST SP 800-82 Rev. 3 also gives four specific recommendations for wireless field networks: choose a standard, non-proprietary protocol; make sure encryption is used between field instruments and access points; allowlist devices in the wireless device manager so rogue devices cannot connect; and use appropriately complex passwords and join keys.

Step by step: inventory, unique join keys, key rotation and a gateway zone

The steps below are defensive and mostly paperwork. Where they touch a live system, do them in a maintenance window with the unit's owners, and follow the gateway manufacturer's procedure for every key or firmware change.

Step 1: inventory gateways, access points and firmware

CISA's asset inventory guidance recommends defining scope by zone, then collecting attributes for each asset through physical inspection and logical survey. For wireless networks, a spreadsheet or CMDB record per gateway and access point is enough to start. A minimal template:

asset_id,role,standard,manufacturer,model,serial,firmware_version,firmware_date,location,zone,ip_address,upstream_protocols,mgmt_interfaces,network_id,join_key_mode,last_key_rotation,security_manager,support_contact,advisory_feed
GW-U200-01,gateway,WirelessHART,<maker>,<model>,<serial>,<ver>,<date>,Unit 200 rack 3,Z-WL-GW-200,10.20.0.10,"HART-IP;Modbus TCP","HTTPS;SSH",<id>,per-device,2026-09-01,embedded,<contact>,<url>
AP-U200-02,access point,ISA100,<maker>,<model>,<serial>,<ver>,<date>,Unit 200 pipe rack,Z-WL-FIELD-200,fd00::12,"n/a","HTTPS",<id>,per-device,2026-09-01,GW-U200-SM,<contact>,<url>

Record each field device and adapter too: tag, device type, firmware or device revision, power source and the date its join key was last set. Read firmware versions from the gateway's management interface or your asset management tool rather than by scanning; active network scans can upset older embedded stacks.

If you want to confirm what is actually talking upstream, capture passively from a mirror port on the gateway's switch. For example, to see only HART-IP traffic on its default port:

# Passive only: the capture interface is a SPAN or TAP port that cannot transmit.
# Confirm the interface name before you start.
ip link show
sudo tcpdump -i eth1 -nn -w gw-u200-hartip.pcap 'port 5094'

Compare the source addresses in the capture with the conduits you expect. Any HART-IP or Modbus client you cannot name is a finding.

Step 2: set a unique join key per device

Both FieldComm Group and the ISA100 WCI describe unique join keys per device as the way to turn the gateway's key list into an access control list. Where your gateway supports it, switch the network to per-device join keys.

1. Generate keys on a trusted, offline workstation. A 128-bit key is 32 hexadecimal characters:

# One random 128-bit join key per device tag, written to a file only you can read.
umask 077
for tag in PT-2001 TT-2002 LT-2003; do
  printf '%s,%s\n' "$tag" "$(openssl rand -hex 16)"
done > joinkeys-unit200.csv

2. Load each key into the device through the manufacturer's provisioning path: a handheld or software tool over the maintenance port for WirelessHART, or OOB provisioning (infrared, Bluetooth Low Energy or USB) for ISA100 where available. Prefer out of band methods so the key never crosses the radio.
3. Enter the same key for that device in the gateway's security manager, or import the provisioning file the tool produced.
4. Confirm the device joins, then remove it from any shared join key list.
5. Store the key file in your secrets vault, not on the provisioning laptop, and delete the working copy.

FieldComm Group's paper says plainly to never use default keys and recommends randomly generated keys. If a supplier ships devices with a factory join key, treat replacing it as part of commissioning.

Step 3: rotate network and session keys on schedule

The security manager rotates WirelessHART network and session keys, and ISA100's master, DL and session keys expire and renew automatically (the WCI guide gives a maximum of 48.5 days). Your job is to check that rotation is on and to set a policy for the keys a human controls.

• Check the gateway's security settings for automatic key rotation and the configured period, and record it in the inventory.
• For a shared join key, change it on a schedule your security policy sets. FieldComm Group warns to make sure every device is on the network when you change it, so none are orphaned.
• With per-device join keys, FieldComm Group notes rotation is not required for the join key itself, since each key belongs to one device. Re-key a device when it is replaced, removed or its key may have been exposed.
• After any rotation, watch the gateway's join failure and stale data alarms for a full reporting cycle.

Step 4: put the gateway in its own zone

A simple host firewall or zone firewall policy, expressed here in nftables syntax as an illustration, shows the shape. Use the ports and addresses your gateway is actually configured with, test it on a lab gateway first, and apply it at the zone firewall rather than on the gateway itself unless the manufacturer supports that.

# Illustrative conduit policy for the Unit 200 wireless gateway zone (Z-WL-GW-200).
define DATA_PORT = 10000  # placeholder: set the Modbus TCP or OPC UA port your gateway uses

table inet wl_gw_zone {
  set historians  { type ipv4_addr; elements = { 10.30.0.21, 10.30.0.22 } }
  set asset_mgmt  { type ipv4_addr; elements = { 10.30.0.40 } }
  set jump_hosts  { type ipv4_addr; elements = { 10.40.0.5 } }

  chain forward_to_gateway {
    type filter hook forward priority 0; policy drop;
    ct state established,related accept
    # HART-IP from the asset management server only (default port 5094)
    ip saddr @asset_mgmt ip daddr 10.20.0.10 tcp dport 5094 accept
    ip saddr @asset_mgmt ip daddr 10.20.0.10 udp dport 5094 accept
    # Upstream data protocol from the historians only; set the port your gateway uses
    ip saddr @historians ip daddr 10.20.0.10 tcp dport $DATA_PORT accept
    # HTTPS management from the jump host only
    ip saddr @jump_hosts ip daddr 10.20.0.10 tcp dport 443 accept
    log prefix "wl-gw-deny " drop
  }
}

Set DATA_PORT to the port configured on your gateway. Then remove any route from the corporate network into the zone, disable management services you do not use (HTTP without TLS, Telnet, unused SNMP versions), change default accounts, and forward the gateway's logs, and HART-IP audit and syslog events where supported, to your monitoring.

Step 5: keep firmware and adapters current

Subscribe to the gateway and adapter manufacturers' security advisories and to CISA's ICS advisories, and record the firmware version each time you update. Adapters and battery powered devices are easy to forget; plan their updates with the next battery change or turnaround.

Common mistakes

• One join key for the whole plant. Every device then holds the network's admission credential, and a single lost handheld or provisioning file exposes it. Use per-device keys.
• Factory default join keys or gateway passwords. Both FieldComm Group and CISA call this out. Change them at commissioning and record that you did.
• Gateways on the corporate LAN or a flat control network. The gateway decrypts the mesh and speaks unauthenticated protocols upstream. Give it its own zone and named conduits.
• HART-IP left in version 1 mode. If a version 1 client made the first connection, the server has no transport security. Provision gateways with a version 2 client on the bench, or protect version 1 traffic at the network layer.
• OPC UA or Modbus exposed beyond the historian. Restrict clients by address and, for OPC UA, use a signed and encrypted security mode.
• Adapters and field devices never updated. Track device revisions in the inventory and plan updates with maintenance.
• Ignoring stale data and join failure alarms. These are the earliest signs of interference, a failed device or an unexpected join attempt.
• Uncoordinated Wi-Fi. A new Wi-Fi access point on a channel the gateway has not blacklisted can degrade a whole unit.
• Provisioning files left on laptops. Join keys in a spreadsheet on an engineering laptop are the keys to the mesh.

FAQ

What is the difference between WirelessHART and ISA100.11a?

Both are IEEE 802.15.4 mesh standards for process plants with central managers and AES-128 security. WirelessHART extends the HART protocol and keeps HART commands and tools. ISA100.11a uses IPv6 with 6LoWPAN, an IP backbone with access points, and tunnels other protocols such as Modbus, HART and PROFIBUS.

Is WirelessHART encrypted?

Yes. FieldComm Group says security is always on and cannot be disabled. Payloads are encrypted end to end between device and gateway with AES-128 in CCM mode using session keys, with a shared network key for broadcast and a separate join key for the join exchange.

What is a join key in WirelessHART?

A 128-bit key that a device uses to authenticate itself to the security manager and to protect the join exchange. It can be common to the whole network or unique per device; unique keys form an access control list. Users usually manage only the join key, and the security manager handles the rest.

What does the network manager do in WirelessHART?

It configures the network, schedules when each device transmits, manages routes through the mesh and monitors network health. It usually runs in the gateway but can sit in a host application or controller.

What is the difference between the system manager and the security manager in ISA100?

The system manager admits devices, assigns channels and bandwidth, distributes time and monitors performance. The security manager generates, distributes and renews keys and authenticates devices and messages. The WCI's reference architecture often draws the gateway, system manager and security manager as one box.

What IEC standard is ISA100.11a?

IEC 62734. ISA approved ISA100.11a-2011 in May 2011 and ANSI published it in December 2011; the ISA100 WCI says IEC approved it as IEC 62734 in October 2014.

Can WirelessHART and Wi-Fi work in the same area?

Yes, with planning. Both standards use channel hopping and channel blacklisting to avoid busy Wi-Fi channels. Survey the site, coordinate the Wi-Fi channel plan with the gateway's blacklist and keep both documented.

What port does HART-IP use?

FieldComm Group documents 5094 as the default HART-IP port over UDP and TCP. Version 2 of HART-IP requires TLS or DTLS 1.2 or later with PSK or SRP authentication.

How does IEC 62443 apply to wireless sensor networks?

Treat the mesh and access points as one zone, the gateway as another, and define a conduit for each upstream flow (control system, asset management, engineering) with named sources and ports. NIST SP 800-82 Rev. 3 adds wireless specifics such as separate segments, encryption and device allowlisting.

Where Safeguard fits

Safeguard does not monitor wireless networks, manage join keys, configure gateways or firewalls, or scan device or gateway firmware, and it is not an industrial intrusion detection system. WirelessHART and ISA100 radios, gateways and their firmware are patched only by their manufacturers.

The fit is indirect, but real, in software your team builds around the gateway. Historian connectors, OPC UA or Modbus bridges, Python and Node.js data pipelines, dashboards and the container images for an on-site analytics server are ordinary software with open source dependencies. Safeguard can scan those repositories, container images and SBOM files with safeguard scan --dir ., --image <name> or --sbom <file>, match their components against vulnerability databases, show which projects contain a given component and version, rank findings with reachability analysis and evaluate policies and gates in the platform. Our post on SBOM requirements for industrial control systems covers the same discipline from the supplier side.

A rebuilt data collector or edge server pulls its libraries again from public registries and base images, and the bridges that read HART-IP, Modbus or OPC UA from a wireless gateway ship open source parsers, TLS stacks and web frameworks of their own. Those components need the same patch hygiene as any other software you build, even though the radios and gateways stay on their manufacturers' update schedules.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Safeguard Gold rebuilds patched versions of open-source packages and images from source, signs each build, attaches an SBOM, SLSA provenance and VEX, and serves them from registry.safeguard.sh to your organization. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

These demos show dependency, SBOM and remediation workflows, not wireless network monitoring or gateway management. You can download Safeguard and follow the CLI docs to try them on your own projects.

This demo sets up the Safeguard runner on your own machine, approves it with its device code and scans from the terminal. Pointed at the repository or container image of a historian connector or OPC UA bridge your team builds, the same scan lists the packages and versions inside it and their known vulnerabilities.

Click through it at your own pace, or open it full screen.

This demo is a real CLI session: ask it to fix the lodash CVE in a repository and watch it read the finding and the advisory, ask before any command that changes something, move lodash to 4.17.21, run npm install and npm test with your approval, and push nothing. The same flow applies when you bump a vulnerable library in a Node.js or Python service that reads data from a wireless gateway.

Click through it at your own pace, or open it full screen.

This demo connects Claude to the Safeguard MCP server with OAuth and lets you choose which tools Claude can use. You can then ask which of your projects ship a given package version and get the answer from your own scan data.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• IEC 62591:2016, Industrial networks: Wireless communication network and communication profiles, WirelessHART (IEC webstore)
• FieldComm Group: WirelessHART
• FieldComm Group: WirelessHART Security
• FieldComm Group: Intrinsically Secure WirelessHART Field Device Networks and the IIoT (technical paper)
• FieldComm Group: WirelessHART, Expanding the Possibilities (brochure)
• FieldComm Group: HART
• FieldComm Group: HART Technology Explained
• FieldComm Group: HART-IP
• FieldComm Group: Introduction to HART-IP Security, edition 2.0
• FieldComm Group: HART-IP Technical Description
• ISA100 Wireless Compliance Institute
• ISA100 WCI: About ISA100 Wireless
• ISA100 WCI: Why IPv6
• ISA100 WCI: OPC UA and PA-DIM
• ISA100 WCI: Compliance (FDI and FDT)
• ISA100 WCI: ISA100 Wireless, The Complete Guide (PDF)
• ISA: ISA-100 standards
• ISA: ISA/IEC 62443 series of standards
• IEEE 802.15.4 standard page
• IETF RFC 4944: Transmission of IPv6 Packets over IEEE 802.15.4 Networks
• NIST SP 800-82 Rev. 3: Guide to Operational Technology Security
• NIST SP 800-38C: The CCM Mode for Authentication and Confidentiality
• CISA: Industrial Control Systems
• CISA: Primary Mitigations to Reduce Cyber Threats to Operational Technology (6 May 2025)
• CISA: Foundations for OT Cybersecurity, Asset Inventory Guidance (13 August 2025)
• Connectivity Standards Alliance: Zigbee
• LoRa Alliance: About LoRaWAN

Last reviewed: 26 October 2026. IEC 62591, IEC 62734, the ISA/IEC 62443 parts and NIST SP 800-82 are revised from time to time; check the pages above for current editions before relying on a specific clause.