Firmware Campaign Recovery After Factory Reset: Preserve or Reissue the Update Obligation

Define reset separately for campaign intent, execution authorization, transfer progress and actual installation state. A settings reset should not accidentally make an old campaign current again, while a lost local download checkpoint should not erase the management system’s knowledge that an approved update remains outstanding.

This article proposes a product-level reset contract. RFC 9019 and RFC 9124 provide architectural and authorization boundaries, but neither supplies the reset matrix below. No reset, enrollment, credential change or data deletion was performed. Any real reset must use the product’s authorized procedure and explicit data-preservation requirements.

1. Split the state before deciding what reset removes

State class	Meaning	Reset question
Management obligation	The authority still expects the device to reach an approved state	Is the obligation retained or explicitly withdrawn?
Current execution permission	The device may perform a particular update under current conditions	Must time, target and ownership conditions be reissued?
Acquisition progress	Partial bytes and verified checkpoint information	Can it be validated, or must acquisition restart?
Installation/boot evidence	Writes, selected candidate, observed running image and confirmation	How will actual state be reconciled after restart?
Security and device identity	Trust anchors, protected counters and enrollment identity	Which separate authorized lifecycle procedure owns it?

The RFC 9019 role definitions separate status tracking, firmware consumption and boot responsibilities. Use that separation when deciding which component owns each retained fact. Clearing an application’s database does not necessarily clear bootloader state or the server’s campaign record.

2. Name reset types by their actual effects

For the hypothetical product here, a preferences reset changes ordinary user settings only. An updater-state repair reconstructs damaged acquisition bookkeeping through an approved recovery path. A management re-enrollment establishes a new authorized relationship. These are distinct operations even if a support interface previously called all three “factory reset.”

Keep credential and identity handling outside the ordinary preferences-reset implementation. A reset request is not blanket permission to erase keys, lower protected security state or change ownership. It also does not prove that a device has reverted to factory firmware.

Document which persistent regions each reset can affect, including caches and background services that may repopulate state. Test the completion signal against the actual resulting state, not merely the return of the reset handler.

3. Apply a reset-type by campaign-state matrix

Reset and starting state	Proposed disposition	Required evidence before proceeding
Preferences reset with a queued campaign	Retain campaign ordering and obligation; recheck current admission conditions	Same authorized relationship and valid scheduling policy
Preferences reset with downloaded content	Retain only content the reset policy preserves; verify its identity before reuse	Approved artifact and qualified checkpoint/full-file validation
Updater-state repair with partial acquisition	Discard reliance on unverifiable progress; obtain current intent from the authority	No unresolved installer operation and a safe acquisition restart point
Any reset while dispatch or installation is unresolved	Defer ordinary reset or enter the product’s explicit recovery workflow	Actual operation and target state reconciled
Re-enrollment with an old queued campaign	Do not replay old relationship permissions automatically	New authority explicitly retains or reissues the obligation
Reset after confirmed installation	Observe running/boot state rather than infer a firmware rollback	Actual image and confirmation evidence

These choices are a reviewable example, not universal behavior. A product may intentionally cancel a pending campaign during a particular authorized reset, but that cancellation must be explicit and reconciled with the authority. Missing local records alone are not a cancellation receipt.

4. Preserve replay protection or require reconciliation

If campaign ordering survives a preferences reset, retain its authority scope and high-water record consistently. Do not preserve an old timer while erasing the newer decision that superseded it. The result could be a delayed reinstall after reset.

If an approved reset intentionally removes the ordering record, block cached-job dispatch until the authorized management process establishes current intent again. Do not choose the newest-looking file in staging or reset a counter to zero and accept any arriving old command.

RFC 9124’s rights requirement ties actor privileges to authenticated authority. Its manifest-sequence policy is also distinct from an application’s ordinary settings. A campaign-repair flow must not be represented as permission to weaken those independent security checks.

Reset recovery cannot manufacture authority while offline. If the device lacks the retained information needed for safe admission and cannot contact the authorized service, hold the update and report the reconciliation requirement.

5. Reissue an obligation without reviving stale permission

On reconnect, report the reset category, current device relationship, actual running image, available installer evidence and whether acquisition progress remains valid. Use non-secret identifiers and bounded reason codes. Do not upload raw credential stores or private application data.

The authority then decides whether the device still belongs to the campaign, whether the artifact remains approved and which upgrade path is supported. A retained obligation may lead to a new execution permission with current timing and target conditions. It need not reuse an expired URL, old maintenance occurrence or obsolete approval.

Bind the response to the current enrollment and request generation. Delayed responses from before the reset must not overwrite the new decision. If ownership changed, use the product’s authorized transfer procedure rather than inferring that the old account may still manage the device.

6. Test interrupted resets as state transitions

1. Reset preferences while a campaign is queued, then deliver an older delayed job.
2. Reset with a complete staged artifact and with an unverifiable partial artifact.
3. Restart during the reset’s campaign-record update and inspect the recovered interpretation.
4. Lose management connectivity after local state repair and require a clear hold.
5. Re-enroll through the approved test workflow and deliver a stale old-relationship reply.
6. Reset after an installed candidate is selected but before boot confirmation is established.

Use recoverable test devices, disposable accounts where applicable and preserved customer data. The test must establish which facts survive, which are reconstructed and which require renewed authority. These tests were not executed for this article.

Hypothetical reset during a missed campaign

A gateway missed an update while offline. An operator resets preferences to repair a local configuration issue. The server still records an outstanding update obligation, but the earlier maintenance window has expired.

After reconnect, the gateway reports its actual image and reset category. The authority may reissue the campaign with a current window and supported path. The device neither forgets the obligation because a preference changed nor immediately installs under obsolete timing permission.

Close the design with a reset-effect inventory, the cross-state matrix and an explicit offline hold condition. That makes “factory reset” an understandable lifecycle operation instead of an accidental shortcut around campaign history or update authorization.