Threat Modeling before the First Board Spin
The cheapest time to fix a security flaw is before the board exists. A change that is one 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. Once the product is in the field, some fixes are simply impossible, because the hardware cannot be changed.
That 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 gap while it is still a schematic edit is the difference between a free fix and a recall.
Threat Modeling, Applied on Paper
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 in 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. The most consequential security properties of a device are hardware properties, and the window to influence them closes when the design is committed.
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 a competitor with a device on a bench would want to extract drives a decision about a secure element; user data 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. Walked across the planned components, a method turns a vague worry into a concrete list of threats and the design decision each one demands.
| Component | STRIDE threat | What the attacker does | Design decision |
|---|---|---|---|
| Firmware update path | Tampering | Modifies the image | Require signed updates |
| Spoofing | Stands up a fake update server | Authenticate the server and sign images | |
| Elevation | Downgrades to a vulnerable version | Anti-rollback counter | |
| Debug interface | Information disclosure | Dumps flash over SWD | Fuse RDP in production |
| Elevation | Halts the core and patches RAM | Authenticated debug |
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.
The Decisions That Get Frozen
A handful of design-phase decisions outlast everything else, because fabrication makes them permanent:
- Where the keys will live. Choosing a secure element or a key-storing microcontroller, and routing the board for it, is the difference between keys an attacker can read from flash and keys that never leave hardware. It is nearly impossible to retrofit.
- The debug and recovery story. Whether the debug port can be fused off, whether authenticated unlock exists for repair, and whether there is a signed recovery path all depend on parts and interfaces chosen now. Lock debug in production, but plan the repair path, or production is where you discover you stranded it.
- The update mechanism. Signed images, verification in the boot path, and anti-rollback storage have to fit on the board. Bolting a secure update onto a device that was not designed for it 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 engineers implement and testers verify. Each threat 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. By the time the board spins, a model kept alive through design gives the team a current threat list, a set of implemented requirements, and a test plan, all derived from threats considered while they were still cheap to address.
The Payoff
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 secure-by-design 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.
