DET0731: Detection of System Firmware
DET0731 is an ICS ATT&CK detection strategy for activity involving system firmware, specifically related to the System Firmware technique T1693.001. Its pr...
Analyst context for executives and security teams
DET0731 is an ICS ATT&CK detection strategy for activity involving system firmware, specifically related to the System Firmware technique T1693.001. Its practical value is that firmware update paths can affect the trustworthiness and recoverability of industrial assets: if firmware changes are not visible, approved, and auditable, security and operations teams may struggle to distinguish legitimate maintenance from potentially risky or unauthorized change.
Executive priority
Treat this as a governance and resilience question, not only a SOC rule. Leaders should ask whether firmware update activity on industrial assets is inventoried, authorized, logged, and reviewable. The business priority is maintaining operational continuity and audit evidence around changes to device-level software, especially where firmware updates may be performed by users, vendors, software packages, or over the network.
Technical view
ATT&CK provides no official detection text, platforms, or tactics for DET0731, so teams should build validation around the related technique context: system firmware updates on ICS assets. SOC, IR, and OT teams should confirm whether they can identify firmware version changes, update package execution or transfer, vendor maintenance activity, and network-based update attempts where applicable. Detection engineering should be coordinated with asset owners because legitimate firmware maintenance may look unusual without change-window and vendor-context enrichment.
Likely telemetry
- ICS asset inventory and firmware version records
- Change management tickets and approved maintenance windows
- Device or engineering workstation logs related to firmware update tools or packages
- Network logs showing firmware package transfer or remote update activity where such updates are supported
- Vendor maintenance records and remote support activity logs
Detection direction
- Validate that firmware version changes can be compared against approved maintenance records.
- Tune alerts with asset criticality, scheduled maintenance windows, and vendor activity to reduce false positives.
- Look for gaps where older devices require special reprogramming equipment and may not emit useful logs.
- Confirm whether network-based firmware updates are visible in available OT network monitoring or logging.
- Use the relationship to T1693.001 as the primary analytic anchor because DET0731 has no official detection procedure text.
Mitigation priorities
- Maintain an authoritative inventory of ICS assets and expected firmware versions.
- Require documented approval for firmware updates and retain evidence for audit and incident review.
- Restrict firmware update capability to authorized personnel, tools, and maintenance paths where supported by the environment.
- Preserve known-good firmware/version baselines to support recovery and investigation.
- Coordinate SOC monitoring with OT change management so legitimate vendor or user-delegated updates are not treated as unexplained events.
Analyst notes and limits
This detection strategy is newly represented as an ATT&CK detection object, but the supplied fields are sparse. The most useful context comes from its relationship to T1693.001 System Firmware and the related description that firmware updates may be user-delegated, package-based, vendor-enabled, or possible over the network.
No official description, detection text, platforms, tactics, aliases, or labels were supplied for DET0731. Any concrete detection logic, vendor control mapping, or platform-specific assumption requires local asset data and additional engineering validation.
Detection of System Firmware
No official description is available in the imported ATT&CK source object.
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.
Techniques used
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| ICS | T1693.001 | System Firmware Sub-technique | This object detects System Firmware. |
All related ATT&CK context
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 .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.0 | Current bundle | f92fb9f3b182… |
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.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
mitre-attack DET0731Open source URL
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.