Keep the private key that signs firmware in a hardware security module or smartcard, not on build servers or laptops, and let the build call it through PKCS#11. Devices only need the public key to verify updates, so the private half never has to leave protected hardware.
Public and private halves
The U-Boot signature documentation is clear that signing is normally done by mkimage on the host, while verification on the device needs only the public key. That split is the whole design. Anyone who steals the public key learns nothing useful. Anyone who steals the private key can ship firmware your devices will accept.
ETSI EN 303 645 makes a related point. In its examples, a manufacturer public key used to verify an update is not a critical security parameter and does not need to be unique per device.
Practical options
The U-Boot documentation notes that private keys can stay on a smartcard or HSM via PKCS#11 or an OpenSSL engine, with mkimage invoked with a PKCS#11 key URL. You can apply the same idea to any signing tool that supports a hardware-backed key.
| Where the key lives | Risk if the machine is breached |
|---|---|
| File on a developer laptop | Key copied silently |
| File on a CI runner | Key exposed to any job that can read it |
| Smartcard or HSM, used through PKCS#11 | Attacker may request signatures while access lasts, but cannot copy the key |
Note the last row. Hardware protection stops theft of the key, not misuse during a breach, so add controls around who can request a signature.
Controls around the key
- Separate development, test and release keys. A development key must never validate on production hardware.
- Require approval, such as two people or a protected release branch, before a release signature is made.
- Log every signing request with the build identifier.
- Plan rotation and revocation before shipping, since the verifying key is often fixed in a bootloader.
- Back up the key under the same protection as the original.
Test the failure
Ask what you would do if the release key were suspected of compromise tomorrow. If the answer needs a bootloader change on devices you cannot update, fix that in the next design cycle.
Where Safeguard fits
Safeguard supports compliance and evidence automation alongside SBOM and dependency scanning, so a record like this can be kept with your other evidence. Try the free scan at gold.safeguard.sh/scan on a repository you already own.
Quick check
Does a device need the private key?
No. Verification uses the public key only.
Does an HSM make signing safe by itself?
It prevents the key being copied. You still need access control and logging so a compromised build system cannot request signatures freely.
Sources
Last reviewed: 19 October 2026.
