[mjg59]

Some additional context: when the system boots, the secure boot key that was used is recorded into PCR 7[1] in the TPM. This means that booting an OS signed with the Windows signing key will result in a different PCR 7 value to booting an OS signed with the 3rd party signing key. If you care about which signing key was used, you can provide a secret to the TPM and ask the TPM to only release (or make use of) that secret if PCR 7 has a specific value. This means it's possible to configure an OS such that it will only be able to access its secrets if PCR 7 has the expected value. An attacker who intercepted the laptop before it was delivered to its owner could obviously subvert this by sealing the secret to the incorrect PCR 7 value, but such an attacker could also just reconfigure the firmware to trust the 3rd party CA before the owner received it. There isn't a clear description of what threat model this design is intended to protect against, or why alternative approaches weren't used to achieve the same goal.

[1] Modern TPMs have 24 PCRs that can be used to measure different parts of the boot process, but the general expectation is that only 0-7 will be used by the firmware. On UEFI systems, PCR 7 contains information about what the platform's secure boot policy is, and which keys were used to verify the boot process. Booting something signed with a different key will result in PCR 7 having a different value, which is something that can be detected by tying encryption keys to specific PCR values.

[zinekeller]

No contest, but if you are actually a person who is paranoid about this but still requires to have access to Windows software (in an enterprise setting), you would actually check the UEFI and reinstall Windows. If you're actually being attacked by state-sponsored actors the risk management is so different that I don't think it can be discussed here fairly (mainly because it's a case-by-case matter).