BitLocker recovery keys: escrow, rotation and auditing

BitLocker protects data only as long as the recovery key is both available to the right people and unavailable to everyone else. Organisations tend to get one half right: keys are escrowed but readable by hundreds of administrators, or access is tight but a quarter of the fleet has no escrowed key at all and the first failed firmware update becomes a data-loss incident.

The BitLocker hardening pillar covers the encryption policy itself, including the GPO setting that blocks encryption until the key is backed up. This guide covers the life of the key after that: where it lives, how to prove every device has one, who can read it, how reads are audited and how keys are rotated. The BitLocker & Boot Security topic lists the rest of the series.

Where keys live

Microsoft BitLocker Administration and Monitoring (MBAM), part of MDOP, has reached the end of extended support; if you still run it, migrate to Configuration Manager BitLocker management or Intune rather than extending it.

Each volume can have several recovery password protectors over time. The key protector ID shown on the recovery screen ("Recovery key ID", the first 8 characters are enough to search) identifies which one the user needs.

Step 1: prove every device has an escrowed key

The pillar's "Do not enable BitLocker until recovery information is stored" setting protects new encryptions. It does not cover devices encrypted earlier, devices that auto-encrypted before policy applied, or keys lost when a computer object was recreated. Measure coverage.

On the device, compare local protectors with what the directory holds:

(Get-BitLockerVolume -MountPoint C:).KeyProtector |
  Where-Object KeyProtectorType -eq 'RecoveryPassword' |
  Select-Object KeyProtectorId

In Active Directory, list which computers have at least one recovery object:

$withKeys = Get-ADObject -LDAPFilter '(objectClass=msFVE-RecoveryInformation)' -SearchBase 'OU=Workstations,DC=corp,DC=example,DC=com' |
  ForEach-Object { ($_.DistinguishedName -split ',',2)[1] } | Sort-Object -Unique
Get-ADComputer -Filter * -SearchBase 'OU=Workstations,DC=corp,DC=example,DC=com' |
  Where-Object { $_.DistinguishedName -notin $withKeys } |
  Select-Object Name

Run this with an account that can read the recovery objects, otherwise every computer looks unprotected. For Entra ID, list key metadata (not the keys) with Microsoft Graph PowerShell and compare the DeviceId values with your Intune device inventory:

Connect-MgGraph -Scopes 'BitLockerKey.ReadBasic.All'
Get-MgInformationProtectionBitlockerRecoveryKey -All |
  Select-Object Id, DeviceId, CreatedDateTime, VolumeType

The Intune encryption report also shows per-device encryption status. For gaps, back up the existing protector with Backup-BitLockerKeyProtector (AD) or BackupToAAD-BitLockerKeyProtector (Entra ID), as shown in the pillar, through a remediation script. The Microsoft > Windows > BitLocker-API > Management event log on the device records each backup attempt and its result; alert on backup failures.

Step 2: restrict who can read keys in Active Directory

msFVE-RecoveryPassword is a confidential attribute: reading it requires the Control Access right on the attribute in addition to normal read permission. By default, that means Domain Admins and anyone with Full Control on the computer objects, which in many domains includes service accounts and over-delegated helpdesk groups.

1. Create a group such as BitLocker-Recovery-Readers for the people who actually perform recoveries.
2. Delegate read access on the recovery objects in the workstation OUs to that group:

dsacls "OU=Workstations,DC=corp,DC=example,DC=com" /I:S /G "CORP\BitLocker-Recovery-Readers:RP;;msFVE-RecoveryInformation"
dsacls "OU=Workstations,DC=corp,DC=example,DC=com" /I:S /G "CORP\BitLocker-Recovery-Readers:CA;msFVE-RecoveryPassword;msFVE-RecoveryInformation"

3. Review who else holds Full Control or All extended rights on those OUs and computer objects, and remove it where it is not needed. The same review you did for Windows LAPS password readers applies here, and the two groups are often the same people.

Test the delegation in a lab first. Install the BitLocker Recovery Password Viewer RSAT feature on the helpdesk's admin workstations; it adds a BitLocker Recovery tab to computer objects and a search by key ID.

Step 3: restrict who can read keys in Entra ID

In Entra ID, reading the key itself requires the permission microsoft.directory/bitlockerKeys/key/read. Several built-in roles include it, among them Cloud Device Administrator, Helpdesk Administrator, Intune Administrator and Security Administrator; check the current role reference before assigning. Recommendations:

