I want to start with a scenario I have seen more than once. A manufacturer ships a connected device. The OTA update mechanism works - firmware gets delivered to devices in the field, the update applies, everything looks fine. Then someone points out that the device accepts any firmware image delivered through the update channel. No signature check. No integrity verification. The device flashes whatever it receives.

At that point the "working OTA update" is actually an attack vector.

This is not an exotic vulnerability. Unsigned or weakly authenticated firmware updates are one of the most common security failures in IoT devices, and they are one of the things CRA directly addresses. This article is about what a correct OTA update architecture looks like, what can go wrong without it, and how the pieces fit together in practice. For broader CRA context, start with our complete guide for IoT manufacturers.

What can go wrong without image signing

An OTA update mechanism has one job: get the right firmware onto devices in the field. "Right" means firmware that you wrote, that has not been modified, and that is the version you intended to deploy.

Without image signing, none of those three properties are guaranteed.

Firmware replacement: An attacker who can intercept or influence the update delivery - through a compromised update server, a man-in-the-middle on the network, or a vulnerability in your backend - can substitute their own firmware image. The device has no way to tell the difference between your image and theirs. It flashes whatever arrives.

Image tampering: Even if the attacker cannot replace the image entirely, they may be able to modify it in transit. Insert a backdoor into a legitimate firmware binary, change configuration values, patch out a security check. Without a cryptographic signature over the entire image, the device cannot detect that modification occurred.

Rollback to vulnerable versions: Without anti-rollback protection, an attacker can push an old firmware version with known vulnerabilities back onto devices you have already patched. Your update process fixed a vulnerability; they undo it by rolling devices back to the version before the fix.

Fake update server: A device that accepts firmware from any server it can reach - or that does not verify the server's identity - can be redirected to an attacker-controlled update endpoint. The device thinks it is updating from your infrastructure. It is not.

Each of these is a real attack pattern, not a theoretical one. And each is preventable with a correctly designed OTA architecture.

What a secure OTA architecture looks like

The core of secure OTA is asymmetric cryptography applied to the firmware image. You sign the image with your private key during the build process. The device verifies the signature using your public key before applying the update. An image that was not signed with your key - or that was modified after signing - fails verification and is rejected.

Here is how the components fit together:

Image signing at build time. As part of your firmware build pipeline, the final binary is signed using your private signing key. The signature is embedded in or attached to the firmware package along with metadata: version number, target hardware identifier, minimum supported version (for anti-rollback). The private key never leaves your build infrastructure - only the signed image is distributed.

