Yes, but each additional recipient key enlarges the bundle, so very large fleets split their keys into subsets and encrypt the same payload once per subset. The payload is stored once and only a small wrapper differs. RAUC documents this approach for its encrypted bundles.
Why encrypt firmware at all
Encryption protects the confidentiality of the image: trade secrets, proprietary algorithms, or settings. It does not replace signing, which protects integrity and origin. A device should verify the signature and then decrypt, or follow the order your format specifies. Treat the two as separate controls.
What RAUC says about size
The RAUC documentation states that for each recipient given to its encrypt command, the bundle grows by a small amount. For RSA 4096 it lists about 620 bytes, and for ECC about 250 bytes, with actual sizes depending on certificate metadata. With a very large number of keys, the overhead becomes problematic. The suggested fix is to split the keys into several subsets and encrypt the same bundle once per subset. Each device then needs the version for its subset. The encrypted payload is identical across subsets, only the encrypted structure containing the signed manifest differs, so the payload needs storing once.
A quick size check
| Recipients | ECC overhead, approx | RSA 4096 overhead, approx |
|---|---|---|
| 100 | 25 kilobytes | 62 kilobytes |
| 10,000 | 2.5 megabytes | 6.2 megabytes |
| 100,000 | 25 megabytes | 62 megabytes |
These figures simply multiply the documented per key sizes by the number of recipients, so check them against your own certificates. Each device would download all of it unless the bundle is split.
Design steps
- Decide whether you need per device keys or per group keys. Per group keys are simpler to manage.
- Estimate overhead using your certificate sizes.
- Choose subset sizes so the wrapper stays small.
- Map each device to its subset in your device record.
- Serve the right bundle to each device, and share the payload storage underneath.
- Plan key rotation and loss: what happens to a device whose key was replaced.
The tradeoff
Per device keys limit the harm of one stolen key, but raise operational load: key issuance, mapping, and rotation across the life of the device. Group keys are easier but a leak exposes the whole group. Choose by the value of what you are protecting.
For component tracking
Encrypted bundles do not change your inventory needs. Keep the release SBOM in the clear in your own systems, because you must know what the encrypted image contains. Safeguard can scan that SBOM; see gold.safeguard.sh/scan.
Mistakes to avoid
Do not forget key loss. If a device key is wiped or replaced, the device cannot read bundles encrypted to the old one, so plan a recovery path before you ship. Do not hold the encryption material in the same place as the signing key, since a single breach would then cover both. And test with your real certificate sizes, because the per key overhead depends on certificate contents and can differ from the documented examples.
Quick check
Does encrypting a bundle replace signing it?
No. Encryption protects confidentiality, while a signature protects integrity and origin.
Why split keys into subsets?
Each recipient adds overhead to the bundle, so splitting keeps the size manageable while the payload is stored once.
Sources
Last reviewed: 19 October 2026.
