Escaping the Encryption Trap: The Entra ID Escrow Audit

PowerShell BitLocker BackupToAAD & Entra ID Recovery Key Escrow Audit Guide

4 min. read

The Ticket: The "Where is the Key?" Nightmare

A VIP client spills coffee entirely across their laptop keyboard. The motherboard is completely fried, but the M.2 storage drive looks physically intact. Your Tier 1 tech pulls the drive, puts it into a USB enclosure, and logs into the Entra ID portal to grab the 48 digit BitLocker recovery key.

They locate the device object, click on the BitLocker section, and stare in horror. It is completely blank. The Intune dashboard showed this laptop as 100% compliant and encrypted just yesterday, but the recovery key never actually synced to the cloud. Because the drive is encrypted and the key is missing, that data is now officially vaporized. We need a script to force every machine in the fleet to escrow its key immediately, along with a way to verify the upload actually worked.

Pre-Flight Check

• Permissions: Local Administrator rights.
• Tools: PowerShell 5.1+ and an active Entra ID device registration.
• Impact: High data protection value, zero disruption to the end user.

[!WARNING] The Risk Factor: Escrowing a key does not encrypt an unencrypted drive. This script only works if the drive is already encrypted and has a numerical recovery password generated. If the drive only relies on the hardware TPM chip and lacks a numerical password, the script will fail because there is nothing to upload.

The Solution: The Escrow Force Sync

We are going to use PowerShell to grab the unique ID of the local recovery password and force Windows to push it directly to the Azure Device Registration Service. Then, we will query the local Event Log to prove the transaction was successful.

Save this as a .ps1 file or run it through your RMM platform:

PowerShell

# *** 404 & More: Entra ID Escrow Force Sync ***

# 1. Find the local Numerical Recovery Password ID
$BitLocker = Get-BitLockerVolume -MountPoint "C:"
$RecoveryProtector = $BitLocker.KeyProtector | Where-Object { $_.KeyProtectorType -eq "RecoveryPassword" }

if ($RecoveryProtector) {
    Write-Host "Found Recovery Password. Pushing to Entra ID..."
    
    # 2. Force the upload to the cloud
    BackupToAAD-BitLockerKeyProtector -MountPoint "C:" -KeyProtectorId $RecoveryProtector.KeyProtectorId
    
    # 3. Verify the escrow was successful via Event ID 845
    Start-Sleep -Seconds 2
    $Verify = Get-WinEvent -LogName "System" -MaxEvents 50 -ErrorAction SilentlyContinue | 
              Where-Object { $_.Id -eq 845 -and $_.ProviderName -eq "Microsoft-Windows-BitLocker-Driver" }
              
    if ($Verify) {
        Write-Host "SUCCESS: BitLocker key confirmed escrowed to Entra ID." -ForegroundColor Green
    } else {
        Write-Host "WARNING: The backup command ran, but the success event (845) was not found." -ForegroundColor Yellow
    }
} else {
    Write-Host "CRITICAL: No 48-digit numerical recovery password found on this drive." -ForegroundColor Red
}

The "Why" (Root Cause)

How does a drive get encrypted without saving the key? When a user signs into a brand new Windows 11 Pro laptop with their Microsoft 365 account, Windows triggers a feature called "Silent Encryption". It automatically starts encrypting the drive in the background to protect the user.

However, if the Wi-Fi drops for a microsecond during that initial out of box setup, or if a third party antivirus blocks the background API call, the key fails to upload to Microsoft. Windows does not care. It just keeps running happily encrypted. Intune queries the machine, sees that BitLocker is turned on, and marks it as compliant. You never realize the key is missing until the motherboard dies.

Under the Hood (Technical Deep Dive)

The BackupToAAD-BitLockerKeyProtector cmdlet relies entirely on the primary Refresh Token of the device itself, rather than the user who is logged in.

When you execute the command, the BitLocker API packages the numerical password and sends an authenticated POST request to the Entra ID graph endpoint. If the device object in Entra is corrupted, deleted, or if the laptop was never properly joined to the tenant, this API call will fail with a generic COM error. The secondary verification step in our script is crucial because it hunts for Event ID 845 in the System log. Event ID 845 is hardcoded into the Windows kernel to only trigger when the Microsoft cloud explicitly sends back a "200 OK" receipt confirming the key was securely written to the database.

RMM & Automation Tips

• The Missing Protector Fix: If the script throws the red critical error stating no numerical password was found, you can easily automate the fix. Have your RMM execute Add-BitLockerKeyProtector -MountPoint "C:" -RecoveryPasswordProtector first. This forces Windows to generate a brand new 48 digit string, which you can then immediately escrow using the primary script.
• Onboarding Baseline: Never assume a new client environment is fully protected. Set this script to run automatically on every single machine during your initial RMM onboarding phase.

Troubleshooting & Edge Cases

• Edge Case 1: The Hybrid AD Trap. If the device is Hybrid Azure AD joined, the cmdlet might get confused and try to push the key to your local on-premise Active Directory instead of Entra ID. You need to ensure the Group Policy setting "Save BitLocker recovery information to Azure Active Directory" is explicitly enabled in your domain controllers to force the cloud routing.
• Edge Case 2: Duplicate Keys in the Portal. If you run this script multiple times, or if you generate new keys without deleting the old ones, you will see multiple 48 digit passwords listed under the device in Entra ID. Always look at the "Key ID" column in the portal and match it to the Key ID displayed on the physical laptop's blue recovery screen to ensure you are typing in the correct active password.

If you want to see more guides, scripts, and technical deep dives just like this, make sure to follow us on Twitter, check out our Facebook page, and sign up for the weekly 404 & More newsletter! ✌️