Code that runs before the operating system can hide from every agent you deploy and survive a reinstall, so the only reliable defence is to verify the boot chain itself. MITRE ATT&CK M1046 Boot Integrity is the mitigation for that problem: it covers UEFI Secure Boot, TPM-based measurement and attestation, firmware setup passwords and runtime integrity checks. This guide takes the ATT&CK point of view: which techniques ATT&CK says M1046 mitigates, which of them it genuinely stops, where it leaves gaps and which other mitigations close them, and how to prove coverage across laptops, servers, hypervisors and network devices. It is written for detection engineers, endpoint and infrastructure owners and anyone building an ATT&CK coverage map. For the mechanics of the boot chain itself, see the Firmware and Boot Security Guide; this page does not repeat it.
Key takeaways
- Fourteen technique entries, one theme. In ATT&CK v20, M1046 mitigates 14 techniques and sub-techniques, centred on T1542 Pre-OS Boot, T1601 Modify System Image and T1495 Firmware Corruption.
- Secure Boot blocks, measured boot reports. Microsoft documents that Secure Boot and Trusted Boot refuse unsigned or modified components, while Measured Boot blocks nothing and only records hashes in the TPM for a remote verifier to judge.
- SPI flash implants need a hardware root of trust. ESET corrected its own LoJax advice to say Secure Boot does not protect against that UEFI rootkit, and pointed to hardware roots of trust such as Intel Boot Guard.
- Signing keys are the weak link. Every boot check trusts a key: the 2023 MSI leak exposed firmware and Boot Guard private keys, and the 2011 Microsoft Secure Boot certificates reached their expiry dates during 2026.
- Coverage is a percentage you can measure. Device health attestation, ESXi secure boot status and network image verification give you per-fleet numbers rather than a policy statement.
What M1046 is in ATT&CK terms
ATT&CK describes Boot Integrity as ensuring that a system starts securely by verifying the integrity of its boot process, operating system and associated components, using secure boot, hardware-rooted trust and runtime integrity checks. It lists four implementation measures:
- Secure Boot: enable UEFI Secure Boot and allow only signed bootloaders and operating systems.
- TPM attestation: use TPM-based attestation so that changes to firmware, bootloader or operating system are detected.
- Firmware passwords: protect BIOS or UEFI settings with a strong password and limit physical access.
- Runtime integrity monitoring: verify critical files and processes after boot, for example to stop a modified kernel module loading.
MITRE D3FEND relates M1046 to two defensive techniques: D3-BA Bootloader Authentication and D3-TBI TPM Boot Integrity. That pairing is the whole idea in short: one control prevents untrusted code from running, the other produces evidence of what did run.
Techniques M1046 mitigates, prioritised
The table lists all 14 ATT&CK v20 entries, grouped by tactic, with ATT&CK's own description of how the mitigation helps and our view of how strong the coverage is. Priority reflects how often the technique matters to an enterprise estate and how directly boot integrity stops it.
| Tactic | Technique | How M1046 helps (per ATT&CK) | Coverage strength |
|---|---|---|---|
| Persistence, Stealth | T1542.003 Bootkit | TPM technology and a secure or trusted boot process prevent system integrity from being compromised | Strong where Secure Boot is on and the revocation list (dbx) is current |
| Persistence, Stealth | T1542.001 System Firmware | Check BIOS or EFI integrity, use the TPM, move the root of trust to hardware to prevent tampering with SPI flash | Partial: needs a hardware root of trust plus attestation, not Secure Boot alone |
| Persistence, Stealth | T1542 Pre-OS Boot | TPM and secure or trusted boot; check BIOS or EFI integrity | Depends on sub-technique |
| Persistence, Stealth | T1542.004 ROMMONkit | Secure boot features validate the signature of the boot environment and system image with a special purpose hardware device; failed validation stops the boot | Strong on network devices that support hardware-anchored secure boot |
| Persistence, Stealth | T1542.005 TFTP Boot | Same hardware-anchored signature validation of the boot environment and image | Strong where supported; pair with configuration control |
| Defense Impairment | T1601 Modify System Image | Cryptographic signing of network device operating system images, checked at boot, implemented following vendor guidelines | Strong at boot, none for in-memory changes between reboots |
| Defense Impairment | T1601.001 Patch System Image | As T1601 | As above |
| Defense Impairment | T1601.002 Downgrade System Image | As T1601 | Partial: an older image may still carry a valid signature |
| Defense Impairment | T1553.006 Code Signing Policy Modification | Secure Boot may prevent some implementations of modification to code signing policies | Partial, ATT&CK says "some" |
| Impact | T1495 Firmware Corruption | Check the integrity of existing BIOS and device firmware to determine whether it can be modified | Weak: detects exposure, does not stop a destructive write |
| Initial Access | T1195.003 Compromise Hardware Supply Chain | TPM and secure or trusted boot; check BIOS or EFI integrity | Partial: only what is measured or signed |
| Initial Access | T1195 Supply Chain Compromise | Secure methods to boot and verify the operating system and loading mechanisms | Narrow: the boot path only |
| Persistence | T1505.006 vSphere Installation Bundles | Secure boot lets ESXi validate software and drivers during boot | Strong for unsigned VIBs on hosts with Secure Boot enforced |
| Persistence | T1505 Server Software Component | Secure boot validates software and drivers during initial boot | Narrow: most server components (web shells, IIS modules) are not boot components |
Related technique guides: the T1195 Supply Chain Compromise guide, the T1505 Server Software Component guide and the T1553 Subvert Trust Controls guide.
Secure Boot, measured boot and attestation by technique
The three mechanisms are often treated as one. They answer different questions, and each technique needs a specific one.
| Mechanism | What it does | Techniques it addresses best | What it cannot do |
|---|---|---|---|
| UEFI Secure Boot (D3-BA) | Firmware verifies signatures of option ROMs, EFI applications and the OS loader against db, with dbx taking precedence for revoked items | T1542.003 bootkits that replace the boot loader, T1553.006 on Windows | Trust a signed but vulnerable loader that is not yet in dbx; protect firmware already in SPI flash |
| Trusted Boot and ELAM (Windows) | The boot loader verifies the kernel; the kernel verifies boot drivers and the Early Launch Anti-Malware driver, which can stop untrusted boot drivers loading | Kernel and boot driver tampering after the loader | Anything that runs before the boot loader |
| Measured boot and TPM attestation (D3-TBI) | Firmware records hashes of firmware, loader and boot drivers in TPM registers; a remote verifier checks a TPM-signed log | T1542.001 and T1195.003 detection, proof of state for conditional access | Block anything: it only reports, and is only as good as the verifier's policy |
| Hardware root of trust (for example Intel Boot Guard) | Verifies the first firmware code before it runs | T1542.001 SPI flash implants such as LoJax | Survive a leak of the OEM signing key |
| Network device secure boot and image signing | Hardware-anchored check of ROMMON and the system image before loading | T1542.004, T1542.005, T1601 | Detect changes made in running memory without a reboot |
| ESXi UEFI Secure Boot | Boot loader verifies the kernel with a VMware key; a VIB verifier checks every installed VIB | T1505.006 | Address abuse of valid administrator credentials on the host |
On Windows, Microsoft documents that Measured Boot does not block anything: the TPM signs the boot log with a key from the attestation server, and the server decides whether to grant full network access or a quarantine network. Microsoft Intune evaluates the same evidence through Device Health Attestation, with compliance settings "Require Secure Boot to be enabled on the device", "Require BitLocker" and "Require code integrity", all "Not configured" by default. Intune notes that devices without TPM 2.0 report as not compliant when Secure Boot is required.
On ESXi 7.0 Update 2 and later, Broadcom documents that a host with a TPM seals sensitive information with a policy based on Secure Boot PCR values, released at reboot only if the policy holds. A tampered VIB produces a purple screen listing VIBs that failed signature verification. See the VMware ESXi Hardening Guide.
Gaps, and which mitigations cover them
- Component firmware: T1542.002 Component Firmware (disk, network card and other peripheral firmware) is not mapped to M1046 in ATT&CK v20; its only listed mitigation is M1051 Update Software. See the M1051 Update Software guide.
- Who can flash firmware: T1542.001 and T1495 are also mapped to M1026 Privileged Account Management. Boot checks do not stop an administrator with a signed update tool from writing firmware. See the M1026 Privileged Account Management guide.
- Signed but vulnerable loaders: Secure Boot trusts what db trusts. Until a vulnerable loader is revoked in dbx, it is accepted. Revocation and certificate updates are an operational process, not a setting.
- Signing key compromise: the controls hold only while the keys behind them are private. Code signing policy is covered under M1045. See the M1045 Code Signing guide.
- Destructive firmware writes: for T1495, boot integrity at best tells you a platform is exposed. Recovery depends on firmware resiliency, which NIST SP 800-193 frames as protection, detection and recovery, and on spare hardware and clean images.
- Running-state tampering: boot checks run at boot. Network device images patched in memory, and hosts that are rarely rebooted, need runtime integrity checks and configuration monitoring as well.
Where identity fits: the keys and accounts behind boot trust
Every boot integrity control is a trust decision about a machine credential. The Secure Boot Platform Key, the Key Exchange Key and the db certificates are cryptographic identities; so are OEM firmware signing keys and Boot Guard keys. Microsoft lists three 2011 certificates being replaced by four 2023 certificates: Microsoft Corporation KEK CA 2011 (expiry 24 June 2026, replaced by Microsoft Corporation KEK 2K CA 2023), Microsoft UEFI CA 2011 (27 June 2026, replaced by both Microsoft UEFI CA 2023 and Microsoft Option ROM UEFI CA 2023) and Microsoft Windows Production PCA 2011 (19 October 2026, replaced by Windows UEFI CA 2023). Microsoft states that devices left on the 2011 certificates keep booting but stop receiving new early-boot protections such as boot manager updates and revocation list updates. See the Secure Boot Certificate Expiry 2026 guide.
The other identity question is who can change the platform: accounts with rights to run firmware update tools, BMC and out-of-band management accounts, the service accounts used by configuration management and PXE provisioning, and the credentials of network device image servers. Treat them as privileged non-human identities with owners, vaulted credentials and logged use. See the Bare-Metal Provisioning and PXE Boot Security Guide and the Code Signing Security Guide.
Implementation priorities
The order below is an NHI Mgmt Group recommendation.
- Inventory boot state: collect Secure Boot status, TPM version, firmware version and certificate state per device class (Windows endpoints, Linux servers, ESXi hosts, network devices). Unknown state counts as off.
- Enable Secure Boot in audit first: report compliance without blocking access, using Intune or your MDM compliance setting, and fix exceptions (legacy BIOS mode, unsigned drivers, custom kernels).
- Bring revocation up to date: apply the 2023 certificates and current dbx updates on a pilot ring, confirm boot on each hardware model, then widen. Keep firmware recovery media for each model before you start, because revocation can stop older media booting.
- Turn reporting into enforcement: make Secure Boot and code integrity a conditional access requirement for sensitive applications, and quarantine non-compliant devices rather than blocking them outright at first.
- Servers and hypervisors: enable UEFI Secure Boot on ESXi hosts, and enforce it where TPM sealing is available; enable Linux Secure Boot with shim and kernel module signing. See the Linux Secure Boot and Shim Guide.
- Network devices: use the vendor's hardware-anchored secure boot and image signing where available, verify image hashes against the vendor's published values, and remove TFTP boot paths that are not needed. See the Network Device Management Plane Hardening Guide.
- Lock firmware setup: set firmware passwords, managed centrally and rotated like any shared secret, and disable booting from external media where the use case allows.
- Rollback plan: for every enforcement step, document how to suspend it (compliance policy back to "Not configured", Secure Boot enforcement off on a single host) and who may approve that.
Detection and coverage measurement
Boot integrity produces evidence you can query. Useful signals and measures:
- Attestation failures: devices whose health report changes from compliant to non-compliant without a planned change are investigation leads for T1542.
- Secure Boot turned off: any device that previously reported Secure Boot on and now reports it off, or that boots in legacy mode.
- Firmware version drift: firmware versions that do not match the vendor release you approved, which also covers T1601.002 downgrades on network devices.
- ESXi verification errors: VIB signature verification failures and entries in
/var/log/esxupdate.logduring upgrades. - Firmware tooling on endpoints: execution of firmware flashing utilities or loading of known low-level hardware access drivers outside a change window. LoJax used the signed RwDrv.sys driver from the RWEverything utility to reach SPI flash.
| Metric | Target (NHI Mgmt Group judgement) | Source |
|---|---|---|
| Endpoints reporting Secure Boot on and attested | At or near 100% of supported hardware | MDM compliance or attestation service |
| Devices on current Secure Boot certificates and dbx | Rising each month to 100% | Endpoint management inventory |
| ESXi hosts with Secure Boot enforced | All hosts on supported hardware | vCenter host inventory |
| Network devices with verified signed images | All devices that support it | Network configuration management |
| Time to investigate an attestation failure | Same working day | SOC case data |
| Hardware models without a tested recovery image | Zero | Platform engineering records |
Common failure patterns
- Secure Boot treated as firmware protection: ESET's LoJax research showed an SPI flash implant that survived operating system reinstall and disk replacement; ESET's own update says Secure Boot did not protect against it.
- Measured boot with nobody reading it: TPM measurements are collected but no verifier or conditional access policy acts on them, so they block nothing.
- Revocation never applied: dbx and certificate updates are deferred because of fear of boot failures, leaving known vulnerable loaders trusted indefinitely.
- Signing keys stored like files: the MSI signing key leak exposed firmware image signing keys for 57 products and Boot Guard keys for 116, which would let modified firmware pass the very checks M1046 relies on.
- Servers and network devices left out: endpoint compliance reports look complete while hypervisors and routers, the targets of T1505.006 and T1542.004, are never measured.
- Exceptions that never close: devices granted a Secure Boot exception for one legacy driver stay exempt for years.
Framework mapping
| Framework | Reference | Link to M1046 |
|---|---|---|
| NIST SP 800-53 Rev. 5 | SI-7(9) Verify Boot Process; SI-7(10) Protection of Boot Firmware | Direct equivalents of Secure Boot and firmware protection |
| NIST SP 800-53 Rev. 5 | SI-7 Software, Firmware, and Information Integrity; CM-14 Signed Components; SR-11 Component Authenticity | Integrity checking, signed components, hardware supply chain |
| NIST CSF 2.0 | PR.PS-01; PR.PS-05; DE.CM-09 | Configuration management, preventing unauthorised software, monitoring hardware and runtime environments |
| NIST SP 800-193 | Protection, detection, recovery | Firmware resiliency beyond boot checks |
| MITRE D3FEND | D3-BA Bootloader Authentication; D3-TBI TPM Boot Integrity | Related defensive techniques listed by D3FEND for M1046 |
Practitioner checklist
- Map your fleet against the 14 ATT&CK techniques above and mark which device classes are measured.
- Report Secure Boot, TPM and code integrity status for every Windows device, and act on non-compliance.
- Apply the 2023 Secure Boot certificates and current dbx updates through a tested pilot ring.
- Enable and enforce Secure Boot on ESXi hosts and Linux servers, with kernel module signing.
- Use signed images and hardware-anchored secure boot on network devices that support them, and remove unneeded TFTP boot paths.
- Treat firmware passwords, BMC accounts and signing keys as privileged machine credentials with owners and vaulting.
- Keep a tested firmware recovery image per hardware model.
- Pair M1046 with M1051 and M1026 for component firmware and firmware write rights.
Standards and references
- MITRE ATT&CK: M1046 Boot Integrity
- MITRE ATT&CK: T1542 Pre-OS Boot
- MITRE D3FEND: TPM Boot Integrity
- NIST: SP 800-193 Platform Firmware Resiliency Guidelines
- Microsoft: Secure the Windows boot process
- Microsoft: Windows Secure Boot certificate expiration and CA updates
- Broadcom: UEFI Secure Boot for ESXi Hosts
- ESET: LoJax, first UEFI rootkit found in the wild
Related NHI Mgmt Group resources: Firmware and Boot Security Guide · Firmware and Bootkit Compromise Playbook · Secure Boot Certificate Expiry 2026 · Hardware and Firmware SBOM Guide