OTA Firmware Updates: How to Update Embedded Devices Safely

Once your embedded device ships, fixing bugs or adding features requires a firmware update. In the past, this meant recalling hardware, sending technicians to the field, or asking customers to connect a USB cable and run desktop software.

Over-the-Air (OTA) firmware updates solve this by allowing devices to download and install new firmware remotely over Wi-Fi, Ethernet, cellular, or other network connections. Done correctly, OTA updates transform embedded products into maintainable, long-lived systems. Done poorly, they create security vulnerabilities and bricked devices.

This guide covers the practical engineering decisions required to build a safe, reliable OTA update system.

Why OTA Firmware Updates Matter

Key benefits:

Fix bugs remotely without customer interaction
Deploy security patches quickly when vulnerabilities are discovered
Add new features to already-deployed hardware
Reduce support costs by eliminating manual update procedures
Extend product lifetime with continuous improvements

Risks if done incorrectly:

Devices bricked by interrupted updates
Security vulnerabilities from unsigned firmware
Downgrade attacks installing vulnerable older firmware
Network or storage exhaustion during mass rollouts

A robust OTA system must handle failure gracefully. Devices should never become permanently unbootable due to a failed update.

OTA Update Flow

A typical OTA update follows this sequence:

Check for Update → Download → Verify → Install → Reboot → Validate → Confirm or Roll Back

Let’s break down each step:

1. Check for Update

The device periodically contacts an update server to check if a new firmware version is available.

Common approaches:

Poll an HTTP/HTTPS endpoint with current firmware version
MQTT message with version query
CoAP or custom protocol for constrained devices

The server responds with metadata: version number, firmware size, download URL, checksum, and signature.

Version comparison determines whether an update is needed. Use semantic versioning (1.2.3) or monotonic version numbers, not just timestamps.

2. Download Firmware

The device downloads the new firmware image over the network.

Key considerations:

Chunked/resumable downloads: Handle network interruptions gracefully
Progress tracking: Store download offset to resume after connection loss
Storage location: Write to inactive partition or external flash, never overwrite running firmware
Size validation: Verify available space before starting download

Transport options:

HTTPS: Encrypted, authenticated, widely supported
HTTP: Simpler but lacks transport-layer security (rely on firmware signature instead)
MQTT: Efficient for IoT devices with existing MQTT infrastructure
Custom protocols: For bandwidth-constrained or proprietary systems

3. Verify Integrity and Authenticity

Before installation, verify the downloaded firmware is complete and legitimate.

Integrity check (checksum/hash):

Compute SHA-256 hash of downloaded firmware
Compare with hash provided by server
Detects corruption during download or storage

Authenticity check (digital signature):

Verify firmware is signed by trusted authority
Use asymmetric cryptography (RSA, ECDSA)
Public key stored securely in device, private key held by manufacturer
Prevents malicious firmware injection

Critical distinction:

Hashing detects accidental corruption
Signing prevents intentional tampering

Both are necessary. Hash alone cannot detect malicious firmware with a matching hash provided by an attacker.

4. Install Firmware

The bootloader or update agent installs the verified firmware.

Installation strategies:

A/B partitions (dual-bank flash):

Two complete firmware slots: Active (A) and Inactive (B)
Download new firmware to inactive slot
Switch boot partition after successful verification
If new firmware fails, automatically boot from old slot
Advantage: Atomic updates, instant rollback
Disadvantage: Requires 2x firmware storage space

Single partition with bootloader validation:

Smaller devices without space for dual partitions
Bootloader validates firmware before jumping to application
Uses external storage or compressed differential updates
Advantage: Lower flash usage
Disadvantage: More complex recovery, slower updates

Write protection: Lock old firmware partition until new version is confirmed working.

5. Reboot

After installation, the device reboots to start the new firmware.

Bootloader responsibilities:

Select correct partition (A or B)
Verify firmware signature and integrity before execution
Enforce secure boot chain
Provide fallback if primary firmware is invalid

6. Validate New Firmware

After booting into the new firmware, the application must validate that it is functioning correctly.

Validation checks:

Basic functionality tests (sensor reads, network connection)
Configuration compatibility verification
Self-test routines

Confirmation mechanism:

