Modernizing BitLocker Key Management: A Strategic Shift from ConfigMgr to Intune

As businesses move toward modern endpoint management, transitioning BitLocker key handling from Configuration Manager (ConfigMgr) to Microsoft Intune is more than a technical change—it’s a strategic evolution. This is especially crucial for organizations with hybrid, co-managed devices joined to Microsoft Entra ID.

This guide doesn’t just explain what to do—it walks you through how to do it right. With a hands-on, scenario-driven approach, it addresses the realities of managing already encrypted devices and ensures business continuity throughout the migration.

For years, enterprises have relied on MBAM or ConfigMgr to oversee BitLocker encryption and recovery keys. But with the rise of cloud-first IT strategies, Intune introduces a simpler, more secure alternative—built directly into the Microsoft ecosystem and natively integrated with Entra ID (formerly Azure AD).

Migrating isn’t a matter of flipping a switch. It’s a process that demands foresight: preserving access to recovery keys, maintaining encryption status, and keeping compliance intact. This resource was crafted with those challenges in mind, guiding you step by step through a hybrid co-managed environment.

Legacy Meets Cloud: Understanding Your Starting Point

If you’re still using ConfigMgr’s BitLocker Management—powered by the MBAM agent—you’re not alone. Whether you’re running MBAM standalone or leveraging ConfigMgr’s built-in features, this guide helps you assess your current setup, map your migration path, and make the move to a future-ready BitLocker solution.

BitLocker Key Management in Action: From Policy to Proof

A Modern Take on BitLocker with ConfigMgr

In a ConfigMgr-managed environment, BitLocker isn’t just flipped on—it’s orchestrated. Here’s how encryption gets enforced and tracked:

1. Deploy the Policy, Define the Rules

Everything starts with a tailored encryption policy, scoped to a device collection. This policy governs the essentials—cipher strength, key protector options (like TPM and recovery password), and where recovery keys should be stored.

2. Kick Off Encryption

Once the policy lands, the MBAM Agent gets to work:

• It enables BitLocker,
• Generates protectors,
• Locks down the TPM, and
• Sends recovery keys to your configured backend—ConfigMgr’s database or Active Directory.

3. Track and Troubleshoot

Visibility is built-in. You can confirm encryption status and key escrow using tools like:

• manage-bde
• PowerShell cmdlets (Get-BitLockerVolume)
• MBAM Helpdesk Portal
  ConfigMgr also logs key lifecycle events via BitLocker’s API, offering a clear view of what’s happening and when.

---

How to Check If BitLocker’s Doing Its Job

Need to verify encryption or confirm recovery key escrow? Here’s your toolkit:

Via PowerShell:

Get-BitLockerVolume

Via manage-bde:

Powershell

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

Check the Registry (Escrow Timestamp):

BitLocker escrow timing is logged under the hood in UNIX format:

Powershell

$LastEscrowTime = Get-ItemPropertyValue HKLM:\SOFTWARE\Microsoft\CCM\BLM -Name ‘LastEscrowTime’

Testing Key Escrow in MECM 2203+ Environments

Running MECM 2203 or later? You can trigger escrow or rotate keys using a custom PowerShell function built on the local client API.

Escrow Trigger Script (With Optional Rotation):

Powershell

Invoke-CCMBitlockerEscrowKey -rotate -Verbose

This script:

• Verifies that the ConfigMgr agent version is current,
• Clears existing escrow keys (if -rotate is used),
• Calls the local WMI API to escrow fresh keys for all encrypted volumes,
• Returns success status and drive-level escrow data.

Behind the scenes, it connects to the CCM_BLM_KeyEscrow WMI class and executes key escrow per drive—secure, automated, and traceable.

---

Before You Start: Know Your Hybrid Footprint

BitLocker migration planning starts with knowing your device posture. If your environment includes Entra-Hybrid-Joined, co-managed devices, make sure you shift the Endpoint Protection workload to Intune. That handoff allows Intune to take the lead on BitLocker moving forward—while ConfigMgr gracefully steps back.

Step 1: Shift Control – Hand Off BitLocker to Intune

To begin managing BitLocker through Intune instead of ConfigMgr, you’ll need to redirect authority. But don’t worry—it’s not a rip-and-replace. You can stage the transition safely and gradually.

🔧 Redirect the Workload

In the ConfigMgr console:

• Go to Administration → Cloud Services → Co-management
• Slide the Endpoint Protection workload over to Intune

This sets Intune as the new policy engine for disk encryption. No policies are applied immediately—this just preps the environment for the next step.

🧪 Stage Devices Safely

Assign target devices to a staging collection. This lets them receive Intune policies without disrupting existing encryption configurations right away—ideal for testing and phased rollouts.

---

Step 2: Confirm Co-Management Status Like a Pro

Before handing over encryption control, confirm that your devices are truly co-managed.

🔍 Check Co-Management Locally or Remotely

• Registry:

Plaintext

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\CCM\CoManagementFlags

SQL View (for admins):
vClientCoManagementState

PowerShell Decoder:
Use this script to interpret what the CoManagementFlags value actually means:

Powershell

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

💡 Heads-Up: What Happens Behind the Scenes

Once you shift BitLocker management to Intune:

