BitLocker Enterprise Deployment and Recovery Key Management: The Practitioner Guide for Intune, MBAM, and Active Directory Escrow

Intune is the preferred management path for cloud-joined or hybrid-joined Windows 10/11 devices. Configuration is done through an Endpoint Protection profile.

Create the profile: Intune > Devices > Configuration > Create > Windows 10 and later > Endpoint Protection

Key settings under Windows Encryption:

• Encrypt devices: Require
• BitLocker OS drive policy: Configure
  • Startup authentication required: Yes
  • Compatible TPM startup: Allowed
  • Compatible TPM startup PIN: Required with TPM (enforces PIN)
  • OS drive recovery: Enable
  • Recovery key: Allow 48-digit recovery password
  • Save BitLocker recovery information to Azure AD: Required
  • Store recovery information in Azure AD before enabling BitLocker: Required (this is critical -- ensures escrow completes before encryption starts)
• BitLocker fixed drive policy: Configure (same recovery key escrow settings)
• BitLocker removable drive policy: Block write to drives not protected by BitLocker (optional but recommended)

Verify recovery key escrow in Azure AD:

# Using Microsoft Graph PowerShell
Connect-MgGraph -Scopes 'BitlockerKey.Read.All'
$keys = Get-MgInformationProtectionBitlockerRecoveryKey -All
$keys | Select-Object Id, CreatedDateTime, DeviceId | Format-Table
# Cross-reference DeviceId with your device inventory

For domain-joined devices managed via Group Policy:

Group Policy path: Computer Configuration > Administrative Templates > Windows Components > BitLocker Drive Encryption

OS Drive settings:

• Require additional authentication at startup: Enabled
  • Require TPM: Not allowed
  • Configure TPM startup PIN: Require startup PIN with TPM
• Choose how BitLocker-protected operating system drives can be recovered: Enabled
  • Allow data recovery agent: Yes
  • Configure 48-digit recovery password: Require
  • Save BitLocker recovery information to AD DS: Enabled
  • Do not enable BitLocker until recovery information is stored in AD DS: Enabled (escrow before encrypt)

Extend the AD schema (required for key escrow): Run on a domain controller from the Windows installation media:

cscript C:\Windows\System32\manage-bde.wsf -forcerecovery
# Or use the MBAM GPO templates which handle schema extension automatically

The recovery key lands in AD as a child object of the computer account. Verify:

Get-ADObject -Filter {objectclass -eq 'msFVE-RecoveryInformation'} `
  -SearchBase (Get-ADComputer COMPUTERNAME).DistinguishedName `
  -Properties msFVE-RecoveryPassword | Select msFVE-RecoveryPassword

TPM-only protection is the default and is insufficient for high-security environments. A TPM seals the encryption key and releases it automatically at boot if the measured boot sequence matches. This means the disk decrypts without user interaction -- protecting against offline attacks but not against a powered-on stolen device or DMA-based key extraction.

TPM+PIN requires a 6-20 character PIN at every boot, preventing decryption without physical presence.

Configure minimum PIN length: Computer Configuration > Administrative Templates > Windows Components > BitLocker Drive Encryption > Operating System Drives

• Configure minimum PIN length for startup: 8 (minimum; use 12 for high-sensitivity endpoints)

Allow enhanced PIN (alphanumeric):

• Allow enhanced PINs for startup: Enabled

Enforce via Intune (see above) or set via Group Policy as above. Note: TPM+PIN requires the user to enter the PIN at every boot including after updates and patches. Factor this into your patch restart workflow -- machines that restart remotely after patching will hang at the pre-boot PIN prompt until a user physically (or via IPMI/iLO) enters the PIN. Plan for automated PIN bypass in headless server environments using the Network Unlock feature.

Knowing which machines have BitLocker enabled (and whether the recovery keys are escrowed) requires active auditing. 'BitLocker is in your policy' is not the same as 'BitLocker is encrypting your devices.'

Audit via PowerShell (on-premises, run as domain admin):

# Get all computers in AD
$computers = Get-ADComputer -Filter * -Properties Name, OperatingSystem
$results = foreach ($c in $computers) {
    try {
        $keys = Get-ADObject -Filter {objectclass -eq 'msFVE-RecoveryInformation'} `
            -SearchBase $c.DistinguishedName -Properties Created -ErrorAction Stop
        [PSCustomObject]@{
            Computer = $c.Name
            OS       = $c.OperatingSystem
            HasKey   = ($keys.Count -gt 0)
            KeyCount = $keys.Count
            LastKey  = ($keys | Sort-Object Created | Select -Last 1).Created
        }
    } catch {
        [PSCustomObject]@{
            Computer = $c.Name
            OS       = $c.OperatingSystem
            HasKey   = $false
            KeyCount = 0
            LastKey  = $null
        }
    }
}
$results | Where-Object HasKey -eq $false | Export-Csv 'no-bitlocker-key.csv' -NoTypeInformation

Audit via Intune: Devices > Monitor > Encryption report shows encryption status and key escrow status per device. Filter by 'Not encrypted' or 'Key escrow: Not ready' to identify gaps.

Rotate recovery keys after any use:

# Force key rotation after a recovery
manage-bde -protectors -adbackup C: -id {KEYID}
# Or via Intune: rotate BitLocker key from the device blade