Everything else is convenience. This is the one that decides whether a bad build is an incident or a recall.
A device you cannot reach physically has exactly one defence against a bad update: the ability to notice and undo it by itself. That mechanism lives in the bootloader, not in the cloud dashboard, and it is decided when you choose the update model — not later.
Three models are in common use. A/B partitions keep a full second copy and switch between them, which costs storage and is close to bulletproof. OSTree-style atomic updates commit a new filesystem tree and can boot the previous one, which is more space-efficient. Single-copy updates with a rescue image are cheapest and least forgiving — recovery means booting a minimal system that can only fetch a fresh image, and if that fails too, someone gets in a van.
A/B with automatic rollback if the device fails to confirm after reboot.
OSTree atomic updates with rollback, without paying the full A/B storage cost.
Signed OSTree updates with secure boot treated as part of the same design.
Whatever you configure — A/B, single-copy or rescue, wired into U-Boot or GRUB.
A different layer: cohort rollouts halted by crash-rate regression before the fleet is reached.
Test rollback by deliberately shipping a broken build to a real device. A rollback path nobody has exercised is a belief, not a feature.
Tell us the target hardware, roughly how many devices, and what happens commercially if one bricks. You get back a shortlist and the reasoning. No vendor is given your details.