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.