DEV Community: Artem Sulyma

What is Secure Boot - and Why Every IoT Device Needs It

Artem Sulyma — Mon, 03 Aug 2026 07:44:25 +0000

One of the questions that came up in a recent discussion about CRA compliance was whether secure boot is actually required or just recommended. The short answer is: it is required, and it is required because without it, none of your other security measures work reliably.

A device that boots unverified firmware is a device an attacker can fully own - regardless of how good the rest of your security architecture is.

If you are still assessing where your product stands on CRA requirements overall, our [complete guide to the EU Cyber Resilience Act] covers the full compliance picture including deadlines and product categories.

What happens when a device boots without secure boot

When your microcontroller powers on, it starts executing code from a defined memory location. On most embedded platforms, this is the bootloader - a small piece of code that initializes hardware and loads the main application firmware.

Without secure boot, the bootloader loads whatever firmware it finds at the expected address. It does not check whether that firmware was written by you, whether it has been modified since you shipped it, or whether it is legitimate in any way. It just runs it.

This means an attacker who can write to your device's flash memory - through a firmware update channel, a debug interface, physical access, or a vulnerability in your update mechanism - can replace your firmware with their own. The device will boot it without complaint. It will appear to function normally. It is now running attacker code.

The attacker does not need to break your encryption. They do not need your private keys. They just need to get their firmware onto the device, and the device will run it.

This is not a theoretical scenario. It is the standard attack against IoT devices that lack firmware integrity verification. The Mirai botnet, which took down significant internet infrastructure in 2016, was built largely on devices where firmware modification was trivial.

How secure boot works - the chain of trust

Secure boot solves this by making the device verify firmware authenticity before executing it. The mechanism is a cryptographic chain of trust that starts at the hardware level.

Here is how the chain works, step by step:

Step 1 - Root of trust in hardware. The process starts with something that cannot be modified after manufacturing: a public key hash burned into One-Time Programmable (OTP) memory, or a key stored in hardware security elements on the chip. This is the hardware root of trust. It is the anchor of the entire chain - the one thing the attacker cannot replace.

Step 2 - Bootloader verification. When the device powers on, the first-stage boot code (which lives in ROM and cannot be modified) reads the bootloader from flash and checks its cryptographic signature against the public key in OTP memory. If the signature is valid, the bootloader is authentic and execution continues. If the signature does not match, boot halts.

Step 3 - Application firmware verification. The bootloader, now verified, performs the same check on the main application firmware. It reads the firmware image, verifies its signature against a trusted public key, and only passes execution to the application if the signature is valid.

Step 4 - Chain continues. Each verified component can extend the chain further - verifying configuration data, checking software versions, validating update packages before applying them.

The result: the device only runs code that was signed with your private key. An attacker who replaces your firmware with their own cannot sign it with your key. The device will reject it and refuse to boot.

Why CRA treats secure boot as a baseline

Annex I of the CRA requires manufacturers to ensure the integrity of software running on connected products. The specific requirement is that products must include mechanisms to verify the authenticity and integrity of software - both at boot time and during updates.

Secure boot satisfies the boot-time requirement. Without it, there is no basis for claiming that the software running on a shipped device is the software you intended to ship.

This is why CRA treats secure boot not as an advanced security feature but as a baseline - the minimum foundation without which everything else is unreliable. Encrypted communications are only meaningful if you can trust that the device establishing the connection is running legitimate firmware. Unique device identity is only meaningful if the identity cannot be replaced along with a firmware swap. That control is covered in detail in our article on device identity in IoT and what CRA requires.

Secure boot is the prerequisite that makes the rest of the security architecture trustworthy.

To understand the full set of December 2027 product requirements, see our guide on CRA product classification: Default, Important Class I, and Class II.

What this looks like on Nordic nRF and STM32

Nordic nRF (nRF5340, nRF9160, nRF52 series)

Nordic's security architecture centers on the Trusted Execution Environment (TrustZone-M on Cortex-M33 cores) and the NSIB - Nordic Secure Immutable Bootloader. The NSIB lives in the device's ROM-equivalent region and is the hardware root of trust on these platforms.

The typical secure boot chain on nRF:

NSIB verifies the first-stage bootloader (MCUboot) using a public key provisioned in the device's Key Management Unit (KMU) or UICR registers
MCUboot verifies the application image signature before loading it
Firmware images are signed with ECDSA (typically using a P-256 key pair) as part of the build process

Nordic's nRF Connect SDK includes MCUboot integration. The key management - generating signing keys, provisioning public keys into the device, signing images at build time - is where most teams need to put deliberate effort. The tooling exists; it requires intentional setup.

