M0946: Boot Integrity
Use secure methods to boot a system and verify the integrity of the operating system and loading mechanisms.
Analyst context for executives and security teams
Boot Integrity is an ICS mitigation focused on making sure a system starts from trusted operating system and loading components. Its business value is resilience: if firmware or boot components can be modified without integrity checks, recovery decisions, safety functions, and trust in industrial assets become harder to validate after an incident.
Executive priority
Prioritize this where industrial systems or components could be exposed to firmware modification risk. Leaders should ask which critical assets have secure boot or equivalent integrity verification, how exceptions are documented, and whether evidence supports IEC 62443-4-2 CR 3.14 and NIST SP 800-53 SI-7 expectations. This is especially relevant for incident recovery because a device that boots successfully is not necessarily trustworthy if firmware or boot integrity was not verified.
Technical view
For SOC, engineering, and IR teams, validate Boot Integrity as a control against ATT&CK ICS Modify Firmware, including System Firmware and Module Firmware. Because ATT&CK provides no detection text for this mitigation and no platform scope, coverage should be assessed asset by asset: identify which devices support secure boot or boot-time integrity validation, confirm configuration state, preserve integrity evidence, and define how responders will verify firmware and boot mechanisms before returning equipment to service.
Likely telemetry
- Asset inventory records showing firmware-capable systems and modular components
- Secure boot or boot integrity configuration evidence where available
- Firmware version, update, and validation records
- Change management records for firmware and boot-related maintenance
- Vendor or device integrity verification outputs where available
Detection direction
- Do not treat this mitigation as a SOC alert by itself; ATT&CK does not provide detection guidance for M0946.
- Validate whether monitoring can reveal unauthorized firmware or boot-related changes through change records, asset state comparison, or device integrity checks.
- Tune review processes to distinguish approved maintenance and vendor updates from unexpected firmware or boot changes.
- Pay special attention to modular hardware because related ATT&CK context notes that module firmware may have different or weaker integrity-checking capabilities.
- Document blind spots where older devices, factory-installed firmware, or special reprogramming requirements limit routine validation.
Mitigation priorities
- Inventory critical ICS assets and identify which support secure boot or other boot integrity verification.
- Enable and document secure boot or equivalent integrity mechanisms where supported.
- Integrate firmware and boot integrity checks into maintenance, change control, and incident recovery procedures.
- Require evidence of trusted firmware and boot state before restoring affected systems to operational service.
- Track exceptions for devices that lack integrity checking and prioritize compensating controls or lifecycle planning.
Analyst notes and limits
This is a mitigation object, not an adversary behavior. Its main decision value is control assurance: whether the organization can prove that critical ICS devices boot from trusted firmware and loading mechanisms, especially when defending against firmware modification techniques.
ATT&CK provides no official detection text, no specified platforms, and limited relationship context beyond mitigation of Modify Firmware, System Firmware, and Module Firmware. Local asset capabilities, vendor documentation, and engineering procedures are required to determine actual coverage.
Boot Integrity
Use secure methods to boot a system and verify the integrity of the operating system and loading mechanisms.
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 | Check the integrity of the existing BIOS or EFI to determine if it is vulnerable to modification. Use Trusted Platform Module technology.CitationN/A Move system's root of trust to hardware to prevent tampering with the SPI flash memory.CitationESET Research Whitepapers September 2018 Technologies such as Intel Boot Guard can assist with this.CitationIntel |
| ICS | T1693 | Modify Firmware | Check the integrity of the existing BIOS or EFI to determine if it is vulnerable to modification. Use Trusted Platform Module technology.CitationN/A Move system's root of trust to hardware to prevent tampering with the SPI flash memory.CitationESET Research Whitepapers September 2018 Technologies such as Intel Boot Guard can assist with this.CitationIntel |
| ICS | T1693.001 | System Firmware Sub-technique | Check the integrity of the existing BIOS or EFI to determine if it is vulnerable to modification. Use Trusted Platform Module technology.CitationN/A Move system's root of trust to hardware to prevent tampering with the SPI flash memory.CitationESET Research Whitepapers September 2018 Technologies such as Intel Boot Guard can assist with this.CitationIntel |
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.1 | Current bundle | 08126614a035… |
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 M0946Open 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.