Regulation has settled the argument: if your product has digital elements and a support period, you need a way to fix it in the field. The question is no longer whether to build OTA, but whether yours will survive contact with a real deployment.
The layout that makes it survivable
The standard approach is two application banks plus an immutable bootloader. The device runs from bank A, downloads into bank B, verifies it, then marks B as the boot target and resets. If the new image fails to check in within a set time, the bootloader falls back to A. You need flash for two images plus the bootloader, which is a silicon decision made long before the first update is written — one of several reasons to think about updates while choosing the MCU.
Where flash is tight, the alternatives are a compressed image with an external flash staging area, or delta updates. Both work; both add complexity exactly where you least want it, which is the code path that runs when something has already gone wrong.
Sign everything, and verify before you commit
Images must be signed, and the bootloader must verify the signature against a key it holds, before the image is ever marked bootable. Verify the whole image after it lands in flash, not just as it streams in — a download that passes in transit and lands corrupted is a real failure mode on flash near end of life.
Keep the signing key somewhere that is not a developer's laptop. If that key leaks, an attacker can ship firmware to your entire fleet, and the CRA reporting clock will be the least of the consequences.
The failure modes that actually happen
Power loss mid-write. Test it, deliberately, dozens of times, by cutting power at random points through the update. If the bootloader can be interrupted while it updates its own metadata, you have a brick.
Everyone downloads at once. A thousand devices waking on the same schedule and pulling an image will flatten your endpoint and, on a metered connection, produce a memorable bill. Stagger with a random offset and rate-limit server side.
Battery devices with no headroom. A cellular download plus a flash write is the highest-current thing the device will ever do. Check the battery state before starting, and refuse if it is marginal. A device that bricks at 20% charge is worse than one that waits.
Downgrade attacks. Refuse images older than the current version unless an authorised recovery path says otherwise; otherwise a patched vulnerability can simply be reinstalled by anyone who kept the old image.
The device that never reports back. You need telemetry of update success and failure per device. Without it you find out about the failed rollout from customers.
Roll out in stages
Ship to ten devices you control. Then one percent of the fleet. Then ten. Wait long enough at each stage to see failures — which usually means at least one full duty cycle of the product, not an hour. Have an abort that stops the rollout server side without needing the devices to cooperate.
None of this is exotic. It is a week or two of engineering that, done up front, is the difference between a routine security patch and an expedition to a customer's site with a programmer in your bag.