Malware that loads before the operating system can hide from every tool that runs after it, so the only reliable evidence of a clean boot is a measurement taken by hardware and checked by someone other than the device itself. MITRE D3FEND names this countermeasure TPM Boot Integrity (D3-TBI) and describes it as assuring platform integrity "by demonstrating that the boot process starts from a trusted combination of hardware and software and continues until the operating system has fully booted and applications are running." It is also called Static Root of Trust Measurement (STRM). D3-TBI sits under the Harden tactic as a child of Platform Hardening (D3-PH). This card explains how measurement and attestation work, why D3FEND lists no ATT&CK mapping for it, where it is implemented on Windows and Linux, how to verify it and where it falls short. It is written for endpoint, platform and zero trust engineers who already know the basics in the Firmware and Boot Security Guide.
Key takeaways
- Measure, then compare elsewhere. The firmware's Core Root of Trust for Measurement hashes each boot component and the TPM records those hashes in Platform Configuration Registers (PCRs); a verifier compares them with known-good values.
- The TPM does not enforce anything. D3FEND's own consideration is that the TPM only provides the PCR information. A decision, such as releasing a disk key or granting network access, has to be built on top.
- Attestation needs a remote verifier. A signed Quote of PCR values is trusted because the signing key never leaves the TPM, but a rootkit can lie to local software, so the health verdict must come from a server.
- Measured boot complements Secure Boot. Secure Boot blocks unsigned boot code; measured boot records what actually ran, including signed but unexpected components, and proves it later.
- No direct ATT&CK mapping in D3FEND. The D3FEND entry has no ATT&CK relations. The pre-OS boot techniques it addresses are listed below as NHI Mgmt Group's view, alongside ATT&CK's own Boot Integrity mitigation.
D3-TBI at a glance
| Attribute | Value |
|---|---|
| D3FEND ID | D3-TBI (d3f:TPMBootIntegrity) |
| Tactic | Harden |
| Parent technique | Platform Hardening (D3-PH), whose definition names hardware security devices such as Trusted Platform Modules and boot process logic |
| Synonyms | Static Root of Trust Measurement, STRM |
| Digital artefacts | No artefact relation in the D3FEND ontology (checked November 2026). In practice it acts on firmware, bootloader and boot driver code and on the TPM's PCRs |
| ATT&CK mapping in D3FEND | None |
| D3FEND references | TCG TPM 2.0 Library Specification; TCG Trusted Attestation Protocol (TAP) Use Cases for TPM Families 1.2 and 2.0 and DICE |
| Main limitation | Detects boot changes only where someone acts on the measurements; does not cover what happens after the measured phase |
How it works
D3FEND's knowledge base article describes four steps.
- Measurement: with the defence enabled, the BIOS boot block acts as the Core Root of Trust for Measurement (CRTM) and measures boot components such as firmware and ROM before they run.
- Recording: the TPM hashes those measurements into PCRs. A PCR cannot be written directly, only extended, so the final value depends on every measurement in order.
- Comparison: on a later boot the new measurements are given to a verifier, which compares them with the stored values. A match shows the boot components are unchanged.
- Attestation: a verifier requests a Quote, a concatenation of the requested PCR values hashed and signed by the TPM's unique key. The signature is trusted because the private key is held in hardware and never leaves the TPM.
Microsoft's description of Windows Measured Boot follows the same pattern. UEFI firmware stores in the TPM a hash of the firmware, bootloader, boot drivers and everything loaded before the anti-malware software. At the end of start-up, a remote attestation client receives a key from a trusted attestation server, the TPM signs the measurement log with it, and the server decides whether the device is healthy, granting either full network access or access only to a quarantine network. Microsoft notes that rootkits can hide from the local client, which is why the server's assessment is what gives Measured Boot its value.
The firmware side is specified by the Trusted Computing Group: the PC Client Platform Firmware Profile (latest version 1.06 Revision 52, December 2023, per the TCG page checked November 2026) defines how platform firmware initialises and interacts with a TPM 2.0 device. The TPM 2.0 Library Specification was also published as ISO/IEC 11889:2015, Parts 1 to 4.
Measured boot, Secure Boot and BitLocker sealing
| Mechanism | What it does | Failure behaviour |
|---|---|---|
| UEFI Secure Boot | Verifies signatures of firmware drivers and the bootloader before they run | Unsigned or untrusted code does not start |
| Trusted Boot (Windows) | Bootloader verifies the kernel; the kernel verifies boot drivers, start-up files and the ELAM driver | Modified components are refused |
| Measured boot (D3-TBI) | Records hashes of what ran into PCRs and a signed log | Nothing on the device; the verifier decides |
| TPM sealing (for example BitLocker) | Releases a disk key only if PCR values match. BitLocker uses the PCR 7 Secure Boot measurement by default and seals to PCR 11 so a different OS loader cannot unseal it | Device enters recovery and the key is not released |
D3-TBI is the measurement and attestation row. It is strongest when combined with the others: Secure Boot to block, sealing to protect data locally, attestation to prove state to a remote party. For the signature side see D3-BA Bootloader Authentication; for disk keys see the BitLocker guide.
ATT&CK techniques and D3-TBI
Relationship type: none in D3FEND. D3FEND 1.6.0 (checked November 2026) lists no ATT&CK relationship for D3-TBI, direct or inferred, because the entry has no digital artefact relation to infer from. The rows below are NHI Mgmt Group's view of the techniques whose effects a measured boot can reveal, cross-checked against ATT&CK v20 mitigation M1046 Boot Integrity, which lists each of them.
| ATT&CK ID | Technique | What boot measurement can show (our view) |
|---|---|---|
| T1542.001 | System Firmware | Changed firmware code produces different early PCR values, if the change is in a measured region |
| T1542.003 | Bootkit | A replaced or patched boot manager or loader changes the measurements recorded before the OS starts |
| T1553.006 | Code Signing Policy Modification | Boot configuration that turns off signature enforcement is reflected in measured boot state and in health attestation results |
| T1495 | Firmware Corruption | Unexpected firmware measurements after an update or tampering event |
| T1542 | Pre-OS Boot (parent) | The general class of persistence below the operating system |
Network devices (T1542.004 ROMMONkit, T1542.005 TFTP Boot, T1601 Modify System Image) also appear under M1046, but depend on vendor-specific image verification rather than PC-style TPM measurement. Technique detail is in MITRE ATT&CK T1542 Pre-OS Boot and MITRE ATT&CK T1495 Firmware Corruption; the ATT&CK mitigation is covered in M1046 Boot Integrity.
Where it is implemented
| Implementation class | Examples (alphabetical, not a recommendation) | What it provides |
|---|---|---|
| Device management health attestation | Endpoint management platforms that consume the Windows Device Health Attestation service | Compliance rules such as requiring BitLocker, Secure Boot and code integrity; BitLocker state is measured at boot, so a device stays noncompliant until it reboots after encryption |
| Open source remote attestation | Keylime, a CNCF sandbox project built on the Linux TPM2 Software Stack | Remote boot attestation and Linux IMA runtime integrity monitoring, with agent, registrar, tenant and verifier components and a revocation framework |
| Disk encryption sealing | BitLocker on Windows; TPM-bound unlock for LUKS on Linux | Local enforcement: the key is released only for expected PCR values |
| Network access control and zero trust brokers | Products that consume attestation or device health signals | Conditional access or quarantine based on the verifier's verdict |
| Hardware-assisted boot verification | Intel Boot Guard, AMD Hardware Verified Boot (named by Microsoft as stronger Secure Boot implementations) | Verification and measurement anchored before the first mutable firmware code |
Measured boot on Windows needs UEFI 2.3.1 and a TPM, and Windows provides the APIs while the remote attestation client and server come from other tooling. Linux disk sealing is covered in the LUKS Disk Encryption Guide and the boot chain in the Linux Secure Boot and Shim Guide.
Where identity fits
The TPM's attestation key is a device credential: a non-human identity whose proof of possession depends on hardware. Attestation turns "this device has a certificate" into "this device has a certificate and booted cleanly", which is why device health appears in conditional access and zero trust designs. The same hardware-bound pattern is used for device identity in the IoT Device Identity with TPM and DICE Guide and for keys in Hardware key attestation.
Implementation steps
- Inventory platform capability. Record TPM version, UEFI mode and Secure Boot state per device. D3FEND notes that TPM 2.0 is the current version while many existing implementations use TPM 1.2; some attestation settings need TPM 2.0.
- Turn on the boot chain first. Enable UEFI mode, Secure Boot and the TPM in firmware, and set a firmware administrator password as defence in depth, as Microsoft's BitLocker countermeasures guidance suggests.
- Choose the verifier. Use the device management platform's health attestation for managed endpoints, or a remote attestation service for servers and Linux fleets. Decide which PCRs and log events the policy checks.
- Build golden values. Capture expected measurements per hardware model and firmware version. Without a reference set, every firmware update looks like an attack.
- Run in report-only mode. Collect attestation results for a pilot ring without blocking access. Investigate every mismatch and classify it as an update, a configuration change or a real anomaly.
- Enforce gradually. Tie failed attestation to an action: a compliance flag, conditional access block, quarantine network, or key withholding. Start with the least disruptive action.
- Plan updates and rollback. Update golden values before firmware and bootloader rollouts, suspend sealing where the platform requires it during updates, and keep recovery keys escrowed so a failed measurement does not cause data loss. Rollback means switching enforcement back to report-only, not disabling measurement.
How to verify it works
- Attestation coverage: the share of devices returning a valid, signed attestation result to the verifier.
- Negative test: on an approved lab device, change a measured boot setting (for example turn Secure Boot off) and confirm the verifier reports the change and the enforcement action fires.
- Golden value freshness: confirm reference measurements were updated for every firmware version deployed in the last cycle.
- Recovery events: track BitLocker or LUKS recovery prompts per device; a spike after an update shows golden values or sealing policy were not prepared.
| Metric | Example target (NHI Mgmt Group suggestion, not a standard) | Why it matters |
|---|---|---|
| Devices with Secure Boot on and a TPM 2.0 present | Close to 100% of supported hardware | Prerequisite for meaningful measurement |
| Devices returning a fresh attestation result | Above 95% | Unattested devices are unknown, not healthy |
| Unexplained attestation failures per month | Each investigated within one working day | A real boot compromise looks like one of these |
| Recovery prompts after planned updates | Falling release on release | Shows update and golden value process is working |
Limits, bypasses and failure patterns
- Measurements nobody reads: a TPM recording PCRs with no verifier is not a control. D3FEND states the TPM does not act on PCR values itself.
- Local self-checks: trusting a health result produced by software on the possibly compromised device repeats the problem Microsoft describes, where rootkits hide from the local client.
- Unmeasured code: components loaded outside the measured chain, or firmware regions the CRTM does not cover, are invisible. Runtime changes after boot are also out of scope; that is what runtime integrity measurement, such as Linux IMA, adds.
- Golden value drift: firmware and bootloader updates change PCRs. Teams that cannot keep reference values current end up allowing anything, which removes the control.
- Physical attacks and TPM-only unlock: Microsoft describes TPM-only BitLocker as the default and less secure than options that add a pre-boot authentication factor, such as TPM plus PIN, which suit higher physical-access threats.
- Broad Secure Boot trust: a measured boot of a signed but vulnerable bootloader still records a "trusted" result if the policy only checks Secure Boot state. Check the revocation list (dbx) state as part of the policy; see D3-SFV System Firmware Verification for firmware-level checks.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SI-7(9) Verify Boot Process | Verifying the integrity of the boot process |
| NIST SP 800-53 Rev 5 | SI-7(10) Protection of Boot Firmware | Protecting boot firmware integrity |
| NIST SP 800-53 Rev 5 | SC-51 Hardware-based Protection | Hardware-rooted protection of firmware |
| NIST CSF 2.0 | PR.PS-01, DE.CM-09 | Configuration management; monitoring hardware and software for adverse events |
| MITRE ATT&CK mitigation | M1046 Boot Integrity | The ATT&CK counterpart |
| MITRE D3FEND | D3-PH, D3-TBI | Parent and technique |
Related countermeasures
- Bootloader Authentication (D3-BA): the enforcement partner that blocks unsigned boot code.
- System Firmware Verification (D3-SFV) and Firmware Verification (D3-FV): check firmware against known-good images. See D3-FV Firmware Verification.
- Endpoint Health Beacon (D3-EHB): carries device health signals to a decision point. See D3-EHB Endpoint Health Beacon.
- Disk Encryption (D3-DENCR) and System Configuration Permissions (D3-SCP): sibling Platform Hardening techniques; see D3-SCP System Configuration Permissions.
Practitioner checklist
- Inventory TPM version, UEFI mode and Secure Boot state on every device.
- Enable Secure Boot and the TPM, and set a firmware administrator password.
- Choose a remote verifier; never rely on a local self-reported health result.
- Maintain golden measurements per hardware model and firmware version.
- Run attestation in report-only mode before enforcing.
- Tie failed attestation to a defined action such as conditional access block or quarantine.
- Update reference values before firmware and bootloader rollouts.
- Escrow disk recovery keys and track recovery prompts after updates.
- Add runtime integrity monitoring where post-boot tampering is in scope.
Standards and references
- MITRE D3FEND: TPM Boot Integrity (D3-TBI)
- Trusted Computing Group: TPM 2.0 Library Specification
- Trusted Computing Group: PC Client Platform Firmware Profile Specification
- Trusted Computing Group: Trusted Attestation Protocol Use Cases for TPM Families 1.2 and 2.0 and DICE
- MITRE ATT&CK: M1046 Boot Integrity
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls (SI-7)
- Microsoft Learn: Secure the Windows boot process
- Microsoft Learn: BitLocker countermeasures
- Microsoft Learn: Intune Windows compliance settings (Device Health)
- Keylime: Remote attestation project
Related NHI Mgmt Group resources: Firmware and Boot Security Guide · M1046 Boot Integrity · D3-BA Bootloader Authentication · Disk Encryption Guide: BitLocker and FileVault · MITRE D3FEND Guide