OTA Firmware Updates for Engineers: A/B Rollbacks, Not Bricked Devices

OTA firmware updates let connected devices receive new code and security patches remotely, without a technician ever touching the hardware. The single most important engineering priority is getting the trust chain right: signed, versioned manifests paired with staged, job-based rollouts that can be paused or reversed the moment something looks wrong. This guide walks through the architecture, security, and operational choices that make that possible.

TL;DR:

Choose dual bank updates when flash permits: they keep the current image active during installation and automatically restore it after boot or health check failures.

Verify a manifest’s signature before parsing it, then enforce a monotonic version counter to block replay of older, still signed but vulnerable firmware.

Start with a canary and expand only after its success rate clears a threshold; pause for verification failures or crash loops, but retry network drops.

For constrained devices, download firmware in checked blocks to limit RAM use, and defer installation below a safe battery threshold.

Test real flash writes and power loss on hardware before rollout, and require boot and peripheral health checks before marking an update complete.

A/B updates versus legacy update architectures

The biggest architectural decision in any OTA program is whether a device can hold two firmware images at once. Dual-bank, or A/B, updates write the new image to an inactive partition while the device keeps running on the current one. Once the new image is verified, the bootloader simply flips which partition is active. If the new firmware fails to boot or fails a health check, the device falls back to the known-good partition automatically, which is why A/B architectures are the default choice for anything that cannot tolerate being bricked in the field.

Single-slot, or legacy, updates overwrite the existing firmware directly. They need less flash storage, which matters on microcontrollers with only a few hundred kilobytes to spare, but a failed write or a power loss mid-flash can leave the device unresponsive. Legacy updates still make sense for low-cost sensors with tight memory budgets, devices behind a wired bench-programming process, or products where a failed update simply triggers a manual reflash during manufacturing rather than in the field.

A few practical differences shape the choice:

Downtime: A/B updates install in the background with activation happening at the next reboot, so the device stays usable during download.
Storage cost: A/B needs roughly double the flash for firmware partitions; legacy needs a fallback image stored separately or no fallback at all.
Bootloader complexity: A/B requires a bootloader that tracks partition state and boot-attempt counters; legacy bootloaders are simpler but offer less protection.
Recovery: A/B gives you an automatic rollback path; legacy typically needs an external recovery mechanism such as a factory-restore image.

The TCG's secure update guidance recommends supporting dual-bank updates specifically to avoid bricking devices during failed installs, which lines up with why most connected products with any field population choose A/B wherever flash budget allows, as described in the TCG secure update guidance.

Pro Tip: If flash is too tight for full A/B, look at partial dual-bank schemes that duplicate only the bootloader and critical recovery code, leaving application firmware single-slot.

Choosing payload formats and transport for update delivery

Once the architecture is set, the next decision is what you actually send over the wire. A full-image update ships the entire firmware binary and is simple to build and verify, but it costs the most bandwidth and battery. A delta, or diff-based, package sends only the bytes that changed between two known firmware versions, which can cut transfer size dramatically on devices that update often, according to the Wikipedia overview of OTA updates. The tradeoff is complexity: the device needs enough RAM and flash headroom to reconstruct the new image locally, and the delta engine must know exactly which base version it's patching, which means your fleet's version tracking has to be accurate.

For constrained devices, downloading in shards or blocks rather than one continuous stream helps avoid holding the full payload in RAM. A common pattern is fetching a small signed manifest first, verifying it, then pulling the payload in blocks while checking integrity incrementally rather than waiting until the whole file lands.

Transport choice depends heavily on the network available to the device. Some platforms, including several MQTT-based IoT services, impose payload size limits that force you to chunk large images, as noted in the Wikipedia OTA entry. Before locking in a transport, check:

TLS everywhere: every update channel, whether HTTPS, MQTT, or BLE, should run over TLS with certificate validation, not just an encrypted link.
File size limits: confirm your messaging platform's maximum payload and plan chunking or sharding around it.
Fragmentation handling: low-power radios like BLE need explicit reassembly and retry logic for dropped fragments.
Network availability windows: cellular devices may need to queue updates until a stable connection window opens.

