Burning in the firmware would do it, but I&#x27;m not sure they want to give up the ability to update this software. I&#x27;d say a better plan would be to give the SE a small amount of internal storage. Two 256-bit fields would do. Place a master key in one field, place a secure hash of the current firmware version in the other. On boot, if the firmware hash doesn&#x27;t match but the firmware signature is valid, rewrite the master key with a new random value. Then build the firmware to allow updating the hash, but only if the phone is unlocked. The normal update procedure would then be: install update, tell SE about the new hash, reboot. A &quot;forgot passcode&quot; update would be unable to do that second part, and would then effectively wipe the phone.<p>You might want a third field, so you can store both &quot;old&quot; and &quot;new&quot; firmware hashes to temporarily bridge the gap in case the procedure got interrupted at just the wrong moment. But the point being, you could allow updates without this vulnerability, and it shouldn&#x27;t be particularly hard.<p>Obviously, that doesn&#x27;t mean they&#x27;ve actually done it yet. I imagine they will do something like your scheme or mine for the next hardware design.