As organizations transition to modern management with Microsoft Intune, migrating BitLocker recovery key management from Configuration Manager (ConfigMgr) to Intune is a critical step, especially in hybrid scenarios with co-managed, Entra-Hybrid-Joined devices.

This in-depth guide provides a practical, step-by-step approach to ensure a seamless migration, focusing on real-world considerations for already encrypted devices.

BitLocker, Microsoft’s disk encryption technology, is widely used to secure corporate devices. Traditionally, Configuration Manager (ConfigMgr) with its BitLocker Management feature or the Microsoft BitLocker Administration and Monitoring (MBAM) solution has been the go-to for managing encryption and recovery keys.

However, with the shift to cloud-based management, Intune offers a streamlined, modern approach to BitLocker management, integrating recovery key escrow with Microsoft Entra ID (formerly Azure AD).

Migrating from ConfigMgr to Intune is not just about enabling a new policy it requires careful planning to ensure existing encrypted devices continue to function, recovery keys are properly escrowed, and compliance is maintained.

According to the this Microsoft guide assumes you’re working in a hybrid environment with co-managed devices and focuses on practical steps for a successful transition.

Understanding the Current Setup: ConfigMgr BitLocker Management

In a typical ConfigMgr environment, BitLocker encryption and key management are handled through the MBAM Agent Service, either via MBAM Standalone or ConfigMgr’s integrated BitLocker Management feature.

Here’s How it Works:

Policy Configuration: A BitLocker policy is created in ConfigMgr and assigned to a device collection. The policy defines encryption settings, such as cipher strength, key protectors (e.g., TPM, recovery password), and escrow requirements.
Encryption Process: Once the policy is applied, the MBAM Agent Service initiates encryption, creates key protectors, seals the TPM, and escrows the recovery key to the ConfigMgr database or Active Directory (AD).
Monitoring: Encryption status can be verified using tools like manage-bde.exe, PowerShell, or the MBAM Helpdesk Portal. ConfigMgr logs BitLocker API events, such as key protector creation and encryption initiation.

Verifying Encryption Status

To check the encryption status and recovery key details, use the following methods:

PowerShell:powershellGet-BitLockerVolume

manage-bde:powershellmanage-bde -status manage-bde -protectors -get C: -type RecoveryPassword

Registry Check for Escrow Time: ConfigMgr stores escrow details in the registry in UNIX DateTime format.

Convert it using: powershell$LastEscrowTime = Get-ItemPropertyValue HKLM:\SOFTWARE\Microsoft\CCM\BLM -Name 'LastEscrowTime' $oUNIXDate = [System.DateTimeOffset]::FromUnixTimeSeconds($LastEscrowTime) $oUNIXDate

Testing Key Escrow in ConfigMgr (MECM 2203 or Higher)

For environments running Microsoft Endpoint Configuration Manager (MECM) version 2203 or later, you can test key escrow and rotation using a local API. Below is a PowerShell function to trigger escrow or rotate keys:

