Definitely save those recovery keys, because BitLocker loves freaking out after BIOS updates or minor hardware changes. I think I had to enter mine after a GPU firmware update.
I think it will lead to lots of lost data. Kind of like how your kid's old ipad loses its mind and your apple id password doesn't work and the data is lost.
This kind of thing should be super-explicit when setting things up, and they should provide a way out.
No. That doesn’t help anyone other than computer nerds that have the background understanding to have usefully thought through the pros and cons. The reality is data is effectively “lost” all the time already when a laptop’s display fails, or some other problem that’s left the actual data completely in tact, because most people don’t know what to do about that and a sizeable portion of those people won’t bother to ‘take it in to the shop’.
non-computer nerds cannot remember any account credentials and if they use any hardware key their chances of recovery are way worse than restoring any failed archaic system. This is to get people into the MS ecosystem. It isn't about growth or providing a service.
I guess it's because measured boot doesn't like the new system state? But then I wonder: Whose responsibility is it to tell the TPM that the system has been legitimately changed? (Or am I completely off track here?)
The current approach (as I understand it) for Windows is to turn off measured boot for bitlocker, do the update that's likely to cause the issue, and then turn it back on again after the update has completed.
Hence you'll often notice UEFI updaters turning off bitlocker.
I've seen HP devices tell you what the value of PCR0 will be for each given update, meaning you can know beforehand what that will be, and prepare by locking measured boot to that value before rebooting.
In Linux with systemd-measure, there's an option to lock to a signed manifest for PCR11, so you can have updated kernels (UKIs, for example), able to boot, while still locking the measured boot to the kernel image, initrd, cmdline, and public key used to sign the values. At that point, your OS distribution (or yourself) can take control of that process. It doesn't help for firmware updates though, as far as I know, unless you can prepare and ship an updated PCR policy, and your OS distribution is unlikely to be tightly integrated with your hardware vendor to do that, so it will likely fall onto the user, or to unlock the disk while doing those updates.
And, since Microsoft likes to pretend an account is required to even install Windows now, most people will likely have a linked account.