There's a number of issues with discrete TPMs and physical security. Before I describe them, there is good news: some CPUs can run a firmware TPM in an ME or a secure enclave, and using it does not involve a bus on a motherboard that could be hacked into. The problems with discrete TPMs:

- the BMC and BIOS don't use encrypted sessions -- their communications with the TPM can be snooped (read: bitlocker keys can be stolen) and tampered with (read: malware can be excluded from PCR measurements with the help of a physical attacker)

- to authenticate the TPM when using encrypted sessions the BMC and BIOS would need to be able to store a public key for the TPM somewhere that isn't easy for malware to tamper with -- this means that even with encryption there would be a TPM impersonation / MITM attack

- even using encrypted sessions, if the attacker can force the TPM to reset without also resetting the CPU, then the attacker can make the PCRs match golden state (i.e., without the malware measured into the PCRs)

The first point is easy enough to address -- it's just a matter of code.

The second point is very difficult to address.

The third point would probably require changes to the CPU and additional design and standardization. It's just very difficult to strongly bind the TPM's resetCount to the CPU's state to ensure that both always reset together.

The only current solution to all three problems is to use firmware TPMs (fTPMs) where available.

Of course, for things like servers in secure racks in secure data centers, this is all really not a problem. But for laptops, it is.

If an fTPM is not available, there's always the possibility of adding physical protection to the bus (burying it deeper in the PCB, using resin, etc.).