BitLocker asked for the recovery key after a firmware update: Measured Boot, the PCRs, and which change broke the seal

A laptop takes a vendor firmware update on Tuesday night. On Wednesday morning the user is staring at a blue screen asking for 48 digits. Nothing is broken. No disk failed. No policy changed. BitLocker simply refused to hand the key over, because the machine that asked for it no longer looks like the machine the key was sealed to. This post is about that check: what Measured Boot measures, which Platform Configuration Register (PCR) holds which measurement, and how to work out - after the fact, from the device itself - exactly which change broke the seal.

The problem: one firmware update, 48 digits, no explanation

The symptom is always the same. A device that has booted silently for months suddenly shows the BitLocker recovery screen. The help desk retrieves the recovery password, the user types it in, and the device boots normally afterwards. Everybody moves on. Nobody writes down why.

That is the mistake. Microsoft's own guidance on the recovery process puts root cause analysis in the middle of the help desk checklist, before the password is handed over, because a recovery prompt is the only signal you get that the measured boot path changed. Most of the time the change was authorised - a firmware update, a Secure Boot certificate rollout, a technician who toggled a setting in the firmware menu. Occasionally it was not, and that is exactly the case you cannot afford to file under "BitLocker being BitLocker".

Here is the part that trips people up. BitLocker did not decide to prompt. The boot manager asked the TPM for the volume master key, the TPM compared the current measurements with the ones the key was sealed against, they differed, and the TPM refused to unseal. BitLocker is the messenger. The interesting question is which measurement moved.

Everything below assumes a native UEFI device with a GPT disk and a TPM 2.0, because that is what a Windows 11 fleet looks like. Where BIOS or Compatibility Support Module (CSM) devices behave differently, I say so, because the same PCR numbers mean completely different things on those machines.

Why it happens: Measured Boot, the TCG log and the PCR seal

What a PCR actually is

A Platform Configuration Register is a small piece of storage inside the TPM. You cannot write a value into it. You can only extend it. Extend means: take the current register value, append the new measurement, hash the result, store that back. The register therefore holds a running hash of everything that was measured into it, in order.

Two consequences fall out of that design. First, the final value depends on the order of the measurements, not just their content. Second, nothing that runs later can undo a measurement made earlier. That is what makes the register trustworthy: malware that loads after the boot manager cannot rewrite the record of the boot manager.

Alongside the registers, the firmware keeps a plain-text log of every measurement it made - the Trusted Computing Group (TCG) log, which Microsoft also calls the Windows Boot Configuration Log (WBCL). The log says what was measured; the registers prove the log was not edited. Replay the log, extend the values yourself, and you should arrive at the register values the TPM reports. That is the whole basis of remote attestation, and it is also how you audit a recovery event locally.

How the seal is created and checked

When BitLocker creates or updates a TPM protector, it does not save a key anywhere you can read. It asks the TPM to seal the volume master key against a chosen set of PCR values - the platform validation profile. The sequence at every subsequent boot is short and worth memorising:

1. The UEFI firmware measures itself and its configuration into PCR 0 through PCR 7 and writes matching entries to the TCG log.
2. The firmware measures the boot manager image it is about to launch, then hands control to bootmgfw.efi on the EFI system partition.
3. The boot manager extends PCR 11 with the BitLocker access control measurement, then asks the TPM to unseal the volume master key.
4. The TPM compares the live register values against the values recorded in the sealed blob. If every register in the profile matches, it releases the key. If one differs, it refuses.
5. On refusal the boot manager writes an event describing what it detected, then shows the recovery screen.
6. On success the boot manager passes control to winload.efi, which loads the kernel; fvevol.sys then performs on-the-fly decryption for the volume.

Step 3 hides a nice piece of engineering. Microsoft documents that when Windows seals the key, it seals it with a PCR 11 value of zero, and the boot manager always extends PCR 11 to a different value before passing control to any boot loader. An attacker who boots their own loader and then tries to unseal the blob from inside that loader finds PCR 11 already dirty. That is why PCR 11 must be in the profile - it is not a hardware measurement at all, it is the gate that stops the key being unsealed outside the boot manager.

