Secure OTA Updates for IoT Devices: What Can Go Wrong and How to Build It Right

Here's a scenario we've 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, and 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 among the most common security failures in IoT devices, and CRA directly addresses them. 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 you wrote, that hasn't 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 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 the modification.

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 theoretical. And each is preventable with a correctly designed OTA architecture.

What a Secure OTA Architecture Looks Like

A secure firmware update process comes down to one piece of security architecture: 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, you sign the final binary with 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 an attacker can replace 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 used 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 MCUboot build compiles the public key into the MCUboot binary, which is then 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 include STiROT (ST immutable RoT) in 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, and 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 - wiring imgtool and key provisioning into CI from the first commit, not treating it as a manual pre-release checklist item.

What CRA Requires Specifically

OTA update security is a direct CRA requirement, not just good practice. Annex I of the CRA requires manufacturers to "provide for mechanisms to securely distribute updates for products with digital elements to ensure that vulnerabilities are fixed or mitigated in a timely manner" (Part II, point (7)). In practice, updates must be distributed in a way that preserves the software's integrity and authenticity.

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 compromises your incident response: 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 runs only 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 firmware for secure boot verification is what signs OTA packages. Keeping these aligned avoids managing two separate key hierarchies.

The Provisioning Side

One thing that doesn't get discussed enough in OTA security articles: the public key devices use to verify firmware must be provisioned correctly at the manufacturing stage, and it must 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 depends on the key being trustworthy, which means the factory provisioning process must be secure.

This is where OTA security and secure provisioning intersect. The security of your update mechanism depends partly on 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 mostly a build-pipeline change—configure imgtool in your build system, generate keys, and 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 an attacker compromises your private signing key, they 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, and key rotation procedures. The key is the root of your entire update security model.