BitLocker Silent Encryption With Intune: Why Devices Won't Encrypt

Silent BitLocker encryption is supposed to be invisible: the device encrypts in the background, the recovery key lands in Entra ID, and the user never sees a prompt. When one requirement is missing, the device quietly stays unencrypted, and compliance (and cyber insurance) quietly fail with it.

Requirements for silent encryption

All of these have to be true:

• A TPM is present and ready (TPM 2.0 on modern hardware)
• The policy uses TPM-only startup. Requiring a startup PIN or key breaks silent encryption.
• Windows Recovery Environment (WinRE) is enabled
• The device is Entra joined or hybrid joined, so the recovery key has somewhere to go
• The policy allows standard users to enable encryption (needed for Autopilot, where users aren't admins)
• No third-party encryption is installed
• The device boots in UEFI mode with Secure Boot

Check the device

# Encryption status of each volume
manage-bde -status

# TPM state
Get-Tpm | Select-Object TpmPresent, TpmReady, TpmEnabled, TpmActivated

# WinRE must be Enabled
reagentc /info

Then check the BitLocker events: Event Viewer -> Applications and Services Logs -> Microsoft -> Windows -> BitLocker-API -> Management. When silent encryption fails, this log usually says exactly which requirement wasn't met.

Common causes and fixes

WinRE is disabled. Very common on devices imaged with an old process, or after a disk resize. Enable it:

reagentc /enable

If that fails, the recovery partition may be missing or too small. That's a disk layout problem to fix before BitLocker will cooperate.

The policy requires a startup PIN. Silent encryption can't prompt for a PIN. Use TPM-only for silent encryption. If you need pre-boot authentication, it's a deliberate, user-facing rollout.

Conflicting policies. A BitLocker setting in an endpoint security disk encryption policy and in a device configuration profile (or a leftover GPO) can conflict and stop both. Check Devices -> [device] -> Device configuration for conflicts, and keep BitLocker in exactly one policy.

Hardware encryption quirks. Older self-encrypting drives and some firmware versions cause failures. Update the BIOS/firmware and, where possible, set the policy to use software encryption.

The device was already partly encrypted. A drive encrypted manually, with a different method or cipher strength than your policy requires, reports as non-compliant rather than being re-encrypted. Decrypt it, or align the policy to the existing encryption.

Recovery keys

Encryption without key escrow is a data-loss risk. Confirm the key is in Entra ID: Entra admin center -> Devices -> [device] -> BitLocker keys, or check from the device:

(Get-BitLockerVolume -MountPoint C:).KeyProtector |
  Where-Object KeyProtectorType -eq "RecoveryPassword" | Select-Object KeyProtectorId

If a key isn't escrowed, force a backup:

$kp = (Get-BitLockerVolume -MountPoint C:).KeyProtector | Where-Object KeyProtectorType -eq "RecoveryPassword"
BackupToAAD-BitLockerKeyProtector -MountPoint C: -KeyProtectorId $kp.KeyProtectorId

Also decide who can view recovery keys. In Entra ID, you can restrict users from reading keys for their own devices. Most businesses should.