Do Son 
Ask an experienced embedded team what keeps them up at night, and it’s rarely the first firmware release — it’s the second. Shipping code to a device you can physically hold is straightforward; shipping it reliably to a hundred thousand devices scattered across the field, some behind flaky networks, some low on battery, none of which you can ever touch again, is one of the genuinely hard problems in connected products. A botched over-the-air update doesn’t throw a stack trace you can read; it bricks a device in someone’s wall, and a single bad rollout can turn a fleet into a recall. That’s why a robust update path is not a feature you add later but a foundation you design first, and it’s a discipline Crunch-IS builds into its firmware development services from day one — because Crunch-IS is a leader in shipping firmware that can be safely changed after it leaves the building. Modern security regulation is now making a secure update mechanism mandatory rather than optional. Here’s what separates an OTA system you can trust from one that will eventually strand your fleet.
Why OTA is harder than it looks
A cloud service can roll back a bad deploy in seconds. A field device can’t, because the thing that failed might be the very mechanism you’d use to fix it. Three constraints make embedded updates uniquely unforgiving. Devices lose power mid-update, so an interrupted flash must never leave the device unbootable. Networks are unreliable and expensive, so pushing a full firmware image to every device wastes bandwidth and money. And the update software itself can fail, which means the recovery path has to be more trustworthy than the thing it’s recovering. Design for the happy path only, and you’ll meet all three the hard way.
The anatomy of a safe update
Atomic updates with rollback. The bedrock pattern is A/B partitioning: the device holds two firmware slots, writes the new image to the inactive one, verifies it, and only then switches over. If the new image fails to boot, the bootloader automatically falls back to the last known-good version. Power can drop at any point without bricking the device, because the running slot is never overwritten. This single pattern prevents the majority of catastrophic OTA failures.
Cryptographic signing and a chain of trust. Every image must be signed, and the device must verify that signature against a key rooted in immutable boot code before running a single instruction of new firmware. Without this, your update channel becomes an attack channel — anyone who can push an image owns the device. Secure boot and OTA are two halves of the same system.
Delta updates. Sending only the difference between old and new firmware, rather than the whole image, can cut update payloads dramatically — which matters enormously on metered cellular connections and battery-powered devices where every transmitted byte costs power and money.
Staged, monitored rollouts. Never ship to the whole fleet at once. Release to an internal ring, then a small canary group, then widening percentages, with automated monitoring watching failure and reconnect rates at each stage. If the canary misbehaves, the rollout halts before it reaches the millions. This turns a release from a leap of faith into a controlled, reversible operation.
Compliance is forcing the issue
Secure updateability used to be a mark of good engineering. It’s becoming a legal requirement. The EU’s Cyber Resilience Act and consumer-IoT baselines like ETSI EN 303 645 expect connected products to receive security updates over a defined support lifetime, and to receive them securely. In practice this means a device shipping today without a signed, reliable OTA mechanism may not be sellable in major markets for its intended lifespan. The update path is now part of the product’s regulatory surface, not just its maintainability.
Designing for it from day one
The teams that get OTA right make a handful of decisions before the first prototype. They reserve flash for dual partitions early, because retrofitting A/B onto a memory map that didn’t plan for it is painful. They establish the signing and key-management scheme up front, since keys baked into hardware can’t be changed later. They budget for the bandwidth and power cost of updates in the connectivity plan. And they build the update mechanism to be the most tested, most conservative code in the whole product — because it’s the one component that, if it fails, takes everything else down with it.
Everything else in an IoT product can be imperfect and fixed later — but only if the mechanism for fixing it works. Get OTA right and every other bug becomes survivable. Get it wrong and your first serious field defect becomes your last, because you’ll have no safe way to reach in and repair it. It is, quietly, the most important code you’ll write.