By default, the secure boot status is part of the TPM registers that are used to unseal the encryption key for your drive. That's because if you disable secure boot, or reconfigure it with different keys, any bootloader could just replay measurements from a normal Linux system to the TPM and unlock your drive.
Calling systemd-cryptenroll with --tpm2-pcrs would allow you to manually pick a set of options. I believe Bitlocker uses 0, 2, 7, and 11 (11 being an OS specific register rather than a spec-defined one), which is why firmware updates often make you re-enter your Bitlocker key. Some people choose to only record the secure boot state, relying on the firmware to validate its own updates and config, which means you don't need your recovery key after firmware updates as long as the secure boot state remains the same.
Not taking secure boot state into account makes the entire setup rather easy to bypass, but you could do it to make your setup harder to break while still protecting against the "thief steals my SSD but not my laptop" scenario.
If you want, you can pick a different set of registers to use. The Arch wiki has a bunch of them: https://wiki.archlinux.org/title/Trusted_Platform_Module#Acc...
Calling systemd-cryptenroll with --tpm2-pcrs would allow you to manually pick a set of options. I believe Bitlocker uses 0, 2, 7, and 11 (11 being an OS specific register rather than a spec-defined one), which is why firmware updates often make you re-enter your Bitlocker key. Some people choose to only record the secure boot state, relying on the firmware to validate its own updates and config, which means you don't need your recovery key after firmware updates as long as the secure boot state remains the same.
Not taking secure boot state into account makes the entire setup rather easy to bypass, but you could do it to make your setup harder to break while still protecting against the "thief steals my SSD but not my laptop" scenario.