Understanding BitLocker Management
How the BitLocker agent, policy deployment, recovery key storage, and report fields work.
Agent
Specifications of agent processes
Resource usage for each BitLocker-related agent process.
Agent process footprint
Discovery
Initial status and device data collection
The agent scans drives after installation. Review the following coverage limits.
What gets scanned
The BitLocker component installs immediately after agent installation, containing the binaries for the module's functions. The Endpoint Central MSP agent then scans internal drives and displays their encryption status in Managed Computers under the BitLocker Management module's Insights section.
Coverage limitations
- External drives — encryption of external drives isn't currently supported by Endpoint Central MSP.
- Locked drives — a locked volume can prevent new data collection or encryption operations. Check the actual Windows state and the last reported console data. Drives previously encrypted through Windows native BitLocker, Device Encryption, MBAM (legacy Microsoft BitLocker Administration and Monitoring), or another tool need migration checks. A console status mismatch does not establish which tool encrypted the drive.
For understanding how manually encrypted drives are reported and how to bring them under Endpoint Central MSP management, see Recovery Key Troubleshooting > Manually Encrypted Drives.
To manage a device's encryption through Endpoint Central MSP, you have to create and deploy an Endpoint Central MSP BitLocker policy on it.
Before changing encryption management, securely back up a usable recovery password and match it to the drive’s recovery identifier. An identifier alone is not proof that the password was stored. Review the existing encryption method, full/used-space setting and protectors against the intended policy. Matching settings can be retained; incompatible settings can trigger decryption and re-encryption. Do not assume that every pre-encrypted device will always be adopted unchanged, or always be decrypted.
Coordinate the policy transition with the administrator of the existing tool. Confirm the supported coexistence or migration procedure for your product and build. Test it on a pilot computer before applying it broadly.
For a status mismatch, compare the same volume’s current Windows status with the console’s last reported data. Do not diagnose every Fully Decrypted value as proof of manual encryption. See Recovery-key and status troubleshooting.
A computer can appear under Available For Deployment because it has no associated BitLocker policy, even when a drive is already encrypted. Compare the device’s current Windows state with the reported data and dashboard tile definitions. Before assigning a policy, verify recovery-password backup and compare encryption method, encryption level and OS-drive protectors. Existing encryption alone is not a guarantee of unchanged adoption.
Deployment
How policy deployment actually rolls out
The two deployment options use different delivery schedules, especially for large groups.
Deploy Immediately vs. Deploy
- Deploy Immediately — pushes the policy right away to agent machines currently online. For groups over 200 machines, it applies to the first 200 immediately, with the rest following in the next refresh cycle.
- Deploy — schedules the policy for the next 90-minute refresh cycle.
Devices then encrypt or decrypt according to the policy that was implemented. Deployment status is visible by drilling into the applied policy.
Enforcement
How the agent enforces policy
Review timing, non-TPM handling, policy changes, deletion and conflicts separately.
When encryption actually starts
The agent starts BitLocker processes during its refresh cycle; how long it takes depends on the individual machine's performance. Drive encryption only begins once the recovery key is stored successfully on the server. If encryption fails, check whether all encryption prerequisites are met.
If no Endpoint Central MSP BitLocker policy was deployed, check whether Windows Device Encryption, another tool or a manual action enabled encryption. See How are drives fully encrypted without deploying the policy?. Compare current Windows status with the reported console data before changing policies.
Effect on non-TPM machines
Non-TPM machines require a passphrase for encryption — end users see a password prompt, and encryption starts only once that password is provided. A single policy can configure encryption for both TPM and non-TPM machines together.
Effect of modifying a policy
Editing encryption settings creates a difference between the edited and old policy, which causes every machine under that policy to decrypt and then re-encrypt with the new settings. If the change only touches advanced settings — like recovery key rotation or domain controller backup — those settings apply on their own, with no decrypt/re-encrypt cycle.
Effect of deleting a policy
If a policy is deleted, dissociated, or the machine is removed from the Scope of Management (SoM), existing encryption on the drives stays intact. Deploy a decryption policy to decrypt the drives.
Policy conflict precedence
When multiple BitLocker policies are deployed to the same endpoint, the most recently deployed one takes effect. Check which policy is currently active by drilling into the system's view under Managed Systems.
Recovery keys
How recovery keys are stored
The key is stored before encryption ever starts, and retained for a while even after a device leaves management.
Storage and retention
The recovery key is created and updated on the server before encryption starts — encryption begins only after the server confirms the key was updated safely. Endpoint Central MSP also supports updating the key to both Active Directory and Azure AD.
With Recovery Key Retention enabled under Retrieve Recovery Key, the key stays on the server for up to one year after a computer is removed from SoM or becomes unmanaged under a limited license. With it disabled, removed computers' keys are discarded after 30 days.
Because of how sensitive the key is, any technician who accesses a recovery key has that action captured in the Action Log Viewer.
The Computer Details → Security → BitLocker view uses Inventory permissions. Viewing a BitLocker recovery key is restricted to users with full Inventory access. This differs from the BitLocker Management recovery-key role. See the narrower module permission before granting technicians broad Inventory access.
With Periodic Rotation of the Recovery Keys enabled in a policy, the key updates on the agent after the set period and uploads to the server on the next refresh cycle, repeating at that interval. A key also changes on the agent at the machine's next reboot if it's ever been accessed.
Reading a recovery key, rotating it on the agent and posting new key data are separate events. An Inventory scan is not proof that rotation ran or that the new recovery password was stored. Compare the identifier and server update information with the device’s current protector state. See retrieval checks if data does not update.
Resetting the BitLocker password
The encryption key — PIN, password, or passphrase — can be reset by logging in with the recovery key. If an end user forgets their encryption key, giving them the recovery key is the way through: logging in with it prompts them to reconfigure their password or PIN.
For troubleshooting password reset prompts that do not appear or appear intermittently, see Recovery Key Troubleshooting > Password/PIN Reset Prompt.
Reports
Keywords in BitLocker reports
Use the field definitions below to interpret the reported drive state.
Report field reference
A fully encrypted drive can show Protection Status: Disabled when its protectors are suspended. The status does not identify the actor or trigger. Review maintenance actions, Windows state and other management tools. Do not infer that Endpoint Central MSP never performs suspension, or that every BIOS/firmware deployment automatically suspends and resumes protection. Confirm the update-specific workflow and verify protection after maintenance.
A deployment marked Applied Successfully or Policy has been applied must be checked separately from current drive conversion and protection. A fully decrypted drive can also show protection disabled. Compare the actual drive with the applied-policy diagnostic checks instead of assuming deployment success proves completed encryption.
Protector types
A protector is the key that allows access to encrypted data on a Windows device. Every drive also has a numerical password protector that serves as the recovery key, and data drives additionally carry an 'external key' for auto unlock.
TPM+Enhanced PIN shows as TPM+PIN in reports too — BitLocker itself only has a TPM+PIN protector, and TPM+Enhanced PIN is an extension of it rather than a separate protector type.