Blowing Fuses: Locking Down a Production Device
Most secure microcontrollers have one-time-programmable fuses that permanently enable protections: locking debug ports, enabling secure boot, and anchoring keys. Blowing them is how a device goes from development to truly hardened, and forgetting to is one of the most common and most expensive misses I find.
The One-Way Switch
A fuse is a tiny element inside the chip that can be changed exactly once, from its blank state to a programmed one, and never back. That permanence is the entire point. A setting an attacker can flip back in software is not a security boundary, but a fuse, once blown, holds its decision against software, against a reset, and against the manufacturer.
Designers use fuses to make the most important protections sticky. The question for any device is not whether the chip has these fuses, almost all secure parts do, but whether anyone actually blew them before the unit shipped. The gap between the capability and the act is where most of the trouble lives.
What Fuses Control
The fuses that matter gate the protections you most want enforced: disabling JTAG and SWD so the debug port cannot read memory, enforcing signature verification at boot so the chip refuses unsigned firmware, and locking a key or its hash so it cannot be altered. Each of those is optional until a fuse makes it mandatory.
There are usually others too, like disabling a serial bootloader or a test mode. The common thread is that every one of them converts a software-configurable convenience into a hardware-enforced rule. Before they are blown, a determined attacker can often just turn the protection off.
Reading the Fuse State
The first thing I check on a unit is what state its fuses are actually in, which the vendor tool reports directly. On STM32, that means reading the option bytes and the readout-protection level over the debug interface.
# read the option bytes / protection level from a connected unit
STM32_Programmer_CLI -c port=SWD -ob displRead Out Protection: RDP : 0xAA (Level 0, no protection) nBOOT0 : 1 Write Protection : none # RDP 0xAA means debug and flash read are fully open
An RDP Level 0 reading on what is supposed to be a production unit is a finding on its own. It means the debug port can read flash, the firmware is exposed, and none of the chip’s protection was actually engaged. The tool just told you the door is open.
Why They Are One-Time
The value of a fuse comes precisely from the fact that it cannot be undone, even by someone with full access to the chip. A reversible setting invites an attacker to reverse it. A fuse removes that move entirely, which is what lets a downstream system trust that the protection is really on.
That same permanence is what makes blowing them a decision to take seriously. There is no second attempt and no recovery if you lock something you needed open. The irreversibility that makes fuses trustworthy is also what makes the order of operations and the repair plan matter so much.
The Shipping Mistake
Development boards run with fuses unblown so engineers can debug freely, reflash at will, and connect a probe whenever they need to. That is correct for development. The danger is shipping production units in the same state, with full debug access and verification disabled, because no one added the fuse step to the manufacturing flow.
This is rarely a knowledge problem. The team knows the fuses exist. It is a process problem: the lock step was never made a required, verified stage of production, so units leave the line in their open development state and nobody notices until an assessment, or an attacker, reads the firmware straight off the debug port.
Auditing a Production Unit
Confirming the lock happened means testing a finished unit the way an attacker would, not trusting the build paperwork. Try to read flash over the debug port. If it succeeds, the fuses were never blown, regardless of what the process document claims.
# attempt to read flash from a shipped unit; this should FAIL on a locked device
STM32_Programmer_CLI -c port=SWD -r32 0x08000000 0x100 fw_head.binError: Read operation failed (RDP active?) <- GOOD: protection engaged # vs. on an unlocked unit: # Reading 256 bytes... OK <- BAD: production unit is wide open
A read that fails with a protection error is the result you want on a shipped unit. A read that succeeds means the device is unlocked, the firmware is exposed, and the manufacturing process let an open unit through. The test takes a minute and it is the only way to be sure.
Anchoring the Key, Not Just Locking Debug
Fuses do more than disable debug. They anchor the root of trust by storing a public key hash that the boot ROM checks every signature against. Once that hash is fused, the chip will only run firmware signed by the matching private key, which is what makes secure boot real rather than aspirational.
A device that enabled secure boot in software but never fused the key hash is trusting a check it can be talked out of. Fusing the key anchor is the step that ties the whole verified-boot chain to something an attacker cannot rewrite, and skipping it quietly defeats the rest of the design.
The Order of Operations
Sequence matters because each step is permanent. Provision the keys and confirm the device boots its signed firmware before you lock anything. Then enable secure boot and the key anchor, verify a signed image still runs and an unsigned one is refused, and only then blow the debug-disable fuse as the last step.
Doing it in the wrong order strands units. Lock debug before you have confirmed the signed boot works and you have no way to diagnose the unit that will not start. The careful sequence, provision, verify, then lock, is what keeps a manufacturing batch from turning into a pile of bricks.
Plan for Repair First
Because the operation is permanent, locking everything can strand a unit that later needs field diagnosis or a firmware recovery. Decide how legitimate access will work before you close the door: an authenticated debug unlock that requires a cryptographic challenge, or a signed recovery path that re-flashes authentic firmware without exposing raw debug.
The worst outcome is locking a device fully, then discovering a fielded unit needs service and there is no way in. Designing the recovery story first, and proving it works on a locked unit, is what lets you commit to the lockdown with confidence instead of regret.
Verifying After Blowing
Blowing the fuse is not the end, confirming it took is. Read the fuse and protection state back after programming, and re-run the attacker’s read test, so the manufacturing record reflects a verified locked state rather than an assumption.
# after locking, confirm RDP advanced and debug read now fails
STM32_Programmer_CLI -c port=SWD -ob displ | grep RDPRDP : 0xBB (Level 1, flash read protected) # and the earlier read test now returns a protection error -> locked and verified
A protection level that advanced and a read test that now fails together prove the lock engaged on this specific unit. Recording that verification per batch, or per unit, is what turns “we blow the fuses in production” from a claim into something you can stand behind.
The Step That Gets Forgotten
The failure here is almost never ignorance of fuses, it is a manufacturing flow that never includes blowing them. Engineering samples run unblown so the team can work, and unless someone explicitly adds the lock step and a verification check, production units ship in the same open state.
The fix is process, not knowledge. Make fuse programming a required, audited stage of manufacturing, sample finished units to confirm it happened, and treat an unlocked production unit as a line defect. The chips give you strong protection. A disciplined manufacturing step is what actually turns it on.
A Production Lock-Down Checklist
Before a device ships, a short checklist closes the gap. Confirm keys are provisioned and the device boots signed firmware, secure boot and the key anchor are enabled, an unsigned image is refused, the recovery path works on a locked unit, and the debug-disable fuse is blown and verified by a failed read test.
That list is short and every item is a yes-or-no question with a known way to check it. A product that runs it, and records the results, has decided deliberately and verifiably which protections are on before the device leaves the line, rather than discovering after a breach that they were never enabled.
Where This Fits
Reviewing whether a product’s hardware protections were actually enabled at manufacturing, not just designed in, is a core part of a hardware penetration test and a pre-production security review. If you want your production lock-down audited on real shipped units, that is the kind of work we do at Berkner Tech.