Direct answer

Rollback is a tested recovery capability, not a promise to reinstall an older binary. Preserve a signed, compatible recovery artifact; an immutable or recoverable boot path; enough storage for safe switching; and a data strategy that remains readable after partial migration. Define when rollback is automatic, when it needs approval, and when forward repair is safer because state cannot move backward.

Scope and non-scope

This guide covers device firmware and closely coupled local data. It does not assume A/B partitions are always possible or that every update is reversible. Bootloader changes, secure-element policy, anti-rollback counters, irreversible data transformations, and physical calibration may require staged forward recovery instead.

Recovery architecture

A/B slots are common because the device writes an inactive image, verifies it, switches boot intent, and retains the previous slot until health is confirmed. A smaller rescue image can serve constrained devices, but it must still authenticate recovery artifacts and communicate enough diagnostics. Single-slot overwrite needs power-loss-safe writes and a credible external recovery path.

Separate installation success from acceptance. The bootloader can confirm signature and image integrity. Early firmware can confirm startup, watchdog stability, storage access, and essential peripherals. The application can confirm connectivity and its critical workload. Mark the new version permanent only after all required stages pass within bounded attempts or time.

Data compatibility

Firmware and persistent data form one release unit. Prefer backward-compatible schemas and expand-then-contract changes. If migration is necessary, journal progress and make each step idempotent after power loss. Preserve a backup only when its integrity, confidentiality, size, and restore path are controlled. Never assume that booting old code against new data is safe.

Anti-rollback security protects against reinstalling vulnerable versions. Recovery policy must respect signed version metadata and explicitly authorize permitted recovery versions rather than disabling the counter during incidents.

Implementation procedure

  1. Enumerate firmware, bootloader, radio, secure-element, configuration, and data dependencies.
  2. Define compatible source and target versions, including skipped-version upgrades.
  3. Verify signed metadata, hashes, hardware identity, and available power and storage before writing.
  4. Write inactive content with interruption-safe progress tracking.
  5. Verify the stored artifact before changing boot intent.
  6. Boot with a limited trial counter and collect staged health evidence.
  7. Commit only after acceptance; otherwise return to an authorized recovery image.
  8. Report terminal outcome and reason after connectivity returns.
  9. Test forward repair for states that cannot be safely rolled back.

Failure modes

A device can oscillate between two bad images if trial counters are not durable. An A/B layout can still brick when the shared bootloader or partition table changes. A rollback may boot but corrupt data created by the new version. Devices without reliable clocks can reject valid metadata if time is the only freshness control. Battery loss during flash writes can expose controller-specific behavior absent from desktop tests. A platform may repeatedly offer the failed artifact unless campaign state records the terminal result.

Implementation checklist

  • Recovery trust and anti-rollback policy are explicit.
  • Boot intent and trial counters survive power interruption.
  • Artifact and hardware compatibility are checked before installation.
  • Application acceptance covers critical peripherals and outcomes.
  • Data migrations are backward-compatible, journaled, or forward-repairable.
  • Failed artifacts are not automatically offered again.
  • Recovery works without normal application availability.
  • Power-loss and repeated-failure tests run on every hardware family.

Evidence to retain

Keep artifact and metadata hashes, compatibility matrices, partition layouts, migration tests, power-interruption results, trial-boot logs, and recovery timing. Exercise rollback from early, middle, and completed migration states. A successful clean rollback is not enough; failures occur at boundaries where only part of the system advanced.

Recovery test matrix

Exercise interruption before download, during erase, during every write region, after verification, after boot-intent change, during first boot, and during data migration. Repeat with low battery, full storage, damaged inactive image, missing network, expired metadata, and a failed health signal. Confirm that every path ends in a known bootable state or an explicitly supported service procedure.

Include skipped-version upgrades and downgrade attempts outside the allowed window. Verify that manufacturing recovery cannot be invoked by an untrusted remote actor. Measure flash wear and retained diagnostic space on real hardware. Finally, have someone other than the implementation author recover devices from preserved runbooks and artifacts. A recovery design that depends on unstated laboratory knowledge is not a production recovery capability.

Define the field-service boundary before release. If automated recovery exhausts its attempts, the device must enter a diagnosable, bounded state with authenticated service instructions. Avoid endless reboot loops that destroy logs, consume batteries, or repeatedly affect the attached process.

Primary sources

The Uptane Standard is the primary reference for secure software-update metadata and compromise resilience. NIST SP 800-193 defines platform firmware resiliency principles. Hardware boot, flash, and secure-element behavior must be verified in the relevant manufacturers’ official documentation.