An authenticated firmware image still needs a recovery plan
A fictional device supports two firmware image slots. Its bootloader can verify a signed image before selecting a slot, and an approved update design preserves the previous image until a new version completes defined health checks. An engineer proposes erasing both slots first because the incoming file has a valid signature. The update also changes a stored configuration format, but compatibility with the previous firmware has not been tested. The exercise concerns design review only; it does not authorize updating any deployed device. The team must distinguish image authenticity, functional compatibility, interruption recovery and state migration. No statement is made that every commercial bootloader implements atomic selection, rollback protection or this exact two-slot arrangement.
1. Why does a valid signature not justify erasing both images first?
Read the worked answer
A signature supports origin/integrity under its trust model, not power-failure recovery or functional correctness. Erasing both bootable images removes the intended fallback before the update has passed its defined checks.
2. What compatibility issue remains despite preserving the old image?
Read the worked answer
A changed persistent-state format may prevent the previous firmware from functioning after rollback. Specify compatible migration/recovery behavior, image-selection atomicity, health criteria and authorized version transitions, and test interruption points.