Over-the-air updates are the whole product
A connected device you cannot update is a device that is as good as it will ever be, and one disclosed vulnerability away from being scrap.
Teams building their first connected product tend to treat updates as a phase-two concern. It is not a feature - it is the thing that determines whether the product has a future.
What a safe update needs
- **Atomicity.** An interrupted update must leave a device that still boots. A/B partitions are the standard answer: write to the inactive slot, verify, switch, keep the old slot as fallback.
- **Verification.** Signed images, checked on the device before anything is applied. A fleet that installs unsigned firmware is a fleet that installs an attacker's firmware.
- **Automatic rollback.** The device boots the new image, runs a health check, and confirms. No confirmation within a window means boot back to the old slot.
- **Staged rollout.** One device, then ten, then a percentage, then everything. With the ability to stop.
The failure that hurts
The genuinely bad outcome is not a failed update. It is a successful update that bricks devices, applied everywhere at once. Staged rollout with health gating is what stands between a bad build and a truck roll to every site.
Bandwidth is a design constraint
A cellular-connected fleet paying per megabyte cannot ship a full image for a one-line change. Delta updates matter, and so does compressing what you send. Design the update payload as deliberately as you design the API.
Test the recovery path
Simulate power loss mid-write. Simulate a corrupt download. Simulate a health check that fails. If the rollback path has never been exercised, you do not have a rollback path - you have an untested assumption that a field technician will eventually disprove.