T1542.002: Component Firmware
Adversaries may modify component firmware to persist on systems. Some adversaries may employ sophisticated means to compromise computer components and install malicious firmware that will execute adversary code outside of the operating system and main system firmware or BIOS. This technique may be similar to System Firmware but conducted upon other system components/devices that may not have the same capability or level of integrity checking.
Malicious component firmware could provide both a persistent level of access to systems despite potential typical failures to maintain access and hard disk re-images, as well as a way to evade host software-based defenses and integrity checks.
Analyst context for executives and security teams
Component Firmware matters because persistence can live below the operating system, outside many normal endpoint controls and survive actions such as hard-drive reimaging. For leaders, the key issue is not day-to-day malware volume; it is whether the organization can prove firmware hygiene, integrity, and recovery for critical Windows, Linux, and macOS systems when host-based evidence is incomplete.
Executive priority
Treat this as a high-assurance resilience and incident-response readiness question. Ask whether critical assets have an owner for firmware updates, whether firmware changes are tracked as compliance evidence, and whether IR playbooks include scenarios where rebuilding the OS may not remove persistence. Budget priority should favor firmware patch governance, asset/component visibility, and validated detection strategy coverage where systems are operationally important or difficult to replace.
Technical view
This is a sub-technique of Pre-OS Boot with stealth and persistence tactics. SOC and IR teams should validate visibility below the OS boundary: component firmware versions, firmware update activity, boot/integrity evidence, and deviations from approved component baselines. ATT&CK does not provide native detection text for this object, but relationship context identifies DET0323, Detection Strategy for T1542.002 Pre-OS Boot: Component Firmware, as detecting it. Teams should map that strategy to local telemetry and confirm coverage across Windows, Linux, and macOS endpoints rather than assuming EDR alone is sufficient.
Likely telemetry
- Hardware and component asset inventory, including firmware versions where available
- Firmware update, driver update, and vendor management logs
- Boot integrity, secure boot, measured boot, or attestation evidence where implemented
- Endpoint security alerts showing persistence that survives OS remediation or reimaging
- Change management records for approved firmware maintenance
Detection direction
- Validate DET0323-style coverage against actual telemetry sources; the ATT&CK object itself has no official detection text.
- Baseline approved component firmware versions for critical systems and alert on unexpected changes or downgrade patterns where telemetry supports it.
- Correlate firmware changes with maintenance windows, vendor updates, and change tickets to reduce false positives.
- Do not rely only on operating-system or file-system monitoring; this technique is explicitly outside normal OS and main firmware/BIOS visibility.
- During incidents involving recurring access after rebuild or disk reimage, include component firmware persistence in the hypothesis set.
Mitigation priorities
- Prioritize M1051 Update Software for firmware as well as operating systems, applications, and drivers.
- Maintain vendor-supported firmware update processes for critical Windows, Linux, and macOS systems.
- Tie firmware updates to asset inventory and change management so compliance and IR teams can distinguish authorized maintenance from suspicious modification.
- For high-value systems, validate integrity or attestation capabilities and document recovery procedures that include hardware/component replacement if needed.
- Ensure incident response plans account for persistence that may survive normal OS rebuilds.
Analyst notes and limits
Relationship context includes a revoked predecessor technique T1109, a parent relationship to T1542 Pre-OS Boot, a detection-strategy relationship to DET0323, mitigation M1051 Update Software, and use relationships to Equation and Cyclops Blink. These relationships support treating the behavior as sophisticated, stealthy persistence, but they do not by themselves prove current exploitation in any environment.
ATT&CK provides no official detection text for this object, and the supplied fields do not identify specific components, vendors, events, or tools. Local asset scope, firmware management capabilities, and available integrity telemetry determine practical coverage.
Component Firmware
Adversaries may modify component firmware to persist on systems. Some adversaries may employ sophisticated means to compromise computer components and install malicious firmware that will execute adversary code outside of the operating system and main system firmware or BIOS. This technique may be similar to System Firmware but conducted upon other system components/devices that may not have the same capability or level of integrity checking.
Malicious component firmware could provide both a persistent level of access to systems despite potential typical failures to maintain access and hard disk re-images, as well as a way to evade host software-based defenses and integrity checks.
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 |
|---|---|---|---|
| Enterprise | T1109 | Component Firmware | Component Firmware revoked by this object. |
| Enterprise | T1542 | Pre-OS Boot | This object subtechnique of Pre-OS Boot. |
Groups, software, and campaigns
G0020: Equation
S0687: Cyclops Blink
Cyclops Blink is a modular malware that has been used in widespread campaigns by Sandworm Team since at least 2019 to target Small/Home Office (SOHO) network devices, including WatchGuard and Asus. Cyclops Blink is assessed to be a replacement for VPNFilter, a similar platform targeting network devices.[1][2][3]
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 | 2.0 | Current bundle | a5783bdf437a… |
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 T1542.002Open 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.