Activate Firmware Update Mode (T0800) silences a protective device by putting it into the mode used for loading new firmware, so it stops doing its job exactly when the process needs it. MITRE ATT&CK for ICS lists it under Inhibit Response Function: no new code is needed, only access to a legitimate maintenance function. The one procedure example is Industroyer, whose SIPROTEC denial-of-service module left protection relays in Ukraine's grid unable to perform their protective role in 2016. This guide is for protection engineers, OT security engineers and SOC analysts at utilities and plants with intelligent electronic devices (IEDs), relays and controllers. It covers what the technique does, how to restrict and authenticate firmware management, how to detect mode changes and how to respond with process safety first. For the wider matrix see the MITRE ATT&CK for ICS Guide.
Key takeaways
- The goal is silence, not new firmware. ATT&CK describes a device left in update mode, with no firmware supplied, sitting in an inactive holding state with monitoring and protective functions halted.
- Protection relays are the clearest target. Industroyer used this against Siemens SIPROTEC relays, leaving an unprotected link in electric transmission, according to ATT&CK's procedure text.
- Who may reach the management function is the main control. ATT&CK's mitigations all restrict, authenticate or filter access to firmware management: allowlists, authentication, authorisation, segmentation and protocol filtering.
- Detection pairs a mode change with silence. ATT&CK's embedded analytic looks for an update-mode sequence from an unapproved source followed by the device's alarm telemetry going quiet.
- A silenced relay is a safety problem first. Response starts with protection engineers deciding whether the protected equipment must be taken out of service until protection is restored.
What T0800 covers
ATT&CK for ICS (v20) describes T0800 as activating firmware update mode on devices to prevent expected response functions from engaging during an emergency or process malfunction. Devices such as protection relays may have an operating mode designed for firmware installation, which may halt process monitoring and related functions while new firmware is loaded. If no firmware is provided, the device may stay in an inactive holding state. By entering and leaving a device in this mode, the adversary denies its usual functions. The technique applies to Embedded, Windows, Linux and Network Devices platforms.
| Technique | Adversary aim | Difference from T0800 |
|---|---|---|
| T0800 Activate Firmware Update Mode | Stop the device performing its function by holding it in update mode | Firmware itself is not changed |
| T1693 Modify Firmware | Load altered or corrupted firmware | Changes the device's code, often persistently |
| T0858 Change Operating Mode | Move a controller into program, stop or remote mode | Uses run and program modes rather than the firmware update function |
| T0816 Device Restart/Shutdown | Restart or shut the device down | Interrupts the device rather than parking it in a mode |
| T0837 Loss of Protection | The impact: protective functions unavailable | An outcome that T0800 can cause |
See the ATT&CK for ICS Inhibit Response Function Tactic Guide, the T1693 Modify Firmware page, the ICS T0858 Change Operating Mode page and the T0837 Loss of Protection page.
The procedure example: Industroyer and SIPROTEC
ATT&CK v20 lists one procedure example. It records that Industroyer's SIPROTEC denial-of-service module places the victim device into firmware update mode, a legitimate use case under normal circumstances, used here to stop the SIPROTEC relay performing its designed protective functions, so the normal safeguards were disabled and an unprotected link was left in the electric transmission network.
- ESET's analysis: ESET's Industroyer report says the module exploits CVE-2015-5374 in Siemens SIPROTEC devices and that a targeted device stops responding to any commands until it is rebooted manually. ESET assessed it as highly probable that Industroyer was used in the 17 December 2016 attack that cut power to part of Kyiv for about an hour.
- ATT&CK's detection note: the T0800 embedded analytic records Industroyer's use of CVE-2015-5374 to start an incomplete firmware update sequence on SIPROTEC relays.
- The lesson: the vulnerability made the attack easy, but the underlying exposure was a reachable management function on a protection device. Patching closes one path; restricting who can reach the function closes the class.
ATT&CK lists no other software, groups or campaigns for T0800. A related pattern appears under Modify Firmware: CERT Polska reports that in the December 2025 attacks on Polish energy sites the attacker logged in with a default account and uploaded corrupted firmware to RTUs, causing a reboot loop, and that the secure update feature was not enabled on any of those devices. That is firmware modification rather than T0800, but it shows the same weakness: firmware management open to anyone holding a default credential. See the ICS Malware History Guide and the Sandworm Threat Actor Profile.
Which devices are exposed
Any device whose firmware can be loaded over the network has a management path that could be misused. Build the list from the asset inventory and vendor documentation, and rank by consequence.
| Device class | Function lost while held in update mode | Consequence ranking |
|---|---|---|
| Protection relays and IEDs | Fault detection and tripping | Highest: equipment damage and safety risk if a fault occurs |
| Safety controllers | Safety instrumented functions | Highest: see the Safety Instrumented Systems Security Guide |
| PLCs and RTUs | Control and telemetry | High: loss of control or view |
| Communication modules and gateways | Data path between devices and supervisory systems | Medium to high: loss of view over many devices |
| Network devices in OT | Switching and routing | Medium: loss of communications |
For each device record how firmware is loaded (vendor tool, file transfer protocol, web interface or local port only), which hosts are meant to do it, whether the device supports authentication or signed firmware for that function, and whether a physical switch or local action is needed. Devices where update needs local presence carry far less T0800 risk. See the OT Asset Visibility Guide.
Prevention: closing the management path
ATT&CK lists eight mitigations for T0800. The table shows what each means in practice.
| Mitigation | ATT&CK guidance in brief | OT implementation |
|---|---|---|
| M0807 Network Allowlists | Devices accept connections only from master stations or known engineering workstations | Host or switch-level allowlists on relay and controller networks |
| M0930 Network Segmentation | Restrict access to critical functions to predetermined management systems | Put device management in its own zone, reached only from engineering workstations |
| M0937 Filter Network Traffic | Filter protocols and payloads associated with firmware activation or update | Block firmware transfer and management protocols at conduits except during approved work |
| M0804 Human User Authentication | Remote firmware management requires authentication, with account, password and user management policies | Turn on device authentication for management functions; remove defaults |
| M0813 Software Process and Device Authentication | Authenticate connections from software and devices to protected management functions | Use authenticated engineering sessions where the device supports them |
| M0802 Communication Authenticity | Device management protocols authenticate all messages | Prefer authenticated or secure protocol variants on new deployments |
| M0800 Authorization Enforcement; M0801 Access Management | Only authorised individuals may change configuration or firmware; enforce authorisation where devices cannot | Access broker in front of devices that lack strong authentication |
Phased rollout
- Inventory and rank: list every device with network firmware management, starting with protection and safety devices.
- Restrict reachability: allow management traffic only from named engineering workstations. Put new rules in logging mode first and review the hits with protection and controls engineers, because some legitimate polling or diagnostics may share ports with management functions. Keep the previous rule set ready to restore.
- Turn on device protections: enable authentication for management and any signed or secure update features the vendor provides, after testing on a spare or test device. CERT Polska's finding that the secure update feature was disabled on every affected RTU shows why this step matters.
- Apply vendor updates: where an advisory covers a management-function flaw, schedule the update through your OT patch process. See the OT Patch Management Guide and the ICS Advisory Triage and OT Vulnerability Management Guide.
- Control the process: require a change ticket and a maintenance window for any firmware work, so detection has something to compare with.
Small sites can rely on segmentation and a single engineering workstation; large utilities with many substations should add central access brokering and the full analytic set.
Detection: ATT&CK's analytics with the OT fidelity gate
ATT&CK v20 attaches the detection strategy Detection of Activate Firmware Update Mode to T0800. Each analytic uses the same gate: alert only when the action is not attributable to an authorised operator or engineering source for that target and function, and is outside an approved change or maintenance window or lacks matching change-control context; where telemetry allows, require a corroborating device, configuration or process-state effect. Suppress activity that fully matches approved maintenance, commissioning, failover, recovery or tested control procedures.
| Platform | What the analytic identifies |
|---|---|
| Embedded | An ICS protocol message sequence placing a field device into firmware update mode from a source not on the approved engineering workstation list, followed by the device's alarm telemetry going silent within a short grace period without acknowledgement |
| Network devices | File transfer traffic such as TFTP, or vendor-specific traffic, starting update mode on ICS device addresses from sources not on the approved list |
| Windows | A vendor firmware update tool activating update mode on a field device outside a maintenance window or by an account not in the firmware management role |
| Linux | A firmware update tool on an ICS Linux engineering host starting update mode outside a maintenance window, by a user ID not among the approved firmware managers |
- Watch for silence: loss of heartbeat, status or alarm reporting from a protection device is itself an event. Route device communication loss alarms to both the control room and the SOC.
- Log engineering tool use: record who ran vendor firmware tools, on which host and against which device. See the Engineering Workstation Security Guide.
- Monitor the protocols: OT network monitoring that decodes the relevant vendor and file transfer protocols can see mode changes that host logs miss. See the OT Network Security Monitoring Guide.
Safety-aware response
- Treat it as loss of protection: protection or controls engineers decide immediately whether the protected equipment must be taken out of service, switched to backup protection or watched locally until the device is confirmed working.
- Stop further access: block the source at the conduit and disable the account used, without touching other protective devices on the same network.
- Restore the device under procedure: recovery may need a manual restart, as ESET described for SIPROTEC, done by qualified staff under the site's switching and safety rules.
- Verify firmware and settings: after restart compare firmware version and settings with the recorded baseline, and reload settings from offline copies if needed. See the OT Backup, Recovery and Golden Image Guide.
- Check the rest of the fleet: Industroyer targeted devices in bulk, so check every device of the same type and every device reachable from the same source.
- Preserve evidence: keep sensor captures, engineering workstation logs and device event records. See the OT Incident Response Guide.
Metrics that show it is working
- Management reachability: share of protection and safety devices whose firmware management is reachable only from approved engineering workstations. Target 100%.
- Device protections enabled: share of devices with management authentication and any available secure update feature turned on.
- Unticketed firmware activity: firmware management sessions without a matching change record. Target zero.
- Silence detection time: time from a protection device going quiet to an alarm reaching the control room and SOC.
Framework mapping
| Control area | NIST SP 800-53 Rev 5 | NIST CSF 2.0 | ATT&CK for ICS mitigation |
|---|---|---|---|
| Restrict management paths | SC-7 Boundary Protection | PR.IR-01 | M0930, M0807, M0937 |
| Authenticate management | IA-2 Identification and Authentication (Organizational Users) | PR.AA-03 | M0804, M0813, M0802 |
| Authorise firmware changes | AC-3 Access Enforcement; CM-3 Configuration Change Control | PR.AA-05; PR.PS-01 | M0800, M0801 |
| Firmware integrity | SI-7 Software, Firmware, and Information Integrity | PR.PS-01 | Not listed for T0800 |
| Detection | SI-4 System Monitoring | DE.CM-09 | Detection of Activate Firmware Update Mode |
| Response | IR-4 Incident Handling | RS.MI-01 | Not applicable |
NIST SP 800-82 Rev. 3 (final, September 2023) is the OT tailoring reference; see the NIST SP 800-82 OT Security Guide and, for device security capabilities, the IEC 62443-3-3 and 4-2 Security Levels Guide.
Common failure patterns
- Flat substation or process networks: any host on the network can reach every relay's management function.
- Device security features left off: authentication and secure update features exist but were never enabled at commissioning.
- Communication loss treated as a nuisance: a silent relay is logged as a telecom fault rather than investigated.
- No settings baseline: without recorded firmware versions and settings, engineers cannot confirm a restored device is correct.
- Firmware work without tickets: if update activity is never tied to change records, the detection gate cannot tell attack from maintenance.
Practitioner checklist
- List every device with network firmware management, ranking protection and safety devices first.
- Allow firmware management only from named engineering workstations, enforced at the conduit and on the device where possible.
- Enable management authentication and secure update features after testing on a spare device.
- Remove default accounts on relays, RTUs and controllers.
- Require a change ticket and maintenance window for all firmware work.
- Alarm on loss of communication from protection devices to both control room and SOC.
- Deploy the ATT&CK T0800 analytics with an approved engineering workstation list.
- Keep offline records of firmware versions and settings for every protective device.
- Agree with protection engineers in advance what happens to protected equipment if a relay is silenced.
Standards and references
- MITRE ATT&CK for ICS: Activate Firmware Update Mode (T0800)
- NIST: SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security
- ESET: Win32/Industroyer, A New Threat for Industrial Control Systems
- ESET: Industroyer, Biggest Threat to Industrial Control Systems Since Stuxnet
- CERT Polska: Energy Sector Incident Report 2025
- CISA, DOE, NSA and FBI: AA22-103A, APT Cyber Tools Targeting ICS/SCADA Devices
Related NHI Mgmt Group resources: MITRE ATT&CK for ICS Guide · Firmware and Boot Security Guide · Energy Sector Identity and OT Access Guide · OT Security Guide