> anyone who can get close enough (physically or digitally) to one for it to matter isn't going to be hindered by some pesky firmware lock. I mean, being unabl

> anyone who can get close enough (physically or digitally) to one for it to matter isn't going to be hindered by some pesky firmware lock. I mean, being unable to modify secure embedded systems by getting close to them "digitally" is the whole positive point of the much-reviled-in-personal-computing Trusted Computing Base paradigm. If Intel CPUs can cryptographically verify that microcode updates come only from Intel, and that the bootloader ROM is signed by the manufacturer key stored in the CPU's own TPM, then the microcontrollers in critical systems like these should be doing no less. "Unlocking" such a system to free modification by the installation IT administrator really does lose you some quite-powerful security advantages vs. having an end-to-end-secure logistical pipeline for updates direct from the manufacturer to your microcontroller, that not even the site admin can tamper with. Also, on a tangent — with really-critical embedded systems, there are ways to prevent physical proximity from giving someone the keys to the kingdom as well. For example: making the system a distributed-majority-consensus system run across several secure installations, where you'd need to physically penetrate several installations at once — hopefully all with independently-designed security policies — in order to get the system as a whole to do something else. Where any timing slip-ups would reveal one of the systems as faulty, and prompt an immediate [probably armed] investigation response.