A Pre-Production Hardware Security Checklist
Before a connected product ships is the last cheap moment to fix a security problem. After production, fixes mean recalls or field updates; after the design is locked, hardware fixes mean respins. A pre-production security checklist catches the recurring issues while they are still cheap to address. Here is the checklist I walk before a device goes to manufacturing.
Why a Checklist
A checklist is not a substitute for a real assessment, but it is a fast, repeatable way to catch the issues that show up again and again. Most shipped-device findings are not exotic, they are the same handful of misses: an open debug port, a key in flash, an unsigned update. A checklist ensures none of those obvious-in-hindsight problems slips through because everyone assumed someone else had checked.
The value is in the timing. Run at pre-production, the checklist catches issues while changing them is still a configuration or a firmware edit rather than a recall, and it turns security from a vague worry into concrete yes-or-no questions a busy team will actually answer.
Debug Interfaces
The first and highest-value section is debug. JTAG and SWD give direct access to memory and execution, so each item is verified empirically on a finished production unit, not trusted from a configuration file.
- JTAG and SWD disabled or authenticated on production units, verified by a failed connect
- Readout protection at the intended level, verified by a failed flash read
- UART console disabled, password-protected, or non-interactive in production
- Test points carrying debug signals not populated or accessible
- Authenticated debug or a signed recovery path exists for legitimate repair
The recurring failure is a device configured to lock debug but shipped unlocked due to a missed fuse or option byte. A failed connect and a failed read are the proof; the configuration file is not. This section alone catches one of the most common serious findings in the field.
Firmware Protection
The firmware section assumes the image can be extracted and asks what that extraction yields:
- No hardcoded credentials, API keys, or private keys in the image
- No debug services or test code in release builds, verified by an image scan
- Firmware encrypted if its contents are sensitive, with the key in hardware
- Sensitive data not logged or left in the image
- Software bill of materials produced, with no known-vulnerable components
Running the same grep an attacker would, over your own release image, finds the embedded key before the attacker does, which is the whole point of checking pre-production.
Keys and Cryptography
Where keys live decides whether the cryptography is real, so this section gets careful attention:
- Sensitive keys in a secure element or fused storage, not readable flash
- Per-device keys, not one shared key across the fleet
- Keys generated from a real random source, a hardware RNG
- Authenticated encryption such as AES-GCM, no ECB, unique IVs per message
- Provisioning never exposes private keys to the manufacturing line
The two highest-impact items are a single shared key across all units and a key sitting in readable flash, either of which can turn one compromised device into a fleet-wide break. Confirming per-device keys in hardware storage before the line spins up is far cheaper than discovering the problem after launch.
Secure Boot and Updates
This section confirms the device runs only authentic code and can be safely updated, all tested by trying to run and install unauthorized images:
- Secure boot enabled, and an unsigned image is refused, verified on a unit
- Firmware updates require a valid signature before installation
- Anti-rollback prevents installing older, vulnerable versions
- Update mechanism cannot be abused to install attacker firmware over the network
- Signing key protected in an HSM or controlled signing service
The verification is empirical: flash an unsigned image and confirm it will not run, attempt a downgrade and confirm it is refused. An unsigned-firmware path is a route to running attacker code, sometimes remotely, so confirming the chain of trust holds on a real unit is among the most important checks on the list.
Physical and Interface Hardening
This section covers the rest of the physical attack surface, scaled to the threat model:
- No secrets transmitted in the clear over inter-chip buses such as SPI and I2C
- Unused interfaces and ports disabled in production
- Boot-mode strap pins not trivially abusable to force a bootloader
- Tamper response appropriate to the threat model, where applicable
- External flash protected, or its contents non-sensitive given other controls
Not every device needs tamper meshes and decapping resistance, but the basics, no keys crossing a bus in the clear and no unnecessary open interfaces, apply broadly and close the easy physical findings an assessment would otherwise flag.
Network and Radio Surface
For a connected product, the most exposed surface is often the one reachable without touching the device:
- Only necessary ports and services exposed, with no debug services listening
- TLS used for cloud comms, with certificate validation enforced
- Wireless pairing and bonding authenticated, with no fixed-code or weak RF
- Local network not treated as a trust boundary, with commands authenticated
- Device API authorization checked per object, not just authentication
Confirming certificate validation and per-object authorization pre-production catches flaws that scale across the whole fleet over the network, which are among the worst to discover after launch.
Process and Documentation
The final section steps back to process: is there a threat model, are the security requirements written and tested, is there a software bill of materials, and is there a plan for handling vulnerabilities found after launch. A device can pass every technical item by luck and still lack the process to stay secure as it ages. Confirming the threat model, the requirements traceability, and the postmarket plan exist is what distinguishes a product that is secure now from one that will remain defensible over its service life.
Using the Checklist Well
The checklist is a floor, not a ceiling. Used as a pre-production gate, it ensures the obvious problems are caught cheaply and tells you whether the device is ready for a deeper test or still has basic gaps to close first. Walked honestly, with every item verified on a real production unit rather than assumed, it prevents the most common and most embarrassing field findings, the last inexpensive opportunity to fix security before a device ships.
Where This Fits
Running a pre-production security review, and the deeper assessment a product’s threat model calls for, is the work I do to catch issues while they are still cheap to fix. If you want your product checked against this list before it ships, that is the kind of work we do at Berkner Tech.
