Forum Discussion
BitLocker suspended by recent hotpatch?
We appear to have seen BitLocker get suspended by an automated process this past month or so (since August 2026 Patch Tuesday or thereafter) and left that way. Has anyone else seen their estate do this? We're using Autopatch with hotpatch updates.
My No.1 suspect is KB5123607 but I've not yet been able to test this theory. What's not clear is if this was intentional or perhaps a mistake not to resume BitLocker after completing the patch. Leaving the devices with suspended BitLocker would seem to be a risky thing to do.
Hotpatch updates means that our devices can now go for extended periods without being rebooted. BitLocker being suspended, resulted in the devices becoming non-compliant because encryption is a requirement. Many devices were going over 14 days with BitLocker in a suspended state. We send automated non-compliance emails to users after 14 days of that state. It's supposed to be highly unlikely that they'd reach that deadline before re-achieving compliance.
A device from our last ring booted to recovery but was fine after a further restart. I was concerned this was the same thing.
Would be good to get to the bottom of this, in case it occurs again and next time it causes a data loss.
1 Reply
Your concern is valid: a device left with BitLocker protection suspended still has encrypted data, but its normal protection checks are bypassed until protection is resumed. The information provided does not prove KB5123607 caused the change. Microsoft’s guidance says ordinary Windows quality updates do not require users to suspend BitLocker, and automatically suspended protection should normally resume at the next restart. Start by inventorying affected devices: capture protection status, suspension date, reboot history, hotpatch deployment ring, recovery-key escrow state, and BitLocker and update events. Immediately resume protection on devices that remain suspended, after confirming their recovery keys are available. Then reproduce the update in a pilot ring with before-and-after status collection; do not infer causation from timing alone. Check whether an Intune policy, remediation, firmware process, or other deployment is issuing an indefinite suspension. If the pilot reproduces it, open a Microsoft support case with the logs and update identifiers.