The documented PCR list for native UEFI devices

These are Microsoft's descriptions from the BitLocker policy documentation, not community folklore. Learn them once and most recovery tickets explain themselves.

Two default profiles are documented, and which one a device gets is decided by hardware, not by you. The base default secures the key against PCR 0, 2, 4 and 11. When Secure Boot State support in PCR 7 is available, the default becomes PCR 7 and PCR 11. Microsoft is explicit about why: with PCR 7, BitLocker binds to the Secure Boot policy - which keys are trusted, and whether Secure Boot is on - "rather than to PCRs 0, 2, and 4, which have the measurements of the exact firmware and Bootmgr images loaded". Binding to a policy instead of an image hash is what lets a firmware update land without a recovery prompt.

Which real-world change touches which register

This is the table I actually use when a ticket arrives. The PCR column follows the documented measurement definitions; the effect column follows from which profile the device is bound to.

Microsoft publishes a longer list of recovery scenarios covering docking and undocking, changes to the partition table, PXE boot, TPM self-test failure, exceeding the sign-in lockout threshold, and "modifying the Platform Configuration Registers (PCRs) used by the TPM validation profile" - which is to say, changing the policy itself is on the list of things that trigger recovery.

The BCD angle, because it surprises people

The measurement story is not only about hardware. During boot, BitLocker also verifies that security-sensitive Boot Configuration Data settings have not changed since it was last enabled, resumed or recovered. The default validation profile covers 25 settings, including all:device, all:path, all:loadoptions, all:bootdebug, all:testsigning, all:nointegritychecks, winload:kernel, winload:hal, winload:nx and winload:winpe. When one of these changes, BitLocker enters recovery and event ID 523 records the hex value that identifies the setting - for example 0x16000010 for bootdebug, which Microsoft notes is always validated and cannot be excluded.

How to verify: bound PCRs, policy profile, events and logs

Four questions, in order. What is the protector sealed to? What does policy say it should be sealed to? Is Secure Boot actually usable for binding? And what did the boot manager complain about?

1. Which PCRs is the protector bound to right now

This is the single most useful command in the whole post. It reports the protectors on the operating system volume and, for the TPM protector, the exact PCR profile the key is sealed to.

That output is a genuine run from a Windows 11 Enterprise device, build 26200, with the protector identifiers and the recovery password replaced. If you want the same answer without the password appearing on screen at all, read it from WMI instead. The GetKeyProtectorPlatformValidationProfile method of Win32_EncryptableVolume returns the profile as an array of PCR indices and nothing else.

Read the result like this. PCR 7 present means the device bound to Secure Boot state. PCR 0 present means it bound to the firmware image hash, and any firmware flash is going to cost you a recovery prompt. PCR 4 present means it bound to the boot manager image hash, and a Windows update that ships a new boot manager can cost you one too.

2. Whether the device can bind to PCR 7 at all

Some devices cannot use PCR 7 even with Secure Boot on. Microsoft documents the cause: BitLocker only accepts early boot components signed with the expected Microsoft certificate for PCR 7 binding, and when a binary in the boot path carries a different signature, "BitLocker switches to PCR 0, 2, 4, 11", where "Windows measures exact binary hashes instead of the CA certificate". The documented place to read that verdict is System Information.

3. What policy is asking for

The platform validation profile has exactly one policy surface, and it writes to a registry subkey with one value per PCR index. The shared parent key is:

Those names come from the BitLocker administrative template shipped in Windows, C:\Windows\PolicyDefinitions\VolumeEncryption.admx, cross-checked against the policy descriptions on Microsoft Learn. If you have seen a single value called PlatformValidationProfile quoted in a blog or a script, it does not exist on Windows 11 - the real surface is the subkey plus the numbered values.

4. What the boot manager complained about

The measurement verdict is written to a dedicated channel. State it once and read it often:

