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.
Analyst 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.
Analyst 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.
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 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. CitationTCG Trusted Platform Module Move system's root of trust to hardware to prevent tampering with the SPI flash memory.CitationESET LoJax Sept 2018 Technologies such as Intel Boot Guard can assist with this. CitationIntel Hardware-based Security Technologies |
| Enterprise | T1542.003 | Bootkit Sub-technique | Use Trusted Platform Module technology and a secure or trusted boot process to prevent system integrity from being compromised.CitationTCG Trusted Platform ModuleCitationTechNet Secure Boot Process |
| Enterprise | T1601.001 | Patch System Image Sub-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. CitationCisco IOS Software Integrity Assurance - Secure Boot |
| Enterprise | T1195.003 | Compromise Hardware Supply Chain Sub-technique | Use Trusted Platform Module technology and a secure or trusted boot process to prevent system integrity from being compromised. Check the integrity of the existing BIOS or EFI to determine if it is vulnerable to modification. CitationTCG Trusted Platform Module CitationTechNet Secure Boot Process |
| Enterprise | T1542.004 | ROMMONkit Sub-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. CitationCisco IOS Software Integrity Assurance - Secure Boot |
| Enterprise | T1505 | Server Software Component | Enabling secure boot allows validation of software and drivers during initial system boot. |
| Enterprise | T1553.006 | Code Signing Policy Modification Sub-technique | Use of Secure Boot may prevent some implementations of modification to code signing policies.CitationMicrosoft TESTSIGNING Feb 2021 |
| 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. CitationCisco IOS Software Integrity Assurance - Secure Boot |
| Enterprise | T1505.006 | vSphere Installation Bundles Sub-technique | Enabling secure boot allows ESXi to validate software and drivers during initial system boot.CitationGoogle Cloud Threat Intelligence ESXi Hardening 2023 |
| Enterprise | T1601.002 | Downgrade System Image Sub-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. CitationCisco IOS Software Integrity Assurance - Secure Boot |
| Enterprise | T1542 | Pre-OS Boot | Use Trusted Platform Module technology and a secure or trusted boot process to prevent system integrity from being compromised. Check the integrity of the existing BIOS or EFI to determine if it is vulnerable to modification. CitationTCG Trusted Platform Module CitationTechNet Secure Boot Process |
| 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 Boot Sub-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. CitationCisco IOS Software Integrity Assurance - Secure Boot |
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]
mitre-attack M1046Open 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.