Why manifests and standards like SUIT matter

A manifest is the piece of metadata that tells a device what an update is, where to get it, and whether it's allowed to apply it, and treating that manifest as the primary security object is the single habit that separates resilient OTA systems from fragile ones. The SUIT manifest draft being developed through the IETF specifies a structure for exactly this: signatures, applicability conditions, payload size, dependency information, fetch locations, and a sequence of commands the device executes to validate and install the update.

That command-sequence model matters because it lets a single manifest describe complex flows, not just "download and flash." A device can check hardware revision compatibility, stage a payload without activating it, verify a secondary component's signature, and only then invoke the final install step, all driven by instructions inside the signed manifest rather than hardcoded device logic.

The non-negotiable rule here is ordering: verify the manifest's signature before parsing or acting on anything inside it. Parsing untrusted data before verification opens the door to exploits that never need to touch the firmware payload itself, since a malicious manifest can be crafted to exploit a parser regardless of what the referenced image contains.

Practical manifest requirements worth building into your pipeline:

Cryptographic signature covering the entire manifest, checked before any field is trusted.
Applicability metadata specifying hardware revision, current firmware version, and compatible variants.
Payload size and location, including fetch URIs and expected hash of the target image.
Dependency and command sequence data describing any prerequisite components and the exact install steps.

Implementers building constrained-device update clients should treat the SUIT draft and related IETF work as the reference point rather than inventing a bespoke manifest format from scratch.

Security controls that protect the update pipeline

Security in OTA systems isn't one feature, it's a chain, and the chain is only as strong as its weakest link. The NTIA's voluntary framework for update process security frames the update lifecycle as a sequence: create, sign, protect, send, receive, check, distribute, process, stage, apply, re-verify, activate, and clean up, and recommends selecting security features based on a device's risk profile, starting with baseline protections like TLS and signing before layering on hardware roots of trust and more advanced defenses.

Signing is the floor, not the ceiling. Developers should avoid relying on CRC or simple checksums alone; cryptographic signatures combined with monotonic version counters are what actually prevent tampering and downgrade attacks. A monotonic counter embedded in the signed manifest, checked at boot or by the update engine, stops an attacker from replaying an older, vulnerable firmware image even if that image's original signature is still technically valid. This single control addresses one of the more commonly underestimated attack paths in connected-device security.

A device whose update engine trusts data before verifying its signature inherits every vulnerability baked into that parser, which is why the verify-then-parse order matters as much for firmware images as it does for manifests, per the NTIA framework.

Beyond signing and versioning, a defensible OTA security posture includes:

Transport protections: TLS 1.3, certificate pinning, and server identity validation to guard against man-in-the-middle interception of update traffic.
Hardware-backed roots of trust: TPM or DICE-based attestation anchors the signing-key chain in silicon rather than in software that an attacker could modify.
Isolated update engine: running the fetch, verify, and apply logic in a separate, minimally privileged component (sometimes called a First Update Engine) limits what a compromised application can touch.
TOCTTOU avoidance: verify data immediately before it's used, not earlier in the pipeline, since caching unverified data creates a time-of-check-to-time-of-use gap attackers can exploit.
Recovery paths: always keep a known-good, factory-validated image available in case an update sequence fails in a way normal rollback can't fix.

The TCG's guidance on secure updates reinforces several of these points directly: isolate the update engine, measure and attest platform state, protect signing keys, and support dual-bank updates so a failed install never leaves a device unrecoverable.

Orchestrating rollouts with jobs, canaries, and targeting

Shipping firmware to a fleet of ten thousand devices is an operations problem as much as an engineering one, and the pattern that scales is treating each update as an immutable job rather than a one-off push. A job carries a unique ID, a defined state machine, and an audit trail, which is what makes staged rollouts, retries, and rollback decisions auditable instead of ad hoc.

A practical job state machine typically includes:

