Embedded Systems & Product Development Consultancy · London, UK

Bootloaders, OTA updates and device security

Every connected device will need a fix after it ships. We design the bootloader, the update path and the security around them, so updates arrive signed, install safely and can be rolled back, and each device can prove who it is.

Talk to an engineer Wireless & IoT

One bad update away from a recall

Update and security code runs rarely, so its bugs surface late, usually on devices you can no longer reach.

An update interrupted by a power cut leaves the device unable to start.
Images that aren’t signed, so anyone with a programmer or the right packet can replace the firmware.
Shared keys or passwords built into every unit, so one leaked device exposes them all.
Debug ports left open on production units.
No way to update a co-processor, radio or modem once the product has shipped.
Updates that need a technician on site, so fixes simply don’t happen.

We design updates and security as part of the architecture, then test the failure cases on purpose.

What we put in place

Bootloaders. Custom and MCUboot-based bootloaders with dual-bank or swap layouts, image checks and recovery modes.
Over-the-air updates. Updates over BLE, Wi-Fi, cellular or Ethernet, with resume after interruption and automatic rollback. →
Co-processor and module updates. Update paths for radios, modems, baseband processors and other chips on the board, driven from the main processor.
Secure boot and signing. Signed images, a chain of trust from the boot ROM and a signing process that keeps private keys off engineers’ laptops.
Provisioning and identity. Unique keys and certificates for each device, injected in production and stored in a secure element where possible. →
Linux updates. A/B image updates with SWUpdate, RAUC or Mender for embedded Linux products. →

Designing updates that can fail safely

Model the threats. What an attacker could gain, how the device could be reached and what has to be protected.
Plan the memory. Flash layout for two images or a recovery image, the bootloader and room for growth.
Build the chain of trust. Boot ROM, bootloader and application, each checking the next before it runs.
Break it on purpose. Power cuts mid-update, corrupted images, wrong versions and full flash, tested on hardware.
Hand over the process. Signing, release and key-handling procedures your team can run without us.

Bootloaders, crypto and update services

Bootloaders: MCUboot, U-Boot, vendor ROM bootloaders, custom bootloaders for STM32, nRF and PIC32

Security hardware: secure elements such as Microchip ATECC608, Arm TrustZone, STM32 and nRF secure boot features, i.MX HAB

Crypto and protocols: TLS with X.509, SHA-256, ECDSA, AES, Mbed TLS

Update services: AWS IoT Jobs, nRF Connect Device Manager, SWUpdate, RAUC, Mender

Updates and security in the field

Client names stay private. The engineering doesn’t.

Firmware updates for the VHF chip and the mapping system in marine transponders

View case studies

Secure provisioning and OTA updates for a wearable medical device

Read the case study

Security hardware

An ATM security device with more than 40,000 units in service, an NB-IoT sensor authenticated to AWS IoT Core with X.509 certificates, and public-key encryption on an infrared data link.

Ask about this work

Frequently asked update and security questions

What happens if power fails during an update?

Nothing harmful, if the design is right. The new image is written to a separate slot and checked before the switch; if it doesn’t start properly, the bootloader goes back to the previous version.

Do we need a secure element?

Not always, but it is the simplest way to keep private keys out of reach. For connected or safety-related products we usually recommend one; many microcontrollers also offer secure key storage.

Can you add OTA to a product that’s already in the field?

Often. It depends on how much flash is free and whether the existing bootloader can be replaced safely. We assess that first and plan a one-time migration update.

What does the UK PSTI regulation mean for us?

Since April 2024, consumer connectable products sold in the UK must not use universal default passwords, must publish a way to report vulnerabilities and must state how long they will receive security updates. We design devices and update processes that meet these requirements.

Who holds the signing keys?

You do. We set up the signing process and key storage so release builds are signed in a controlled place, and hand over the procedure with the project.

Can you review the security of our existing firmware?

Yes. We review the bootloader, update path, key handling and debug access, and give you a prioritised list of fixes.

Need devices you can update safely?

Tell us how your devices connect, what they run on and how you update them today.

An engineer will read it and reply within one business day.

Talk to an engineer