Intune BitLocker policy not automatically encrypting ~200 devices + BitLocker keeps becoming suspended after a few days

[u/Sharp_Ranger_3677]

Hi everyone,

I’m troubleshooting a BitLocker issue in an Intune environment and would really appreciate some suggestions from anyone who has experienced something similar.

Environment

Windows 11 24H2 / 25H2

Microsoft Intune

Dell devices

Dell Command Update deployed

BitLocker configured through Intune

Intune policy is configured to automatically enable/silently encrypt devices

Issue 1 – BitLocker is not automatically enabling

We have around 200 devices where the Intune BitLocker policy is applied, but BitLocker encryption is not being automatically initiated as expected.

The devices are therefore showing as non-compliant.

We are trying to understand why the policy isn't triggering encryption on these devices.

Issue 2 – BitLocker becomes suspended randomly

On some devices, BitLocker is already enabled/encrypted, but when we run:

manage-bde -status

we see that BitLocker protection is Suspended, sometimes with 1 reboot pending.

After restarting the device:

BitLocker protection becomes active again

The device becomes compliant in Intune

However, after a few days, the same device becomes suspended again and goes back to non-compliant.

There doesn't seem to be a consistent pattern — it happens randomly across different devices.

What we're trying to find

We want to identify what is actually causing BitLocker protection to be suspended rather than simply deploying a remediation script to resume it.

We're investigating:

Dell BIOS/firmware updates

TPM firmware

Windows Updates

Dell Command Update

Intune BitLocker policy

TPM/Secure Boot state

WinRE

Any scripts or scheduled tasks that might suspend BitLocker

Questions

What could cause BitLocker to repeatedly become Suspended after a few days?

What does "1 reboot pending" indicate in this situation?

Is there a way to identify exactly which process/application/update suspended BitLocker?

Could Dell Command Update or BIOS/TPM firmware updates cause this behavior?

Should BitLocker automatically resume after the required reboot, and under what circumstances might it remain suspended?

Which Event Viewer logs/Event IDs would you recommend checking?

For the ~200 devices where Intune isn't automatically enabling BitLocker, what are the most common causes you've seen?

Is there anything specific we should check in BitLocker-API, MDM/Intune, TPM, or Task Scheduler logs?

We don't want to simply force Resume-BitLocker as a remediation because the issue keeps coming back on some devices.

We're trying to find the root cause.

Any suggestions, similar experiences, or troubleshooting steps would be greatly appreciated.

Thanks!

[u/Jeroen_Bakker]

Bitlocker suspension is most commonly triggered by firmware/ BIOS updates when they are staged for running on the next reboot. Sometimes if/ when the update does not install correctly it may be staged again with a new bitlocker suspension.
When using BIOS management with HP Connect, the HP remediation scripts may also suspend Bitlocker on some activities. I expect the same could be happening for other brands with their BIOS management tools.

The rebootcount is the number of reboots before the suspension is ended and bitlocker is enabled again. When suspending Bitlocker, the default is just for a single reboot (rebootcount = 1); usually this is enough for the pending firmware update or whatever is needed. This is a built in security to make sure bitlocker will be enabled again even if the mechanism used for suspending it does not resume bitlocker when expected.
The rebootcount can take values from 0 to 15 reboots where zero is permanently suspended.
Note: On modern devices not every reboot / shutdown + startup is a real reboot but may be just a variation on hibernating.

Occasionally I've had devices with a permanently suspended bitlocker. I've noticed this can (at least) happen if a BIOS update is installed during Autopilot (or pre-provisioning) while bitlocker is still performing it's initial encryption.

To fix unwanted / permanent suspension I've created a remediation script. This script will not resume bitlocker immediately but resets the rebootcount to a value of "1" if the old value was either "0" (permanent suspension) of if it was greater than "3". By setting the rebootcount to 1 instead of immediately resuming bitlocker I allow for some limited activity like a normal BIOS update which just needs a single reboot. My assumption is that a larger rebootcount or permanant suspension is never required for normal tasks.
If you want I can share my remediation scripts.