New firmware explicitly marks itself as “good” after successful validation
If confirmation does not occur within timeout (e.g., 5 minutes), assume failure
Bootloader automatically rolls back to previous version

Watchdog integration: Use hardware watchdog to detect firmware hang or crash.

7. Confirm or Roll Back

Success path:

Firmware validation passes
Application confirms update success to bootloader
Old firmware partition can now be erased (or kept as backup)

Failure path:

Firmware fails validation, crashes, or does not confirm within timeout
Bootloader detects failure (via persistent flag or lack of confirmation)
Device automatically reboots into previous working firmware
Update failure logged and reported to server

This automatic rollback is the most critical safety feature in an OTA system.

Power Loss During Update: A Practical Failure Scenario

Scenario: Device is halfway through writing new firmware to flash when power is lost.

Without protection:

Firmware is partially written and corrupted
Device cannot boot
Requires factory reset, JTAG recovery, or RMA

With A/B partitions:

New firmware was being written to inactive partition
Active partition remains untouched
Device boots normally from active partition after power restoration
Update process restarts from beginning

With single partition + bootloader:

Bootloader detects corrupted firmware (signature or CRC check fails)
Bootloader enters recovery mode
Download firmware again or boot from backup recovery image
Device is recoverable without external tools

Key lesson: Never overwrite running firmware. Always write to a separate location and switch atomically.

Single-Partition vs. A/B Updates

Single-partition update:

Pros:

Saves flash memory (critical for small MCUs)
Lower BOM cost

Cons:

More complex bootloader logic
Longer update time if using external storage or differential updates
Harder to implement instant rollback

A/B (dual-bank) update:

Pros:

Atomic updates: new firmware fully written before activation
Instant rollback on failure
Simpler, more reliable design

Cons:

Requires 2x firmware flash space
Higher cost for larger flash

Recommendation: Use A/B partitions if flash budget allows. The reliability and simplicity advantages outweigh the storage cost for most modern embedded systems.

Encryption vs. Signing

Digital signatures (always required):

Prove firmware authenticity
Detect tampering
Prevent malicious firmware injection

Encryption (situational):

Protects firmware intellectual property during transit
Prevents reverse engineering of downloaded firmware
Not a substitute for signing

When encryption is needed:

Proprietary algorithms or trade secrets in firmware
Regulatory or contractual IP protection requirements

When encryption is optional:

Firmware already contains public information
Obscurity is not a security requirement
Performance or complexity constraints

Important: Encrypted firmware must still be signed. Encryption without authentication provides no security benefit.

Secure Boot

Secure boot ensures only trusted, signed firmware can execute on the device.

How it works:

Bootloader verifies firmware signature before execution
Public key or certificate stored in write-protected memory
If signature verification fails, firmware does not run

Integration with OTA:

New firmware must be signed with same trusted key
Bootloader rejects unsigned or incorrectly signed updates
Prevents attackers from installing modified firmware even if they compromise the update server

Secure boot is the foundation of a trustworthy OTA system.

Preventing Downgrade Attacks

A downgrade attack installs an older, vulnerable firmware version to exploit known security flaws.

Mitigation: Version monotonicity enforcement

Methods:

Monotonic counter: Store firmware version in non-volatile memory; reject updates with lower version numbers
Anti-rollback counter: Hardware-enforced counter that can only increase
Timestamp validation: Reject firmware older than a certain date

Considerations:

Allow rollback during development/testing
Support emergency rollback in production with explicit authorization
Balance security with operational flexibility

Configuration and Data Compatibility

Firmware updates can break compatibility with existing configuration files, persistent data, or external systems.

Design strategies:

Version configuration schemas:

Include version metadata in config files
Migrate old config to new format during update

Separate data partitions:

Keep application data separate from firmware
Avoid reformatting data partitions unless necessary

Compatibility checks:

Verify data version before starting application
Provide migration path or reject incompatible data with clear error

Database/NVRAM changes:

Test upgrades and downgrades during development
Plan migration scripts for schema changes

Failure to handle compatibility is a common cause of post-update crashes.

Updating Multiple Processors

Some products contain multiple processors or MCUs (application processor + Bluetooth chip, main MCU + motor controller, etc.).

Challenges:

