SLX Field Device Manager: Secure BLE OTA Firmware Updates

Secure firmware updates over Bluetooth Low Energy

SLX Field Device Manager is an internal research and development project for managing firmware updates on embedded devices through Bluetooth Low Energy. It was designed around a practical field scenario: the device may be reachable from a phone or laptop, but it does not have a permanent Internet connection and cannot depend on a cloud gateway to be maintained.

The objective is not simply to transfer a binary file. A usable OTA path must identify the target, expose diagnostics, verify the authenticity of the image, prevent unsafe version changes and recover cleanly if the first boot of a new image fails.

Local updates for industrial devices without permanent Internet access

Bluetooth LE is well suited to commissioning, local maintenance and controlled updates in environments such as machinery, portable instruments, test equipment and connected products installed where Wi-Fi or cellular connectivity is unavailable, restricted or simply unnecessary.

A technician can connect close to the device, inspect its identity and software version, upload an approved image and confirm the result without moving the update process through an external network. This reduces operational dependencies while keeping the workflow understandable for service personnel.

Nordic nRF5340-DK as the development platform

The prototype runs on the Nordic nRF5340-DK, selected for its Bluetooth LE capabilities and dual-core architecture. The board provides a realistic environment for validating boot behavior, radio communication, memory layout and update recovery before the design is transferred to custom hardware.

Dual-core architecture: application and connectivity

The nRF5340 combines an application core with a network core. In this project, the application core hosts the business logic, diagnostics, update policy and device services, while the network core supports Bluetooth LE connectivity. Keeping these responsibilities explicit makes the firmware easier to reason about as the product gains sensors, actuators and additional communication requirements.

Zephyr RTOS and the nRF Connect SDK provide the software base. The update path is built with MCUboot as the bootloader and MCUmgr SMP as the management protocol transported over Bluetooth LE.

Bluetooth LE diagnostics and device identification

Before an update is accepted, the operator needs enough information to confirm that the expected device is connected. The BLE service exposes device identity, firmware version, hardware data and diagnostic values. This helps avoid an update being applied to the wrong unit and gives the service workflow an immediate verification point.

The same connection is used to transfer the signed firmware image through the MCUmgr management channel. Designing diagnostics and update capability together avoids treating OTA as a hidden maintenance feature with no operational context.

OTA workflow with Web Bluetooth, MCUmgr SMP and MCUboot

The reference workflow uses a browser dashboard with Web Bluetooth to establish the local connection. The dashboard reads the basic device data, selects an approved firmware package and sends it to the device through MCUmgr SMP over BLE.

The image is written to the secondary slot. MCUboot then validates it during reboot and starts it as a test image. The application confirms the image only after the defined health checks have succeeded. Until confirmation, the previously working firmware remains available for recovery.

Firmware signing, anti-downgrade checks, health checks and rollback

The prototype treats integrity and recovery as part of the normal update path, rather than optional additions. A transferred file is not trusted simply because a BLE connection was established.

Authenticity checks before boot

Firmware images are signed with ECDSA P-256. MCUboot verifies the signature against the public key embedded in the boot chain before it allows the candidate image to run. This creates a clear boundary between an uploaded binary and an executable release.

Anti-downgrade control

The device compares release metadata and rejects versions that are not permitted by the update policy. This helps prevent accidental rollback to an obsolete image and provides a base for product-specific rules such as minimum supported versions or staged release channels.

Health checks and image confirmation

A newly booted image initially remains provisional. The application must complete the expected startup checks and explicitly confirm the image. The policy can include peripheral initialization, configuration validation, basic communication checks and other product-specific conditions.

Rollback to the previous image

If the application cannot confirm the new image, MCUboot returns to the last known working version on the following reboot. This is essential in embedded maintenance: a failed update must not turn a recoverable issue into an inaccessible device.

Timed service mode and target-side OTA policy

Update availability is controlled by the device, not only by the dashboard. A timed service mode can be enabled locally when maintenance is required, then close automatically after a defined period. This reduces the attack surface during normal operation while keeping the procedure simple for an authorized operator.

Target-side checks also make it possible to enforce rules such as the allowed hardware revision, image type, version constraints and the state of the device before an update begins.

Web dashboard for local connection, diagnostics and release control

The dashboard was developed for the demonstration environment and used to validate the BLE connection, diagnostics and OTA workflow on physical hardware. It provides a direct maintenance interface without requiring a dedicated native mobile application for the prototype.

For a production system, the same interaction model can be extended with authenticated operator access, release approval, audit logs and an organization-specific package distribution process.

Open the tool: SLX Field Device Manager, BLE OTA dashboard.

Using the OTA demo on a Nordic nRF5340-DK

1. Prepare the hardware

Program the reference firmware and bootloader on the Nordic nRF5340-DK, then power the board through USB. The board advertises the BLE service used by the demonstration.

2. Connect locally

Open the dashboard in a browser that supports Web Bluetooth, select the device and check the identity, firmware version and diagnostic information before starting the update.

3. Upload an approved signed image

Choose a package produced by the signing process. MCUmgr transfers it to the secondary slot through BLE; the target validates the image during the next boot.

4. Confirm operation or recover automatically

The candidate firmware completes its health checks and confirms itself only when it is operating correctly. If confirmation is missing, the bootloader restores the previous image at the next reboot.

Automated tests and updates verified on physical hardware

The OTA sequence was verified on a real nRF5340-DK with demonstration releases from 1.0.11 to 1.0.14. Tests cover the signed transfer path, boot behavior, device-side version control, confirmation and rollback conditions.

Testing on physical hardware matters because update reliability depends on the interaction between flash layout, bootloader configuration, radio transfer behavior and application startup—not only on the desktop tooling that initiates the upload.

From a development kit to a custom embedded product

The development kit is a useful starting point, but the same architecture can be adapted to a custom board. The production design must define the memory map, protected key material, debug access policy, image signing workflow, manufacturing process and recovery procedure around the actual device lifecycle.

That transition is where firmware, electronics and the maintenance interface need to be designed together: the update system must match the hardware constraints and the way technicians will use the product in the field.

Technical references: Nordic nRF5340-DK, Zephyr, MCUmgr and MCUboot

• Nordic nRF5340-DK
• Zephyr Project documentation
• MCUmgr device management
• MCUboot documentation

When to build a custom OTA system

A custom OTA solution is relevant when an embedded product needs controlled field maintenance, local updates without permanent Internet access, a defined recovery path or security rules that generic update tools do not cover. It is especially valuable when the same team must connect custom electronics, firmware, diagnostics and the service interface.

Talk about a secure embedded update workflow