Risk of BitLocker/boot issues with Secure Boot updates on outdated UEFI firmware?
Posted by Zarphyl@reddit | sysadmin | View on Reddit | 16 comments
Hi all,
I’m managing \~1,600 endpoints in a constrained environment (WSUS-only, no budget for additional tooling like SCCM/Intune or third-party patch management).
We have a mixed hardware fleet, and a significant number of devices are running outdated BIOS/UEFI firmware. With the recent Windows updates that touch Secure Boot / UEFI trust chain (e.g., DB/DBX updates, revocation lists, etc.), I’m concerned about potential mismatches between OS-level updates and firmware state.
My main questions:
- If Windows applies updates that modify the UEFI trust chain (e.g., Secure Boot DBX updates) but the underlying firmware is outdated, can this lead to BitLocker recovery being triggered due to PCR measurement changes?
- Is there a realistic risk of rendering systems unbootable if firmware does not properly support or reflect these updates?
- How tolerant is BitLocker to these kinds of changes in practice (TPM + Secure Boot measurements drift)?
- Any known edge cases where outdated firmware + newer Windows cumulative/security updates caused boot failures or required manual intervention?
Given that we don’t have centralized firmware management, I’m trying to assess the real risk before broadly approving updates in WSUS.
Any insights, especially from people who’ve dealt with Secure Boot DBX rollouts or similar scenarios at scale, would be very helpful.
Thanks!
GeneMoody-Action1@reddit
I hate to be that guy, but since you do not have the tools to manage this properly, and are approaching the situation with trepidation (appropriate IMHO)... What is the plan for if it DOES fail? 1600 ep is a lot to do manually or fail. YOU do not have the luxury of a guess, you need a good plan that will work, and is fault tolerant.
I would consider the reality of the following, “no budget for additional tooling”. As that is a bit like saying I have to breathe but no money for oxygen. What businesses can afford is always negotiable. Imagine if the plumbing in the slab of the business failed and bathrooms were rendered unusable. Repair will not be cheap by any means, but no one would dare say “we cannot fix the bathrooms because we do not have the budget.” It would happen, because it must.
Maintaining security is a lot like that. I would use this as a driving force to get those tools, remind them of the bathroom scenario, then what happens when security backs up… It’s a stink in either situation!
Avas_Accumulator@reddit
After this ordeal I've changed how we do hardware replacement: I no longer look at age if the department accept the increased risk as years pass - the hard limit is now at (Days since Vendor released a BIOS update)
Part of this exercise has been to properly root out all old devices, ensuring their BIOS is up to date, or that the hardware is.
After that I've been running some blog-published scripts, but it did really show me how much Intune/Action1 can help out in a modern world with modern needs.
Even with a brand new setup and brand new hardware, we had some 5% compliance for this update before I started working on it. Mind blown.
Nexthink_Quentin@reddit
you’re right to think about this, the interaction between firmware, secure boot, and bitlocker can get tricky at scale. dbx updates can change measured boot values, so yes you can see bitlocker recovery prompts if the TPM PCR values shift, especially on older or inconsistent firmware. outright unbootable systems are less common but not impossible, usually tied to edge cases where firmware doesn’t properly handle updated revocation lists or bootloaders. in practice bitlocker is somewhat tolerant, but it depends heavily on how consistent your fleet is and whether devices have seen prior firmware updates. biggest risk is not mass failure, but a scattered set of devices hitting recovery or needing manual intervention. if you can, test dbx-related updates on a representative sample of your oldest hardware first before broad approval
Zarphyl@reddit (OP)
Understood. We mostly have Dell and Lenovo devices that are around 3–4 years old. My concern is about systems with BIOS versions prior to 2023 (before the certificate update was introduced). If I update Windows but the BIOS is older and doesn’t have the updated certificates, what could happen? BitLocker is centrally managed through McAfee ePO.
Impossible_IT@reddit
How many Dell computers? Do you use GPOs? If you use GPOs you can deploy Dell Command Update to the Dell computers. Then use PowerShell to initiate DCU-CLI.
Nexthink_Quentin@reddit
yeah you’re not off here, that mismatch is exactly where things can get weird
in most cases you won’t brick the system, but you can definitely see bitlocker recovery prompts if the measured boot values shift after those updates. the bigger risk is when microsoft starts enforcing the dbx revocations more aggressively, then older firmware that hasn’t been updated can cause boot issues or at least require manual intervention
with dell/lenovo 3–4 year old hardware you’re probably in that gray zone where most devices will be fine, but a subset will act up depending on firmware state. if bitlocker is in play via epo, I’d definitely expect some recovery events if you roll broadly without testing
Do what you're already thinking- test on a handful of devices first
Matazat@reddit
I've had a very small number of devices trigger bitlocker, and rebooting once or twice was enough to make it go away without needing the key. I would still double check that you have the keys saved somewhere first.
thebigshoe247@reddit
I'm running 7th Gen Intel's which haven't seen BIOS updates since before COVID... ThisIsFine.jpg
paleologus@reddit
I’m working on a 4th gen laptop right now. It’ll be fine.
thebigshoe247@reddit
Oh I meant my workplace itself. For myself, if I can RDP, use a browser, and SSH, I'm good.
... Mind you my work machine is a Framework 13.
stoned_as_hell@reddit
Did I smoke something real good or am I reading it right in that you crammed a 7th gen board into a FW13 somehow because I'm very interested if it is the latter
thebigshoe247@reddit
Ha, that would be neat.
Nope, I use a FW13 as my daily driver. The rest of the office is still using 7th Gen Acer computers (no, not my choice).
Mitchell_90@reddit
My biggest concern with this is that 80% of our devices are in remote locations and some will go into BitLocker recovery during this (A lot of the Dell machines we have seem to do this after regular Windows Updates)
jamesaepp@reddit
I've read/watched/listened to so much material on these SB changes that it's all a blur and I can't give you any source, but my TL;DR points are:
Yes, the secure boot updates are "BitLocker aware" and as an admin you SHOULD NOT have to worry about it.
Notwithstanding the above, bugs exist and the nature of these SB updates is that it's a "two to tango" situation and not all firmware gracefully takes these KEK/DB updates gracefully as they should and SOME models/devices/firmware ("buckets") may trip bitlocker recovery.
The above point is why Microsoft is rolling this out slowly in waves and using telemetry to gauge how the updates are going. Whether their telemetry includes measuring bitlocker-related failures is .... unknown.
My opinion/take:
Test your servers (especially VMs) and update them like you would for any other big change. Microsoft isn't doing anything automatic for servers apart from the SB updates being in the LCUs/Windows code.
Take a bit of a cowboy approach to endpoints. Microsoft is doing CFR to Home/Pro SKUs as part of the waves, and that's how they get the confidence buckets established for Enterprise. If you can monitor 1801 and 1808 events, great. If you can push out 0x5944 or CFR to a smaller test fleet, super great. I'd focus on 1801 event collection/review before anything else though.
Smith6612@reddit
When Windows updates the Bootloader or anything which might trip BitLocker, it should temporarily suspend or add a "grace unlock" to BitLocker so it doesnt trip.
If the Secure Boot signing keys get changed from a BIOS update done outside of Windows, then you'll see BitLocker get tripped.
In terms of how the rest of the hardware reacts, this really is a PC by PC issue. I've seen some cheap Mini PCs end up being unbootable until the power was pulled following the Microsoft Secure Boot update. Most PCs have just updated the Certificates and moved on with their day. Whatever you can do to ensure a system's BIOS is up to date is probably going to help ensure you'll have a limited number of issues. Common brands like Dell and HP usually publish their BIOS updates to Windows Update and the fwupdate Linux database.
Zarphyl@reddit (OP)
Yes, we were considering the option of deploying a policy to allow devices to download drivers directly from Windows Update. However, we're concerned that rolling this out to 1,800 users could lead to issues if devices fail or are powered off during the update process.
We might be able to roll it out in smaller groups, but we're still evaluating our options. What would you recommend?