Coordinating updates across multiple devices
Maintaining protocol compatibility during partial updates
Recovery if one processor updates successfully but another fails

Strategies:

Sequential updates: Update and validate one processor at a time
Version compatibility matrix: Ensure firmware versions are interoperable
Fallback communication: Maintain backward-compatible communication protocols
Centralized coordinator: One processor manages the update process for others

Test multi-processor updates thoroughly in all failure scenarios.

Staged Rollouts

Never update all devices simultaneously.

Staged rollout strategy:

Internal testing: Deploy to development and test devices first
Canary deployment: Update 1–5% of fleet
Monitor for failures: Track crash reports, rollback rate, connectivity issues
Gradual expansion: Increase rollout percentage if no issues detected (10% → 25% → 50% → 100%)
Emergency halt: Ability to stop rollout immediately if critical bug discovered

Benefits:

Limit blast radius of bad firmware
Detect issues before widespread deployment
Preserve rollback capacity on most devices

Implementation:

Server-side rollout controls
Device grouping by region, customer segment, or random sampling
Metrics and telemetry for rollout health monitoring

Logging and Failure Reporting

Capture and report update failures to improve reliability.

Log events:

Update check attempts
Download progress and completion
Verification results (integrity, signature)
Installation success/failure
Boot validation outcome
Rollback events

Telemetry data:

Firmware version (old and new)
Failure reason (network, verification, boot failure)
Retry count
Device environment (battery level, network strength)

Reporting strategy:

Store logs locally in persistent storage
Upload logs on next successful network connection
Aggregate failure metrics on server for fleet-wide analysis

Failure data drives continuous improvement of OTA reliability.

Common OTA Mistakes

1. Overwriting running firmware directly

Guarantees bricked device on power loss or failure
Always write to inactive partition or separate storage

2. Trusting firmware without signature verification

Allows malicious firmware injection
Cryptographic signatures are mandatory, not optional

3. No rollback mechanism

Failed update leaves device unusable
Automatic rollback is a core requirement

4. Ignoring configuration/database compatibility

New firmware crashes on old config formats
Plan data migration and compatibility checks

5. Assuming network or power will remain available

Downloads fail, power is interrupted
Design for resumable downloads and atomic installation

6. Updating all devices simultaneously

Bad firmware affects entire fleet instantly
Use staged rollouts to limit risk

7. Insufficient testing of failure paths

Most OTA bugs appear in edge cases: power loss, network timeouts, corrupted storage
Test failure scenarios extensively

8. No recovery mechanism

Even with perfect OTA design, devices sometimes fail
Provide UART/JTAG recovery or factory reset capability

OTA Design Checklist

Use this checklist when designing an OTA update system:

Firmware stored in separate partition or external flash during download
A/B partition support or equivalent atomic update mechanism
Resumable/chunked downloads to handle network interruptions
SHA-256 or stronger hash verification of downloaded firmware
Digital signature verification using asymmetric cryptography
Secure boot enforces signature validation before execution
Public key/certificate securely stored in write-protected memory
Version comparison prevents downgrade attacks
Configuration and data compatibility verified before starting new firmware
Bootloader validates firmware integrity before booting
Application self-validation after reboot with explicit confirmation
Automatic rollback on boot failure or validation timeout
Watchdog integration to detect firmware crashes
Multi-processor update coordination if applicable
Update events and failures logged and reported
Staged rollout capability to limit risk
Emergency stop/rollback for fleet-wide issues
Recovery mechanism (factory reset, UART recovery, JTAG) for worst-case failures
Power-loss testing during all update phases
Testing of partial updates, network failures, and corrupted downloads

Conclusion

OTA firmware updates are essential for modern embedded products, but safety and reliability must be built in from the start. A robust OTA system requires secure download mechanisms, cryptographic verification, atomic installation, and automatic rollback on failure.

The engineering effort is worthwhile: properly implemented OTA updates extend product lifetimes, reduce support costs, improve security posture, and enable continuous improvement of deployed devices.

Design for failure. Test every failure path. Never assume network or power will remain stable. Implement rollback before the first production device ships.

With careful architecture and thorough testing, OTA updates transform embedded devices from static products into maintainable, long-lived systems.

What OTA challenges have you encountered in your embedded projects? Share your experience.