For every firmware release, archive the signed binary, its hash, the SBOM, the build log, the toolchain version, the signing key identifier, the release notes and the list of devices that received it. Store them together, tagged with the version, for the whole support period of the product.
Why bother
The Cyber Resilience Act recitals say the period during which a manufacturer handles vulnerabilities should be no less than five years, unless the product's expected lifetime is shorter (Recital 60). Whatever your own number turns out to be, the practical meaning is the same: you will get questions about old releases long after the engineers who built them moved on.
A support request, a customer audit or an advisory about a library will all start the same way: what was in version 1.1.4, and who got it?
The eight artifacts
| Artifact | Answers the question |
|---|---|
| Signed binary | What exactly shipped? |
| SHA-256 hash | Has it changed since? |
| SBOM for that build | Which components were inside? |
| Build log and toolchain version | How was it built? |
| Signing key identifier | Which key vouched for it? |
| Release notes | What changed and why? |
| Test results | What was checked? |
| Rollout record | Which serial numbers received it? |
Add the vendor SDK version and your patch level to the SBOM by hand if your tooling cannot see it.
Where to store it
Use storage with versioning and restricted write access. The goal is an archive you can trust has not been edited. Keep it separate from the working repo, so a repo cleanup does not delete history. Make one person responsible for checking, each quarter, that a random old release can actually be retrieved and that its hash still matches.
Steps to start this week
- List your current releases and find which artifacts exist for each.
- Pick a folder layout with one directory per version.
- Make the release pipeline write all eight artifacts on every tag.
- Back up the archive to a second location.
- Run a retrieval test on the oldest release.
How the record gets used
When a new advisory arrives, search the archived SBOMs for the affected component. The rollout record then tells you which devices to prioritise. Without the archive, you are guessing. With it, you can reply to a customer within hours and say which versions are affected and which are not.
A common mistake
Teams often keep the binary and forget the toolchain. Two years later the compiler version is unknown, the vendor SDK drop has been replaced, and nobody can rebuild the release to test a fix against it. Record the exact toolchain and SDK versions in the release record, and keep an installer or container image of the toolchain if the licence allows it. A rebuild you cannot repeat is a release you cannot patch.
Quick check
Do we need to keep the source code too?
Keep a tag or snapshot of it in your repository history. The archive should point to the exact commit.
How long should we keep releases?
At least as long as you support the product. The CRA recitals point to five years as a baseline, but check the regulation text and your counsel for your case.
Sources
Last reviewed: 19 October 2026.
