BitLocker only protects a lost or stolen Windows device if the right key protectors are in place and every recovery key is escrowed somewhere the organisation can reach, audit and rotate. Most BitLocker trouble in practice is not the encryption itself but the recovery key: users locked out after a firmware update, help desks hunting for a 48 digit password, keys sitting in old AD DS objects nobody reviews. This guide goes deeper than our cross-platform overview and covers BitLocker specifically: TPM only, TPM and PIN and Network Unlock, escrow to Microsoft Entra ID and Active Directory Domain Services, who can read recovery keys, recovery and rotation at scale, Intune policy settings and the physical attack scenarios Microsoft documents. It is written for Windows endpoint engineers, identity administrators and service desk leads. For the platform neutral view, see the Disk Encryption Guide: BitLocker and FileVault.
This is an independent guide from NHI Mgmt Group, based on Microsoft's public BitLocker documentation as of November 2026. It is not sponsored or reviewed by Microsoft. Product features change, so confirm settings against Microsoft's current documentation.
Key takeaways
- Choose protectors by threat, not habit. Microsoft recommends TPM only for opportunistic attackers with limited physical access, and TPM with an enhanced PIN, hibernate instead of sleep, for devices that face skilled, targeted physical attack.
- Escrow before you encrypt. Set "Store recovery information in Microsoft Entra ID before enabling BitLocker" (or the AD DS equivalent) to Required, so no drive is encrypted without a retrievable recovery password.
- Recovery key readers are privileged users. In Entra ID the permission is microsoft.directory/bitlockerKeys/key/read; scope it with a custom role and administrative units rather than handing out broad admin roles.
- Rotate after every use. A recovery password read out over the phone is spent. Configure recovery password rotation so Windows replaces it after it unlocks a drive.
- Suspend, do not trigger recovery. Firmware, boot order and TPM changes cause most recovery prompts; suspending BitLocker for planned changes avoids them.
How identity and access work in BitLocker
BitLocker encrypts whole volumes. Access to the volume is controlled by key protectors: each protector is a different way to release the volume master key at boot. The protector choice decides who, or what, can unlock the drive, and therefore which attacks it resists.
| Protector | What unlocks the drive | Fits | Operational cost |
|---|---|---|---|
| TPM only | The TPM releases the key if boot measurements (PCRs) match | Default for most laptops and desktops; Microsoft's recommendation against opportunistic attackers | None for users; recovery when measured boot components change |
| TPM + PIN | TPM measurements plus a preboot PIN; enables TPM anti-hammering | Devices at risk of skilled physical attack, admin workstations, travel devices | PIN prompt at every boot and resume from hibernate; blocks silent enablement |
| TPM + startup key | TPM plus a USB key file | Niche: kiosks or labs with physical key control | Key media must be managed and kept apart from the device |
| TPM + PIN + Network Unlock | On a wired corporate network, a WDS server supplies half the key so no PIN is needed; off network, the PIN prompt applies | Desktops and servers that need unattended patch reboots | WDS server, DHCP, certificate management |
| Startup key, no TPM | USB key file only | Hardware without a TPM | No preboot integrity verification |
| Recovery password | 48 digit numerical password | Recovery only, always escrowed | Help desk process, rotation after use |
Password only protector: a password protector for OS drives without a TPM exists but Microsoft discourages it and it is disabled by default, because it has no lockout logic. Use a TPM-based protector instead.
Requirements worth checking first
- TPM and firmware: TPM 1.2 or later for integrity checks. TPM 2.0 requires native UEFI with Legacy and CSM disabled; Microsoft recommends Secure Boot. Convert legacy disks with mbr2gpt.exe before switching to UEFI.
- Partitions: the OS drive must be NTFS; a separate unencrypted system partition (FAT32 on UEFI) of about 350 MB is recommended. New installations create it automatically.
- Editions: BitLocker can be enabled on Windows Pro, Enterprise, Pro Education/SE and Education. Microsoft documents that the management entitlement is granted by Windows Enterprise E3/E5 and Education A3/A5, which is separate from the enablement entitlement.
Device encryption on Windows 11
Device encryption switches BitLocker on automatically on qualifying hardware, using XTS-AES 128-bit by default and encrypting the OS and fixed drives (not removable drives). Encryption starts with a clear key, which Windows removes only after the recovery key is backed up to Entra ID, AD DS or a Microsoft account and the TPM protector is created. Microsoft notes that from Windows 11 version 24H2 the DMA and HSTI/Modern Standby prerequisites are removed, so far more devices qualify. Two consequences matter for enterprises: devices that only ever use local accounts have encrypted data but no backed up key, and an already encrypted device needs decrypting before a different cipher policy can apply, so deploy cipher policy before or during enrolment (the Enrollment Status Page can delay encryption until policy lands). Check eligibility with msinfo32.exe ("Device Encryption Support").
Admin roles and privileged access
Whoever can read a recovery password can unlock that device's drive with physical access. Treat recovery key access the way you treat password reset rights: a privileged action with a named owner, scope and audit trail. See the Account Recovery and Help Desk Security Guide for the wider pattern.
| Where keys live | Who can read by default | How to narrow it |
|---|---|---|
| Microsoft Entra ID (bitlockerRecoveryKey) | The device owner (self-service at myaccount.microsoft.com); built-in Cloud Device Administrator, Helpdesk Administrator and Global Administrator | Custom role with microsoft.directory/bitlockerKeys/key/read scoped to administrative units; set "Restrict users from recovering the BitLocker key(s) for their owned devices" where self-service is not wanted |
| Intune admin center | Roles with the Entra key read permission; Intune Help Desk Operator and Endpoint Security Administrator hold the Rotate BitLockerKeys remote task | Intune RBAC scope tags plus the Entra permission above |
| AD DS (ms-FVE-RecoveryInformation child objects) | Domain Admins | Delegate read of recovery information to a dedicated help desk group on specific OUs |
| Microsoft account (personal devices) | The account holder | Not an enterprise escrow location: enrol corporate devices into Entra ID or AD DS |
- Self-service decision: self-service retrieval cuts help desk volume but means anyone who has phished the user can also obtain the key. Microsoft advises limiting self-service to trusted environments. A common middle ground keeps self-service for standard staff and restricts it for high-value roles through help desk recovery with identity verification.
- Reused Autopilot devices: when a device changes owner, the new owner has to ask an administrator for the key; admins with custom or administrative unit scoped roles keep access, so check scopes after reassignment.
- Privileged access: put the roles that can read keys under just-in-time activation. See the Active Directory and Entra ID Hardening Guide.
Integrations, API tokens and service accounts
Recovery keys are reachable by automation as well as by people, and that is where key access quietly widens.
- Microsoft Graph: the bitlockerRecoveryKey resource exposes keys to any application or script granted the BitlockerKey.Read.All scope. Inventory every app registration and service principal holding it, prefer delegated over application permission, and review consent regularly. See the Entra ID Applications and Consent Guide.
- Configuration Manager: the BitLocker management agent escrows keys to the site database; the accounts and service connection point that reach that database belong in your privileged inventory.
- AD DS delegation: scripts that read ms-FVE-RecoveryPassword attributes usually run under service accounts. Give them the narrowest OU scope and a managed credential.
- Network Unlock server: the WDS server's Network Unlock certificate private key is the decryption point for unlock requests, and Microsoft notes it can be exported. Protect it as a tier 0 secret and restrict which subnets each certificate can unlock from with bde-network-unlock.ini.
- Data Recovery Agent certificates: a DRA acts as a master key for drives configured with the organisation's identifiers. Keep the private key offline, logged and dual controlled.
The general discipline for these identities is covered in the NHI Discovery Across Cloud, SaaS, CI/CD and On-Premises Environments and the Group Managed Service Accounts (gMSA) Guide.
Recovery at scale
Microsoft lists the common recovery triggers: too many wrong PIN entries, boot order or boot manager changes, firmware or BIOS upgrades, TPM cleared or disabled, motherboard replacement, PCR profile changes, moving the drive to another machine, and exceeding a machine account lockout threshold. Most of these are planned events. The process below keeps recovery predictable.
- Prevent avoidable prompts. Suspend BitLocker before firmware and BIOS updates (Suspend-BitLocker or manage-bde with a reboot count); it resumes automatically. Build this into vendor firmware deployment packages.
- Verify the caller. Confirm the requester is the authorised user of that device before reading any key. Record the device name and the recovery key ID shown on the preboot screen.
- Look up by key ID. Search Entra ID or Intune (Devices, the device, Recovery keys, Show Recovery Key), or in AD DS use the BitLocker Recovery Password Viewer's Find BitLocker Recovery Password with the first eight characters of the ID.
- Find the cause before handing over the password. Check protection mode, PCR profile and recent boot file changes with manage-bde -status and the event log. Repeated prompts on one model usually mean a firmware or PCR profile issue that needs a fleet fix.
- Rotate. If automatic rotation is configured, Windows replaces the password after use; otherwise trigger BitLocker key rotation from Intune (Windows 10 1909 or later) or Configuration Manager.
- Last resort. For damaged volumes, repair-bde.exe uses the key package. Key packages are not stored in Entra ID and are not saved to AD DS by default, so enable "Backup recovery password and key package" where you need this option.
Limits to know: Entra ID holds a maximum of 200 BitLocker recovery keys per device, and reaching the limit makes silent encryption fail. Deleting the Intune object for an Entra joined BitLocker device removes the OS volume key protectors and suspends BitLocker, so retire devices through a documented process.
Logging and detection
Two things need watching: who read keys, and which devices are not compliant.
- Key reads: Show Recovery Key in Intune creates a KeyManagement audit log entry. Entra ID audit logs record recovery key reads; forward both to your SIEM and alert on reads by unexpected principals, out-of-hours bulk reads, or reads with no matching ticket.
- Graph access: monitor sign-ins and activity for service principals holding BitlockerKey.Read.All.
- Endpoint events: BitLocker writes to its own event channels under Applications and Services Logs > Microsoft > Windows > BitLocker-API (log file Microsoft-Windows-BitLocker%4BitLocker Management.evtx). Collect them to see protector changes, suspensions, recovery unlocks and escrow failures.
- Compliance: the Intune Encryption report shows encryption status per device, and the BitLocker CSP feeds Intune compliance policies and Conditional Access. See the Device Trust and Posture Guide.
- Abuse of BitLocker itself: attackers have used native encryption tools for impact (MITRE ATT&CK T1486 Data Encrypted for Impact). Alert on BitLocker being enabled or protectors added on servers outside change windows.
| Metric | Target | Source |
|---|---|---|
| Managed Windows devices encrypted with key escrowed | 100% of in-scope devices | Intune Encryption report, Configuration Manager |
| Encrypted devices with no escrowed key | Zero | Compare encryption status with Entra or AD DS key objects |
| Recovery events per 1,000 devices per month | Falling trend; spikes investigated by model | Help desk tickets, BitLocker event logs |
| Recovery passwords rotated after use | 100% | Rotation events, Intune remote action history |
| Principals able to read keys | Reviewed quarterly, shrinking | Entra role assignments, Graph permission grants, AD DS delegations |
Hardening baseline
Settings below use Microsoft's policy names. Most apply only when BitLocker is first turned on; changing the cipher later requires decryption and re-encryption, so get the baseline right before broad rollout.
| Setting | Recommended value | Why |
|---|---|---|
| Choose drive encryption method and cipher strength | XTS-AES 256-bit on capable hardware (default if unset is XTS-AES 128-bit) | Microsoft's recommendation; set before encryption begins |
| Require device encryption / Allow standard user encryption | Enabled | Silent encryption for standard users in Intune |
| Save BitLocker recovery information to Microsoft Entra ID / Store before enabling | Enabled / Required | No unescrowed drives |
| Do not enable BitLocker until recovery information is stored in AD DS | Enabled (AD joined devices) | Same guarantee for on-premises devices |
| Configure recovery password rotation | 2 (Entra joined and hybrid joined) | Spent passwords are replaced; requires escrow to be Required |
| Require additional authentication at startup | TPM only for general fleet; TPM + PIN for high-risk roles | Matches Microsoft's attacker-based guidance |
| Allow enhanced PINs for startup | Enabled where PINs are used | Alphanumeric PINs raise the cost of bypass |
| Kernel DMA Protection, or "Disable new DMA devices when this computer is locked" | Kernel DMA Protection where supported; the policy otherwise | DMA port protection; the two are not compatible |
| Prevent memory overwrite on restart | Not enabled | Keeps memory cleared at restart |
| Allow standby states (S1-S3) when sleeping; Show hibernate | Disable standby, show hibernate, for PIN devices | Hibernate locks the drive; sleep keeps keys in memory |
| Deny write access to removable drives not protected by BitLocker | Enabled, with organisation identifiers | Data leaving on USB is encrypted |
Physical attacks: TPM sniffing and related scenarios
Public research has shown that on some hardware the key can be read from the bus between a discrete TPM and the processor during a TPM only boot; Microsoft's countermeasures page describes the same class as eavesdropping on an exposed bus during startup. The documented defence is preboot authentication: with TPM + PIN the TPM does not release the key until the PIN is entered. Microsoft also documents protection against bootkits through PCR measurement, against memory remanence through Secure Boot, firmware passwords, disabling standby and hibernating before devices leave the user's control, and against rogue operating systems through PCR 11 sealing. Where PIN prompts block unattended patching, Network Unlock keeps the PIN for devices off the corporate wired network.
Phased Intune rollout
- Inventory: list devices by TPM version, UEFI mode, Secure Boot state and existing third party encryption, which must be removed first; Microsoft warns that disabling "Allow Warning For Other Disk Encryption" with another product present can cause data loss.
- Build the profile: Endpoint security, Disk encryption, BitLocker profile. Microsoft recommends Endpoint security or device configuration policies for enablement, because they carry the TPM startup authentication controls needed for silent enablement; use it for "Enforce drive encryption type on operating system drives" if you need Full or Used Space Only encryption.
- Pilot ring: a few devices of each model, with TPM startup PIN and key set to Do not allow for silent enablement. Check that security baselines do not switch a TPM PIN on, which blocks silent enablement.
- Verify escrow: confirm every pilot device shows a key in Entra ID before widening.
- Broad rings: expand by department, watching recovery rates by model.
- High-risk overlay: a separate profile for TPM + PIN groups, deployed with user communication.
- Rollback: unassigning a profile does not decrypt drives. Suspend or decrypt deliberately with manage-bde, and keep keys escrowed until the device is wiped.
Common misconfigurations
- Encryption before escrow: drives encrypted by local setup or device encryption on local-account devices, with no key in Entra ID or AD DS. Fix with the "store before enabling" settings and a report comparing encrypted devices against escrowed keys.
- Broad key readers: recovery key access granted through general admin roles or a Graph app with BitlockerKey.Read.All nobody owns. Move to a scoped custom role and review app permissions.
- No rotation: the same recovery password reused after it was read aloud. Turn on rotation and use the Intune remote action.
- Baseline conflicts: a security baseline requiring a TPM PIN applied to the same devices as a silent encryption profile, so encryption never starts. Align profiles per device group.
- Firmware updates without suspension: fleet-wide recovery prompts after a BIOS rollout. Suspend for one reboot in the update package.
- Stale AD DS keys: old recovery objects remain until the computer object is deleted, and Entra keys accumulate towards the 200 key limit. Clean up as part of device retirement.
Framework mapping
| Framework | Reference | BitLocker control |
|---|---|---|
| NIST SP 800-53 Rev 5 | SC-28, SC-28(1) Protection of Information at Rest, Cryptographic Protection | Volume encryption on endpoints and fixed drives |
| NIST SP 800-53 Rev 5 | SC-12 Cryptographic Key Establishment and Management | Escrow, rotation, DRA and Network Unlock certificate handling |
| NIST SP 800-53 Rev 5 | AC-6 Least Privilege; AU-6 Audit Record Review | Scoped key read roles; review of key read audit logs |
| NIST CSF 2.0 | PR.DS-01; PR.AA-05 | Data at rest protected; key access permissions managed |
| CIS Controls v8.1 | 3.6 Encrypt Data on End-User Devices | Fleet-wide BitLocker with escrow |
| ISO/IEC 27001:2022 Annex A | A.8.1 User endpoint devices; A.8.24 Use of cryptography | Endpoint encryption policy and key management |
| MITRE ATT&CK | T1486 Data Encrypted for Impact | Monitor unexpected BitLocker enablement on servers |
Practitioner checklist
- Set escrow to Required (Entra ID and AD DS) before any encryption policy reaches devices.
- Set XTS-AES 256-bit as the cipher on capable hardware before encryption starts.
- Assign protectors by attacker profile: TPM only for the general fleet, TPM + enhanced PIN with hibernate for high-risk roles.
- Replace broad admin roles with a custom role holding microsoft.directory/bitlockerKeys/key/read, scoped by administrative unit.
- Inventory and justify every app with BitlockerKey.Read.All and every AD DS delegation on recovery objects.
- Configure recovery password rotation (value 2) and rotate after every help desk recovery.
- Add BitLocker suspension to firmware and BIOS update packages.
- Forward Intune KeyManagement and Entra audit events to the SIEM, with alerts on unusual key reads.
- Report monthly on encrypted devices without escrowed keys and on recovery rates by model.
- Protect Network Unlock and DRA private keys as tier 0 secrets.
Standards and references
- Microsoft Learn: BitLocker overview
- Microsoft Learn: BitLocker countermeasures
- Microsoft Learn: BitLocker recovery overview
- Microsoft Learn: BitLocker recovery process
- Microsoft Learn: Configure BitLocker
- Microsoft Learn: BitLocker Network Unlock
- Microsoft Learn: Encrypt Windows devices with BitLocker in Intune
Related NHI Mgmt Group resources: Disk Encryption Guide: BitLocker and FileVault · Endpoint Security Guide · Entra Device Identity · Group Policy to Intune Migration · Account Recovery and Help Desk Security Guide