Staged: the update package and manifest are available to targeted devices but not yet pushed.
Applying: the device has started fetching or installing the payload.
Verifying: post-install checks are running before the device commits to the new firmware.
Activated: the update succeeded and the device has confirmed it's running the new version.
Failed: any step broke down, triggering a rollback or retry based on the failure type.

Canary rollouts start with a small slice of the fleet, often a few percent, and expand only once that group's success rate clears a defined threshold. Choosing canary size and thresholds depends on fleet size and how costly a bad update would be: a safety-relevant automotive update warrants a smaller, slower canary than a minor UI tweak on a consumer gadget. Automated triggers should distinguish between failure types: a transient network drop deserves a retry, while a verification failure or crash loop should pause the rollout and trigger rollback for already-updated devices.

Targeting rules let you avoid rolling out blind. Common targeting dimensions include hardware revision (never ship a payload built for a newer board to an older one), battery level (defer installs below a safe charge threshold), region (for staged compliance or bandwidth reasons), and connectivity class (cellular devices may need smaller batches or off-peak scheduling to control data costs).

Pro Tip: Log every job state transition with a timestamp and device ID from day one. It costs almost nothing upfront and becomes the dataset you'll need the first time a rollout goes sideways and you need to know exactly which devices were affected and when.

Testing, validation, and recovery when updates fail

OTA reliability is built in testing long before a rollout ever reaches a canary group. A practical test pyramid runs from unit tests on the update-engine code, through hardware-in-the-loop rigs that exercise real flash writes and power-loss scenarios, into small internal fleet pilots, and only then into staged production rollout. Skipping the hardware-in-the-loop stage is a common shortcut that tends to surface exactly the power-loss and timing bugs that unit tests can't catch.

Post-update, devices should run automated health checks (confirming the new firmware boots, core services start, and critical sensors or peripherals respond) and report that status back before the update is considered complete. That status report, including integrity verification results, is what feeds the success-rate metrics a rollout policy depends on.

Recovery needs to be designed, not improvised:

Automated rollback triggers should fire on verification failure, crash loops, or missed health-check deadlines, not require a human watching a dashboard.
Dual-bank swaps give an instant, low-risk recovery path when the architecture supports it.
Factory-restore images serve as the last resort when incremental rollback itself fails, a pattern common enough in vehicle OTA systems that full-factory recovery images are standard practice, per Siemens' overview of OTA in software-defined vehicles.
Minimal human intervention should be the design goal: a device that can self-diagnose and self-recover from a bad update scales far better than one that needs a support ticket.

Adapting OTA for constrained and low-power devices

Microcontrollers and battery-powered sensors need a leaner version of everything above. Flash is often too tight for full A/B duplication, so partitioning strategies frequently protect just the bootloader and a minimal recovery image while treating application firmware as single-slot with careful atomic-write handling to avoid a corrupted partial write.

Shard or block-based downloads matter even more here: fetching the signed manifest first, verifying it, then pulling the payload in small blocks with incremental integrity checks avoids ever holding a full image in RAM, which many constrained devices simply don't have room for.

Power-aware scheduling is just as important as the technical download mechanics:

Battery thresholds: defer installs below a safe charge level to avoid a power-loss failure mid-write.
Connectivity windows: batch downloads to coincide with known Wi-Fi or low-power network availability rather than forcing a cellular radio to stay active.
Lightweight crypto: choose signature and hash algorithms sized to the device's CPU budget, since a verification routine that takes too long or draws too much current defeats the purpose of a low-power design.
Incremental verification: check each block as it arrives instead of verifying only the complete assembled image, catching corruption early and saving a wasted full download.

Monitoring OTA health and tuning rollout policy

A rollout policy is only as good as the data feeding it back. The core KPIs worth tracking on every release are update success rate, rollback rate, time-to-complete per device, and mean time to recovery when something breaks. Device-level telemetry, including status codes, battery level during install, connectivity type, and install duration, lets you diagnose why a specific cohort is underperforming rather than guessing.

