The short answer
Documenting Firmware Versions
A security advisory says which models and which firmware versions are affected, so an inventory that lacks versions cannot answer whether the utility is exposed. Every device with firmware is recorded with its version and the date it was read: controllers with their processor, module, and communication card firmware separately, drives, switches and firewalls, radios and modems, HMI panels with their runtime, instruments with configurable firmware, and the operating system and application versions of computers. Versions are read from the device display, the programming or configuration software, the device web page, the protocol identification function, or a passive monitoring sensor, recorded in the inventory at commissioning and after every update, and verified on an annual cycle, with the vendor lifecycle status beside them so that the end of support is planned rather than discovered.
Key points
- Advisories name versions; an inventory without versions cannot be matched to them.
- One controller has several firmware versions: processor, I/O modules, communication cards, and sometimes the backplane.
- Record the version and the date it was read; a version without a date is a guess.
- Read it from the device, the software, the web page, the protocol identification, or the sensor, and note which.
- Record the vendor lifecycle status beside the version so end of support is planned.
- Commissioning, every update, and an annual verification: the cadence that keeps it true.
Why versions
A vulnerability notice for a controller family reads like this: affected products, models such and such, firmware versions prior to a stated release. The utility that has recorded the model and version of every controller answers in a minute whether it is affected, which units, and where. The utility that has not spends a day driving to sites with a laptop, and does it again for the next advisory. Versions also decide behavior: a firmware update on a drive can change parameter defaults, and a controller update can change how a communication module handles a timeout, so knowing what is running is part of knowing how the plant works. And vendors end support by version; a device on firmware that will never be patched needs a replacement plan.
Where to read it
| Device class | Where the version is | Notes |
|---|---|---|
| Controllers and remote units | Programming software online with the controller; the controller web page; a front panel display on some models | Processor firmware, each I/O module, and each communication card have their own; record all of them |
| HMI panels | The runtime or system settings screen; the configuration software | Runtime version and the underlying operating system version where exposed |
| Drives and soft starters | The keypad parameter that shows firmware; the configuration software | Control board and power board firmware may differ; option cards have their own |
| Managed switches, routers, firewalls | The management interface; the command line | Firmware and, on some, a separate boot version |
| Radios and cellular modems | The web interface or the configuration utility | Modem firmware and the cellular module firmware can be separate |
| Instruments and analyzers | The device menu; the configuration tool over the protocol; the HART or fieldbus device description | Software revision and hardware revision; the device description version matters for the tool |
| Uninterruptible power supplies, power monitors, cameras | Network card web page; front display | The network card firmware is what advisories usually target |
| Servers and workstations | Operating system and application version dialogs; a configuration audit script | Also the hypervisor, the firmware of the server hardware, and the management controller |
| Any networked device | Protocol identification: the device identification function in Modbus, the identity object in EtherNet/IP, the system description in SNMP; a passive sensor reads these from traffic | Confirms the recorded version without a site visit |
Recording it
- One line per firmware-bearing component, not one per device: a controller with a processor, four modules, and a communication card is six lines or six fields.
- The version exactly as the device reports it, including revision letters and build numbers.
- The date it was read and the method, so that a later reader knows how current and how reliable it is.
- The hardware revision, which advisories and update compatibility also depend on.
- The vendor lifecycle status: active, mature, end of sale, end of support, with the date if announced.
- The latest available version from the vendor, and the date that was checked, so the gap is visible.
- A link to the update record when the version was changed, which is a change record.
The cadence
- 1
At commissioning
Every version read from the device and recorded before acceptance; the integrator handover includes it.
- 2
At every update
The change record for a firmware update includes the version before and after, and the inventory is updated as the closing step.
- 3
At every advisory
The inventory is consulted; if the recorded version is more than a year old or the method was a document rather than the device, the version is re-read before the utility declares itself unaffected.
- 4
Annually
A verification pass, during the site walk or by protocol identification from the sensor, comparing the device against the record and correcting it.
When the version is the problem
The record will show devices whose firmware is years behind, devices whose vendor no longer publishes updates, and devices whose firmware has a published vulnerability with no fix. Each is a decision: update through the firmware management process, apply compensating controls and record them, or plan a replacement with a date. The inventory with versions is what makes the list of decisions visible, and the risk assessment ranks them.
Frequently asked questions
- The controller programming software shows one version and the web page shows another. Which is right?
- They may be reporting different components: the processor firmware in one and the communication module in the other, or a boot loader and an application. Record both with the label the device uses. If the same component reads differently in two places, the device is telling you something and the vendor should explain it.
- Do we really need module firmware, or just the processor?
- Modules and communication cards have their own advisories and their own updates, and a communication card is often the exposed part. Record them. The programming software usually shows all of them on one screen once connected.
- How do we find the latest version without giving devices internet access?
- From the vendor support site, on a workstation outside the control network, on a schedule and when advisories arrive. Record the latest version and the date checked in the inventory. Devices do not check for themselves.
- Is the version a sensitive piece of information?
- Yes: the inventory with versions is the map an attacker would want, because it says exactly which known vulnerabilities apply. It is protected like the rest of the security documentation, and not emailed to bidders or posted in shared folders.
Related topics
- Building an OT Asset InventoryThe list of everything in the control system with a network interface or a program, and how to build one that is right: what counts, the fields to record, the site walk, the switch tables and passive listening that find the rest, and keeping it current.
- Passive DiscoveryFinding out what is on a control network by listening rather than probing: why active scans are risky around older controllers, how a mirror port feeds a sensor, what the traffic reveals, the blind spots, and how the sensor becomes continuous monitoring.
- Firmware ManagementUpdating the firmware of controllers, modules, drives, HMIs, switches, and radios without breaking the plant: why firmware lags and why it still matters, tracking versions, deciding what to update and when, and the update as a planned outage with a rollback.
- Advisories and AlertsWhere a utility learns its equipment has a known vulnerability and what to do with the news: the government and vendor advisory feeds, the sector center, the exploited catalog, subscribing by product, a weekly triage on exposure and consequence, and records.
- Change Management for OTA change process sized for a utility control system: what counts as a change, the request with risk and rollback, owner approval, the window, backup before and verification after, the baseline update, the emergency path, and the record.
- Compensating ControlsWhat to do about a vulnerability that cannot be patched now or ever: restricting who can reach it, disabling the service, blocking dangerous protocol functions, allowlisting, monitoring, physical and procedural controls, matched to the attack path.
Direct contact
Have a controls question?
Reach Eric Sullivan directly about anything on this site, a controls or automation topic, or one of his personal projects.