M1046: Boot Integrity
Boot Integrity ensures that a system starts securely by verifying the integrity of its boot process, operating system, and associated components. This mitigation focuses on leveraging secure boot mechanisms, hardware-rooted trust, and runtime integrity checks to prevent tampering during the boot sequence. It is designed to thwart adversaries attempting to modify system firmware, bootloaders, or critical OS components. This mitigation can be implemented through the following measures:
Implementation of Secure Boot:
- Implementation: Enable UEFI Secure Boot on all systems and configure it to allow only signed bootloaders and operating systems. - Use Case: An adversary attempts to replace the system’s bootloader with a malicious version to gain persistence. Secure Boot prevents the untrusted bootloader from executing, halting the attack.
Utilization of TPMs:
- Implementation: Configure systems to use TPM-based attestation for boot integrity, ensuring that any modification to the firmware, bootloader, or OS is detected. - Use Case: A compromised firmware component alters the boot sequence. The TPM detects the change and triggers an alert, allowing the organization to respond before further damage.
Enable Bootloader Passwords:
- Implementation: Protect BIOS/UEFI settings with a strong password and limit physical access to devices. - Use Case: An attacker with physical access attempts to disable Secure Boot or modify the boot sequence. The password prevents unauthorized changes.
Runtime Integrity Monitoring:
- Implementation: Deploy solutions to verify the integrity of critical files and processes after boot. - Use Case: A malware infection modifies kernel modules post-boot. Runtime integrity monitoring detects the modification and prevents the malicious module from loading.
Security context for executives and security teams
Boot Integrity is a resilience control for attacks that try to survive below or before the operating system. Its business value is that it raises the cost of firmware, bootloader, system image, and critical OS tampering that can otherwise undermine recovery, hide from normal endpoint tools, or make devices unavailable.
Executive priority
Prioritize Boot Integrity for systems where loss of trust in the startup path would create major operational or incident-response consequences: servers, administrator workstations, network devices, and virtualization infrastructure where applicable. Leaders should ask whether Secure Boot, TPM-based attestation, BIOS/UEFI protection, runtime integrity monitoring, and controlled device images are actually enforced and auditable, not merely supported by hardware.
Technical view
MITRE lists no detection guidance for M1046, so validation should focus on control state and tamper evidence. Confirm that bootloaders and operating systems must be signed, TPM attestation is configured where available, BIOS/UEFI settings are password-protected and physically protected, and runtime integrity checks cover critical files, processes, kernel modules, firmware, and system images. Relationship context makes this especially relevant to supply chain compromise, hardware supply chain compromise, firmware corruption, pre-OS boot persistence, bootkits, network-device ROMMON/TFTP boot abuse, code-signing policy modification, modified or downgraded network-device system images, and ESXi VIB-based persistence.
Likely telemetry
- Secure Boot enablement and policy state
- TPM measurement and attestation results
- BIOS/UEFI configuration and change records
- Firmware, bootloader, OS image, and critical file integrity measurements
- Runtime integrity monitoring alerts for critical files, processes, and kernel modules
Detection direction
- Treat this primarily as a prevention and assurance control because ATT&CK provides no official detection text for M1046.
- Baseline approved firmware, bootloader, OS image, network-device image, and ESXi component states, then alert on drift or unauthorized downgrade.
- Tune monitoring to distinguish approved maintenance, firmware updates, image upgrades, and recovery activity from unexpected boot-path changes.
- Validate that SOC playbooks recognize pre-OS and firmware tampering as potential reasons normal endpoint telemetry may be incomplete.
- Correlate boot integrity failures with related ATT&CK behaviors such as Pre-OS Boot, Bootkit, Firmware Corruption, Code Signing Policy Modification, and Modify System Image.
Mitigation priorities
- Enable and enforce UEFI Secure Boot where supported so only trusted signed boot components execute.
- Use TPM-based attestation where available to detect changes to firmware, bootloader, or operating system measurements.
- Protect BIOS/UEFI settings with strong passwords and limit physical access to devices.
- Deploy runtime integrity monitoring for critical files, processes, and kernel modules after boot.
- For network devices and ESXi environments, maintain approved image/component inventories and validate boot or startup components against those baselines.
Additional notes and limits
This mitigation is most valuable where adversaries could gain persistence, impair defenses, or disrupt availability by altering the boot chain, firmware, system images, or startup components. The relationship set broadens the scope beyond traditional endpoints to network devices and ESXi-related persistence, but local asset criticality should drive rollout order.
The ATT&CK mitigation object has no explicit platforms, tactics, aliases, or official detection section. Platform references here come from the supplied relationships, not from the mitigation object itself. Local hardware capabilities, firmware management processes, device types, and telemetry availability are required to determine actual coverage.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Boot Integrity
Boot Integrity ensures that a system starts securely by verifying the integrity of its boot process, operating system, and associated components. This mitigation focuses on leveraging secure boot mechanisms, hardware-rooted trust, and runtime integrity checks to prevent tampering during the boot sequence. It is designed to thwart adversaries attempting to modify system firmware, bootloaders, or critical OS components. This mitigation can be implemented through the following measures:
Implementation of Secure Boot:
- Implementation: Enable UEFI Secure Boot on all systems and configure it to allow only signed bootloaders and operating systems. - Use Case: An adversary attempts to replace the system’s bootloader with a malicious version to gain persistence. Secure Boot prevents the untrusted bootloader from executing, halting the attack.
Utilization of TPMs:
- Implementation: Configure systems to use TPM-based attestation for boot integrity, ensuring that any modification to the firmware, bootloader, or OS is detected. - Use Case: A compromised firmware component alters the boot sequence. The TPM detects the change and triggers an alert, allowing the organization to respond before further damage.
Enable Bootloader Passwords:
- Implementation: Protect BIOS/UEFI settings with a strong password and limit physical access to devices. - Use Case: An attacker with physical access attempts to disable Secure Boot or modify the boot sequence. The password prevents unauthorized changes.
Runtime Integrity Monitoring:
- Implementation: Deploy solutions to verify the integrity of critical files and processes after boot. - Use Case: A malware infection modifies kernel modules post-boot. Runtime integrity monitoring detects the modification and prevents the malicious module from loading.
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 |
|---|---|---|---|
| Enterprise | T1195 | Supply Chain Compromise | Use secure methods to boot a system and verify the integrity of the operating system and loading mechanisms. |
| Enterprise | T1542.001 | System FirmwareSub-technique | |
| Enterprise | T1542.003 | BootkitSub-technique | |
| Enterprise | T1601.001 | Patch System ImageSub-technique | Some vendors of embedded network devices provide cryptographic signing to ensure the integrity of operating system images at boot time. Implement where available, following vendor guidelines. [5] |
| Enterprise | T1195.003 | Compromise Hardware Supply ChainSub-technique | |
| Enterprise | T1542.004 | ROMMONkitSub-technique | Enable secure boot features to validate the digital signature of the boot environment and system image using a special purpose hardware device. If the validation check fails, the device will fail to boot preventing loading of unauthorized software. [5] |
| Enterprise | T1505 | Server Software Component | Enabling secure boot allows validation of software and drivers during initial system boot. |
| Enterprise | T1553.006 | Code Signing Policy ModificationSub-technique | Use of Secure Boot may prevent some implementations of modification to code signing policies.[6] |
| Enterprise | T1601 | Modify System Image | Some vendors of embedded network devices provide cryptographic signing to ensure the integrity of operating system images at boot time. Implement where available, following vendor guidelines. [5] |
| Enterprise | T1505.006 | vSphere Installation BundlesSub-technique | Enabling secure boot allows ESXi to validate software and drivers during initial system boot.[7] |
| Enterprise | T1601.002 | Downgrade System ImageSub-technique | Some vendors of embedded network devices provide cryptographic signing to ensure the integrity of operating system images at boot time. Implement where available, following vendor guidelines. [5] |
| Enterprise | T1542 | Pre-OS Boot | |
| Enterprise | T1495 | Firmware Corruption | Check the integrity of the existing BIOS and device firmware to determine if it is vulnerable to modification. |
| Enterprise | T1542.005 | TFTP BootSub-technique | Enable secure boot features to validate the digital signature of the boot environment and system image using a special purpose hardware device. If the validation check fails, the device will fail to boot preventing loading of unauthorized software. [5] |
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 | 352038daac3d… |
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]TCG Trusted Platform Module
Trusted Computing Group. (2008, April 29). Trusted Platform Module (TPM) Summary. Retrieved June 8, 2016.
- [2]ESET LoJax Sept 2018
ESET. (2018, September). LOJAX First UEFI rootkit found in the wild, courtesy of the Sednit group. Retrieved July 2, 2019.
Open source URL - [3]Intel Hardware-based Security Technologies
Intel. (2013). Intel Hardware-based Security Technologies for Intelligent Retail Devices. Retrieved May 19, 2020.
Open source URL - [4]TechNet Secure Boot Process
Microsoft. (n.d.). Secure the Windows 10 boot process. Retrieved April 23, 2020.
Open source URL - [5]Cisco IOS Software Integrity Assurance - Secure Boot
Cisco. (n.d.). Cisco IOS Software Integrity Assurance - Secure Boot. Retrieved October 19, 2020.
Open source URL - [6]Microsoft TESTSIGNING Feb 2021
Microsoft. (2021, February 15). Enable Loading of Test Signed Drivers. Retrieved April 22, 2021.
Open source URL - [7]Google Cloud Threat Intelligence ESXi Hardening 2023
Alex Marvi, Greg Blaum, and Ron Craft. (2023, June 28). Detection, Containment, and Hardening Opportunities for Privileged Guest Operations, Anomalous Behavior, and VMCI Backdoors on Compromised VMware Hosts. Retrieved March 26, 2025.
Open source URL - [8]mitre-attackM1046Open source URL
- [9]mitre-attackM1046Open source URL
- [10]mitre-attackM1046Open source URL
- [11]ESET LoJax Sept 2018
ESET. (2018, September). LOJAX First UEFI rootkit found in the wild, courtesy of the Sednit group. Retrieved July 2, 2019.
Open source URL - [12]Intel Hardware-based Security Technologies
Intel. (2013). Intel Hardware-based Security Technologies for Intelligent Retail Devices. Retrieved May 19, 2020.
Open source URL - [13]TCG Trusted Platform Module
Trusted Computing Group. (2008, April 29). Trusted Platform Module (TPM) Summary. Retrieved June 8, 2016.
- [14]TCG Trusted Platform Module
Trusted Computing Group. (2008, April 29). Trusted Platform Module (TPM) Summary. Retrieved June 8, 2016.
- [15]TCG Trusted Platform Module
Trusted Computing Group. (2008, April 29). Trusted Platform Module (TPM) Summary. Retrieved June 8, 2016.
- [16]TechNet Secure Boot Process
Microsoft. (n.d.). Secure the Windows 10 boot process. Retrieved April 23, 2020.
Open source URL - [17]Cisco IOS Software Integrity Assurance - Secure Boot
Cisco. (n.d.). Cisco IOS Software Integrity Assurance - Secure Boot. Retrieved October 19, 2020.
Open source URL - [18]TCG Trusted Platform Module
Trusted Computing Group. (2008, April 29). Trusted Platform Module (TPM) Summary. Retrieved June 8, 2016.
- [19]TCG Trusted Platform Module
Trusted Computing Group. (2008, April 29). Trusted Platform Module (TPM) Summary. Retrieved June 8, 2016.
- [20]TechNet Secure Boot Process
Microsoft. (n.d.). Secure the Windows 10 boot process. Retrieved April 23, 2020.
Open source URL - [21]TechNet Secure Boot Process
Microsoft. (n.d.). Secure the Windows 10 boot process. Retrieved April 23, 2020.
Open source URL - [22]Cisco IOS Software Integrity Assurance - Secure Boot
Cisco. (n.d.). Cisco IOS Software Integrity Assurance - Secure Boot. Retrieved October 19, 2020.
Open source URL - [23]Cisco IOS Software Integrity Assurance - Secure Boot
Cisco. (n.d.). Cisco IOS Software Integrity Assurance - Secure Boot. Retrieved October 19, 2020.
Open source URL - [24]Microsoft TESTSIGNING Feb 2021
Microsoft. (2021, February 15). Enable Loading of Test Signed Drivers. Retrieved April 22, 2021.
Open source URL - [25]Cisco IOS Software Integrity Assurance - Secure Boot
Cisco. (n.d.). Cisco IOS Software Integrity Assurance - Secure Boot. Retrieved October 19, 2020.
Open source URL - [26]Cisco IOS Software Integrity Assurance - Secure Boot
Cisco. (n.d.). Cisco IOS Software Integrity Assurance - Secure Boot. Retrieved October 19, 2020.
Open source URL - [27]Google Cloud Threat Intelligence ESXi Hardening 2023
Alex Marvi, Greg Blaum, and Ron Craft. (2023, June 28). Detection, Containment, and Hardening Opportunities for Privileged Guest Operations, Anomalous Behavior, and VMCI Backdoors on Compromised VMware Hosts. Retrieved March 26, 2025.
Open source URL - [28]Cisco IOS Software Integrity Assurance - Secure Boot
Cisco. (n.d.). Cisco IOS Software Integrity Assurance - Secure Boot. Retrieved October 19, 2020.
Open source URL - [29]TCG Trusted Platform Module
Trusted Computing Group. (2008, April 29). Trusted Platform Module (TPM) Summary. Retrieved June 8, 2016.
- [30]TechNet Secure Boot Process
Microsoft. (n.d.). Secure the Windows 10 boot process. Retrieved April 23, 2020.
Open source URL - [31]Cisco IOS Software Integrity Assurance - Secure Boot
Cisco. (n.d.). Cisco IOS Software Integrity Assurance - Secure Boot. Retrieved October 19, 2020.
Open 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.