Live Active security incident? Get immediate response
MITRE ATT&CK® Technique

T0800: Activate Firmware Update Mode

Adversaries may activate firmware update mode on devices to prevent expected response functions from engaging in reaction to an emergency or process malfunction. For example, devices such as protection relays may have an operation mode designed for firmware installation. This mode may halt process monitoring and related functions to allow new firmware to be loaded. A device left in update mode may be placed in an inactive holding state if no firmware is provided to it. By entering and leaving a device in this mode, the adversary may deny its usual functionalities.

ICST0800TechniqueObject v1.0 Modified
Discuss defensive coverage Back to ATT&CK
Glexia's Take

Analyst context for executives and security teams

Analyst confidence High

Activate Firmware Update Mode matters because an ICS device placed into an update or installation state may stop doing the monitoring, protection, or control work the operation expects from it. For executives and plant leaders, the key issue is not “firmware” itself; it is whether critical field devices, protection devices, controllers, gateways, or HMIs can be put into a non-operational holding state without authorized maintenance intent and without rapid visibility.

Executive priority

Treat this as an operational resilience and safety-function assurance concern. The business question is whether firmware-update capability is governed like a high-risk change: authorized users only, authenticated communications, segmented access paths, and evidence that SOC/OT teams can recognize unexpected device mode changes. Priority should be highest where targeted assets support protection, safety, control, telemetry aggregation, or operator visibility, including PLCs, RTUs, IEDs, safety controllers, DCS controllers, PACs, Field I/O, Data Gateways, and HMIs.

Technical view

ATT&CK provides no official detection text for T0800, but it links a detection strategy, DET0802: Detection of Activate Firmware Update Mode. SOC, OT, and IR teams should validate whether they can observe devices entering firmware update, maintenance, inactive, or equivalent vendor-defined states, and correlate those events with approved maintenance windows and authenticated administrative activity. Because the technique has no ATT&CK platform value specified, coverage should be mapped by asset class and device family rather than assumed from generic endpoint telemetry.

Likely telemetry

  • Device mode/state changes from controllers, relays, gateways, HMIs, and other ICS assets
  • Engineering workstation or HMI activity associated with maintenance or firmware operations
  • Authentication and authorization logs for users or systems permitted to issue device commands
  • Network traffic to targeted ICS assets, especially management or automation-protocol messages where available
  • Change-management or maintenance-window records used to validate legitimate update activity

Detection direction

  • Build detections around unexpected firmware-update or maintenance-mode transitions, especially outside approved maintenance windows.
  • Correlate device state changes with authenticated user identity, source system, and authorized change records to reduce false positives from legitimate firmware work.
  • Prioritize assets named in ATT&CK relationships: HMIs, PLCs, RTUs, IEDs, Data Gateways, Safety Controllers, Field I/O, DCS Controllers, and PACs.
  • Validate visibility at the protocol and device-management layer; generic IT endpoint logging may not show embedded controller mode changes.
  • Use the Industroyer software relationship as historical context that this behavior is represented in ATT&CK threat knowledge, not as evidence of current activity in any local environment.

Mitigation priorities

  • Start with Authorization Enforcement so only approved authenticated users can read, manipulate, or execute device functions tied to firmware mode changes.
  • Use Access Management controls or gateways where field devices cannot enforce sufficient identification and authorization on their own.
  • Require Human User Authentication and, where appropriate, Software Process and Device Authentication before accepting device commands.
  • Use Communication Authenticity to reduce risk from spoofed or unauthorized messages over untrusted networks.
  • Apply Network Segmentation and Network Allowlists to restrict which systems can reach management or automation interfaces.
Analyst notes and limits

The supplied ATT&CK object is ICS-focused and describes denial of usual device functionality by leaving a device in firmware update mode. Relationship context materially expands the defensive view: many ICS asset classes are targets, DET0802 is the associated detection strategy, and multiple access-control, authentication, segmentation, allowlisting, and traffic-filtering mitigations apply.

Official detection content is not provided, tactics are not specified, and the technique itself lists no platforms. Local device models, vendor event semantics, maintenance procedures, network architecture, and available OT telemetry are required to determine actual exposure and detection coverage.

Official MITRE ATT&CK definition

Activate Firmware Update Mode

Adversaries may activate firmware update mode on devices to prevent expected response functions from engaging in reaction to an emergency or process malfunction. For example, devices such as protection relays may have an operation mode designed for firmware installation. This mode may halt process monitoring and related functions to allow new firmware to be loaded. A device left in update mode may be placed in an inactive holding state if no firmware is provided to it. By entering and leaving a device in this mode, the adversary may deny its usual functionalities.

View the same entry on attack.mitre.org (MITRE-hosted reference; in-page links above use the Glexia ATT&CK library.)

Glexia analysis

How security teams should use this page

Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.

Associated objects

Groups, software, and campaigns

Malware ICS

S0604: Industroyer

Industroyer is a sophisticated malware framework designed to cause an impact to the working processes of Industrial Control Systems (ICS), specifically components used in electrical substations.[1] Industroyer was used in the attacks on the Ukrainian power grid in December 2016.[2] This is the first publicly known malware specifically designed to target and impact operations in the electric grid.[3]

Windows
Relationship explorer

All related ATT&CK context