• ConfigMgr stops enforcing encryption policies
• However, its BitLocker configuration item may still appear compliant
• If you decrypt and re-evaluate the ConfigMgr BitLocker CI, it will still report success—even though it’s no longer in control

Translation: Visual indicators in ConfigMgr may not reflect the real management authority.

---

Step 3: Deploy BitLocker Policy via Intune

Now it’s time to create your Intune BitLocker policy.

✅ Match Your Legacy Settings

Recreate encryption settings that mirror your ConfigMgr policies. This prevents unnecessary re-encryption or compliance drift.

🚫 Understand Intune’s Boundaries

While Intune offers streamlined cloud management:

• No MBAM Agent is required
• But… features like silent encryption with startup PINs aren’t fully supported, due to the lack of native UI for standard users

That’s not a blocker, but it’s critical to know what to expect during rollout—especially in user-interactive scenarios.

Creating the Policy

Modernizing BitLocker Policy Deployment with Intune: A Smarter Approach

Shifting BitLocker management to Intune is a key move in any cloud-first strategy. But how you build and apply those policies determines whether the transition is seamless—or disruptive.

---

🔧 Step 1: Choose the Right Policy Method (The Smart Way)

Intune offers three ways to configure BitLocker, but not all are created equal:

• Endpoint Security → Disk Encryption
  ✔ Best choice. Direct, validated, and purpose-built for encryption workflows.
• Settings Catalog
  ⚙ Power and granularity, but lacks guided structure—dependencies must be set manually.
• Device Configuration Templates
  🧩 Wizard-driven, but limited flexibility and falling out of favor.

Recommendation: Use Endpoint Security → Disk Encryption. It’s reliable, intuitive, and reduces policy conflicts.

---

🛠 Step 2: Configure the Policy (Mirror What Works)

To prevent re-encryption or non-compliance, match your existing ConfigMgr settings:

• Encrypt OS Drive – Enable drive protection.
• Cipher Strength – Keep consistent (AES-128 or AES-256).
• Key Protectors – Choose TPM, recovery password, or both.
• Recovery Key Storage – Escrow to Entra ID (formerly Azure AD).
• Silent Encryption – Enable for userless rollout (hardware must support it).

⚠ Tip: Changing cipher strength post-encryption will force decryption + re-encryption.

To override local GPOs, deploy the MDMWinOverGPO CSP to prioritize Intune policy enforcement.

---

🚀 Step 3: Apply and Monitor the Policy

Roll out the policy to a test group—either in Entra ID or via a synced ConfigMgr staging collection.

🔎 Verify Deployment

• Windows Settings App: Settings → Privacy & Security → Device Encryption
• Registry Paths:
  • HKLM\SOFTWARE\Policies\Microsoft\FVE
  • HKLM\SOFTWARE\Microsoft\PolicyManager\current\device\BitLocker

🧠 Heads-up: Intune does not automatically back up existing keys. You’ll need to rotate or re-trigger key generation.

---

🔁 Step 4: Escrow Existing Keys to Entra ID

To get your keys backed up to Entra ID, choose between automation or manual execution.

✅ Option 1: Rotate via Intune

• Go to Intune → Devices → Windows → Select Device → BitLocker Key Rotation
• Rotation triggers a new key backup (requires WinRE to be enabled)

💻 Option 2: Use PowerShell

Automate backups with this script:

Powershell

Backup all RecoveryPassword KeyProtectors to Entra ID

$Volumes = Get-BitLockerVolume | Where-Object { $_.ProtectionStatus -eq ‘On’ }
foreach ($v in $Volumes) {
$kp = $v.KeyProtector | Where-Object { $_.KeyProtectorType -eq ‘RecoveryPassword’ }
if ($kp) {
BackupToAAD-BitLockerKeyProtector -MountPoint $v.MountPoint -KeyProtectorId $kp.KeyProtectorId
}
}

🔐 Safe to run repeatedly—no duplication, no error if already escrowed.

---

🧪 Step 5: Validate a Clean Encryption Cycle

Use a VM (e.g., Gen 2 with vTPM) to simulate the full lifecycle:

1. Decrypt: manage-bde -off C:
2. Remove Old Keys: manage-bde -protectors -delete C:
3. Reapply Policy: Run dsregcmd /refresh or sync from Intune
4. Verify Encryption:
   • manage-bde -status
   • manage-bde -protectors -get C:
   • Check Intune reports for compliance & key escrow

---

📌 Best Practices to Keep You in Control

• Workload Transition First: Don’t move keys until Intune owns the BitLocker workload.
• Policy Alignment: Match settings precisely between ConfigMgr and Intune to avoid drift.
• Understand Escrow Behavior: Hybrid devices might escrow keys to both AD and Entra ID.
• Visibility: Use registry and manage-bde for transparent status checks.
• Ongoing Validation: Deploy a Proactive Remediation script to enforce key escrow regularly.
• Access Control: Viewing recovery keys requires Entra ID roles—RBAC in Intune won’t apply.

---

🎯 Final Thoughts

Moving BitLocker key management to Intune isn’t just a checkbox—it’s an opportunity to streamline your encryption posture for a modern, cloud-first world. With the right prep, automation, and validation, your organization can make the leap smoothly—and securely.