Migrating BitLocker Recovery Key Management from ConfigMgr to Intune: A Practical Guide
Hi, I'm Herbert Fuchs, a Cloud Solution Architect. In this blog, I’ll guide you through migrating existing BitLocker recovery keys from Configuration Manager to Intune—especially for scenarios involving already encrypted devices. While many posts cover Intune setup basics for greenfield deployments, this guide dives deeper into real-world considerations for Hybrid-Joined, co-managed environments. Current Setup: ConfigMgr BitLocker Management In many organizations, BitLocker encryption and key management is handled via MBAM Standalone or the Configuration Manager BitLocker feature. In both cases, the MBAM Agent Service is responsible for encrypting devices and configuring key protectors based on policy — either via GPO or Configuration Manager profiles. You configure a BitLocker policy and assign it to devices. For Configuration Manager, the Configuration tab will show a BitLocker configuration profile once the client receives the policy. Once the encryption process starts, the BitLocker API events show: Key protector creation TPM sealing Encryption initiation You can check encryption status via PowerShell or using manage-bde.exe. You can also compare the recovery password with what's available in the MBAM Helpdesk Portal. PowerShell: Manage-bde: Compare Key: Note: When Configuration Manager escrows the BitLocker key, the information is written to the registry in UNIX DateTime format. Here's how to convert it: $LastEscrowTime = Get-ItemPropertyValue HKLM:\SOFTWARE\Microsoft\CCM\BLM -Name 'LastEscrowTime' $oUNIXDate=[System.DateTimeOffset]::FromUnixTimeSeconds($LastEscrowTime) $oUNIXDate If your environment is running MECM 2203 and higher than you can test the Escrow through the local API, also the Key-Rotation: Function Invoke-CCMBitlockerEscrowKey { [CmdletBinding()] Param ( [Parameter(Mandatory = $false)] [switch]$rotate ) $ErrorActionPreference = 'stop' #ensure client agent is at least CB 2203 if (([wmi]"ROOT\ccm:SMS_Client=@").ClientVersion.Split('.')[2] -lt 9078){ Write-Host "Required client version is at least CB 2203! Aborting..." -ForegroundColor Yellow break } if ($rotate) { # remove escrowed reference to force key rotation Write-Verbose "Removing HKLM\SOFTWARE\Microsoft\CCM\BLM\Escrowed key (if exists), to force key rotation" Remove-Item HKLM:\SOFTWARE\Microsoft\CCM\BLM\Escrowed -Recurse -ErrorAction SilentlyContinue } # Execute Package/Program Try { $ReturnObj = New-Object System.Collections.ArrayList Write-Verbose "Connect CCM_BLM_KeyEscrow Class" $CCMBLMSDK = ([WMIClass]'root\ccm\clientsdk:CCM_BLM_KeyEscrow') Write-Verbose "Retrieving drive letter(s) of encrypted volumes" $EncryptedDrives = (([wmiclass]"ROOT\cimv2\Security\MicrosoftVolumeEncryption:Win32_EncryptableVolume").GetInstances() | Where-Object ProtectionStatus -EQ 1).DriveLetter # loop through all encrypted drives & escrow the recovery key foreach ($ed in $EncryptedDrives) { Write-Verbose "Execute EscrowKey-Method for drive $ed" $Escrow = $CCMBLMSDK.EscrowKey($ed) Write-Verbose "Fill up HashTable-Object with Information" $Input = @{ 'ReturnValue'= $Escrow.ReturnValue 'Escrowkey' = $Escrow.KeyID 'DriveLetter' = $ed } $InfoTable = New-Object PSObject -Property $Input [Void]$ReturnObj.Add($InfoTable) } Return $ReturnObj } Catch { Write-Host "Exception Type: $($_.Exception.GetType().FullName)" -ForegroundColor Red Write-Host "Exception Message: $($_.Exception.Message)" -ForegroundColor Red Write-Host "Exception Stack: $($_.ScriptStackTrace)" -ForegroundColor Red } } Invoke-CCMBitlockerEscrowKey -rotate -Verbose Step 1: Identify Co-Managed Devices In this migration scenario, we're working with Entra-Hybrid-Joined devices that are co-managed. First, set Endpoint Protection workload authority to Intune. Assign your devices to a staging collection. This will not immediately change BitLocker policies on the device — but prepares the system to receive policy from Intune. In this Registry-Area you can see the Windows Encryption Settings which are enforced: You'll also find the MBAM-Agent configurations here: You can verify workload authority using the CoManagementFlag via this PowerShell Function. The CoManagement Flag you get from the Configmgr-Control-Panel or the Registry: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\CCM\CoManagementFlags. You can also find this state in the SQL-View vClientCoManagementState. Function Get-CoMgmtClientFlag { [CmdletBinding()] Param ( [Parameter(Mandatory=$True)] [Int]$CoMgmtFlag ) $CoMgmtFlagsTable = @{ 'CompliancePolicy' = 2 'ConfigurationSettings' = 8 'Default' = 8193 'DiskEncryption' = 4096 'EpSplit' = 8192 'Inventory' = 1 'ModernApps' = 64 'None' = 0 'Office365' = 128 'ResourceAccess' = 4 'Security' = 32 'WUfB' = 16 } $FlagsObject = [ordered]@{} foreach ($FlagType in $CoMgmtFlagsTable.Keys) { if (($CoMgmtFlag -band $CoMgmtFlagsTable[$FlagType]) -ne 0) { $FlagsObject.Add($FlagType, $True) } } return $FlagsObject } Get-CoMgmtClientFlag -CoMgmtFlag 12527 Once the workload is set to Intune, Configuration Manager is no longer responsible for BitLocker. The original configuration item remains visible, but BitLockerManagementHandler will defer to Intune. Key Insight: Even if you decrypt the disk and reevaluate the BitLocker CI, ConfigMgr will report it as compliant—but it is no longer enforcing the settings. In the next step we will discuss the BitLocker Policy in Intune. In a Migration-Workflow, ensure you setup the same Encryption Policies as you did in your Configuration Manager Policies – with one exception Startup Pin. Intune does not require the MBAM-Agent to manage and control Disk-Encryption – the downside out of the Box you cannot configure a Silent/Unattended Encryption with a Startup PIN because no UI for a Standard User is provided. For Registry-Policies, you might want to deploy the Custom CSP MDMWinOverGPO. However, if you for instance, define a different Cipher-Strength you will always get a Non-Compliant-State. The Reason for such an activity it would be necessary to decrypt and encrypt the System again. Step 2: Create and Assign BitLocker Policy in Intune You can create BitLocker policies in Intune via: Endpoint Security > Disk Encryption Device Configuration Templates Settings Catalog Each has slightly different UI/UX and wording, so take care during setup. Recommendation: Use Endpoint Security > Disk Encryption—it maps directly to the Settings Catalog, and the UI enforces proper dependencies and validations. Example: Silent Encryption Configuration by Endpoint Security Disk Encryption Configure OS drive encryption settings, cipher strength, and recovery options. Assign the policy to a test group in Entra or your staged collection by Collection/Group Sync. Once assigned, the device will receive the policy via the MDM channel. You can verify this via the Windows Settings app or Registry: HKLM\SOFTWARE\Policies\Microsoft\FVE – As we can see now each Configuration Options now added to this space – which is difference to the Configuration Manager Policy item. HKLM\SOFTWARE\Microsoft\PolicyManager\current\device\BitLocker The PolicyManager is in general a good reference for tracking which provider is managing settings. Important: The KeyProtector RecoveryPassword will not automatically back up to Entra unless a new key protector is created and encryption is re-triggered. Step 3: Trigger Backup to Entra or Rotate Key To ensure key escrow to Entra: Option 1: Use Intune to Rotate BitLocker Key From Intune, trigger BitLocker Key Rotation for the device for ad hoc testing. Requires that Windows Recovery Environment (WinRE) is enabled. Windows Recovery Environment (Windows RE) | Microsoft Learn The Client will receive the Notification and execute the Rotation Successful Upload Event to Entra: Successful Upload Event to Active Directory Option 2: Use PowerShell Use the built-in PowerShell cmdlet to back up the recovery key manually. Ideal for scripting or proactive remediation: BackupToAAD-BitLockerKeyProtector BackupToAAD-BitLockerKeyProtector (BitLocker) | Microsoft Learn Here an example for this purpose: <# .Synopsis Backup Bitlocker Recovery Key to Entra .DESCRIPTION The Script will get all Volumes which have Bitlocker Protection On. For each of this Volumes we look for the RecoveryPassword KeyProtector. The ID of this KeyProtector is used to execute the BuiltIn-Cmdlet BackupToAAD-BitlockerRecoveryKey. The activities are added to a Hashtable for a Final Return to be displayed in Endpoint-Analytics. For Troubleshooting Write-Verbose Output can be called. .EXAMPLE BackupBitlockerKeyToEntra.ps1 -Verbose .REQUIREMENT The Script Execution requires Elevated Permissions #> [CmdletBinding()] Param() Try { Write-Verbose "Create empty Array-Object" $BLKeyObject = New-Object System.Collections.ArrayList Write-Verbose "Get all Volumes where Bitlocker Protection is on" $Volumes = Get-BitLockerVolume | where {$_.ProtectionStatus.value__ -eq 1} If ($Volumes -is [System.Object]) { Foreach ($Volume in $Volumes) { Write-Verbose "Get for Drive $($Volume.MountPoint) RecoveryPassword KeyProtector" $KeyProtector = (Get-BitLockerVolume -MountPoint $Volume.Mountpoint).KeyProtector | where {$_.KeyProtectorType -eq 'RecoveryPassword'} If ($KeyProtector) { Write-Verbose "Trigger Backup Bitlocker Recovery Key to Entra for Drive: $($Volume.MountPoint) with ID: $($KeyProtector.KeyProtectorId)" BackupToAAD-BitLockerKeyProtector -MountPoint $Volume.MountPoint -KeyProtectorId $KeyProtector.KeyProtectorId Write-Verbose "Prepare Return HashTable" $Input = @{ Drive = $Volume.MountPoint KeyProtector = $KeyProtector.KeyProtectorId BackupToEntra = $true } $ResultTable = New-Object PSObject -Property $Input [void]$BLKeyObject.Add($ResultTable) } } } Else { Write-Host "WARNING - The System does not have any Bitlocker Encrypted Drive!!!" Exit 1 } Write-Verbose "Backup-Execution successful" Return $BLKeyObject } Catch { Write-Error $_ } Note: In hybrid scenarios, keys may be escrowed to both AD and Entra. If Entra is unavailable during encryption and you've set "Do not enable BitLocker until recovery information is stored to AD DS...", the key will be escrowed to AD only. Recommendation: Use a Proactive Remediation Script to periodically validate and enforce Entra key escrow. You can safely run BackupToAAD-BitLockerKeyProtector multiple times without issues. You can verify backup locations using: manage-bde -protectors -get C -type RecoveryPassword Step 4: Test a Fresh Encryption Cycle To confirm full Intune-based encryption and key escrow: Confirm Policies are applied Decrypt the Volume Remove all key protectors Trigger an Intune policy sync Confirm silent encryption with proper key backup Tip: You can test this with a Generation 2 VM with a virtual TPM. Key Takeaways Ensure BitLocker workload is shifted to Intune before key migration. Match Intune Configuration Profile with existing Configuration Manager Policies – otherwise you get Non-Compliance Messages (Note that Bitlocker-PreProvisioning in a TaskSequences, implies Used Space Encryption) Use key rotation or PowerShell scripts to escrow keys to Entra. Hybrid-joined devices may escrow to both AD and Entra (this is by Design, there is no option to configure only Entra) Confirm encryption compliance locally via Settings app, Registry, and manage-bde.exe – or use the Intune Reports Consider a proactive remediation script to ensure consistent key backup. Intune does not offer RBAC for viewing recovery keys. Show BitLocker-Recovery-Key is an Entra-Permission Device management permissions for Microsoft Entra custom roles - Microsoft Entra ID | Microsoft Learn Thanks for reading! Let me know your feedback or share your own tips and tricks for BitLocker migration from ConfigMgr to Intune! Disclaimer The sample scripts are not supported under any Microsoft standard support program or service. The sample scripts are provided AS IS without warranty of any kind. Microsoft further disclaims all implied warranties including, without limitation, any implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample scripts and documentation remains with you. In no event shall Microsoft, its authors, or anyone else involved in the creation, production, or delivery of the scripts be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample scripts or documentation, even if Microsoft has been advised of the possibility of such damages.
