Before shipping your first thousand units, confirm ten things: production signing keys are separate and protected, updates work end to end, debug interfaces are closed, no shared default passwords exist, SBOMs are generated, vendor SDKs are recorded, a disclosure contact is published, an owner handles advisories, rollback works, and a support end date is decided.
The ten checks
| # | Check | Evidence you can show |
|---|---|---|
| 1 | Production keys separate from development keys | Key inventory, bootloader fingerprint |
| 2 | Signing key not on a laptop | Description of signing service or token |
| 3 | Update tested from first firmware to latest | Test log, including power loss |
| 4 | Failed update reverts | Test log from a bench unit |
| 5 | Debug ports closed on production units | Sample unit test |
| 6 | No shared default credentials | Provisioning record |
| 7 | SBOM for firmware and app | Files stored with release |
| 8 | Vendor SDKs recorded with versions | Table with owner |
| 9 | Disclosure address live and monitored | Published page, test email |
| 10 | Named owner for advisories | Rota or name in the runbook |
Each row is a yes or no, and each yes needs an artifact. A checklist with no evidence is a wish list.
Why the first thousand are special
By the first production run, hardware choices are fixed. Software can change, if the update path works. Anything you cannot fix over the air becomes a permanent property of every unit. That is why the checks lean toward the update channel and the physical interfaces, which are the things you cannot patch later.
How to run the review
- Schedule two hours with firmware, hardware, app and backend owners.
- Walk the table. Anyone can say no, and a no is a task with a date.
- Decide which noes block shipment. Items 1, 3, 5 and 6 usually should.
- Store the filled table with the batch record.
- Re-run it before the second production batch, because things drift.
What a customer may ask later
Enterprise buyers often ask how you handle updates, how you track component vulnerabilities and how researchers can report problems. The table is a ready source for truthful answers. Do not describe controls you have not built, and do not claim certifications you do not hold.
If you cannot tick a box
Not every item will be done on day one. For each gap, write the risk in one sentence, an owner and a date. Some gaps are acceptable for a small first run, such as a manual process that will later be automated. Others, like shared default credentials, are hard to undo once units are in homes. Decide in advance which are which, so the launch conversation is about facts and not about deadlines.
Related reading
For component records see what SBOM a hardware startup needs before it ships. For release records see which files to archive for every firmware release.
Quick check
Which item do startups skip most often?
Testing recovery from a failed update on real hardware with power loss. It is tedious, and it is the failure that bricks devices.
Is ten items enough?
It is a starting set for a first run. Add rows as your product adds interfaces and features.
Sources
Last reviewed: 19 October 2026.
