I feel like the obvious "How can we prevent this?" solution is "Don't fail open if your SPI transactions fail"? The most straightforward implementation of this would be for the firmware to read from the security EEPROM to obtain a hashed password of some sort and then verify that the entered password satisfies that, and if that read fails simply refuse to either enter the firmware or boot depending on config - that's sufficient to deal with the screwdriver attack. However, that still allows an attacker to replace the security EEPROM with something that simply provides a known hash, so the next level would be to encrypt the stored hash with the TPM (which will use an encryption key that's specific to the motherboard in question) which prevents that attack. At which point the attacker removes the TPM from the board, puts their own board on those lines, and sends back whatever they want and then they still win.

This is a legitimately hard problem to solve! Unless firmware starts using authenticated sessions with TPMs (in which the traffic over the easy to sniff bus is encrypted), swapping out the TPM is going to be a plausible vector for someone with physical access to the machine. Moving to fTPMs (in which the TPM stack runs as a software component on a segregated chip somewhere else on the device, such as the Intel Management Engine or the AMD Platform Security Processor) or an on-die TPM (such as Microsoft's Pluton) makes it massively more difficult to carry out this kind of attack.

tl;dr - unless you're introducing strong cryptography into things, trying to make security happen over unauthenticated buses is probably not going to work well for you