Nobody at a ten person startup should keep the production OTA signing key on a personal laptop. Put it in a hardware token or a managed signing service, let the release pipeline request signatures, and require a second person to approve each production release. One compromised account should not be enough to ship firmware.
Why the question is harder than it looks
Early teams sign with whatever works: a key file in a shared drive, or one engineer's machine. That is fine for a prototype. It becomes a problem the day a device in a customer's home trusts that key, because an attacker who gets the key can push a properly signed but malicious update. The Update Framework describes this exact case as key compromise, and says its design aims to minimise the impact of key compromises.
The point is not to buy expensive hardware. It is to make sure the key is not tied to one person or one disk.
Split the roles, even with few people
TUF names four top-level roles: root, targets, snapshot and timestamp. The root role lists the other roles and the keys each one trusts. Targets signs the list of files and hashes devices may download. Snapshot records the versions of the targets metadata. Timestamp has a short expiry and is normally re-signed automatically by an online key.
You do not need to adopt TUF to borrow the idea. A small team can use the same separation:
| Role | Who or what holds it | Online? |
|---|---|---|
| Root of trust key | Two founders, hardware tokens, in separate places | No |
| Release signing key | Signing service or token, used by the pipeline | Controlled |
| Freshness or timestamp key | Automated, low blast radius | Yes |
| Break glass copy | Sealed, documented, tested yearly | No |
The TUF metadata page says the timestamp key is the one used online for automatic re-signing, which is the pattern to copy: keep the online key weak in power, and the strong key offline.
A practical release gate
- The pipeline builds the image from a tagged commit.
- A second person approves the release in the repository, not in chat.
- The pipeline asks the signing service to sign. The key never leaves it.
- Signing events are logged with who approved and which hash was signed.
- A staged rollout starts with a small group of devices.
What to write down now
Write the answer to three questions while things are calm. What do we do if the release key is stolen? How do devices learn to trust a new key? Who can authorise that? If your devices cannot accept a new key without a physical visit, you have found a design limit worth fixing before shipping at volume.
Where Safeguard fits
Safeguard's policies and gates can block a pull request or release when dependency checks fail, which keeps a known-vulnerable library out of the image you are about to sign. It does not manage your signing keys.
Quick check
Is a cloud key management service enough for a startup?
It can be a sound choice if access is tightly limited and every signing call is logged. The point is that the key is not exportable and not on a laptop.
Should the same key sign firmware and the mobile app?
No. Use separate keys so a problem in one channel does not become a problem in the other.
Sources
Last reviewed: 19 October 2026.