STM32 (STM32L5, STM32U5, STM32H5 series - TrustZone-capable)

ST implements secure boot through the STM32 Secure Boot and Secure Firmware Update (SBSFU) library, and more recently through the built-in Secure Boot (STiROT and OBKey) mechanisms on newer series.

The chain on STM32:

The immutable ROM bootloader reads the secure boot configuration and public key hash from Option Bytes (OTP-equivalent)
It verifies the application image before passing execution
Anti-rollback protection is enforced through a monotonic counter in Option Bytes - the device will reject firmware older than the current installed version

One important detail on STM32: Option Bytes must be locked before shipping. Development boards ship with Option Bytes in an unlocked state, which allows debug access and key replacement. Shipping a device with unlocked Option Bytes means an attacker with physical access can re-provision the root of trust key. This is a configuration step that has to be part of your manufacturing process.

The mistake that ships with more products than it should

Secure boot is disabled in the production build.

This happens more often than it should, and it happens for an understandable reason: secure boot complicates the development and testing workflow. Signing every firmware image, managing keys, dealing with devices that refuse to boot unsigned debug builds - it adds friction. So teams enable it in the security architecture, implement the mechanism correctly, and then leave a flag or build configuration that bypasses signature verification in production.

The device ships. It passes internal testing. The secure boot feature exists in the codebase. And it does nothing, because the production build has verification disabled or the signing key is a placeholder that was never properly provisioned.

The correct approach is to treat production configuration - Option Bytes locked, debug interfaces disabled, signing key provisioned, verification enforced - as a formal step in the manufacturing process with its own validation check. Not a development task that someone will get to.

FAQ

Does CRA specifically mention secure boot by name?
The regulation does not use the term "secure boot"; it requires manufacturers to "protect the integrity of stored, transmitted or otherwise processed data, personal or other, commands, programs and configuration against any manipulation or modification not authorised by the user" (Annex I, Part I, point (2)(f)). Secure boot is the standard implementation of this requirement for embedded devices. A device that cannot verify firmware integrity at boot time does not meet the Annex I requirement.

Can I implement secure boot on hardware that does not have a hardware root of trust?
Partially. Some lower-end microcontrollers lack OTP memory or hardware key storage. In those cases, software-only implementations provide weaker guarantees - an attacker with flash access can potentially replace both the verification code and the key. For CRA compliance, hardware-backed root of trust is the correct approach. It is a hardware selection decision that should be made at the architecture stage, not after the board is designed.

Does secure boot prevent all firmware attacks?
No. Secure boot verifies that firmware is authentic at load time. It does not protect against vulnerabilities within the legitimate firmware itself - a properly signed firmware image can still contain bugs that attackers exploit at runtime. Secure boot is one layer of a defense-in-depth architecture, not a complete solution on its own.

What happens if my signing key is compromised?
If your private signing key is compromised, an attacker can sign malicious firmware that passes verification. Key management - generating keys securely, storing private keys in hardware security modules, rotating keys if compromise is suspected - is as important as the implementation itself. A secure boot implementation is only as strong as the key management around it.

We have secure boot implemented. Does that mean we are CRA-compliant on firmware integrity?
Secure boot covers boot-time integrity. CRA also requires integrity verification for firmware updates - the OTA update mechanism must verify the authenticity and integrity of update packages before applying them. These are related but separate requirements. Both need to be in place.

Sources: CRA Regulation (EU) 2024/2847 - Annex I; Nordic Semiconductor - Security documentation; STMicroelectronics - SBSFU application note AN5056

Secure OTA Updates for IoT Devices: What Can Go Wrong

Artem Sulyma — Thu, 16 Jul 2026 11:46:32 +0000

Let me describe something I've seen more than once.
A manufacturer ships a connected device. The OTA update mechanism works - firmware gets delivered, 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 "working OTA update" is actually an attack vector.
Unsigned firmware updates are one of the most common IoT security failures. Here's what a correct architecture looks like.

What goes wrong without image signing
Firmware replacement. An attacker who compromises your update server or intercepts the delivery can substitute their own image. The device has no way to tell the difference. It flashes whatever arrives.
Image tampering. Even without replacing the image entirely, an attacker can modify it in transit - insert a backdoor, change config values, patch out a security check. Without a cryptographic signature, the device can't detect it.
Rollback attacks. Without anti-rollback protection, an attacker can push an old firmware version with known vulnerabilities back onto devices you've already patched.
Fake update server. A device that doesn't verify server identity can be redirected to an attacker-controlled endpoint. It thinks it's updating from your infrastructure. It's not.

What a secure OTA architecture looks like