Key storage on the device. The device holds the corresponding public key, used to verify signatures. Where this key lives matters. The strongest approach is hardware-backed storage - OTP memory, a secure element, or a hardware key management unit on the chip (like Nordic's KMU). A public key that can be replaced by an attacker undermines the entire signature scheme. On STM32, the public key hash goes into Option Bytes. On nRF, it goes into the UICR or KMU depending on the series.

Verification before flash. The bootloader or update manager verifies the image signature before writing it to flash. This is not optional and it is not a "we'll add it later" feature - it has to happen in the critical path before any update is applied. If verification fails, the update is rejected, the existing firmware remains, and the event is logged.

Anti-rollback enforcement. A monotonic counter stored in non-volatile memory tracks the minimum acceptable firmware version. Each signed firmware image carries a version number. The device rejects any update with a version number lower than the current counter value. Once you patch a vulnerability and deploy the fix, devices will not accept a rollback to the vulnerable version.

Secure delivery channel. The channel that delivers firmware packages should use TLS - not because TLS replaces image signing, but because defense in depth means you do not rely on a single control. Image signing is your last line of defense; TLS is the layer before it. Server authentication matters here too: the device should verify it is talking to your update server, not a redirected endpoint.

How MCUboot handles this on Nordic and STM32

MCUboot is the open source bootloader we use most frequently for secure OTA on Cortex-M targets. It is well-supported in both the Nordic nRF Connect SDK and STM32 environments, and it implements the core signing and verification logic correctly.

On Nordic nRF (nRF Connect SDK): MCUboot is integrated as the default secure bootloader. Firmware images are signed using imgtool - the signing tool included in the MCUboot toolchain - with ECDSA-P256 keys. The signing step happens at build time and is configurable in the project's CMakeLists. The public key is compiled into the MCUboot binary itself during the MCUboot build, which then gets provisioned to the device. Anti-rollback is supported through the security counter mechanism in the image header.

The nRF Connect SDK also supports the nRF Secure Immutable Bootloader (NSIB) as a first-stage bootloader that verifies MCUboot before MCUboot verifies the application. This gives you a two-stage chain of trust: hardware root → NSIB → MCUboot → application.

On STM32 (STM32L5, STM32U5, STM32H5): ST provides the SBSFU (Secure Boot and Secure Firmware Update) reference implementation, and newer series have STiROT (ST immutable RoT) built into ROM. For projects using MCUboot directly, the signing flow is the same as Nordic - imgtool signs the image, the public key is embedded in MCUboot, verification happens at boot before the application runs. The critical STM32-specific step is locking Option Bytes in production - this prevents an attacker with physical access from re-provisioning the verification key.

In both environments, the build pipeline integration is where teams most often have gaps. Signing needs to be automatic, not manual.

What CRA requires specifically

Annex I of the CRA requires that manufacturers "ensure the security of updates... and ensure that update mechanisms do not introduce additional vulnerabilities." More specifically, updates must be distributed in a way that preserves the integrity and authenticity of the software.

In practice this means:

  • Updates must be authenticated - the device must verify that the firmware came from you
  • Updates must be integrity-checked - the device must detect any modification of the firmware package
  • Updates must be delivered securely - the channel must be protected against interception and tampering
  • Anti-rollback must be in place - you must prevent regression to known-vulnerable versions
  • Updates must be free to the user - you cannot charge for security patches, which has architectural implications for how your update delivery is structured

The last point is worth noting separately. If your OTA mechanism requires a paid subscription to receive updates, that architecture conflicts with CRA's requirement that security updates be provided without charge. This is a product design constraint, not just a billing one.

The September 2026 Article 14 reporting obligation also connects to OTA architecture. If you discover an actively exploited vulnerability and need to deploy a patch quickly, your OTA mechanism needs to be reliable and fast. A broken or unreliable update channel means your incident response is compromised - you can report the vulnerability but you cannot remediate it effectively.

The connection to secure boot

OTA and secure boot are related but separate controls that need to work together.

Secure boot verifies firmware at every power-on - it ensures the device only runs signed firmware from flash. OTA signing verifies firmware before it is written to flash - it ensures only authorized updates get applied. You need both.

A device with secure boot but without OTA signing will reject modified firmware at boot, but it might still write a malicious image to flash if the update mechanism does not verify it first. Depending on how your bootloader handles corrupted images, this could brick the device or cause a boot loop. Either way, the attacker has caused a denial of service even if they cannot execute code.

A device with OTA signing but without secure boot verifies updates correctly, but an attacker with flash access can bypass the OTA mechanism entirely and write directly to the firmware partition. Secure boot is what prevents that.

The correct architecture has both - and they share the same root of trust. The same key infrastructure that signs your firmware for secure boot verification is what signs your OTA packages. Keeping these aligned avoids having to manage two separate key hierarchies.

The provisioning side

One thing that does not get discussed enough in OTA security articles: the public key that devices use to verify firmware has to be provisioned correctly at the manufacturing stage, and it has to be provisioned with the correct hardware lockdown.

If you flash the same MCUboot binary (with the embedded public key) to every device but do not lock the relevant option bytes or OTP registers, an attacker with physical access can potentially overwrite the key. The entire signature verification scheme is contingent on the key being trustworthy - which means the provisioning process at the factory has to be secure.

This is where OTA security and secure provisioning intersect. The security of your update mechanism is partly determined by what happens on the production line, not just in firmware.

FAQ

Does TLS on the update channel replace image signing? No. TLS protects the transport - it prevents interception in transit. Image signing protects the content - it verifies authenticity and integrity regardless of how the image was delivered. If your update server is compromised, TLS does not help. Image signing does. You need both, and image signing is the more important of the two.

What key size should I use for firmware signing? ECDSA with P-256 (256-bit) is the standard for embedded OTA signing and is what MCUboot uses by default. It provides adequate security with small key and signature sizes, which matters in resource-constrained environments. RSA-2048 is an alternative if your platform has the compute headroom, but ECDSA-P256 is the more practical choice for most IoT targets.

We already have OTA updates working. How hard is it to add signing? It depends on your bootloader. If you are already using MCUboot, adding signing is largely a build pipeline change - configure imgtool in your build system, generate keys, update your MCUboot configuration to include the public key. If you have a custom bootloader with no verification logic, you either need to add verification or migrate to MCUboot. The latter is usually the better investment.

Does every firmware update need to be signed, or just major releases? Every update. Partial or selective signing gives an attacker a window. The signing step in the build pipeline should be unconditional - every build that could end up on a device gets signed.

What happens to devices in the field if our signing key is compromised? This is the hardest case in OTA key management. If your private signing key is compromised, an attacker can sign malicious firmware that devices will accept. Your options are: rotate to a new key (which requires deploying an update that installs the new public key - signed with the old compromised key, which is a problem), or accept that already-deployed devices are at risk until you can remediate. This is why private key security is not optional - hardware security modules for key storage, strict access controls, key rotation procedures. The key is the root of your entire update security model.

Sources: CRA Regulation (EU) 2024/2847 - Annex I; MCUboot documentation; Nordic Semiconductor - MCUboot in nRF Connect SDK; STMicroelectronics SBSFU AN5056

Denys Zaliznyak is the CTO of Platanor Technologies. Secure OTA architecture - including image signing, key provisioning, and anti-rollback - is part of the security subsystem we implement for IoT and hardware manufacturers. platanor.com/contact