Bitlockered devices following updates

Which is why the only safe way forward is to suspend bitlocker

And how does one do this?

I'm aware of how to turn it off, but that involves decrypting the disk, which is a non-trivial affair in many cases. If there's a way to make BitLocker not "flake out" (and that's precisely what it's doing, effectively, when a typical system update causes something like we're seeing here, no matter how you defend it) by telling it to suspend itself and then "pick up right where you left off" without this mess, what is it?
 
And how does one do this?

I'm aware of how to turn it off, but that involves decrypting the disk, which is a non-trivial affair in many cases. If there's a way to make BitLocker not "flake out" (and that's precisely what it's doing, effectively, when a typical system update causes something like we're seeing here, no matter how you defend it) by telling it to suspend itself and then "pick up right where you left off" without this mess, what is it?
 
@Markverhyden

Thank you. That's precisely the kind of thing I'd hope would be offered as a matter of course when making suggestions related to "relatively new" technology or issues.

I really wonder what a royal mess is coming, as firmware updates are supposed to become part of Windows Update and you know that unless, somehow, the suspension of BitLocker is automated as part and parcel of the process chaos is bound to ensue. Even manufacturer-supplied firmware update packages really now need to be checking if BitLocker is active and doing a suspend as part of the process if it is.
 
I got the device today.
Definitely bitlockered.
She says it's listed under her account but with no key.
Her previous now defunct Surface Pro is also listed with the associated key, but none for the newer device.
She's adamant they didn't use her brother account at all and she had him check again.
Sounds like the lock was set without generating a key.
If it's listed under her regular account I assume it can't be associated with any other one?
She's going to review her work and school accounts as well just in case.
For grins did you try the recovery key from the old surface?
 
@Markverhyden

Thank you. That's precisely the kind of thing I'd hope would be offered as a matter of course when making suggestions related to "relatively new" technology or issues.

I really wonder what a royal mess is coming, as firmware updates are supposed to become part of Windows Update and you know that unless, somehow, the suspension of BitLocker is automated as part and parcel of the process chaos is bound to ensue. Even manufacturer-supplied firmware update packages really now need to be checking if BitLocker is active and doing a suspend as part of the process if it is.
This is a feature I had no idea existed. It can have the potential to be a huge security risk but at the same time it should have been an integral part of the Windows Update ecosystem. Long before BL was a thing we all knew that, while rare, updates, especially core OS and BIOS updates could hose an OS. Without FDE at least getting the data was trivial to recovering for the customer.
 
This is a feature I had no idea existed.

Same here.

I also have to say that in general I think the presumption that "everyone knows" what "every acronym" stands for is problematic in the same way, particularly where "new or newish tech" is being referenced.

I try my best to do things like, time-based one-time password (TOTP), when introducing what I even thing might be not known by everyone and including links to stuff like BitLocker Suspend when I have every reason to believe that a very great many are likely not familiar with it.
 
if you change the EFI code at all, the hash changes, and this process fires. Which is why the only safe way forward is to suspend bitlocker, or decrypt the disk before a BIOS update.
You're aware that BIOS updates can (and often do) come through Windows Update automatically, right? And that most computers with Windows 11 Home have Bitlocker Device Encryption automatically turned on?

So either the user should get permission before doing BIOS updates (perhaps in Windows Pro), or the "Bitlocker suspension until after reboot" command should be issued automatically (in Windows Home). Either way, a warning before reboot could say encryption is suspended so people know the data is at risk if the computer doesn't reboot.

It's not acceptable for a user to be locked out of their computer due to an update they're not aware of, not by design anyway!
 
You're aware that BIOS updates can (and often do) come through Windows Update automatically, right? And that most computers with Windows 11 Home have Bitlocker Device Encryption automatically turned on?

So either the user should get permission before doing BIOS updates (perhaps in Windows Pro), or the "Bitlocker suspension until after reboot" command should be issued automatically (in Windows Home). Either way, a warning before reboot could say encryption is suspended so people know the data is at risk if the computer doesn't reboot.

It's not acceptable for a user to be locked out of their computer due to an update they're not aware of, not by design anyway!
And those updates are sourced from their respective vendors, and supposed to follow the Bitlocker suspension process, Dell is in particular really good about this. HP isn't far behind, nor is Lenovo. However, as software, it's got bugs, and it's never perfect which is by nature.

Users being unaware of all of this... honestly, that argument falls flat here. If the user doesn't have backups of all locally stored data, and the system suffers some fault... the fault is theirs and theirs alone. As the owner of the property it is fully their responsibility to learn how to manage, use, and maintain the device in question. This is no different than any other bit of property.

Crap happens, efforts are made to prevent issues, and these issues while commonly discussed here are the vast minority of bios updates. As you said, these processes are automated, and we suffer a serious case of Survivorship bias. All we see are the failures, we internally discount the millions of successes.
 
Users being unaware of all of this... honestly, that argument falls flat here.

For you. Most users, and that includes business users, have zero knowledge of any of this, nor should they. This issue is entirely separate from backups and it should NOT be occurring, ever.

When is the last time you heard of similar on other platforms?
 
Most Windows 11 systems ship in a suspended state. The act of logging into a Microsoft Account and storing the key successfully in it locks the system and fully activates BitLocker.

In a suspended state the key is stored in plaintext in the metadata of the boot sector. Any TPM will read that key and automatically decrypt files on the fly. When BitLocker is fully activated the key is stored on the TPM chip and the boot sector key is over written.
 
Another situation where you need a Bitlocker key is when you're trying to run a Microsoft Defender Antivirus (offline scan). I'm attempting that now on a couple of computers and was surprised to learn they had Bitlocker. I was able to simply say "Skip this drive" and Windows rebooted to the normal way of being. Probably not what's in play here, but just pointing that out.
 
Last edited:
Another situation where you need a Bitlocker key is when you're trying to run a Microsoft Defender Antivirus (offline scan).

Not doubting what you're saying, but how in the hell does that make any sense when triggering an offline scan for the same machine that's BitLocker encrypted.

Microsoft has screwed the pooch in so many ways with this `feature` that I've lost count!
 
As the owner of the property it is fully their responsibility to learn how to manage, use, and maintain the device in question. This is no different than any other bit of property.
The problem in my experience is that most of the user totally trust the manufacturer to have ironed it all wrinle free so they can have a smooth experience.
Until the sh*t hits the fan.
And they blame themselves for having messed it up probably.
the account is setup on whatever her main email address is
And it is listed there.
Hard to believe that it could also be registered under some other account 🤔
 
And those updates are sourced from their respective vendors, and supposed to follow the Bitlocker suspension process
OK, that's good to know. So it's the vendors that often have buggy BIOS update processes.
If the user doesn't have backups of all locally stored data, and the system suffers some fault... the fault is theirs and theirs alone.
Yes users are always responsible for the data. But the downtime and frustration caused by an update that results in a non-booting system and requires the user to use another device to login to their MS account and type that long key... all by design or a bug. I don't think that's the fault of the user.
 
OK, that's good to know. So it's the vendors that often have buggy BIOS update processes.

Yes users are always responsible for the data. But the downtime and frustration caused by an update that results in a non-booting system and requires the user to use another device to login to their MS account and type that long key... all by design or a bug. I don't think that's the fault of the user.
True enough, it's validly frustrating. But again, don't forget the survivorship bias. We only see the busted units, we don't see the millions of successfully updated endpoints in the wild. It's not clear to me what causes the failures we still see, because the process is obviously not perfect. But the process will also never BE perfect, we as a species do not know how to write perfect software.

So, we have no choice but to manage the risk as best we can.
 
But again, don't forget the survivorship bias. We only see the busted units, we don't see the millions of successfully updated endpoints in the wild.
In my small repair shop I've come across it about 6 times or so. These are newer PCs with automatically enabled Bitlocker Device Encryption and the ability to for Windows Update to install BIOS updates. It's only going to get worse as PCs get newer, unless vendors improve the mechanism.

And the number of affected users in no way affects my argument that it shouldn't be excused.
 
Back
Top