Sign the image at build time. As part of your build pipeline, the final binary gets signed with your private key. The signature is embedded in the firmware package along with a version number for anti-rollback. The private key never leaves your build infrastructure.
Store the public key securely on-device. The device holds the public key used to verify signatures. Where it lives matters - OTP memory, a secure element, or a hardware key management unit. A public key that can be overwritten by an attacker undermines everything. On STM32, the public key hash goes into Option Bytes (which must be locked in production). On nRF, it goes into UICR or the KMU depending on the series.
Verify before you flash. The bootloader verifies the signature before writing anything to flash. This is not optional and not "add it later" - it's in the critical path. Verification fails → update rejected → existing firmware stays → event logged.
Enforce anti-rollback. A monotonic counter in non-volatile memory tracks the minimum acceptable firmware version. The device rejects any update with a lower version number. Once you patch a vulnerability, it stays patched.
Use TLS for delivery too. TLS doesn't replace image signing - if your update server is compromised, TLS doesn't help. But defense in depth means you don't rely on a single control. Use both.

MCUboot in practice
MCUboot is the go-to open source bootloader for secure OTA on Cortex-M targets (nRF Connect SDK, STM32, Zephyr).
On Nordic nRF: MCUboot is integrated as the default secure bootloader. Images are signed with imgtool using ECDSA-P256 keys. The public key is compiled into the MCUboot binary during its own build. Anti-rollback uses the security counter in the image header.
For a stronger trust chain, nRF also supports NSIB (nRF Secure Immutable Bootloader) as a first-stage bootloader: hardware root → NSIB → MCUboot → application.
On STM32 (L5, U5, H5): ST provides SBSFU and newer series have STiROT in ROM. For direct MCUboot use, the signing flow is identical - imgtool signs the image, the public key is embedded in MCUboot, verification happens before the application runs. Critical step: lock Option Bytes in production.
In both environments, the build pipeline is where teams have the most gaps. Signing needs to be automatic, not a manual step someone might forget.

OTA signing ≠ secure boot (you need both)
These are separate controls that work together.
Secure boot verifies firmware at every power-on - ensures the device only runs signed firmware from flash.
OTA signing verifies firmware before it's written to flash - ensures only authorized updates get applied.
A device with secure boot but without OTA signing will reject a modified image at boot, but it might still write the malicious image to flash - bricking the device or causing a boot loop. Denial of service achieved.
A device with OTA signing but without secure boot verifies updates correctly, but an attacker with flash access bypasses the OTA mechanism entirely and writes directly to the firmware partition.
The correct architecture has both, sharing the same root of trust and the same key infrastructure.

IoT Threat Modeling: A Step-by-Step Guide for Hardware Manufacturers

Artem Sulyma — Wed, 15 Jul 2026 12:08:15 +0000

Written by CTO at Platanor Technologies.

Threat modeling is the process of identifying what can go wrong with your device before an attacker does it for you. For IoT and embedded hardware manufacturers, it is the single most cost-effective security activity you can run — because catching a design flaw at the blueprint stage costs a fraction of what it costs to patch devices already shipped to 50,000 customers.

According to SonicWall's 2025 Annual Cyber Threat Report, attacks on IoT devices rose 124% year-over-year in 2024. The IBM Cost of a Data Breach Report 2024 puts the average cost of a breach in the industrial sector at $5.56 million, 13% above the global average and an 18% jump from 2023.

These numbers describe companies that did not do threat modeling early enough. This guide explains how to do it right.

What Is a Threat Model and Why It Matters for Device Manufacturers
A threat model is a structured document that answers four questions: What are you building? What can go wrong? What are you going to do about it? Did you do a good enough job?
The concept comes from software security, but it applies directly to hardware and firmware. Your device has a microcontroller, a communication interface, a firmware update mechanism, and probably a cloud backend. Each of those components has attack surfaces. Threat modeling forces your engineering team to think like an attacker before the product ships.
For manufacturers, the practical outcome of a threat model is a prioritized list of security requirements. Instead of asking "what security features should we add," you start from "what can break and what does it cost if it does."

The CRA Factor: Threat Modeling Is Now a Legal Requirement

If you manufacture connected devices and sell them in the European Union, the EU Cyber Resilience Act makes threat modeling a compliance obligation, not a best practice. CRA Annex I requires manufacturers to conduct and document a cybersecurity risk assessment covering the full product lifecycle. Annex VII specifies that this documentation must be available for market surveillance authorities.
The deadline for full CRA compliance is December 11, 2027. The vulnerability reporting obligation kicks in earlier, on September 11, 2026.
Threat modeling is the foundation of that documentation. Without it, you cannot produce a credible SBOM, you cannot define your vulnerability management process, and you cannot demonstrate that your design decisions were intentional rather than accidental.

