[colejohnson66]

OP seems to imply it’s affected their entire “fleet”. Genuine question: is it possible the OEM they bought from enabled it? Cause you’re right: if you enable BL, you have a responsibility to not lose your recovery key. But if it was, say, in the box that was thrown away, is it the user’s fault?

[Nextgrid]

In general, at least one PCR will be extended with the hash of the EFI executable that's being run (with it being responsible for extending other PCRs with the hashes it executes, as to perpetuate the chain of trust). Without this, the whole system becomes pointless if you can load untrusted code (which can then set its own PCR values) without irrevocably messing up at least one PCR in the process.

If the OS updates the EFI binary or the files the bootloader will load (and thus extend PCRs based off of), the OS is responsible to "seal" the keys with the (predicted) values of the PCRs corresponding to the new files.

If the OS updates the files and fails to properly do this step, you get in this situation and your only way out is to use a backup key or somehow make the PCRs match what's actually being sealed (which is difficult, as the whole point is to prevent you from doing that - booting from a Linux USB or even merely changing BIOS settings or entering the boot menu will change PCR values) to make the TPM unseal the disk encryption key.

[kmitz]

I confirm this was enabled by default. The laptop were shipped from Dell with Pro versions of Windows. The end-users did not go through bitlocker setup process and therefore were not aware that they had to backup their security key.