MITRE D3FEND Remote Firmware Update Monitoring Implementation Guide: Detecting Unauthorised OT Firmware Changes on the Network

A controller or protection relay that receives new firmware over the network can change its behaviour completely, and in many plants nobody would notice until the process misbehaves. MITRE D3FEND names the network-side control for this Remote Firmware Update Monitoring (D3-RFUM): watching OT network traffic for firmware update commands so that unauthorised installations are detected. Unlike most parent techniques, D3-RFUM has no child techniques, so this guide covers the technique itself: where it sits in D3FEND, how to deploy passive sensors that can see firmware commands, how to tie alerts to approved change windows, how to test it safely, and its limits. It is written for OT security engineers, ICS detection engineers and plant change managers. For OT monitoring in general see the OT Network Security Monitoring Guide; for D3FEND itself see the MITRE D3FEND Guide.

Key takeaways

• D3-RFUM is a detection technique for OT networks. D3FEND defines it as monitoring of remote firmware update commands to identify unauthorised software installations, using passive sensors and deep packet inspection.
• It is a leaf, not a family. In the D3FEND ontology it sits under Application Protocol Command Analysis, inside Network Traffic Analysis, which enables the Detect tactic.
• The hard part is protocol visibility. Firmware transfer uses vendor engineering protocols and protocol-specific services; a sensor that cannot parse them sees only bytes.
• An alert is only useful against an approved change record. Most firmware commands on a healthy network are legitimate maintenance, so correlation with change windows decides whether the control works.
• D3FEND lists no ATT&CK relations for D3-RFUM in the current release. Any mapping to ATT&CK for ICS is a practitioner judgement and is labelled as ours on this page.

What D3FEND says

The D3FEND ontology gives D3-RFUM two relations: it detects OT Device Firmware Command, defined as interaction with the software responsible for low-level control of the system, and it monitors OT Network Traffic, defined as network traffic generated by operational technology devices such as programmable logic controllers. Its parent, Application Protocol Command Analysis, analyses application protocol level remote commands to detect unauthorised activity. The parent of that technique is Network Traffic Analysis (D3-NTA), which enables the Detect tactic.

The D3FEND description of how it works is short: sensors deployed in the OT environment passively monitor network traffic, deep packet inspection identifies protocol-specific commands and produces logs of firmware activity, and behavioural and signature-based analysis can add detection and alerting. Its single reference is a Nozomi Networks patent on detecting anomalies in time series data from infrastructure devices, and its see-also is NIST SP 800-82. As of November 2026 the D3FEND page states "No related offensive techniques in this release" for Enterprise, ICS, Mobile and ATLAS.

Where D3-RFUM sits among firmware defences

D3-RFUM watches the delivery path. Other D3FEND techniques watch the device or the image itself, and a sound firmware programme combines them. D3-RFUM tells you that an update was attempted and from where; verification tells you whether what is running is what should be running. See the D3-FV Firmware Verification, D3-SFV System Firmware Verification and D3-FBA Firmware Behavior Analysis guides.

Deploying the sensors

1. Identify firmware-capable assets and their update paths. From the asset register, list controllers, relays, drives, gateways and network devices that accept remote firmware, the protocol and tool each uses, and the engineering workstations allowed to push it. See the OT Asset Visibility Guide.
2. Place passive sensors where engineering traffic crosses. Typically SPAN or TAP points between the engineering workstation zone and the control zone, and on conduits used by remote access. Passive collection avoids adding traffic to sensitive control networks. See the OT Network Segmentation, Purdue Model and IEC 62443 Zones and Conduits Guide.
3. Confirm protocol parsing. Check that the sensor decodes the specific services used for firmware and program transfer on your equipment, not just the protocol name. Commercial OT monitoring platforms ship vendor protocol parsers; open-source analysers such as Zeek decode common protocols, for example its DNP3 analyser logs request and reply function codes, including file functions such as OPEN_FILE, AUTHENTICATE_FILE and restart commands, and its Modbus analyser logs the function name and any exception.
4. Baseline for a full maintenance cycle. Record which sources send firmware or file transfer commands, to which devices, and when. Legitimate sources should be a short list.
5. Write detections. At minimum: firmware or file transfer commands from a source not on the approved list, outside an approved change window, to a safety or protection device, or followed by a device restart or mode change.
6. Integrate with change management. Feed approved work orders (asset, window, engineer, firmware version) to the SOC so alerts can be closed or escalated quickly. See the OT Security Operations Centre Guide.