• Assign one of these roles, or a custom role with only the BitLocker key permission, to the recovery team, and make it eligible through Privileged Identity Management rather than permanent.
• Scope helpdesk access with administrative units where your licensing allows.
• Decide on user self-service. By default, the registered owner of a device can see its recovery key in their account portal. For company-owned devices, you can turn that off in Entra admin center > Devices > Device settings with the setting that restricts non-admin users from recovering BitLocker keys for their owned devices.
• For automation, use BitLockerKey.ReadBasic.All (metadata only) wherever possible; grant BitLockerKey.Read.All only to the tool that must read keys.

Step 4: audit every key read

Active Directory. On domain controllers, enable Audit Directory Service Access (Success) under Advanced Audit Policy Configuration > Audit Policies > DS Access, then add a SACL on the workstation OUs: principal Everyone, success, Read msFVE-RecoveryPassword, applied to descendant msFVE-RecoveryInformation objects. Every read then produces event 4662 on the DC that served it, with the subject account and the attribute's schema GUID in the Properties field. Look up the GUID to filter on:

Get-ADObject -SearchBase (Get-ADRootDSE).schemaNamingContext `
  -LDAPFilter '(lDAPDisplayName=msFVE-RecoveryPassword)' -Properties schemaIDGUID |
  ForEach-Object { [guid]$_.schemaIDGUID }

Entra ID. Each key read is recorded in the Entra audit log in the KeyManagement category as Read BitLocker key, with the actor and the device. Stream audit logs to your SIEM and alert on reads outside the recovery team, on bulk reads, and on reads by applications.

Correlate reads with tickets. A key read without a matching recovery ticket deserves a question.

Step 5: rotate keys after use

Intune (Entra-joined and hybrid-joined). In your BitLocker policy (Endpoint security > Disk encryption, or the settings catalog), set Configure Recovery Password Rotation to refresh on for Entra-joined, or for both Entra-joined and hybrid-joined devices (BitLocker CSP ConfigureRecoveryPasswordRotation, values 1 and 2). When a recovery password is used to unlock the OS drive, the device generates a new one and escrows it. For a key disclosed without being used, for example read out over the phone to the wrong person, run the BitLocker key rotation device action from the Intune device page.

Active Directory. There is no built-in client-driven rotation. Run a script (through your management tool or a scheduled remediation) that adds a new recovery password, escrows it and only then removes the old protector:

$old = (Get-BitLockerVolume -MountPoint C:).KeyProtector | Where-Object KeyProtectorType -eq 'RecoveryPassword'
$new = Add-BitLockerKeyProtector -MountPoint C: -RecoveryPasswordProtector -WarningAction SilentlyContinue
$newId = ($new.KeyProtector | Where-Object { $_.KeyProtectorType -eq 'RecoveryPassword' -and $_.KeyProtectorId -notin $old.KeyProtectorId }).KeyProtectorId
Backup-BitLockerKeyProtector -MountPoint C: -KeyProtectorId $newId
foreach ($p in $old) { Remove-BitLockerKeyProtector -MountPoint C: -KeyProtectorId $p.KeyProtectorId }

Check that the backup succeeded (the cmdlet throws on failure) before removing anything. Old recovery objects stay in AD; that is harmless because the corresponding protector no longer exists on the drive.

What breaks

• Over-tight delegation leaves the helpdesk unable to recover a device at 7 a.m. Keep a documented break-glass path through Tier 0 administrators.
• Device cleanup scripts that delete stale computer or Entra device objects also delete keys for drives that may still be in a drawer. Check last recovery-key date and encryption state first, and keep the AD Recycle Bin enabled.
• Reimaged devices reuse the name but create new keys; users reading the wrong key ID lose time. Train the helpdesk to always match the key ID.
• Disabling self-service in Entra ID increases helpdesk calls; plan staffing.

Verify it

• Coverage report: zero encrypted devices without an escrowed key, in both AD and Entra ID.
• dsacls or the Advanced Security view on workstation OUs shows only the intended groups with Control Access to msFVE-RecoveryPassword.
• A test read by a helpdesk account produces a 4662 event or an Entra Read BitLocker key audit entry in the SIEM within minutes.
• After a test recovery on an Intune device, the key ID in Entra ID changes and the old password no longer unlocks the drive.

Checklist

• Every encrypted device has an escrowed key in AD DS or Entra ID; gaps remediated
• AD read access to msFVE-RecoveryPassword delegated to a dedicated group only
• Entra key read roles assigned through PIM; self-service decided deliberately
• AD key reads audited with 4662; Entra key reads streamed from the audit log
• Reads correlated with recovery tickets
• Recovery password rotation enabled in Intune; scripted rotation for AD-only devices
• Device cleanup processes protect escrowed keys

Recovery keys are most often needed after boot-chain changes. The Secure Boot and UEFI guide explains which updates can trigger recovery and how to prepare, and the TPM glossary entry explains why the TPM releases the key only when measurements match.