BitLocker key rotates but inventory system shows old key ID

MSP Toolkit
Practical troubleshooting paths for MSP technicians dealing with real-world support failures.
Submitted by Anonymous (not verified) on

Field Summary

When BitLocker rotates a recovery key but inventory still shows the old key ID, the risk is practical: the key a tech sees during an outage may not unlock the device at the recovery screen. Start by matching the recovery key ID shown at boot against the protector ID on the endpoint, then confirm whether the new key escrowed to Entra ID, Intune, AD DS, or the RMM inventory source that technicians actually use.

Common Symptoms

  • Recovery screen shows a key ID that does not match RMM or inventory.
  • Inventory reports BitLocker healthy but the visible recovery key is stale.
  • Key rotation happened after firmware, TPM, policy, or security baseline changes.
  • Endpoint shows a current protector locally, but upstream escrow is delayed or missing.

Fast Triage

  1. Record the recovery key ID shown at boot or in BitLocker management.
  2. On the endpoint, check current protector IDs if Windows is accessible.
  3. Confirm where the client expects recovery keys to be escrowed: Entra, Intune, AD DS, RMM, or documentation vault.
  4. Check recent BIOS, firmware, TPM, Secure Boot, boot order, encryption policy, or RMM inventory changes.
  5. Do not trust an inventory key unless the key ID matches the endpoint prompt or protector output.

Likely Causes

  • RMM inventory has not synced after local key rotation.
  • Key rotated locally but escrow to Entra, Intune, or AD DS failed.
  • Multiple protectors exist and the wrong one is being displayed.
  • TPM protector changed after firmware or Secure Boot state changed.
  • Device object mismatch, duplicate asset, or stale inventory record.

Useful Commands

manage-bde -status
manage-bde -protectors -get C:

Tier 1 Fix Path

  1. If the device is booted, collect protector details and screenshot/record the current ID.
  2. Force the RMM inventory refresh only after confirming the local protector state.
  3. Check Entra/Intune or AD DS for the matching recovery key ID.
  4. If the user is at the recovery screen, release only the key whose ID matches the prompt.

Tier 2 / Admin Investigation

  1. Review Intune device encryption status and recovery key escrow where used.
  2. Check Entra device record and BitLocker recovery keys for matching key ID.
  3. For AD DS escrow, inspect the computer object BitLocker Recovery tab or recovery password objects.
  4. Compare RMM asset ID and serial number against the physical endpoint to rule out duplicate asset records.
  5. Review endpoint security baseline or encryption policy changes that may have rotated protectors.

Advanced Remediation

Rotate protectors or suspend/resume BitLocker only after escrow is verified. Do not clear TPM, decrypt the drive, or delete protectors remotely unless recovery material is confirmed and a maintenance window exists.

Verification

  • The recovery key ID in the technician source matches the endpoint protector or recovery prompt.
  • A test inventory refresh shows the current key ID.
  • BitLocker status is protected and TPM protector is present.
  • The device reboots without unexpected recovery prompts after policy settles.

Ticket Notes to Capture

  • Device name, serial, user, key ID at prompt, local protector ID, escrow source checked, RMM asset ID, recent firmware/TPM/policy changes, fix applied, verification result.

Escalate When

  • No matching key exists in approved escrow.
  • TPM was cleared or motherboard/firmware work changed startup measurements.
  • Multiple devices or inventory sources show stale key IDs.
  • Recovery is needed for an executive or business-critical endpoint.

Prevention

Document the authoritative recovery-key source for each client and add a post-rotation escrow check to encryption policy changes, BIOS updates, and RMM inventory reviews.

Subjects
Security & Continuity
Encryption