Things that would mitigate this to some extent: 1) Requiring an additional factor for disk encryption in addition to the TPM data. You want the TPM to be invol

Things that would mitigate this to some extent: 1) Requiring an additional factor for disk encryption in addition to the TPM data. You want the TPM to be involved in order to be able to detect whether the boot environment has been modified and refuse to hand over the key in that case, but this case is an example of why automatically handing over the FDE key at boot isn't ideal 2) The use of parameter encryption. TPMs support the establishment of sessions that include key exchange, and can then encrypt responses sent to the OS. This isn't ideal - verifying that you're communicating with a real TPM is somewhat convoluted at this point, so someone with physical access can interpose the TPM and MITM the key exchange. This is a substantially more invasive attack, though. I'm surprised that Windows isn't doing this by default, which makes me suspect that there may be some corner cases that make this more difficult than I imagine. 3) Storing the VPN credentials in hardware. Once the attackers had access to the filesystem, they could simply copy the credentials. If the VPN key were actually generated on the TPM then this could be avoided. In order to get on the VPN, the attackers would have had to modify the filesystem in order to let them put the disk back in the original machine and boot it. This would mean they'd need to retain access to the machine for as long as they wanted VPN access, which increases the chances that the machine's absence would be noted and its credentials revoked. 4) Requiring user auth before any amount of VPN access is granted. It's a lot easier to manage systems if they join the VPN without requiring that a user authenticate to the remote endpoint, but this is kind of a failure of the VPN model - once you're on the VPN, you've got access to everything on the VPN that doesn't require auth, and there's probably (for one reason or another) a lot of that. As mentioned elsewhere in the comments, using an fTPM (ie, one that's running on the Management Engine or in the Platform Security Processor) would avoid this (there's no convenient low speed bus for you to probe in that case), but I'm kind of reluctant to argue that the tradeoff is worth it.