so a TPM unseal requires the used TPM state (the PCRs used to seal the key) to be exactly the same as when the key was sealed. if it's not then the TPM will just return error.
when secure boot is disabled, bitlocker on the OS device uses PCRs 0,2,4,11, that's the UEFI firmware itself; option ROMs; the loaded bootloader; and a PCR that gets a cap event extended when bootmgr hands off to the next stage so only bootmgr can unseal the VMK from the TPM
when secure boot is enabled, it uses PCRs 7, 11. PCR 7 is the state of secure boot, the data measured to it includes whether secure boot is enabled at all; if any hardware debuggers were enabled (some systems forgot to do this); the content of dbx (the denylist of certs and hashes); and the values from db (the allowlist of certs and hashes) that were used to allow the binaries that have executed. and PCR 11 is the same as before.
additionally, when secure boot is disabled, the bitlocker metadata on disk contains hashes of allowed second stage bootloaders, and the known boot manager configuration, so if any of that gets changed, the key gets unsealed initially but then wiped from memory by bootmgr later when those hashes are checked. (none of this is done when secure boot is enabled! and there are known bugs in older bootloaders that can be used to dump bitlocker keys!)
...so really if you're using TPM-only bitlocker, you have to do some manual registry configuration to get it to always use the more secure "legacy" integrity validation, alongside setting it to use a combination of both sets of PCRs: 0, 2, 4, 7, 11. alongside making sure your system is updated.
and even then you're still vulnerable to hardware attacks (sniffing the LPC bus, glitching AMD PSP for the non-pluton fTPM implementation, just enabling the hardware debugger on some systems because they forgot to measure an event to the TPM when that's enabled)
there's a reason MS specifically says "use TPM+PIN at least", not that it helps anyone using home edition where TPM-only and recovery key are the only allowed key protectors.
also, automatic bitlocker is a thing, which has caused actual data loss on dbx updates in the past. i've been told they've actually fixed that issue since.
also, about secure boot: excuse me while i laugh hard at the state of the windows bootloader