.png)
Secure OTA Updates: Signing, Verification, and Anti-Rollback in the Real World
Shipping firmware over the air is easy to demo and hard to secure. The hard part is not pushing bytes to a device. It is proving that the bytes came from you, were not changed in transit, are allowed on that exact device, and cannot be swapped for an older but vulnerable build. That is why secure OTA updates are really about trust chains, not transport alone. In production, you need artifact signing, device-side verification, key management, recovery if the new image fails, and anti-rollback that blocks known-bad downgrades. This guide explains how those pieces fit together, which stacks already implement them, and where teams usually get the design wrong.
What secure OTA updates actually protect
At minimum, a secure OTA design should protect four things: authenticity, integrity, device compatibility, and freshness. Authenticity means the update came from a trusted signer. Integrity means the bits were not modified. Compatibility means the image matches the target device or partition layout. Freshness means an attacker cannot replay an older but still correctly signed image. Mender’s docs are explicit that artifact verification is an extra layer independent of the communication channel, and Uptane’s model signs metadata about images, hashes, sizes, and repository roles so devices can verify more than a file download alone.
That last point is where many teams stumble. HTTPS is necessary, but it does not replace signed artifacts. TLS protects the connection. It does not prove that the firmware image itself is trusted after it leaves your server, sits in a cache, or gets copied through another path. Mender’s client can reject unsigned artifacts entirely when verification is enabled, precisely to avoid an attacker bypassing verification by injecting an unsigned payload.
How it works: the real trust chain
A production OTA path usually has six stages:
- Build the firmware image.
- Sign it with a protected private key.
- Publish the signed artifact plus metadata.
- Download it to the device over a secure channel.
- Verify it on-device before install or boot.
- Either commit it, revert it, or reject it based on boot success and version policy.
MCUboot’s image tooling shows this clearly. Images are signed with imgtool, can carry a version, and can also carry a separate security counter used for hardware-backed rollback protection. The bootloader then validates the image and compares the new security counter against a trusted stored value.
Mender supports signing with RSA or ECDSA and verifying on the device with provisioned public keys. It also supports multiple verification keys, which is useful for key rotation.
The device side is where the design becomes real. Android AVB’s boot-time library expects the platform to provide the root of trust and get or set rollback-protection metadata. That is a strong signal that anti-rollback cannot live only in the build pipeline. It needs trusted state on the device. Android compatibility requirements go further and call for tamper-evident storage for the minimum allowable OS version used in rollback protection.
The practical takeaway is simple: signing proves who approved an image, but anti-rollback needs a trusted memory of what the device is no longer allowed to boot.
For teams building custom hardware, this is usually the point where architecture review matters most: root of trust placement, key injection, monotonic counters, and the exact bootloader commit flow.
Best practices and pitfalls
What good looks like
A real-world secure OTA design usually has this checklist:
- keep private signing keys off the build server
- provision a public verification key or root of trust onto devices
- verify artifacts on-device, not just server-side
- use A/B, dual-bank, or equivalent fallback for failed boots
- separate rollback-on-failure from anti-rollback policy
- store anti-rollback state in trusted non-volatile storage
- support key rotation before you need it
- bind updates to device class, hardware revision, or partition layout
- define when an update becomes “confirmed”
- log install, verify, boot, revert, and counter-advance events
Mender explicitly recommends signing on an offline signing system rather than the build system because compromise of the build system makes private-key theft easier. It also supports multiple verification keys for rotation. MCUboot makes the same design pressure visible from the other side: the bootloader needs a trusted validation path and, for hardware rollback protection, a trusted non-volatile security counter.
The pitfall that causes the most confusion
Teams often say “we support rollback” when they actually mean “we can revert after a bad boot.” That is not the same as anti-rollback.
Android’s A/B docs describe automatic return to the old partition when the new OS fails to boot. Android Verified Boot separately describes rollback protection to ensure devices only update to newer versions. MCUboot also makes the split explicit by documenting downgrade prevention alongside rollback protection using a security counter.
Another easy miss: metadata freshness
In larger systems, image signing alone is not enough. Uptane’s standard includes signed Root, Timestamp, Snapshot, and Targets roles, with explicit version checks to detect rollback attacks in metadata itself. Uptane also notes that a TUF-only offline approach does not protect against rollback unless old images are pruned regularly. That matters in fleets where old valid images may remain hosted for legitimate reasons.
Performance, cost, and security considerations
Security controls affect footprint and operations, so the right design is rarely “turn everything on.”
On constrained MCUs, algorithm choice matters. MCUboot’s tooling supports rsa-2048, rsa-3072, ecdsa-p256, and ed25519 keys. Mender supports RSA signing with a recommended minimum of 3072 bits and ECDSA P-256 for artifact signing. Those choices affect signature size, verification speed, code size, and crypto library support.
Storage strategy matters too. A/B and dual-slot updates reduce bricking risk, but they cost space. Android’s Virtual A/B exists largely to reduce that cost. Google’s docs say compressed snapshots reduce full OTA snapshot size by around 45% and incremental OTA snapshot size by around 55%, while still allowing rollback if the new OS fails to boot.
Key storage is another real-world trade-off. Mender documents support for HSMs and TPMs so private keys do not have to sit as plain files on the device. Android’s rollback metadata model assumes a trusted root of trust and tamper-evident storage for minimum allowable versions. If your fleet is high-value enough to target physically, these details are not optional.
Cloud delivery services do not remove this burden. AWS IoT OTA can sign firmware, stream it, and orchestrate jobs, but the device still needs a correct verification and boot policy. AWS’s own OTA flow is sign first, then create a stream, then start the OTA job.
This is also where hidden cost shows up: support costs from bad updates, reflashing, truck rolls, and reputational damage usually dwarf the cost of a better signing and fallback design.
For device makers shipping beyond pilot scale, this is often the stage where a secure-update review is cheaper than one field incident.
Real-world use cases
Consider an industrial gateway with two flash slots and a secure bootloader. The vendor signs firmware in an offline signing environment, the device downloads the artifact over TLS, the bootloader verifies the signature, then boots the new image in trial mode. If the application reaches a health check and marks itself confirmed, the update becomes permanent. If it fails to boot cleanly, the bootloader falls back to the previous slot. If an attacker later tries to reinstall an older signed image with a known bug, the bootloader blocks it because the stored security counter is already higher.
That design is not hypothetical in structure. It closely matches the mechanisms documented by MCUboot and Mender’s MCUboot-based Zephyr flow: two slots, signed firmware, boot confirmation, and reversion when the new firmware fails validation or confirmation.
Now compare that with a vehicle platform updating multiple ECUs. In that world, signing the image is still necessary, but it is not enough. You also need signed metadata about which ECU should install which image, repository role separation, and version checks that prevent mix-and-match or rollback attacks across components. That is exactly the kind of problem Uptane was designed to address.
.png)
FAQs
What are secure OTA updates?
Secure OTA updates are over-the-air firmware or system updates that include controls for authenticity, integrity, and safe installation. In practice that means signed artifacts, device-side verification, and recovery or rejection rules at install or boot time.
Is HTTPS enough for OTA security?
No. HTTPS protects the transport session. Signed artifacts protect the update itself. Mender explicitly treats artifact verification as an additional layer independent of the communication channel.
What is the difference between rollback and anti-rollback?
Rollback usually means reverting to a last known-good image after a failed boot. Anti-rollback means blocking installation or boot of an older vulnerable version even if it was once valid and correctly signed.
Where should OTA signing keys live?
Not on the build server if you can avoid it. Mender recommends signing on an offline signing system, and also supports hardware-backed storage options like HSM or TPM integration.
How does MCUboot handle anti-rollback?
MCUboot supports downgrade prevention based on version checks and hardware-based rollback protection using a security counter stored in trusted non-volatile state and carried in the signed image TLV area.
How does Android handle safe updates?
Android uses Verified Boot and AVB for integrity and rollback protection, and A/B or Virtual A/B for seamless updates and recovery if the new OS fails to boot.
When do I need Uptane instead of a simpler OTA scheme?
Uptane becomes attractive when you need stronger repository metadata, multi-ECU coordination, version checks across roles, or protection against mix-and-match and rollback attacks in complex vehicle-style update systems.
An OTA update is only as secure as the trust chain behind it, not the convenience of delivering it.
Conclusion
Secure OTA updates are not just about sending firmware over the air. They depend on a complete trust chain: protected signing keys, device-side verification, safe recovery when updates fail, and anti-rollback controls that prevent older vulnerable builds from returning. In real deployments, the risk is rarely the update mechanism alone. It is the gap between what teams think is protected and what the device actually enforces. The systems that hold up in the field are the ones designed for authenticity, integrity, recovery, and long-term trust from day one.
If you are building connected devices and need a secure OTA architecture that works in the real world, contact us to design or review your update pipeline before deployment.