Step 1: Define the Scope and Identify Your Assets

Start by drawing a boundary around what you are modeling. The scope of your threat model should match the scope of your CRA risk assessment — the product itself, including its firmware, interfaces, cloud connectivity, and mobile companion app if there is one.
Within that boundary, list your assets. An asset is anything worth protecting. For a connected industrial sensor, the assets typically include:

Device firmware and its integrity. If an attacker can replace your firmware with their own, they own the device.
Cryptographic keys stored on the device. If they are extracted, the entire device fleet is compromised.
Telemetry data the device collects and transmits.
The firmware update channel. A compromised update mechanism can push malicious firmware to every device in your fleet simultaneously.
Provisioning credentials used during manufacturing. If reused across devices, one compromised unit exposes all units.

Step 2: Map Data Flows and Attack Surfaces

Draw a data flow diagram showing how data moves through your system. What matters is that the diagram shows every interface where external input enters the system.
For most IoT devices, the critical attack surfaces are:
Physical interfaces. UART, JTAG, and USB ports left enabled in production firmware are a known and frequently exploited attack path.
Wireless interfaces. Bluetooth, Wi-Fi, Zigbee, and cellular all present network-facing attack surfaces.
Firmware update mechanism. If your OTA update process does not verify the cryptographic signature of incoming firmware, an attacker on the same network can push arbitrary code to your device.
Cloud API. If device authentication relies on a shared secret embedded in firmware, extracting that secret from one device gives access to your entire backend.
Supply chain. A growing share of IoT incidents trace back to third-party suppliers. The manufacturing step — when cryptographic keys are generated and injected into devices — is a significant risk point.

Step 3: Apply STRIDE to Identify Threats

STRIDE maps six threat types to your system components: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege.
Spoofing — Can an attacker impersonate your device to your backend, or vice versa?
Tampering — Can an attacker modify firmware, configuration, or data in transit?
Repudiation — Can an attacker perform an action and deny it happened?
Information Disclosure — Can an attacker read sensitive data? Hardcoded credentials in firmware, unencrypted telemetry, or private keys in plaintext flash all appear in real device audits regularly.
Denial of Service — Can an attacker make the device unavailable? This is a safety issue in industrial and medical applications.
Elevation of Privilege — Can an attacker gain capabilities beyond what they should have?
For each threat, write one specific sentence describing the scenario. Vague threats are not actionable.

Step 4: Rate Each Threat by Risk Level

A useful scoring approach is DREAD (Damage, Reproducibility, Exploitability, Affected users, Discoverability). The point is to end up with a ranked list.
High-priority threats are easy to exploit, affect many devices, and cause significant damage. Low-priority threats require significant attacker resources and have low real-world impact.

Step 5: Define Mitigations for Each High-Priority Threat

Firmware tampering: implement cryptographic signature verification in the bootloader before any application code executes.
Device identity spoofing: provision each device with a unique certificate or key at manufacture time, stored in a hardware security element if possible.
Exposed physical debug interfaces: disable UART and JTAG in production firmware builds.
Insecure OTA updates: enforce signature verification, use TLS, implement rollback protection.

Document the mitigation decision alongside the threat. If you accept a risk rather than mitigate it, document that reasoning — this is what regulators expect to see.

Step 6: Document and Keep It Updated

A threat model is not a one-time document. Update it when your product design changes, when a new CVE affects a component you use, and at least once per year.
This document becomes part of your CRA technical documentation under Annex VII and is the starting point for penetration testing.
Common Mistakes Manufacturers Make

Doing it after the design is finalized. The point is to influence design decisions, not document them after the fact.
Modeling the happy path only. Threat modeling requires thinking about malformed inputs and active attackers.
Treating it as a security team responsibility. It works best when firmware engineers and security professionals work through it together.
Using generic threat lists without adapting to your product.

Frequently Asked Questions

When should we start threat modeling?
At the architecture design phase, before firmware development begins.
Does STRIDE work for hardware as well as software?
Yes. Physical tampering is a STRIDE Tampering threat. Side-channel attacks fall under Information Disclosure.
How long does a threat model take to produce?
For a mid-complexity connected device, an initial workshop takes two to three days. Documentation and review adds another day or two.
Is threat modeling required by the EU Cyber Resilience Act?
CRA Annex I requires a documented cybersecurity risk assessment covering threat scenarios. A formal threat model is the most defensible way to satisfy this requirement.
What tools can we use?
Microsoft Threat Modeling Tool (free, STRIDE-based), OWASP Threat Dragon (open-source), IriusRisk (IoT-specific). A structured spreadsheet works fine at early stages.