powershell

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) {
        Write-Verbose "Removing HKLM\SOFTWARE\Microsoft\CCM\BLM\Escrowed key to force key rotation"
        Remove-Item HKLM:\SOFTWARE\Microsoft\CCM\BLM\Escrowed -Recurse -ErrorAction SilentlyContinue
    }

    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

        foreach ($ed in $EncryptedDrives) {
            Write-Verbose "Execute EscrowKey-Method for drive $ed"
            $Escrow = $CCMBLMSDK.EscrowKey($ed)
            $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

This script ensures the client version supports the API, optionally rotates the key by clearing the escrowed reference, and escrows recovery keys for all encrypted drives.

Step 1: Identify and Prepare Co-Managed Devices

In a hybrid environment, devices are typically Entra-Hybrid-Joined and co-managed, meaning both ConfigMgr and Intune manage different workloads. To migrate BitLocker management, you must shift the Endpoint Protection workload to Intune.

Set Workload Authority:

In ConfigMgr, navigate to Administration > Cloud Services > Co-management and slide the Endpoint Protection workload to Intune.

Assign devices to a staging collection to receive Intune policies without immediately altering existing BitLocker settings.

Verify Co-Management Status:

Check the co-management state using the ConfigMgr Control Panel, registry, or SQL view:

Registry: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\CCM\CoManagementFlags

SQL View: vClientCoManagementState

Use the following PowerShell function to decode the CoManagementFlag:powershellFunction 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

Key Insight: Once the workload is shifted to Intune, ConfigMgr stops enforcing BitLocker policies. The ConfigMgr BitLocker configuration item may still appear compliant, but it no longer controls encryption settings. If you decrypt and reevaluate the BitLocker CI, ConfigMgr will report compliance without enforcing settings.

Step 2: Create and Assign BitLocker Policy in Intune

To manage BitLocker in Intune, you need to create a policy that matches your existing ConfigMgr settings to avoid non-compliance or re-encryption.

Intune does not require the MBAM Agent, but it has limitations, such as no support for silent encryption with a startup PIN due to the lack of a standard user UI.

Creating the Policy

You can create BitLocker policies in Intune via three methods:

Endpoint Security > Disk Encryption: Recommended for its direct mapping to the Settings Catalog and robust UI validations.
Device Configuration Templates: Offers a wizard-based approach but may lack some flexibility.
Settings Catalog: Provides granular control but requires manual dependency configuration.

Recommendation: Use Endpoint Security > Disk Encryption for its simplicity and reliability.

Policy Configuration

Configure the following settings to match your ConfigMgr policy:

OS Drive Encryption: Enable encryption for the operating system drive.
Cipher Strength: Ensure the cipher (e.g., AES-128 or AES-256) matches ConfigMgr settings to avoid re-encryption.
Key Protectors: Enable TPM, recovery password, or other protectors as needed.
Recovery Options: Require recovery key escrow to Entra ID.
Silent Encryption: Enable for unattended encryption (requires compatible hardware and settings).

Note: If you define a different cipher strength, devices may become non-compliant, requiring decryption and re-encryption. To enforce registry-based policies, deploy the MDMWinOverGPO custom CSP to prioritize Intune settings.

Assigning the Policy

Assign the policy to a test group in Entra ID or sync it to your staged ConfigMgr collection. Verify policy application via:

Windows Settings App: Check encryption status under Settings > Privacy & Security > Device Encryption.
Registry:
- HKLM\SOFTWARE\Policies\Microsoft\FVE: Contains Intune-applied BitLocker settings.
- HKLM\SOFTWARE\Microsoft\PolicyManager\current\device\BitLocker: Tracks the managing provider.

Important: Existing recovery keys won’t automatically back up to Entra ID unless a new key protector is created or encryption is re-triggered.

Step 3: Trigger Key Backup to Entra ID or Rotate Keys

To escrow existing recovery keys to Entra ID, you have two options: key rotation via Intune or manual backup using PowerShell.

Option 1: Rotate BitLocker Key via Intune

In Intune, navigate to Devices > Windows > select device > BitLocker Key Rotation.
Trigger the rotation for ad hoc testing.
Ensure the Windows Recovery Environment (WinRE) is enabled, as it’s required for key rotation. Learn more: Windows Recovery Environment (WinRE).

Verification:

Check for a successful upload event in Entra ID or AD.
Use manage-bde -protectors -get C: -type RecoveryPassword to confirm the new key.

Option 2: Use PowerShell for Manual Backup

The BackupToAAD-BitLockerKeyProtector cmdlet allows you to back up recovery keys to Entra ID. Below is a sample script for automation:

powershell

<#
.Synopsis
   Backup BitLocker Recovery Key to Entra ID
.DESCRIPTION
   Retrieves all BitLocker-protected volumes, identifies RecoveryPassword KeyProtectors, and backs up their keys to Entra ID.
.EXAMPLE
   .\BackupBitlockerKeyToEntra.ps1 -Verbose
.REQUIREMENT
   Requires elevated permissions
#>
[CmdletBinding()]
Param()

Try {
    Write-Verbose "Create empty Array-object"
    $BLKeyObject = New-Object System.Collections.ArrayList

    Write-Verbose "Get all volumes with BitLocker protection"
    $Volumes = Get-BitLockerVolume | Where-Object {$_.ProtectionStatus.value__ -eq 1}

    If ($Volumes) {
        Foreach ($Volume in $Volumes) {
            Write-Verbose "Get RecoveryPassword KeyProtector for drive $($Volume.MountPoint)"
            $KeyProtector = (Get-BitLockerVolume -MountPoint $Volume.Mountpoint).KeyProtector | Where-Object {$_.KeyProtectorType -eq 'RecoveryPassword'}

            If ($KeyProtector) {
                Write-Verbose "Trigger backup to Entra ID 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 drives!"
        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 ID. If Entra ID is unavailable and the policy requires AD escrow, keys will only be stored in AD.

Recommendation: Deploy a Proactive Remediation Script in Intune to periodically validate and enforce Entra ID key escrow. The BackupToAAD-BitLockerKeyProtector cmdlet can be safely run multiple times without issues.

Step 4: Test a Fresh Encryption Cycle

To validate Intune’s ability to manage BitLocker and escrow keys, perform a full encryption cycle on a test device (e.g., a Generation 2 VM with a virtual TPM):

Confirm Policy Application: Verify that the Intune BitLocker policy is applied via the registry or Settings app.
Decrypt the Volume: Use manage-bde -off C: to decrypt the drive.
Remove Key Protectors: Clear existing protectors with manage-bde -protectors -delete C: -type RecoveryPassword.
Trigger Intune Sync: Run dsregcmd /refresh or sync from Intune to apply the policy.
Verify Silent Encryption: Confirm encryption occurs without user interaction and the recovery key is escrowed to Entra ID.

Verification:

Check encryption status: manage-bde -status.
Confirm key escrow: manage-bde -protectors -get C: -type RecoveryPassword.
Review Intune reports for compliance.

Key Takeaways and Best Practices

Workload Transition: Shift the Endpoint Protection workload to Intune before migrating keys to avoid conflicts.
Policy Alignment: Match Intune BitLocker settings with ConfigMgr to prevent non-compliance or re-encryption. Note that Intune does not support silent encryption with a startup PIN out of the box.
Key Escrow: Use Intune key rotation or PowerShell scripts to back up keys to Entra ID. Hybrid-joined devices may escrow keys to both AD and Entra ID by design.
Verification: Monitor encryption status and key escrow using manage-bde, registry checks, or Intune reports.
Proactive Remediation: Deploy scripts to periodically validate Entra ID key escrow for ongoing compliance.
Permissions: Intune does not offer role-based access control (RBAC) for viewing recovery keys. The Show BitLocker-Recovery-Key permission in Entra ID is required. Learn more: Microsoft Entra Custom Roles.
Testing: Use a virtual machine to simulate encryption cycles and validate Intune’s behavior.

Migrating BitLocker recovery key management from ConfigMgr to Intune in a hybrid environment requires careful planning and execution. By shifting the Endpoint Protection workload, aligning policies, and using tools like key rotation and PowerShell scripts, you can ensure a smooth transition with minimal disruption. Regular validation through proactive remediation and thorough testing will help maintain compliance and security.

The post Microsoft Published a Practical Guide for Migrating BitLocker Recovery Key Management From ConfigMgr to Intune appeared first on Cyber Security News.