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. It also turns security from a vague worry into a concrete set of yes-or-no questions the team can answer and act on, which is exactly what a busy team needs to actually do the checks rather than intend to.
Debug Interfaces
The first and highest-value section is debug. JTAG and SWD give direct access to memory and execution, so the checklist confirms they are disabled or locked on production units, verified by testing a finished unit, not by trusting the configuration. It also covers UART consoles and any test points that expose debug.
DEBUG CHECKLIST [ ] JTAG/SWD disabled or authenticated on production units (verified by failed connect) [ ] Readout protection at the intended level (verified by failed flash read) [ ] UART console disabled, password-protected, or non-interactive in production [ ] Test points carrying debug signals not populated / not accessible [ ] Authenticated debug or signed recovery path exists for legitimate repair
Each item is verified empirically on a production unit, because the recurring failure is a device that was 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 asks what an attacker who reads the flash would get, and how easily they could read it. It covers whether the firmware is encrypted, whether secrets are present in the image, and whether the storage is easily read. The honest baseline assumption is that the firmware can be extracted, so the question is what that extraction yields.
FIRMWARE CHECKLIST [ ] No hardcoded credentials, API keys, or private keys in the image [ ] No debug services or test code in release builds (verified by 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; no known-vulnerable components
Scanning the actual release image for credentials, keys, and debug services catches what code review can miss, because the shipped binary is what matters. A team that runs the same grep an attacker would, over their 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. It confirms keys are stored in hardware where possible, that keys are per-device rather than shared across the fleet, and that the cryptographic usage, modes, IVs, randomness, follows safe practice.
KEY / CRYPTO CHECKLIST [ ] 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 (hardware RNG) [ ] Authenticated encryption (e.g. 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 after launch that every device shares one extractable key.
Secure Boot and Updates
This section confirms the device runs only authentic code and can be safely updated. It checks that secure boot is enabled and verified, that updates are signed and checked before installation, and that downgrade to a vulnerable version is prevented, all tested by trying to run and install unauthorized images.
SECURE BOOT / UPDATE CHECKLIST [ ] Secure boot enabled; 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 / 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 actually 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: exposed buses that leak data, accessible flash chips, and any interface that should not be reachable in production. It asks whether sensitive data crosses a bus in the clear and whether the device resists basic physical tampering appropriate to its threat model.
PHYSICAL / INTERFACE CHECKLIST [ ] No secrets transmitted in the clear over inter-chip buses (SPI/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 (if applicable) [ ] External flash protected or its contents non-sensitive given other controls
Not every device needs tamper meshes and decapping resistance, so this section is scaled to the threat model. But the basics, no keys crossing a bus in the clear, no unnecessary open interfaces, apply broadly, and checking them pre-production closes the easy physical findings that an assessment would otherwise flag.
Network and Radio Surface
For a connected product, the network and radio surface gets its own section. It confirms that services are authenticated, that TLS is used and certificates validated, that wireless pairing and encryption are sound, and that the device does not expose more than it needs on any network it joins.
NETWORK / RADIO CHECKLIST [ ] Only necessary ports/services exposed; no debug services listening [ ] TLS used for cloud comms, with certificate validation enforced [ ] Wireless pairing/bonding authenticated; no fixed-code or weak RF [ ] Local network not treated as a trust boundary; commands authenticated [ ] Device API authorization checked per object, not just authentication
These items connect the hardware checklist to the connected reality of the product, because the most exposed attack surface is often the one reachable without touching the device. 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. These confirm the device was built securely, not just that it passes the technical checks today.
A device can pass every technical item by luck and still lack the process to stay secure as it ages and as new vulnerabilities emerge. 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, which for connected hardware is the harder and more important property.
Using the Checklist Well
The checklist is a floor, not a ceiling. It catches the recurring, high-impact issues efficiently, but it does not replace a real assessment for a product whose threat model warrants one. Used as a pre-production gate, it ensures the obvious problems are caught cheaply, and it 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, the checklist prevents the most common and most embarrassing field findings. It is the last inexpensive opportunity to fix security, and a team that uses it well ships products that have, at minimum, closed the doors that attackers reach for first.
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.