Is Secure Boot v2’s eFuse Locking Defense Targeting a Valid Attack Scenario?
Posted: Sun Aug 02, 2026 9:08 am
When Secure Boot v2 is enabled, it write-protects the WR_DIS_RD_DIS eFuse to prevent the public key digest block from being read-protected. The stated reason is to prevent an attacker from making the public key digest unreadable, which would break signature verification.
But this threat model seems contradictory to me. If an attacker already has code execution capability on the device and can call eFuse write APIs to corrupt the public key digest block, then they have already fully compromised the device. At that point, why would they bother corrupting eFuses at all? They can already read decrypted firmware from memory, exfiltrate data over the network, or manipulate runtime logic directly. Destroying the eFuse would only kill the device and eliminate their own foothold.
So is this protection actually solving a real threat, or is it defending against a scenario that cannot exist independently, meaning an attacker capable of calling eFuse APIs but somehow not capable of doing anything more directly useful with full code execution?
But this threat model seems contradictory to me. If an attacker already has code execution capability on the device and can call eFuse write APIs to corrupt the public key digest block, then they have already fully compromised the device. At that point, why would they bother corrupting eFuses at all? They can already read decrypted firmware from memory, exfiltrate data over the network, or manipulate runtime logic directly. Destroying the eFuse would only kill the device and eliminate their own foothold.
So is this protection actually solving a real threat, or is it defending against a scenario that cannot exist independently, meaning an attacker capable of calling eFuse APIs but somehow not capable of doing anything more directly useful with full code execution?