The CrowdStrike crash showed why BitLocker recovery keys matter

Friday, July 19, 2024, is a day every Microsoft 365 admin I know will remember. A faulty CrowdStrike Falcon sensor update took down millions of Windows devices worldwide, an estimated 8.5 million according to Microsoft. I saw it up close: blue screens everywhere, devices stuck in boot loops, support lines completely overloaded. BitLocker made things harder still. The fix meant booting into Safe Mode or WinRE and deleting the faulty driver, and on an encrypted drive you couldn't get that far without the BitLocker recovery key. For thousands of organizations, “Where are our recovery keys, actually?” stopped being a theoretical question overnight.

BitLocker recovery keys live in Intune, Entra ID or on-prem AD

Most modern Microsoft 365 environments manage devices through Intune, Microsoft Entra ID (formerly Azure AD) or a hybrid setup with on-premises Active Directory. In theory, the BitLocker recovery keys are escrowed centrally. In the tenants I review, that is rarely the full picture. For Intune-managed devices, the recovery keys sit in the Intune admin center under Devices → device → Recovery keys. In the Microsoft Entra admin center (see the official docs), the path is Devices → All devices → device → BitLocker keys. Hybrid devices may have their keys in on-prem AD (the msFVE-RecoveryInformation attribute).

A policy that requires escrow doesn't guarantee that every key was actually stored, though. The Intune encryption monitoring report is very useful for finding the gaps: Intune admin center → Devices → Monitor → Encryption report shows which devices are encrypted and whether a key is available. In tenants that have grown over the years or combine several management approaches, I find gaps regularly, sometimes on critical endpoints.

Read access to recovery keys needs active governance

A BitLocker recovery key works like a master key. Whoever has it can decrypt the device, no matter what other protections are in place. That makes this an access governance question as much as a technical one. In Microsoft Entra ID, roles such as Cloud Device Administrator and Helpdesk Administrator can read recovery keys by default (check the role documentation). In Intune, any role with "Read BitLocker keys" permissions has access, and that frequently includes the general helpdesk. On-prem AD needs more granular delegation, but it matters just as much.

Practical tip: Review access to BitLocker recovery keys at least quarterly. Check who has it, who should have it and who no longer needs it. Dynamic groups help, but in larger organizations nothing replaces a periodic manual review.

Don't forget monitoring either. Logging who accesses keys and for which devices is an important detective security control, and a clean audit trail can turn out to be decisive.

Many devices never escrowed their recovery key

The CrowdStrike incident showed very plainly how far policy and reality can drift apart. In most tenants I've looked at, a non-trivial number of devices have BitLocker enabled but no recovery key escrowed in Entra, Intune or AD. Devices older than the cloud management setup, manually imaged machines and BYOD endpoints all feed this shadow IT. Even where the intentions were good, I've watched devices slip through because of migration glitches or loosely enforced policies.

The encryption monitoring report in Intune surfaces devices with missing keys quickly. In larger environments you may want a check you can script. With PowerShell 7 and the Microsoft.Graph.DeviceManagement module (plus an app registration with DeviceManagementManagedDevices.Read.All permissions), this lists devices without encryption state:

# Prerequisites: Microsoft.Graph.DeviceManagement module, app registration with DeviceManagementManagedDevices.Read.All
Connect-MgGraph -Scopes "DeviceManagementManagedDevices.Read.All"
Get-MgDeviceManagementManagedDevice -Filter "encryptionState ne 'encrypted'"

If you still rely on users to print or save their own keys, or you're counting on on-prem AD to fill the gaps, your onboarding checklists probably need another look.

Microsoft’s USB recovery tool still depends on the recovery key

Microsoft quickly released a USB-based recovery tool, and it helped many admins remove the faulty Falcon sensor. On encrypted drives, though, the BitLocker recovery key was still a hard requirement. The tool can't bypass encryption, and it shouldn't be able to. Traffic to the BitLocker recovery overview page jumped, which makes sense. Without access to the recovery key, no tool will get you back online.

Tooling is only part of it, and the bigger organizational lesson is about process. Too many teams had no current, offline-accessible list of recovery keys for critical endpoints such as DCs, management workstations or infrastructure nodes. Others lost valuable time working out which devices were business-critical and who should be recovered first. A simple prioritized list with device names, owners and (where policy allows) recovery IDs can be the difference between a one-hour outage and an incident that drags on for days.

Here is a simple diagram of the typical BitLocker recovery process from a support perspective:

flowchart TD
  User["User starts recovery"] --> IT["IT receives request"]
  IT --> Portal["Recovery key portal (Entra/Intune/AD)"]
  Portal --> Key["Fetch recovery key"]
  Key --> User["User enters key"]

Figure: Typical BitLocker recovery flow as seen by IT support.

I see no room left for wishful thinking about recovery keys

The CrowdStrike crash made it painfully obvious that managing BitLocker centrally isn't enough. You have to check regularly that every relevant device has its recovery key escrowed and that authorized staff can retrieve it fast enough when things go wrong. This goes well beyond the helpdesk. It tests how resilient your organization really is, and it belongs in your business continuity playbook.

If you haven't looked at your BitLocker recovery setup since the crash, do it now. Don't wait for the next large-scale outage to show you which devices you can't recover. Put recovery key coverage, access and audit on your IT governance calendar as a standing item. The next crisis won't wait for your policies to catch up, and as last week showed, your users won't either.