T1693: Modify Firmware
Firmware is low-level software embedded in hardware that enables systems and devices to function properly and is commonly found in ICS environments. Adversaries may modify firmware on a system or device by installing malicious or vulnerable versions that enable them to achieve objectives such as Persistence, Impair Process Control, and Inhibit Response Function.
Adversaries may modify system and device firmware by using the built-in firmware update functionality which may support local or remote installation. The malicious or vulnerable firmware may be delivered via Replication Through Removable Media, Supply Chain Compromise, or Remote Services. Once installed, the malicious or vulnerable firmware could be used to provide Rootkit and Hooking functionality, Exploitation for Privilege Escalation, or Denial of Service.[1]
Analyst context for executives and security teams
Modify Firmware is material because firmware sits below normal operating software on ICS devices. If firmware on controllers or modules is replaced with malicious or vulnerable versions, defenders may be dealing with persistence, impaired process control, inhibited response functions, privilege escalation, rootkit or hooking behavior, or denial of service. For leaders, the key issue is whether critical control assets have trusted firmware provenance, controlled update paths, and evidence that firmware has not changed outside authorized maintenance.
Executive priority
Prioritize this where PLCs, safety controllers, DCS controllers, and PACs support safety-critical or continuity-critical operations. The business decision is not only “can we patch firmware,” but “can we prove firmware integrity, restrict who can update it, and detect unauthorized change.” This affects operational resilience, incident response confidence, maintenance governance, supplier assurance, and audit evidence for high-risk ICS environments.
Technical view
ATT&CK does not provide official detection text for T1693, but it does identify a related detection strategy, DET0904 Detection of Firmware Modification. SOC, engineering, and IR teams should validate whether they maintain known-good firmware baselines for targeted embedded ICS assets, can observe local or remote firmware update activity, and can compare device firmware, software, programs, and configurations against trusted states. Pay particular attention to firmware delivered through removable media, supply chain paths, or remote services, and distinguish authorized vendor maintenance from unexpected update behavior.
Likely telemetry
- Firmware version and inventory records for PLCs, safety controllers, DCS controllers, PACs, and relevant modules
- Cryptographic hash or digital signature results from firmware, software, program, and configuration integrity checks
- Device reboot, program download, program restart, and firmware update event records where available
- Authentication and authorization records for users, devices, gateways, and software processes that can access update functions
- Network connection and filtering logs for remote services and automation protocol traffic reaching control devices
Detection direction
- Validate the DET0904 detection strategy against local device types and engineering workflows; the supplied ATT&CK object does not include detection logic.
- Baseline known-valid firmware and module firmware states, then alert or investigate when changes occur outside approved maintenance, reboot, download, or restart events.
- Tune for legitimate firmware maintenance and vendor updates to reduce false positives; unauthorized timing, source, user, device, or package provenance should drive escalation.
- Check blind spots around modular hardware, older devices requiring special reprogramming equipment, and devices with limited native authentication or integrity checking.
- Correlate firmware changes with remote services access, removable media activity, supply chain update handling, and subsequent rootkit, hooking, privilege escalation, or denial-of-service symptoms when observable.
Mitigation priorities
- Start with governance and audit: maintain firmware inventories, trusted baselines, and periodic integrity checks, especially after reboots, program downloads, and program restarts.
- Enforce code signing and boot integrity where supported so untrusted firmware or loading mechanisms are not accepted.
- Restrict update capability with access management, human user authentication, and software process or device authentication, especially where field devices lack strong native controls.
- Reduce reachable update paths with network segmentation, network allowlists, and protocol-aware traffic filtering for control networks.
- Use communication authenticity and encryption for network communications where applicable, and protect sensitive information at rest when it supports firmware or update trust.
Analyst notes and limits
This technique is an ICS ATT&CK technique with sub-techniques for System Firmware and Module Firmware. It targets embedded ICS assets including PLCs, safety controllers, DCS controllers, and PACs. The supplied relationships provide strong mitigation context but limited detection detail, so local engineering data, vendor documentation, and approved maintenance processes are required to operationalize coverage.
Official ATT&CK detection text, tactics, and platforms are not specified for this object. The relationship to DET0904 names a detection strategy but does not provide its analytic content here. This take does not assert active exploitation, attribution, or guaranteed detectability.
Modify Firmware
Firmware is low-level software embedded in hardware that enables systems and devices to function properly and is commonly found in ICS environments. Adversaries may modify firmware on a system or device by installing malicious or vulnerable versions that enable them to achieve objectives such as Persistence, Impair Process Control, and Inhibit Response Function.
Adversaries may modify system and device firmware by using the built-in firmware update functionality which may support local or remote installation. The malicious or vulnerable firmware may be delivered via Replication Through Removable Media, Supply Chain Compromise, or Remote Services. Once installed, the malicious or vulnerable firmware could be used to provide Rootkit and Hooking functionality, Exploitation for Privilege Escalation, or Denial of Service.[1]
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.
Related techniques
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 | System Firmware subtechnique of this object. |
| ICS | T1693.002 | Module Firmware Sub-technique | Module Firmware subtechnique of this object. |
All related ATT&CK context
Mitigation direction
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 | a919c4648fce… |
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]
Basnight, Zachry, et al.
Basnight, Zachry, et al. 2013 Retrieved. 2017/10/17
Open source URL -
[2]
mitre-attack T1693Open 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.