A fleet wide firmware rollout should be approved by someone other than the person who created it, with permission to judge risk. The approver checks the target list, the release contents, the group sizes, and the stop rules, and the approval is recorded. This is a cheap control against a costly mistake.
What an approval step looks like
Eclipse hawkBit offers an approval workflow as an option you must enable explicitly. When on, a user with adequate permissions has to review any new or updated rollout before it can start. The documentation also says it allows integration with third party workflow engines. You can copy the idea in any system: a rollout in a draft state, a separate reviewer, and a start that is blocked until approval.
What the reviewer should check
| Check | Question |
|---|---|
| Target filter | Does it select the devices intended, and no others? |
| Release | Is this the signed image that passed testing? |
| SBOM | Has the release SBOM been scanned, and are open findings accepted? |
| Groups | Is the first group small and varied? |
| Thresholds | Are the success and error limits set? |
| Timing | Is it outside peak hours and staffed for watching? |
| Rollback | Is there a plan if the new release must be replaced? |
Steps to set it up
- Make rollouts draft by default.
- Define who can create and who can approve, and keep the sets separate.
- Give the approver a one page checklist, like the table above.
- Block the start until the approval is on record.
- Re-require approval after any edit to the target list, release, or thresholds. An edited rollout is a new rollout.
- Keep the record with the release: who, when, which version of the plan.
A word on small teams
If you have two engineers, approval can be a short review of a pull request that contains the rollout definition as a file. The point is a second pair of eyes, not a committee. For emergency fixes, allow a faster path, but still require two people and log the reason.
Evidence for later
Customers and auditors sometimes ask how you control changes that reach devices in the field. An approval log answers that. Safeguard supports compliance and evidence automation along with policies and gates on SBOM findings, and the free scan at gold.safeguard.sh/scan can be the first step in the checklist.
Mistakes to avoid
Approval turns into a rubber stamp when the reviewer sees only a name and a button. Give them the diff: what changed in the SBOM since the last release, what the target filter selects, and how many devices it matches. Do not let the creator approve their own work in a small team just because it is late on a Friday. And avoid a long checklist: seven focused questions get answered, thirty get skipped.
Quick check
Is an approval step needed if staged groups already limit harm?
Staging limits damage after a mistake. Approval aims to prevent the mistake, for example a wrong target list.
Should an edit to a rollout need approval again?
Yes. Treat any change to targets, release, or thresholds as a new rollout.
Sources
Last reviewed: 19 October 2026.
