Michael Narehood
BitLocker without escrowed recovery keys is encryption that locks you out. Users forget PINs, TPMs glitch after firmware updates, and motherboards get replaced. When that happens, the recovery key is the difference between a ten-minute unlock and a destructive reimage with data loss.
The rule is simple: every protected volume needs a recovery key stored somewhere your authorized IT staff can reach — and nowhere else.
1. Pick one primary escrow destination
For Microsoft-centric SMBs, the default answer is Entra ID (Azure AD):
- Keys upload automatically when BitLocker is deployed through Intune
- Retrieval is role-controlled and audited in the portal
- Keys follow the device lifecycle — less “where did we save that?” when hardware churns
Acceptable alternatives when Entra is not in play:
- On-prem Active Directory (classic GPO + BitLocker escrow) for hybrid shops that still live there
- MBAM if you already run it — do not add MBAM solely for five laptops
Unacceptable primary stores:
- The user’s personal OneDrive folder with no IT access
- A email thread titled “BitLocker keys”
- A USB stick in someone’s desk drawer labeled “DO NOT LOSE”
2. Deploy BitLocker through policy, not hand-checks
Manual “turn on BitLocker” visits do not scale and they skip escrow half the time.
- Create an Intune disk encryption policy (or Endpoint security profile) requiring BitLocker on fixed drives
- Enable Save BitLocker recovery information to Azure AD
- Require encryption before the device is considered compliant (if you use compliance policies)
- Assign to pilot devices, then broaden
For existing encrypted machines, run a compliance report before you assume keys exist. “BitLocker on” in the status tray does not mean escrow succeeded.
3. Retrieve and test recovery before you need it
Quarterly, pick one non-critical laptop and walk through recovery:
- Entra admin center → Devices → select device → BitLocker keys
- Or Intune → Devices → device → Recovery keys
- Confirm the key unlocks the volume from the BitLocker recovery screen
Log who retrieved keys and why. If retrieval requires Global Admin every time, fix role assignments — help desk should not need god-mode for a forgotten PIN.
4. Handle the edge cases on purpose
Shared workstations — decide whether one escrowed key per device is enough (usually yes) or whether you need documented break-glass access separate from user PINs.
External drives — company data on removable media needs the same discipline. User-managed BitLocker on a portable drive without escrow is a recurring data-loss story.
Decommissioning — when a device leaves the fleet, rotate or retire keys as part of wipe/disposal. Old keys on retired hardware are an unnecessary artifact.
Non-Windows volumes — FileVault and Linux LUKS need their own escrow story. Do not pretend BitLocker policy covers the whole fleet.
5. Write the one-page user script
Users only need three lines:
- Your PIN is personal; do not share it
- If BitLocker asks for a recovery key, call IT — do not guess
- IT will retrieve the escrowed key; you will not find it in your email
Confusion at the blue recovery screen causes panic reboots that make things worse.
Bottom line
BitLocker recovery keys belong in Entra ID for Intune-managed Windows fleets — deployed by policy, verified on a schedule, and retrieved through audited roles. Skip the spreadsheet, test recovery before someone’s PIN fails on a Monday, and treat external drives as first-class citizens in the same plan.