Yes. Each hardware variant needs its own firmware build, test run and rollout record, so ten variants means ten times the update work. Before adding a variant, check whether it can share a firmware image, and decide who tests its updates for the whole support period.
Where the cost shows up
A new variant looks like a hardware change. Over time it becomes a software and support cost. Different flash size, radio module or sensor means a different image or configuration. When a security fix lands, every variant needs it built, tested on real hardware and rolled out.
Recital 60 of the Cyber Resilience Act points to a vulnerability handling period of no less than five years unless the product's expected lifetime is shorter. A variant you add this year may need an update path in 2031. Plan accordingly.
What each variant adds
| Item | Per variant effect |
|---|---|
| Firmware build | Another target in the pipeline |
| Test hardware | Another bench unit to keep |
| SBOM | Another component list |
| Rollout record | Another group to track |
| Vendor SDK drop | Possibly a different version |
| Support end date | Possibly a different date |
Decision questions for a new variant
- Can it use the same firmware image with a runtime configuration?
- Does it change a component that has security impact, such as the radio or crypto hardware?
- Do we have a bench unit and a test script for its updates?
- Is the vendor committing to supply and support the part for our whole period?
- If we stop selling it, how long do we keep updating it?
If the answers to 3 and 4 are no, defer the variant.
Ways to keep the matrix small
- Share one codebase and use build flags with a short, reviewed list.
- Keep the same bootloader and update logic across variants.
- Standardise on one radio module family where possible.
- Retire old variants on a published schedule.
- Automate the bench test so adding a variant costs one more script run, not a week.
Make the tradeoff visible
Add a line to your product planning document that estimates the yearly update cost of each variant in engineer days. Without a number, nobody argues for fewer variants. With one, the cost of a long tail of SKUs becomes visible.
A short example
A team sells a sensor in two sizes. The second size has a larger battery and one extra sensor, nothing else. Built as two images, it doubles the update tests. Built as one image with a runtime flag read from a hardware ID, it adds one bench unit and one more line in the test script. The second route takes more care at the start and pays back at every security release, which is when the cost really shows.
Quick check
Is it ever worth adding a variant?
Yes, when it brings revenue or reach that outweighs the update cost over its full support period. Just write the cost down first.
Can the same image run on several variants?
Often, if the hardware differences are small and handled by configuration. Test each variant on real hardware anyway.
Sources
Last reviewed: 19 October 2026.
