So what can you do about it?

Full Disk Encryption is an option, but that’ll entail needing the use the IPMI console to enter the password at every reboot, essentially turning it into a manual operation.

One can do LUKS with access via dropbear in initramfs.

If you're lucky during network install, you'll never need out of bound access.

But rebooting is still a manual process.

If you have physical access twice, full disk encryption usually doesn't help really at all. IPMI seems about as powerful as physical access.

If you just ignore random reboots, sure. But why would you?

I don't think that'd be necessary, couldn't you make changes and then wait for natural reboots?

You couldn't, not via console access anyway.

However, if the attacker gains RCE many IPMI implementations theoretically allow for DMA, but this is a significantly more complex attack to mount in practice with no public PoCs available.

- Bring your own network and limit LOM/IPMI to a private network accessible by VPN only.

- Or, request a private network with no connectivity and a VPN device connected on that private network.

- Or, hardware disable LOM.

There's no reason you shouldn't request an ASA from your datacenter provider in this day and age.

Use AWS/GCP/Azure

doesn't that shift the vulnerability/risk to the configuration of the firewall, security policy, and machine configuration?

Those cloud computing vendors know better than give open access to the word to your infra by default.