Threat Modeling Before the First Board Spin
The cheapest time to fix a security flaw is before the board exists. A change that is a line in a schematic during design becomes a respin costing weeks and thousands of dollars once the board is fabricated, and an impossibility once the product ships. Threat modeling in the design phase is where security is cheapest and most effective, and it is the step teams most often skip.
The Cost Curve of a Security Fix
The cost of fixing a flaw rises sharply with how late it is caught. In design, adding a secure element or routing debug pins to a removable header is a schematic edit. After fabrication, the same change is a board respin. After production, it may require a recall. After the product is in the field, some fixes are simply impossible because the hardware cannot be changed.
This curve is the entire argument for early threat modeling. The hardware decisions that most affect security, where keys live, whether debug can be locked, whether there is room for verification, are made in design and become permanent at fabrication. Catching a security gap while it is still a schematic edit is the difference between a free fix and a recall.
What Threat Modeling Is
Threat modeling is the structured exercise of asking, before building, what could go wrong: what an attacker wants, how they might get it, and what in the design stands in their way. It is not a tool or a scan, it is a way of thinking applied early, producing a list of threats and the decisions needed to address them.
Done at design time, it works from the architecture rather than from a finished product. You reason about the planned components, the data flows, and the trust boundaries on paper, identify the threats to each, and bake the defenses into the design before anything is committed to silicon. The output feeds directly into the schematic, the BOM, and the firmware architecture.
Hardware Decisions Are Permanent
Software can be patched; hardware largely cannot. Whether the design includes a secure element, whether the debug port can be fused off, whether there is a hardware root of trust, whether sensitive buses are routed where they can be probed, these are decided in design and frozen at fabrication. A missing secure element cannot be patched in later.
That permanence is why threat modeling has to happen before the board spin, not after the firmware is written. The most consequential security properties of a device are hardware properties, and the window to influence them closes when the design is committed. A threat model that arrives after fabrication can only document the gaps it is too late to close.
Start From Assets and Attackers
Begin with what the product must protect, the assets: the firmware, the keys, user data, the device’s integrity, the ability to control it. Then characterize the attackers: a remote attacker on the network, a local attacker in radio range, an owner with physical access, a thief, a competitor wanting to clone the product.
Pairing assets with attackers frames every later question. A signing key that a competitor with a device on a bench would want to extract drives a decision about a secure element. User data that a remote attacker would target drives decisions about the network boundary. Starting here keeps the model grounded in real motives rather than an abstract catalog of attacks.
Apply a Structured Method
A method keeps the analysis complete. STRIDE prompts you to consider spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege against each component. Attack trees decompose each attacker goal into the steps required. Both turn a vague what could go wrong into a systematic enumeration.
DESIGN-PHASE THREAT MODEL (excerpt, STRIDE per component) COMPONENT: firmware update path Tampering -> attacker modifies image -> require signed updates Spoofing -> fake update server -> authenticate the server / sign images Elevation -> downgrade to vulnerable ver -> anti-rollback counter COMPONENT: debug interface Info disclosure -> dump flash over SWD -> fuse RDP in production Elevation -> halt core, patch RAM -> authenticated debug
Walking a method like this across the planned components produces a concrete list of threats and the design decision each one demands. Each row becomes a requirement, sign updates, fuse the debug port, add anti-rollback, that can be designed in now while it is cheap, rather than discovered later when it is not.
Decide Where Keys Will Live
One design-phase decision dwarfs most others: where the keys live. Choosing a secure element or a key-storing microcontroller at design time, and routing the board for it, is the difference between keys an attacker can read from flash and keys that never leave hardware. This choice is nearly impossible to retrofit.
Threat modeling forces the question early, when the BOM and the layout can still accommodate the answer. If the model says a recovered signing key breaks the fleet, the design needs a secure element, and that has to be on the schematic before fabrication. Deferring the decision means defaulting to keys in flash, which the model would have flagged as critical.
Plan the Debug and Recovery Story
How the device will be debugged, locked, and recovered is a design-phase decision with permanent consequences. Whether the debug port can be fused off, whether authenticated debug is supported, whether there is a signed recovery path, all depend on choices made now about which parts and which interfaces the board includes.
A team that threat-models early decides deliberately: lock debug in production, but include authenticated unlock for repair, and a signed recovery mode for bad updates. A team that skips it discovers at production time that locking debug strands their repair process, and faces a choice between an insecure ship and a costly redesign. The model is what surfaces this in time.
Design the Update Mechanism
The firmware update path is a top threat-model target because it is the one channel explicitly allowed to change the device’s code. The model asks: are updates signed, is the signature checked before installation, is downgrade prevented, and what happens if an update is interrupted. These shape both hardware, room for verification, and firmware architecture.
Deciding these at design time means the verification fits, the keys are placed to support it, and the rollback protection is planned. Bolting a secure update mechanism onto a device that was not designed for it, no room for a second image, no anti-rollback storage, no verification in the boot path, is far harder than building it in from the model.
Feed the Model Into Requirements
A threat model that stays on a whiteboard is wasted. Its output should become security requirements, written, testable statements that engineers implement and testers verify. Each threat the model identifies becomes a requirement to mitigate it, traceable from the threat to the design feature to the test that confirms it.
This hand-off is what makes design-phase threat modeling real rather than ceremonial. The model says what could go wrong; the requirements say what the product will do about it; the tests confirm it was done. Without the requirements step, the insights evaporate and the same gaps reappear in the finished product as findings.
Revisit as the Design Evolves
A design-phase model is a starting point, not a one-time event. As the architecture firms up, a component changes, a feature is added, an interface appears, the model should be revisited, because each change can introduce or close a threat. A model updated through design stays relevant; one done once and filed does not.
Keeping it alive through the design phase means the security analysis tracks the product as it actually becomes, rather than as it was first sketched. By the time the board spins, the team has a current model, a set of implemented requirements, and a test plan, all derived from threats considered while they were still cheap to address.
The Payoff
Threat modeling before the first board spin is the highest-leverage security activity a hardware product has, precisely because of the cost curve. Decisions about keys, debug, verification, and trust boundaries are made once and frozen, and making them with the threats in view is what separates a product that is secure by design from one that is patched after the fact, expensively and incompletely.
The teams that do this ship products where the hard problems were solved on paper, where the secure element is on the board because the model called for it, where debug locks cleanly because recovery was planned, where updates are signed because the threat was named in design. That is what designing for security looks like, and it starts before the hardware exists.
Where This Fits
Running a threat model in the design phase, and turning it into requirements your team can build and test, is work I do before a board is ever fabricated. If you want a design-phase threat model for your product while the fixes are still cheap, that is the kind of work we do at Berkner Tech.