Confirm the exact name on the build in front of you with wevtutil.exe el | findstr /i bitlocker - on Windows 11 build 26200 that returns Microsoft-Windows-BitLocker/BitLocker Management, Microsoft-Windows-BitLocker/BitLocker Operational and Microsoft-Windows-BitLocker/Tracing. If you have seen the channel written as Microsoft-Windows-BitLocker-API/Management, that is the publisher name spliced onto a log name; no channel by that name exists on current Windows 11, and a Get-WinEvent -LogName against it fails.

Event 523 is the only one of these documented in prose on Microsoft Learn, on the BCD settings page; the rest come from the Microsoft-Windows-BitLocker-API provider manifest shipped in Windows, which you can enumerate yourself with (Get-WinEvent -ListProvider Microsoft-Windows-BitLocker-API).Events. Treat the descriptions as authoritative for the build you read them on, and re-check after a major upgrade rather than hard-coding them into a detection script.

TPM-side and Secure Boot-side servicing events land somewhere else entirely - in the classic System log, source Microsoft-Windows-TPM-WMI. Two are worth knowing here: event 1032, "The Secure Boot update was not applied due to a known incompatibility with the current BitLocker configuration", and event 1046, which records measured boot log files being deleted.

5. The measured boot log itself

If the events are not specific enough, go to the source. Windows keeps the TCG measured boot logs on disk:

Microsoft's support guidance for tracking PCR changes points at this folder and names two decoders. TBSLogGenerator.exe ships with the Windows Hardware Lab Kit under C:\Program Files (x86)\Windows Kits\10\Hardware Lab Kit\Tests\amd64\NTTEST\BASETEST\ngscb, and produces a text file whose PCR section is at the very end. PCPTool.exe, from the TPM Platform Crypto-Provider Toolkit, converts a log into XML. The commands are:

The binaries, services and tasks in the flow

Names matter when you are reading a 522 event that says "the following boot application has changed".

On the services side there is exactly one to check: BDESVC, display name BitLocker Drive Encryption Service, start type Manual, hosted in the netsvcs svchost group. It being stopped is normal - it starts on demand. Note that there is no separate TPM Base Services service on Windows 11; TBS lives in the driver and DLL above. Two scheduled task folders are relevant: \Microsoft\Windows\BitLocker holds BitLocker Encrypt All Drives and BitLocker MDM policy Refresh, and \Microsoft\Windows\TPM holds Tpm-Maintenance, Tpm-HASCertRetr and Tpm-PreAttestationHealthCheck. None of them change your PCR profile.

The fix: the right profile, and suspend before you touch the boot path

There are two fixes, and the order matters. The operational fix prevents the prompt. The configuration fix is mostly about undoing damage somebody already did.

Fix 1: suspend BitLocker before you change the boot path

Microsoft's documented remedy for "changes to boot files" is blunt: this happens when the firmware is updated, so suspend BitLocker before changing the firmware and resume afterwards. Suspending leaves the volume fully encrypted, but it removes the requirement for the TPM to unseal on the next boot - and resuming re-seals the key against the new measurements without anyone typing 48 digits. The resulting event is 793.

Fix 2: the policy, if you must touch it

The Group Policy path is:

Step by step in the Group Policy Editor, on a domain controller for a GPO or locally with gpedit.msc:

1. Open gpedit.msc for a local test, or the Group Policy Management Console and edit a GPO linked to a pilot organisational unit.
2. Expand Computer Configuration, then Administrative Templates, then Windows Components.
3. Expand BitLocker Drive Encryption, then select Operating System Drives.
4. Open Configure TPM platform validation profile for native UEFI firmware configurations.
5. Read the panel text before you touch a checkbox. It says "We recommend the default of PCRs 0, 2, 4, and 11" and "For BitLocker protection to take effect, you must include PCR 11".
6. The checkboxes are labelled exactly as the documented PCR list: PCR 0: Core System Firmware executable code, PCR 1: Core System Firmware data, PCR 2: Extended or pluggable executable code, PCR 3: Extended or pluggable firmware data, PCR 4: Boot Manager, PCR 5: GPT / Partition Table, PCR 6: Resume from S4 and S5 Power State Events, PCR 7: Secure Boot State, PCR 8/9/10: Initialized to 0 with no Extends, PCR 11: BitLocker Access Control, PCR 12: Data events and highly volatile events, PCR 13: Boot Module Details, PCR 14: Boot Authorities, and PCR 15 through 23 reserved.
7. To undo a previous mistake, set the policy back to Not configured, then run gpupdate /force. That is the remediation Microsoft points at for the April 2026 PCR 7 issue.
8. Confirm the registry subkey OSPlatformValidation_UEFI is gone, then verify the bound profile with the manage-bde or WMI command from the verification section.

