Secure DFU Starts with a Threat Model

"The firmware is signed" is not a complete requirement. We outline who is allowed to issue releases, which devices have the right to upgrade, how lost account details are restored, whether downgrading is allowed, and how different types of failures are avoided. There are four controls that are regularly confused, though.

Control What it protects What it does not guarantee
Cryptographic signature Image authenticity and integrity Confidentiality of firmware bytes
Image encryption Confidentiality at rest or in transit That the plaintext was approved
Secure transport Update delivery session Safety of the image after download
Anti-rollback policy Known-vulnerable version downgrade Correct operation of a newer image

A solution may need all four. We document trust boundaries, public-key placement, private-key custody, recovery, debug policy, factory provisioning, version rules, and responses to unauthorized or interrupted updates.

What MCUboot Does in a Nordic Product

MCUboot serves as the standard bootloader for various applications created with the nRF Connect SDK. It covers all aspects of image metadata and behavior of flash-slot, performing actions such as validating candidates, signing them and determining what can actually run.

In a dual slot configuration, the active image stays in the main slot and its replacement is stored in the second slot.

Once the update is confirmed, it gains permanence. In case of a test update, it is necessary to have the actual application code verify the validity of the update, otherwise, MCUboot will reverse the process after the power cycle. This limits damages from genuine firmware which fails during execution.

MCUboot does not transfer files. MCUmgr and Simple Management Protocol can deliver local updates, while FOTA Download and DFU Target support connected workflows. Separating transport, image management, verification, and application health improves testability.

Relevant Adequate Infosoft Nordic Case Studies

The projects mentioned here contain a Nordic product engineering aspect. We do not mean that each case study employs MCUboot or uses sign DFU technology unless it is stated specifically in the case study.

Their applicability lies in the areas of device firmware, BLE insecurity, hardware, and the field lifecycle of devices.

Our Nordic Secure Boot Engineering Scope

Boot-chain and flash architecture

We have chosen the SoC architecture, the memory, the size of the update, the boot time, and the goal of availability. This work includes sysbuild, MCUboot, device tree, partitions, image slots, applicable swap space, storage of settings, alignment, trailer, and recovery interface.

We have chosen the SoC architecture, the memory, the size of the update, the boot time, and the goal of availability. This work includes sysbuild, MCUboot, device tree, partitions, image slots, applicable swap space, storage of settings, alignment, trailer, and recovery interface.

Development-kit layout may fail while the firmware is growing or the external flash is exposed to the brownout phenomenon. We have budgeted for signing overhead, reserved for growth, checked erase geometry, and tested production memory. The strategies for overwriting, swapping, and direct execution were evaluated based on recovery guarantees.

Image signing and release keys

We integrate supported signing with west, sysbuild, and MCUboot tooling. Development and production keys remain separate. Production private keys should not enter source control or developer laptops; signing can run through a controlled service, hardware security module, or cloud key manager.

We integrate supported signing with west, sysbuild, and MCUboot tooling. Development and production keys remain separate. Production private keys should not enter source control or developer laptops; signing can run through a controlled service, hardware security module, or cloud key manager.

Release controls can include approvals, reproducible builds, manifests, hashes, version metadata, provenance, audit history, and separation of duties. We plan key rotation and incident recovery before deployment.

Rollback and version policy

Version numbers are security components that determine how semantic versions, MCUboot security counters, hardware revisions, versions and release channels interact. If a device receives an image not suitable for the board or a release below the required security level, it will ignore the image.

Version numbers are security components that determine how semantic versions, MCUboot security counters, hardware revisions, versions and release channels interact. If a device receives an image not suitable for the board or a release below the required security level, it will ignore the image.

Rollback protection is sometimes a one-way street. This means that tests have to be done in stages, and there has to be a documented recovery route.

BLE DFU, Mobile Apps, and Cloud FOTA

For local updates, we implement MCUmgr/SMP over Bluetooth LE and validate with nRF Connect Device Manager. We can integrate DFU into native iOS, Android, Flutter, React Native, or .NET MAUI apps.

The client obtains an authorized release, selects the hardware package, transfers it safely, activates, reconnects, and reports the version.

Signing images does not obviate the need for BLE bonding, and having a signed image does not mean that all phones are eligible for updates. We implement access control, rate limiting, maintenance mode, consent, and recovery mechanisms.

For products like the nRF91, firmware can be delivered over HTTPS. The cloud services handle cohort assignments, the staged rollout, reporting, and inventory management. We integrate AWS, Azure, the nRF cloud, or any other software seen fit for the device management.

Learn more about our custom firmware development services.

Multi-Core and Multi-Image Update Planning

nRF5340 and nRF91 products can contain independently versioned application, network-core, modem, bootloader, or companion images. Updating one without compatible partners may leave a device that boots but cannot communicate.

The concepts of compatibility, dependencies, order of update, verification, and recovery are outlined, wherein CI gives rise to one defined release package.

The candidates under consideration undergo testing on erased devices, devices operating with updated versions, field baseline devices as well as supported revised hardware.

Nordic generations differ. The nRF54H20 has an isolated security subsystem and newer update model, so we follow its current secure-domain tooling rather than reusing an nRF52 recipe.

Verification: Try to Break the Update Before Release

Our acceptance plan covers valid installation as well as hostile and accidental failure. Tests can include:

  • modified payloads, headers, signatures, versions, and board identifiers;
  • images signed by an unauthorized, expired, or rotated key;
  • loss of power or radio link during erase, write, swap, and confirmation;
  • full flash, corrupted settings, external-memory errors, and watchdog reset;
  • unconfirmed test images and automatic reversion;
  • repeated update requests, replay attempts, downgrade attempts, and wrong-device packages;
  • low battery, poor RSSI, interrupted mobile apps, and backend timeouts;
  • recovery through approved wired, wireless, or factory service paths.

We record hashes, boot logs, reset reasons, transfer results, active slot, security counter, and post-boot health. Repeated cycles expose wear, timing, and state-machine defects.

From Security Requirements to Production Handover

An engagement begins with the target SoC, current SDK, memory map, update transports, deployed versions, manufacturing process, cloud and mobile architecture, and security obligations.

We then produce a threat model and update state diagram, prove the boot path on representative hardware, integrate delivery, and run destructive fault testing.

Handover may encompass programming code, system-building and partition-setting, signing directives, materials for public keys, CI incorporation, specifications of release packages, mobile or cloud application, the provisioning method, recovery manuals, test schedules, confirmation of proofs, and operational manuals of key management. The private production key will nevertheless be under the client's control.

Frequently Asked Questions

Does MCUboot allow for Nordic firmware updates to be encrypted?

MCUboot may be used in encrypted-image configurations. Nevertheless, signing and encryption are two processes that are not the same. Each of them is used independently, depending on the needs in terms of authenticity, confidentiality, memory, performance, and key management.

Can you migrate from the nRF5 SDK Secure DFU bootloader?

Yes. We inventory deployed bootloader and application versions, SoftDevice dependencies, keys, flash layout, mobile workflow, and recovery options. Migration may require a carefully staged bridge release; it is not always a direct package replacement.

Can we use signed DFU with our apps already on the market?

Yes. We can find a way to integrate the necessary Nordic device management library (or protocol) into the app and connect the app to release APIs, as well as add package selection and other functions to it.

Editorial Sources

Ashok Patel
Ashok Patel
Senior Engineering Project Manager
AI/ML, DevOps, Data Science & Automation | IoT & C#/.NET | Azure & AWS Expert | Certified AI & Cloud Engineer | 1,500+ LinkedIn Followers
Facebook LinkedIn Stack Overflow