Oddbean

and false “verifiability” in HWWs, as their designs also mean it makes verification impossible (SE code) or requiring somewhat costly tools to work around security measures (MCU) having NDAd secure elements is arguably better for security than “verifiability” as in both cases the manufacturer could slide in a backdoor but one means you usually end up opting for worse parts

My take - the take I had adopted for @WalletScrutiny - is that a "secure element" does not get in the way of verifiability iff it does never handle the private key material. It may contribute "true randomness" and it can be used for a key encryption key but the parts that actually touch the keys must be public source and binaries reproducible and the device itself has to show the actual hash of the binary you are trying to install prior to installation.

still, a pointless attempt. coldcard for example has a dedicated privileged flash segment (the “boot ROM” which is not ROM at all) that handles retrieving the key and could store the PIN/root key in its small flash segment it is not truly verifiable without ripping out the chip and faulting it

the goals of security and verifiability are inherently conflicting as to verify you need a chip that anyone can check the content of, but for security you want a chip that no one can see the content of the MCU may have open source code but the moment it is compromised it could log your PIN on next attempt

That is why I came to like the combination of SE and MCU where the SE is oblivious to what the MCU stores but the MCU stores all secrets with a key only the SE knows. What's wrong with that? Now the auditor can treat the SE as a black box that yields a key encryption key only if provided with a secret but bricks itself if the secret cannot be provided in x attempts. You say, Coldcard could do something shady in their not-a-ROM boot ROM? But that's MCU side, right? So can we audit it? Or are you talking about the hardware not being what they claim it is?