targets · ICS Asset A0002: Human-Machine Interface (HMI) ICS mitigates · Mitigation M0807: Network Allowlists ICS targets · ICS Asset A0009: Data Gateway ICS mitigates · Mitigation M0804: Human User Authentication ICS mitigates · Mitigation M0813: Software Process and Device Authentication ICS uses · Malware S0604: Industroyer ICS targets · ICS Asset A0018: Programmable Automation Controller (PAC) ICS targets · ICS Asset A0017: Distributed Control System (DCS) Controller ICS mitigates · Mitigation M0802: Communication Authenticity ICS mitigates · Mitigation M0801: Access Management ICS targets · ICS Asset A0010: Safety Controller ICS targets · ICS Asset A0004: Remote Terminal Unit (RTU) ICS targets · ICS Asset A0005: Intelligent Electronic Device (IED) ICS detects · Detection Strategy DET0802: Detection of Activate Firmware Update Mode ICS targets · ICS Asset A0013: Field I/O ICS mitigates · Mitigation M0937: Filter Network Traffic ICS mitigates · Mitigation M0930: Network Segmentation ICS targets · ICS Asset A0003: Programmable Logic Controller (PLC) ICS mitigates · Mitigation M0800: Authorization Enforcement ICS
Mitigations

Mitigation direction

Mitigation ICS

M0807: Network Allowlists

Network allowlists can be implemented through either host-based files or system hosts files to specify what connections (e.g., IP address, MAC address, port, protocol) can be made from a device. Allowlist techniques that operate at the application layer (e.g., DNP3, Modbus, HTTP) are addressed in Filter Network Traffic mitigation.

Mitigation ICS

M0804: Human User Authentication

Require user authentication before allowing access to data or accepting commands to a device. While strong multi-factor authentication is preferable, it is not always feasible within ICS environments. Performing strong user authentication also requires additional security controls and processes which are often the target of related adversarial techniques (e.g., Valid Accounts, Default Credentials). Therefore, associated ATT&CK mitigations should be considered in addition to this, including Multi-factor Authentication, Account Use Policies, Password Policies, User Account Management, Privileged Account Management, and User Account Control.

Mitigation ICS

M0813: Software Process and Device Authentication

Require the authentication of devices and software processes where appropriate. Devices that connect remotely to other systems should require strong authentication to prevent spoofing of communications. Furthermore, software processes should also require authentication when accessing APIs.

Mitigation ICS

M0802: Communication Authenticity

When communicating over an untrusted network, utilize secure network protocols that both authenticate the message sender and can verify its integrity. This can be done either through message authentication codes (MACs) or digital signatures, to detect spoofed network messages and unauthorized connections.

Mitigation ICS

M0801: Access Management

Access Management technologies can be used to enforce authorization polices and decisions, especially when existing field devices do not provide sufficient capabilities to support user identification and authentication. [1] These technologies typically utilize an in-line network device or gateway system to prevent access to unauthenticated users, while also integrating with an authentication service to first verify user credentials. [2]

Mitigation ICS

M0937: Filter Network Traffic

Use network appliances to filter ingress or egress traffic and perform protocol-based filtering. Configure software on endpoints to filter network traffic. Perform inline allow/denylisting of network messages based on the application layer (OSI Layer 7) protocol, especially for automation protocols. Application allowlists are beneficial when there are well-defined communication sequences, types, rates, or patterns needed during expected system operations. Application denylists may be needed if all acceptable communication sequences cannot be defined, but instead a set of known malicious uses can be denied (e.g., excessive communication attempts, shutdown messages, invalid commands). Devices performing these functions are often referred to as deep-packet inspection (DPI) firewalls, context-aware firewalls, or firewalls blocking specific automation/SCADA protocol aware firewalls. [1]

Mitigation ICS

M0930: Network Segmentation

Architect sections of the network to isolate critical systems, functions, or resources. Use physical and logical segmentation to prevent access to potentially sensitive systems and information. Use a DMZ to contain any internet-facing services that should not be exposed from the internal network. Restrict network access to only required systems and services. In addition, prevent systems from other networks or business functions (e.g., enterprise) from accessing critical process control systems. For example, in IEC 62443, systems within the same secure level should be grouped into a zone, and access to that zone is restricted by a conduit, or mechanism to restrict data flows between zones by segmenting the network. [1] [2]

Mitigation ICS

M0800: Authorization Enforcement

The device or system should restrict read, manipulate, or execute privileges to only authenticated users who require access based on approved security policies. Role-based Access Control (RBAC) schemes can help reduce the overhead of assigning permissions to the large number of devices within an ICS. For example, IEC 62351 provides examples of roles used to support common system operations within the electric power sector [1], while IEEE 1686 defines standard permissions for users of IEDs. [2]

Change history

Object version and sync metadata

The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .

ATT&CK release
19.1
Object version
1.0
Created
Modified
Raw hash
199aa57bd097463f...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 1.0 Current bundle 199aa57bd097…
Raw source

Mirrored ATT&CK source object

The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.

Open mirrored raw JSON Open MITRE-hosted copy
Source references

External references and citations

MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.

  1. [1]
    mitre-attack T0800
    Open source URL
Source and licensing

Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.

Official MITRE ATT&CK site Official STIX data repository MITRE ATT&CK terms of use