Two neighbouring policies in the same folder matter for the same reason. Allow Secure Boot for integrity validation is enabled by default and should stay that way - its own warning says disabling it "might result in BitLocker recovery when manufacturer-specific firmware is updated". And Use enhanced Boot Configuration Data validation profile is the only way to add or exclude a BCD setting from validation; it is ignored entirely when Secure Boot integrity validation is in use.

For completeness, here is where you would look in the admin center to confirm the absence for yourself:

1. Sign in to intune.microsoft.com as an Intune Administrator.
2. Go to Endpoint security, then Disk encryption, then Create policy.
3. Choose platform Windows and profile BitLocker, then Create.
4. Expand every group on the Configuration settings page: BitLocker - Base settings, Fixed drive settings, OS drive settings and Removable drive settings.
5. Search the page for "platform validation" or "PCR". There is nothing to find, which is the point - this profile is built on the BitLocker CSP.
6. Where a recovery prompt needs attributing rather than configuring, use Devices, then the device, then Recovery keys to read the key ID and escrow state, and do the measurement analysis on the device itself.

Proof it worked: a real run on a PCR 7, 11 device

The companion script, Get-MeasuredBootSealState.ps1, does the four checks above in one pass and prints the documented cause next to every measurement event it finds. It is strictly read-only: it never suspends, resumes, decrypts or re-seals, and it never prints a protector ID, a recovery password or a recovery key, so its output is safe to attach to a ticket. It needs no modules beyond what ships in Windows, and it exits 1 if any read fails rather than showing you a reassuring blank.

How to read a bad run. If the volume section reports sealed to PCRs: 0, 2, 4, 11 and the event section shows 522, the boot manager image changed and that device was always going to prompt - attribute it to the servicing or firmware event on that date and move on. If it reports 7, 11 and shows 823 or 824, somebody changed Secure Boot, or a Secure Boot key update landed. If the policy section reports a forced profile that differs from the bound profile, the protector predates the policy: the profile only takes effect when the protector is next created or re-sealed, which is a subtlety that costs people an afternoon.

Independent write-ups worth reading alongside the Microsoft documentation, both verified as live and on topic at the time of writing:

References

• Configure BitLocker - the documented PCR lists, the default profiles, and the exact policy names and Group Policy paths used throughout this post.
• BitLocker preboot recovery screen - the recovery error categories and codes, including E_FVE_PCR_MISMATCH, E_FVE_SECUREBOOT_DISABLED and E_FVE_SECUREBOOT_CHANGED.
• BitLocker recovery overview - the documented list of events that cause a device to enter recovery.
• BCD settings and BitLocker - the default BCD validation profile, the prefix syntax, and event ID 523.
• BitLocker countermeasures - PCR 7 integrity protection and the PCR 11 rogue-loader mechanism.
• Secure the Windows boot process - Secure Boot, Trusted Boot and Measured Boot side by side.
• Decode Measured Boot logs to track PCR changes - the log folder and the TBSLogGenerator and PCPTool commands.
• PCR7 configuration shows as Binding not possible - why a device falls back to the 0, 2, 4, 11 profile, and the msinfo32 check.
• GetKeyProtectorPlatformValidationProfile (Win32_EncryptableVolume) - the WMI method used to read the bound profile without printing secrets.
• Trusted Execution Environment EFI Protocol, Appendix A - what firmware must measure into PCR 7 for Secure Boot binding to work.
• April 14, 2026 - KB5083769 - the one-time BitLocker recovery prompt on devices with PCR 7 forced by policy, and the recommended audit.