Dashboards should flag when success rate drops below a defined threshold for a canary group, which is the signal that should pause further rollout automatically rather than waiting for a human to notice. Over time, this telemetry is what lets you tune canary sizes and scheduling windows: a connected cohort of devices that consistently updates faster and cleaner than average is a candidate for a larger initial canary, while a cohort showing elevated failure rates on a particular hardware revision tells you to narrow targeting before the next push. Related operational patterns, including automated incident response and system resilience monitoring, are covered in MindPod Tech's work on autonomous IT operations, which applies similar state-machine thinking to broader infrastructure monitoring.

Fleets that track rollback rate alongside success rate catch failure patterns that a success-rate number alone would hide, since a cohort that succeeds on the second retry still shows a healthy overall success rate while masking a real first-attempt problem.

A practical OTA checklist for product teams

If we're building OTA into a connected product, the sequence that holds up in practice is: sign manifests before anything else gets built, choose A/B architecture whenever flash budget allows, design updates as auditable jobs rather than one-off pushes from day one, and stage every rollout through a canary before going fleet-wide. We bring this checklist into connected-device engagements, working alongside in-house engineering teams rather than handing off a spec and disappearing. That collaborative, hands-on approach is what lets us help product teams fold OTA infrastructure into a broader platform build without treating it as a bolt-on afterthought.

What most teams get wrong about OTA firmware updates

The conventional advice treats OTA as a download-and-flash problem, and that framing is where most of the risk hides. The evidence points somewhere else: the manifest is the real security boundary, not the firmware image itself, and teams that bolt signing onto an existing update flow as an afterthought tend to get the verification order wrong, parsing before checking rather than checking before parsing.

The more overrated piece of advice is chasing exotic cryptography before the basics are solid. A monotonic counter and a correctly ordered signature check prevent more real-world incidents than an upgrade to a fancier algorithm ever will. Rollback and downgrade protection, in particular, get far less attention than they deserve given how often they're the actual attack path.

If you're prioritizing, start with the manifest and the verification order, then build job-based orchestration before you worry about delta compression or shard optimization. A slow, correct update is recoverable. A fast, unverifiable one is a liability you discover in the field, usually at the worst possible time.

— Loic

FAQ

Are OTA updates necessary for connected devices?

Yes. OTA updates are the standard way to deploy security patches, fix critical bugs, and add functionality to devices that aren't physically accessible, and they're now routine in smartphones, vehicles, and IoT products, per Siemens' overview of OTA in vehicles. Without OTA, a security flaw discovered after deployment often means a costly recall or a truck roll.

What kinds of devices use OTA updates?

OTA mechanisms run across smartphones, vehicles, industrial sensors, smart-home products, and a wide range of other IoT hardware, delivered over Wi-Fi, cellular, or low-power networks depending on the device, as described in the Wikipedia entry on OTA updates. The delivery method and update architecture vary by how much flash and power budget the device has available.

Is an OTA update safe to install?

An OTA update is safe when it comes from a trusted, vendor-validated source and the device verifies the manifest and image signature before installing, with a fallback image available if anything fails. The TCG's secure update guidance recommends dual-bank architectures specifically so a failed update never leaves a device inoperable.

Where can I find the official OTA update file for my device?

Official OTA files are typically distributed through a manufacturer's device management platform or vendor portal rather than third-party sites, as noted in Siemens' coverage of vehicle OTA systems. Installing firmware from any other source bypasses the verification chain that keeps the update trustworthy, so it's worth checking the vendor's own portal before applying anything.

Sources

Bring OTA into your product roadmap

Building a connected product that needs OTA from day one means the firmware architecture, the back-end job orchestration, and the mobile or web app that end users interact with all have to work together, not get designed in isolation. We handle that kind of cross-stack build as AI & automation and connected device work, pairing firmware-adjacent architecture decisions with the app and platform layer that surfaces update status to real users. Our approach keeps your team involved from the first architecture conversation through launch, helping ensure the OTA pipeline matches how your product actually gets used in the field. If you're scoping a connected-device platform or need the app and back-end side of an OTA rollout built out, start a conversation with our team about your project.