Testing and rollback

Test on a lab or spare device, never on a live controller. Replay captured traffic from a real, approved update through the sensor, or perform a planned update on a test bench, and confirm the event, the alert and the change-record match. Because the sensor is passive, rollback is simple: remove or tune the detection rule. The operational risk lies in the SPAN or TAP change itself, so treat it as an OT change with its own approval.

Decision guidance

• Small plants or single sites: start with one sensor at the boundary between engineering and control zones, plus a rule on any firmware or program transfer outside a change window. Pair it with a manual firmware version check at each maintenance visit.
• Multi-site and critical infrastructure operators: deploy sensors per site, centralise alerts in an OT-aware SOC, and add version tracking so every completed update is checked against the expected firmware.
• Where vendors update remotely: route vendor sessions through a monitored remote access path so their updates pass a sensor and match a work order. See the OT Remote Access Guide.

Where identity fits

Firmware pushes come from engineering workstations, vendor accounts and automation service accounts, many of them shared. An alert that says "firmware command from 10.1.2.3" is far less useful than one that names the engineer or vendor session behind it. Tie sensor events to remote access session logs and named accounts, and remove shared engineering logins where you can. See the OT and ICS Identity and Access Guide.

Relevant ATT&CK for ICS techniques (our mapping)

D3FEND lists no ATT&CK relations for D3-RFUM, so the table below is NHI Mgmt Group's view of the ICS techniques whose network delivery this monitoring can observe. It is a test list, not a coverage claim.

In ATT&CK v20 the older ICS techniques for system firmware and module firmware were revoked and replaced by the sub-techniques T1693.001 System Firmware and T1693.002 Module Firmware. See T1693 Modify Firmware and MITRE ATT&CK for ICS T0800 Activate Firmware Update Mode.

Detection and measurement

Example metrics (our suggestions, not standards):

1. Coverage: percentage of firmware-capable assets whose remote update path passes a sensor.
2. Parser coverage: percentage of those assets whose firmware or file transfer service the sensor decodes.
3. Correlation rate: percentage of firmware events matched to an approved work order.
4. Unmatched events: count per month and time to resolve each one.
5. Post-update verification: percentage of detected updates followed by a firmware version or integrity check.

Limits and bypasses

• Local paths are invisible. Serial, USB and front-panel updates never cross the monitored network; firmware verification and physical controls must cover them.
• Encrypted or proprietary sessions. If the sensor cannot decode the session it may log a connection but not the firmware command. Check parser support per device family.
• Approved channels can be abused. An update from the normal engineering workstation in a change window looks legitimate; version verification afterwards is the check that catches it.
• Sensor blind spots. Traffic between devices on the same switch segment may never reach the SPAN point.

Framework mapping

Common failure patterns

• Sensors that see the protocol but not the service. Traffic is classified by protocol name, so firmware writes look like routine reads.
• Alerts with no change context. Every maintenance window floods the SOC and real events are closed as noise.
• No follow-up verification. The update is detected but nobody checks what firmware the device now runs.
• Vendor remote sessions outside the monitored path. Direct modems or cellular gateways bypass the sensors.

Practitioner checklist

• List firmware-capable assets, their update protocols and approved update sources.
• Place passive sensors on the conduits between engineering, remote access and control zones.
• Confirm the sensor decodes firmware and file transfer services for each device family.
• Baseline for a full maintenance cycle before alerting.
• Alert on unapproved sources, out-of-window updates and updates to safety or protection devices.
• Correlate every event with a work order and a named person.
• Verify firmware version or integrity after each detected update.
• Test on a bench or lab device, never on live controllers.

Standards and references

• MITRE D3FEND: Remote Firmware Update Monitoring
• MITRE D3FEND: Application Protocol Command Analysis
• NIST: SP 800-82 Rev. 3 Guide to Operational Technology (OT) Security
• MITRE ATT&CK for ICS: Modify Firmware
• MITRE ATT&CK for ICS: Activate Firmware Update Mode
• NIST: SP 800-53 Rev. 5
• Zeek Project: DNP3 protocol constants

Related NHI Mgmt Group resources: OT Network Security Monitoring Guide · Firmware and Boot Security Guide · NIST SP 800-82 OT Security Guide · NDR Buyer's Guide · MITRE D3FEND Guide