I do want to note about the secure, update claim that there is a tension between providing systems that can't receive false updates and giving users control of their hardware. Solutions for the former often prevent the latter.

An alternative would be to have the firmware show a description of the signed content, like version information, that the user must OK. It might show it along with the current version with a warning if versions are downgrading or the whole thing is changing. The warning might tell you to be sure of the source of this update. If it's the same software, and another version, it might be set to automatically update.

If it's the lowest-level, unrecoverable firmware, I like it being hard for attackers to change it. One idea I used to push was putting that in EEPROM with a jumper (or switch) required to update it. The software will have already performed numerous checks from the kernel state to the payload with external inputs (eg networking) shut down. If malicious, it can't do anything without that physical interaction.

The regular, update mechanism which uses other storage is in that EEPROM. It has highly, security-enhanced mechanisms for updates. It might even have it's own partition if it's a microkernel-based system. So, we have one that's hard to attack with software while the other takes physical attack or social engineering. Also, I think a Chromebook or something implemented a ROM/flash combo.

I feel like there are better ways to make it hard to push malicious updates, while still allowing a user to flash their own devices.

For example: manufacturer bakes in their public key and a per device public/private key pair. The bootloader checks firmware updates against the manufacturers public key and the per device public key. The per device private key is only readable with hardware access via serial or USB etc. The user can extract their device’s private key to be able to sign their own firmware updates. Additionally, the bootloader could support adding new public keys to verify firmware with, so long as the payload to add the new public key was signed by the per device key. This would simplify getting updates from e.g. OpenWRT if they have their own key pair they sign with, vs requiring each user to sign each firmware update with their personal key.