Measured Boot records what a computer loads during startup. Firmware and boot components are measured, those measurements are extended into protected registers in the Trusted Platform Module (TPM), and a separate event log records the sequence. A verifier can later compare the log and TPM values with an approved boot policy.
It is evidence about the boot path, not a promise that the machine is safe forever.
Documentation checked: Microsoft’s measured-boot, PCR-log and Device Health Attestation documentation was reviewed on 30 October 2026. The source pages identify their own update dates below.
The short answer
| Question | Answer |
|---|---|
| What does Measured Boot do? | It records cryptographic measurements of boot components and configuration |
| Where are the protected results kept? | In TPM Platform Configuration Registers, usually called PCRs |
| Is a PCR a list of files? | No. It holds a hash-chain result, while the event log describes the measured events |
| Does it block untrusted code? | Not by itself. Secure Boot enforces a signature policy; Measured Boot records what happened |
| Can the result be checked remotely? | Yes. An attestation service can evaluate signed TPM evidence and the boot log against policy |
| Does a good result prove the whole device is clean? | No. It describes selected boot-time state and says nothing conclusive about every later runtime event |
What gets measured during startup
A measured-boot sequence begins before the operating system is fully running. Firmware measures important code and configuration before handing control to the next component. The bootloader then measures later stages, and the chain continues into operating-system security state.
The exact events depend on the platform and policy. They can include firmware code, boot configuration, Secure Boot state, boot managers, kernel components and security settings.
A measurement is a cryptographic digest. The component is not copied into the TPM. Instead, the platform calculates a hash and extends it into a selected PCR. This is why a modest TPM can represent a long boot sequence without storing every binary.
Microsoft’s Azure description calls the boot record a hash-chained set of measurements. Each new measurement changes the PCR value. A different component, configuration or order should produce a different final result.
A PCR is extended, not overwritten
The important operation is extend. Conceptually, the TPM calculates a new register value from the old register value and the new measurement:
new PCR = Hash(old PCR || new measurement)
The actual hash algorithm and available PCR banks depend on the TPM and platform. The useful property is order sensitivity. Measuring A and then B does not normally produce the same result as measuring B and then A.
Software cannot set an arbitrary final PCR value by simply writing it. Microsoft’s host-attestation documentation says TPM PCRs expose read and extend operations for this process. Reconstructing a desired final value without the expected event sequence is designed to be computationally impractical.
PCRs are grouped by purpose. A verifier should know which registers its platform uses and what each policy expects. Treating every PCR number as universal across all firmware and operating systems is a common mistake.
Our TPM explainer covers the hardware root of trust behind these registers.
The event log explains the final value
A final PCR value is compact evidence, but it is not human-readable history. The event log supplies the missing context. It records the measured events, their digests and the PCRs they affected.
A verifier can replay those events in order. If the replayed result matches the value reported by the TPM, the log is consistent with the protected register state. The verifier can then compare the described components and settings with its policy.
This pairing matters:
- the PCR value protects the sequence against casual editing;
- the event log explains which events produced that value;
- the policy decides whether that state is acceptable.
A log alone can be altered like any other file. A PCR alone is an opaque digest. Together they provide evidence that can be evaluated.
On Windows, Microsoft says measured-boot logs are stored under C:\Windows\Logs\MeasuredBoot. Its troubleshooting guidance uses those logs to identify which events changed PCRs, including cases where a change sends BitLocker into recovery.
Measured Boot and Secure Boot solve different problems
Secure Boot checks signatures and policy before allowing selected pre-OS software to run. Its purpose is enforcement: refuse a component that is not trusted under the configured key and revocation policy.
Measured Boot focuses on evidence. It records the components and settings involved in startup so another system can evaluate the resulting state.
The two controls work well together. Secure Boot can block software that fails its trust policy. Measured Boot can provide evidence that Secure Boot was enabled and that the observed boot sequence matched an approved configuration.
Neither control makes every later process trustworthy. Secure Boot can allow a correctly signed component that contains a vulnerability. Measured Boot can faithfully record an approved boot followed by a later compromise. They protect and describe the startup boundary; runtime hardening and monitoring remain separate work.
What remote attestation adds
Attestation turns local measurements into a decision that another service can use. The device provides TPM-backed evidence plus its boot log. An attestation service validates the evidence, replays or evaluates the log, and compares the result with policy.
Microsoft’s Device Health Attestation documentation says its service validates TPM and PCR logs and produces a health report. Management systems can use that report when deciding whether a device may access a resource.
This is more useful than asking the device to declare itself healthy. TPM-backed evidence ties the statement to protected keys and registers. A policy can require facts such as Secure Boot being active or specified boot-time controls being present.
The decision is only as sound as the policy and reference data. A permissive policy can approve an undesirable state. A stale policy can reject a legitimate update. An attestation failure also needs careful diagnosis: it can indicate tampering, but it can also follow a firmware update, boot configuration change or recovery operation.
Why legitimate updates change measurements
Measured Boot is deliberately sensitive to state. Expected changes can therefore alter PCRs:
- firmware or UEFI updates;
- a new boot manager or operating-system build;
- Secure Boot key or revocation-list changes;
- boot-order and recovery changes;
- kernel or early-boot security policy updates;
- enabling or disabling debugging and other measured controls.
That sensitivity is useful, but it creates operational work. Organisations need a process to approve known updates, update reference policies and investigate unexpected measurements. Otherwise, teams are tempted to disable checks after routine changes cause access failures.
BitLocker provides a familiar example. It can seal key release to selected PCR state. If those PCRs change, the device may ask for a recovery key instead of releasing the key automatically. Recovery is a safety path, not proof that an attack occurred.
What Measured Boot cannot tell you
Measured Boot has clear limits:
- It covers measured events. Anything omitted from the measurement chain is outside that evidence.
- It is strongest at boot time. It does not continuously describe every process, file or network connection after startup.
- It does not judge intent. A measured component can be vulnerable or malicious while still producing an accurate digest.
- It depends on trustworthy implementation. Firmware, the TPM, the measurement code and the attestation verifier are part of the trusted system.
- It does not replace incident response. A mismatch says the observed state differs from policy; investigation must explain why.
- It does not remove update planning. Reference values and approved policies must change when authorised software changes.
The right conclusion is narrow: the attested device presented TPM-backed evidence consistent with a defined boot policy at a particular time.
A practical review checklist
For a measured-boot or attestation deployment:
- Document which PCRs and event types the platform uses.
- Keep the event log with the attestation record needed for investigation.
- Define approved states in policy rather than accepting any internally consistent log.
- Separate Secure Boot enforcement from Measured Boot evidence in diagrams and runbooks.
- Test firmware and operating-system updates before broad rollout.
- Maintain a recovery route for legitimate PCR changes.
- Protect attestation keys and validate their certificate chain.
- Record when reference policies change and who approved them.
- Treat repeated mismatches as a security signal, but diagnose before assigning a cause.
- Combine boot attestation with runtime protection, patching and monitoring.
