Since I started really playing with hardware/software integration (hobby level) a couple of decades ago, and also knowing what I learned from various efforts I'

Since I started really playing with hardware/software integration (hobby level) a couple of decades ago, and also knowing what I learned from various efforts I've been involved in at employers to "bandaid patch" in security (ie, logins, passwords, access control, etc) - and how it never works out, I've since advocated for the implementation of security controls first, whether implementing a hardware and/or software solution, and one of those controls, if hardware is involved, should be a physical "all-stop" cut-the-power control, manifestly separate from any "software" (whether implemented in hardware logic or otherwise). Design the security/safety system up front, for the task of the system being designed, for all potential failure modes - and then implement the first, and test the hell out of it, and document it thoroughly. Unfortunately, this tends to get shot down, until it is needed, and then it gets bandaid-patched in place, because usually at the point it is needed, a whole refactor of the code base is usually called for, and we can't have that, so "just fix it" becomes the call of duty. And it never works out properly. Things get missed, security is effectively out the window, until something happens, with the refrain of "why did this occur" and of course nobody wants to take the blame for "I told you so". Unfortunately, even implementing such a security system first will only get you so far, and it is still possible that something might be missed, and potentially be the cause of a safety critical issue. But hopefully, most if not all of those extreme events can be caught first in the system, by some part of it, and what's left will be relatively minor.