I've noticed an issue where some devices in our fleet enter BitLocker Recovery Mode after updating their UEFI certificates, even though most devices handle the update without any problems. This seems to occur mainly with older devices, especially those that have recently undergone a BIOS update. We make sure to suspend BitLocker before updating the BIOS and haven't faced issues during the BIOS update or the reboot that follows. However, the recovery problem arises days or sometimes a week after the certificate update. I'm beginning to think there's a connection between the certificate update and the BitLocker Recovery issue. Is there a possible way to manage the timing of the certificate update to make sure BitLocker is suspended at the right time?
3 Answers
One possibility could be that if BitLocker is deployed through a policy, it might unintentionally suspend before the reboot, especially if users put their devices to sleep or hibernate during the UEFI capsule update from Windows Update. This could trigger those BitLocker prompts after reboot.
I'm curious about how you figured out the BitLocker prompts started after the certificate updates. We've recently rolled out a policy in Intune for 40,000 devices to refresh certificates as needed, and we've been seeing an increase in BitLocker prompts too. Any chance these issues are linked?
I haven't run into this kind of issue. I implemented the three-step Black Lotus mitigation for most of my devices, and it seems to be working fine without any BitLocker prompts.
I can't say for sure it's directly related to the certificate update, but it definitely seems to happen after the BIOS updates and when BitLocker resumes protection.