DET0790: Detection of Module Firmware
DET0790 is a detection strategy placeholder for identifying changes to module firmware in ICS environments. The business issue is that modular control-syst...
Analyst context for executives and security teams
DET0790 is a detection strategy placeholder for identifying changes to module firmware in ICS environments. The business issue is that modular control-system components can carry their own firmware separate from the main device, so unauthorized or vulnerable firmware can create risk that is not visible through normal host, network, or main-controller monitoring alone.
Executive priority
Treat this as a control-assurance question for cyber-physical resilience: do asset owners know which modular components exist, what firmware should be on them, and how changes are approved and evidenced? Because the ATT&CK object provides no official detection detail, leaders should prioritize inventory, firmware governance, change-control evidence, and incident response readiness before assuming SOC coverage exists.
Technical view
SOC, OT, and IR teams should validate whether they can detect or investigate firmware state changes for modular hardware related to ICS equipment. Since ATT&CK does not specify platforms, tactics, or detection logic for DET0790, coverage should be proven locally through approved firmware baselines, maintenance records, device/module inventories, engineering workstation activity, vendor tooling logs where available, and network or management-session evidence associated with firmware maintenance. Detection should focus on deviations from expected firmware versions or unexpected firmware update activity rather than generic alerting claims.
Likely telemetry
- Module and control-system asset inventory with firmware version fields
- Approved firmware baselines and maintenance/change-control records
- Engineering workstation and maintenance tool logs, where available
- Device or module management logs, where available
- Network records for management or firmware update sessions, where collected
Detection direction
- Confirm which modular hardware devices exist and whether their firmware can be enumerated independently from the main control-system equipment.
- Compare observed module firmware versions against approved baselines and maintenance windows.
- Tune detections around unauthorized change, unexpected version drift, or firmware activity outside documented work orders.
- Account for false positives from legitimate vendor maintenance, commissioning, replacement parts, and scheduled firmware updates.
- Identify blind spots where modules lack integrity checking, logging, remote query support, or centralized collection.
Mitigation priorities
- Establish and maintain an inventory of modular ICS hardware and expected firmware versions.
- Require documented approval and evidence capture for firmware changes on modules, not only main controllers or systems.
- Restrict and monitor access to engineering or maintenance functions used to update firmware.
- Retain vendor-supported firmware validation artifacts for audit, incident response, and recovery decisions.
- Include module firmware verification in IR playbooks, spare-part handling, and post-maintenance acceptance checks.
Analyst notes and limits
The supplied ATT&CK object is a detection strategy for Module Firmware and has no official description or detection text. The relationship to T1693.002 is the main source of decision value: modular ICS components may have separate firmware and may not provide the same integrity checking as the primary control-system equipment.
Platforms, tactics, official detection analytics, and data sources are not specified in the supplied fields. Any implementation must be validated against the local ICS asset base, vendor capabilities, maintenance processes, and available telemetry. This summary does not assert active exploitation, attribution, or guaranteed detection coverage.
Detection of Module 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.002 | Module Firmware Sub-technique | This object detects Module 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 | 3759af85795c… |
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 DET0790Open 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.