Securing Over-the-Air Firmware Updates

A safe OTA firmware update pipeline, from signing at build time to an atomic A/B swap on the device

An over-the-air update is the most powerful feature most IoT products ship: remote code execution, as root, on every device, by design. That makes the update pipeline the single most important thing to get right. Here is what a safe OTA flow looks like and the three ways it usually breaks.

Why OTA Is the Crown Jewel

If an attacker can get a device to accept their firmware, every other control is moot: secure boot, key storage, and network hardening all assume the firmware is yours. The update channel is the one path that can replace the firmware itself, so it has to be the most carefully defended path in the product.

Step 1: Watch the Update Fetch

The first thing to check is how the device gets its update. Intercepting the request often tells the whole story:

curl -sI http://updates.vendor.example/firmware/latest.bin

Example output

HTTP/1.1 200 OK
Content-Type: application/octet-stream
Content-Length: 8388608

An update served over plain HTTP can be swapped by anyone on the network path. That is a critical finding before the signature question is even reached.

Step 2: Check the Manifest and Signature

A safe update ships a signed manifest binding the version, the image hash, and a minimum version:

Anatomy of a signed OTA update manifest showing version, hash, minimum version, and signature

openssl dgst -sha256 -verify update_pub.pem \
  -signature manifest.sig manifest.json

Example output

Verified OK

If the manifest is unsigned, or only the binary is signed while the version field is not, an attacker can downgrade the device to a vulnerable build that still passes the signature check.

Three OTA Failure Modes

The recurring weaknesses in update mechanisms:

Three OTA update failure modes: an unsigned image, no rollback protection, and plain HTTP delivery

Building a Safe OTA Flow

Sign the manifest and the image, enforce a monotonic minimum version to block downgrades, deliver over TLS with certificate validation, and apply updates atomically with an A/B partition scheme so a failed update cannot brick the device. Test the negative cases: a tampered image and a downgrade both have to be rejected.

Where This Fits

Reviewing the update pipeline end to end, and proving tampered and downgraded images are refused, is central to a product security assessment. That work is the kind of work we do at Berkner Tech.