Signed firmware updates with test boot and recovery

The scenario

Imagine a connected product that needs firmware updates after installation. A successful download would be only one stage of the update. This reference design would verify image authenticity, check compatibility with the device, and confirm that a new application can perform essential work before treating the release as permanent.

Describe the release as more than a binary

A release manifest would identify the image, digest, intended hardware revision, version, and required bootloader capabilities. The signing process would keep private signing material out of ordinary developer builds and record which release was approved for publication.

The bootloader configuration would define the trusted verification keys and update strategy. Authenticity and compatibility are different checks: an authentic image can still target the wrong board. Key rotation and any policy preventing installation of older releases would need explicit design and testing.

Choose a recoverable update strategy

For a compatible MCUboot swap configuration, a downloaded image could be marked for a test upgrade. The new application would confirm itself only after passing a bounded set of startup checks. Without confirmation, the configured boot flow could revert on a later reset.

The available flash layout and boot mode matter. Recovery behaviour should be verified for the actual configuration rather than assumed from the bootloader name. Persistent-data migrations would also need a plan: reverting application code is not enough if the previous version can no longer read its settings.

Test interruptions before widening distribution

A test rig would interrupt power at selected update stages and record the resulting boot state. It would also exercise incomplete downloads, invalid signatures, incompatible hardware identifiers, and an application that starts but fails its health checks.

A release service would begin with a limited device cohort and track download, verification, boot, confirmation, and recovery separately. Stopping a rollout would prevent further offers; it would not magically remove an already-installed image. An operator would need a clear view of which stage each device reached.

What to validate

• A modified image is rejected by the configured verification path.
• Hardware compatibility is checked before activation.
• An unconfirmed test image follows the intended recovery path.
• Settings remain usable after both upgrade and supported reversion.

The tradeoff

Recovery consumes flash and adds boot-state complexity. Some update modes have different guarantees, and a confirmed image may not have an automatic route back. The product should choose its storage and update strategy together.