Measured Boot logs become evidence only with a baseline

Measured Boot records the components that execute during the boot process in the TPM's Platform Configuration Registers. Windows can use those measurements with BitLocker and health attestation. The logs can also help an investigator understand why a device entered recovery or whether a boot component changed. A log without a known-good baseline is difficult to interpret, and a baseline without change review is easy to ignore.

Microsoft's Measured Boot documentation describes the PCRs as TPM memory locations that hold measurements of the boot sequence. BitLocker and related technologies depend on specific PCR configurations. Windows records Measured Boot logs under the local MeasuredBoot log directory, and tools such as TBSLogGenerator.exe and PCPTool.exe can decode them. The exact PCR values depend on the platform, firmware, Secure Boot state, and boot configuration.

Build a reference set

Collect logs from representative hardware models, firmware versions, and boot configurations. Record the device model, TPM version, PCR bank, Secure Boot state, BitLocker protector configuration, and Windows build with each sample. A comparison across unrelated hardware is not meaningful. The reference set should be tied to a controlled image and a known deployment state.

Store the baseline centrally and protect it from modification. The device log alone does not prove that the device was healthy at boot; it records measurements. A central copy with a hash and collection time lets an analyst compare the device against a known reference and detect an unexpected change.

Interpret a change carefully

A changed PCR can indicate a firmware update, a driver change, a Secure Boot policy update, a boot configuration change, or malicious modification. It can also be a benign platform update. Review the change against deployment records, update history, and the device's recovery state. Do not label every discrepancy as malware, and do not dismiss a change because the endpoint still boots.

PCR 7 is commonly associated with Secure Boot state, while BitLocker can bind to PCR 7 and PCR 11 on systems with a properly configured TPM and Secure Boot. A recovery prompt may occur when the measured state no longer matches the expected protector policy. The correct response is to establish what changed before resetting the protector or exposing recovery material.

Detection and response workflow

Forward boot measurements and device metadata to a central system. Correlate new measurements with firmware and driver deployment events. Alert on a change that has no approved change record. Preserve the original log and a decoded copy, then capture the current PCR values and the protector configuration.

If compromise is suspected, isolate the device from the network and preserve volatile evidence before rebooting. Use recovery keys through the approved process rather than attempting to bypass BitLocker. Reimage or repair the device after the boot chain is understood. Rebuild the baseline only after the change is approved and verified.

Measured Boot gives defenders a durable record of the boot chain, but the evidence needs context. A baseline, an inventory, and an approved-change process turn PCR measurements into an operational control instead of a pile of hashes.

References

• Microsoft Learn, Decode Measured Boot logs to track PCR changes
• Microsoft Learn, Understand PCR banks on TPM 2.0 devices
• Microsoft Learn, Secure the Windows boot process