Embedded Device Security Guide: EMB3D and Secure Firmware Updates

An embedded device ships once and then runs unattended for years, so a missing signature check, an open debug port or a shared default password in the factory image becomes a permanent, fleet-wide weakness. Embedded systems security is decided at design time: the root of trust, boot chain, update mechanism and debug lockdown have to be chosen before the board is built, because few can be added later. This guide goes deeper than the Firmware and Boot Security Guide, which covers PC and server firmware, and focuses on microcontrollers, embedded Linux and RTOS devices. It covers embedded device security end to end: the MITRE EMB3D threat model, hardware roots of trust and Arm TrustZone for microcontroller security, embedded firmware security through secure OTA updates and anti-rollback protection, JTAG and UART lockdown, embedded device hardening for Linux and RTOS builds, device credentials and firmware SBOMs. It is written for embedded security and product security engineers, firmware developers and the security teams that buy and operate connected devices.

Key takeaways

• Use EMB3D as the shared threat model. MITRE EMB3D lists threats (TIDs) and mitigations (MIDs) across hardware, system software, application software and networking, so engineering and buyers can discuss the same risks by ID.
• Trust starts in silicon. A boot ROM that verifies the first stage against a key hash fused into the chip is the only foundation that software cannot undo; everything later inherits its strength.
• A signed update without rollback protection is not secure. If an attacker can install an older, validly signed image, every vulnerability you fixed returns. Pair signatures with a security version counter in trusted storage.
• Debug ports must be locked, not just unpopulated. Removing a header does not disable JTAG, SWD or a UART console; fuses, readout protection or authenticated debug do.
• Every device needs its own credentials and a published support period. ETSI EN 303 645 forbids universal default passwords and hard-coded critical security parameters, and requires a published support period.

The MITRE EMB3D threat model

MITRE describes EMB3D as "a cultivated knowledge base of cyber threats to embedded devices", aimed at sectors such as critical infrastructure, IoT, automotive and healthcare. Version 2.0 was released in April 2025 and the current release is 2.0.2 (June 2026). It has three linked parts: device properties (PIDs) describe what a device contains, threats (TIDs) describe how an attacker achieves an effect, and mitigations (MIDs) describe what a vendor can build in, graded in three tiers: Foundational, Intermediate and Leading.

To use it, record the device's properties, take the threats EMB3D associates with them and decide per threat which mitigation tier the product meets. Mitigation pages also map to IEC 62443-4-2 component requirements. See the IEC 62443 Guide and, for modelling method, the Threat Modelling Guide.

Hardware root of trust, secure boot and Arm TrustZone

EMB3D separates software-only bootloader authentication (MID-001) from hardware-backed authentication (MID-002), and lists TID-214 Secrets Extracted from Device Root of Trust and TID-220 Unpatchable Hardware Root of Trust as threats in their own right. A typical embedded chain of trust:

• U-Boot verified boot: U-Boot defines verified boot as "the verification of all software loaded into a machine during the boot process" and warns "It is critical that the public key be secure and cannot be tampered with." It also recommends "a different key at each stage", so one leaked key does not open the whole chain.
• Arm TrustZone on Cortex-A: Secure and Non-secure states, with monitor firmware at EL3 switching between them. Arm Trusted Firmware (TF-A) is the reference secure-world firmware; a trusted OS there can hold keys out of reach of a compromised Linux.
• TrustZone for Cortex-M (Armv8-M): Arm says "Any part of the system can be designed as part of the secure world, including debug, peripherals, interrupts and memory." Trusted Firmware-M provides the secure-side services and, in Arm's words, "forms the foundations of a Trusted Execution Environment".
• Hardware-backed keys: keep device private keys in a secure element, TrustZone secure storage or a key store with readout protection (MID-028), never in plain flash beside the application.

Secure firmware updates and OTA

EMB3D lists the ways updates fail: TID-211 unauthenticated firmware installation, TID-212 shared secrets extracted from the update integrity mechanism, TID-213 faulty integrity verification, TID-215 unencrypted updates and TID-217 remotely initiated updates that cause denial of service. ETSI EN 303 645 provision 5.3-10 requires the device to "verify the authenticity and integrity of each update via a trust relationship", and 5.3-2 requires a secure update mechanism.

• Signed firmware update: sign with an asymmetric key held in an HSM or managed signing service; never use a symmetric key shared across the fleet, which is exactly what TID-212 extracts. See the Code Signing Security Guide.
• Verify before you commit: MCUboot checks an image's integrity "immediately before it gets copied into the primary slot". Its option to validate the primary slot only once is, in MCUboot's own words, "reducing the security level".
• Test, then confirm: in MCUboot's swap modes a new image boots in test mode and, unless the application confirms it, the bootloader will "revert back on the next boot". That protects against bricking, which matters as much as security on remote devices.
• Encrypt where confidentiality matters: encrypted images (AES-128 or AES-256 in MCUboot) protect intellectual property and slow patch diffing, but do not replace signatures.
• Over-the-air update security: mutually authenticate server and device over TLS, schedule campaigns in waves and check power before flashing, so a remotely triggered update cannot take a fleet offline (TID-217).

Anti-rollback protection

EMB3D's TID-216 Firmware Update Rollbacks Allowed starts from a simple observation: "Firmware updates will oftentimes include fixes to security vulnerabilities." An attacker who can start an update installs an older, validly signed image and exploits what it still contains. The related weakness is CWE-1328, a security version number mutable to older versions. Firmware rollback protection needs two things: a security version in the signed image and a reference value stored where software cannot lower it.

• Where the reference lives: MCUboot's hardware rollback protection compares an image's security counter against "the currently active security counter value which must be stored in a non-volatile and trusted component of the device", typically OTP fuses or a secure element. The security counter is separate from the marketing version and only rises when you deliberately cut off older releases.
• When to advance it: EMB3D MID-030 describes two approaches. Advancing automatically when a newer image passes secure boot leaves no rollback window but stops users reverting to a last-known-good image. Advancing on an authenticated command from the management service allows testing but leaves devices exposed until the command arrives, and a blocked command means the device never accepts the firmware.
• Protect the counter itself: MID-030 warns that if attackers can spoof the anti-rollback references the device can be made inoperable, so only authorised, verified code may change them.
• Budget the fuses: OTP counters have finite increments; raise the counter only for releases fixing exploitable flaws.

Debug interface lockdown: JTAG, SWD and UART

EMB3D notes that "hardware debugging ports (e.g., JTAG, SWD, etc.) oftentimes have high privileges" and can be used to read memory (TID-119), alongside TID-115 firmware extraction through hardware interfaces and TID-116 latent privileged access ports. MID-057 states: "Physical ports used during the device development and debugging process should be disabled or removed in devices meant for production use." It prefers disabling in hardware, ideally with security fuses, says disabling in software is acceptable, and that removing the physical header is not enough. ETSI EN 303 645 provision 5.6-4A requires that "Debug interfaces shall be disabled or protected via a best practice authentication or access control mechanism."

Verify lockdown on production units pulled from the line, not engineering samples, and record fuse and lifecycle state per serial number. For detection, use tamper-evident enclosures, log debug-enable events where the chip exposes them, and alert when a device reports an unexpected lifecycle state or fails attestation.

Embedded Linux security: Yocto and Buildroot

Most embedded Linux products are built with Yocto or Buildroot, and the dangerous defaults are development conveniences. Yocto's guidance:

• Remove debug-tweaks: new Yocto builds often set EXTRA_IMAGE_FEATURES = "debug-tweaks", which "sets the root password as blank". Make sure neither EXTRA_IMAGE_FEATURES nor IMAGE_FEATURES contains it in release builds. Buildroot configurations need the same review of root password and login settings.
• Compiler hardening: add require conf/distro/include/security_flags.inc to the distro configuration to enable security compiler and linker flags.
• Accounts: set passwords with the extrausers class and do not reuse a password across devices; Yocto suggests a different random password per device set after deployment.
• Least functionality: remove debugging tools and unneeded services; consider SELinux or SMACK and the meta-security layer.
• Integrity: enable hardware secure boot where supported, sign the kernel in a FIT image, and keep the root filesystem read-only with block-level integrity verification such as dm-verity, writing state to a separate partition.

RTOS security: Zephyr and FreeRTOS

On microcontrollers the RTOS and application usually form one image, so isolation comes from the memory protection unit and TrustZone rather than processes.

• Zephyr RTOS: builds kernel and application into one static binary; the project says "Static linking eliminates the potential for dynamically loading malicious code." Memory protection and thread separation arrived in 1.10.0 (x86) and 1.11.0 (Arm and ARC), with the goal that "Individual threads should only have access to their own memory resources." Vulnerabilities are tracked in GitHub security advisories, and MCUboot is the usual secure bootloader.
• FreeRTOS: FreeRTOS-MPU separates privileged and user mode tasks. User mode tasks "can only access their own stack and up to three user definable memory regions", cannot return to privileged mode, and kernel data and system peripherals are reachable only in privileged mode. Create untrusted tasks restricted and avoid shared regions, which FreeRTOS calls "discouraged".
• Both: enable stack guards, run network parsers unprivileged and, on Armv8-M, keep keys in the secure side via Trusted Firmware-M.

Where identity fits: embedded device credentials

Each device is a non-human identity, and its credentials are often the weakest part of the design. ETSI EN 303 645 provision 5.1-1 requires passwords to be "unique per device or defined by the user", and 5.4-3 states "Hard-coded critical security parameters in consumer IoT device software source code shall not be used." EMB3D covers the same ground with TID-311 Default Credentials, TID-328 Hardcoded Credentials and MID-033 Unique and Unpredictable Factory Preinstalled Secret Keys.

• Per-device keys at manufacture: generate the device key inside the secure element or TrustZone and have a manufacturing CA issue a certificate, so no factory system holds private keys.
• No cloud keys in firmware: service API keys compiled into firmware leak whenever an image or source leaks, as the Rabbit R1 hard-coded API keys case showed. Devices should obtain short-lived tokens with their own certificate.
• Fleet administration: the platform that manages devices is a high-value target; the Verkada camera breach began with exposed administrative credentials, not a device flaw.

Identity lifecycle for devices is covered in the Device and IoT Identity Guide.

Firmware SBOM, vulnerability handling and support periods

TID-210 Device Vulnerabilities Unpatchable is partly a process problem. Yocto generates an SPDX SBOM by default through the create-spdx class, written as IMAGE-MACHINE.spdx.json in the image deploy directory, with options such as SPDX_INCLUDE_SOURCES and SPDX_INCLUDE_KERNEL_CONFIG. For RTOS images, build the firmware SBOM from the build's component list, including vendor SDKs and binary blobs. Under ETSI EN 303 645 manufacturers publish a vulnerability disclosure policy (5.2-1) and a defined support period (5.3-13). The EU Cyber Resilience Act, Regulation (EU) 2024/2847, adopted on 23 October 2024 and in force since 10 December 2024, expects manufacturers to draw up an SBOM, and its recitals say support periods should be no less than five years unless the product is expected to be used for less time. See the EU Cyber Resilience Act Guide and the SBOM Guide.

Implementation roadmap

1. Model the device: record EMB3D properties, list the applicable threats and choose a target tier per mitigation. Do this before silicon selection.
2. Choose silicon with a root of trust: fused key hash, secure boot enforcement, readout protection, monotonic counters and, where needed, TrustZone or a secure element.
3. Build the signing pipeline: offline or HSM-held root key, separate keys per boot stage, signed release builds only from CI, and a documented key rotation and revocation plan.
4. Test on engineering samples without blowing fuses: run signature failure, corrupted image, power loss mid-update and downgrade tests. Fusing is irreversible, so validate the full chain first and fuse a pilot batch.
5. Lock production: secure boot fuse, debug disable or authenticated debug, readout protection, release images without debug features, verified on line samples.
6. Roll out updates in waves: canary devices, then percentages of the fleet, watching boot success and reverts; halt the campaign automatically on elevated failure.
7. Operate: SBOM-driven vulnerability monitoring, published support period, and end-of-life features (MID-025) for decommissioning.

Decision guidance

• Microcontroller or embedded Linux: MCUs with TrustZone-M and MCUboot give a small, auditable chain; Linux SoCs bring features and a much larger patching burden.
• Software-only or hardware-backed boot authentication: MID-001 is acceptable only where the bootloader itself sits in immutable memory; otherwise choose MID-002.
• Automatic or commanded rollback counters: automatic for unattended consumer devices; commanded where operators must validate firmware, as in industrial settings.
• Small or large manufacturers: small teams should use reference secure boot, MCUboot or U-Boot verified boot unmodified, and a managed signing service; large ones add authenticated debug, attestation (MID-003) and per-product EMB3D assessments.
• Buyers: ask suppliers for EMB3D or IEC 62443-4-2 mapping, SBOM, support period and debug lockdown evidence. See the IoT Security Guide.

Measurement

• Secure boot enforcement: percentage of shipped units with secure boot fused and debug locked, from manufacturing records.
• Update reach: share of the fleet on a supported firmware version 30 days after release.
• Update reliability: revert and failed-boot rate per campaign.
• Rollback floor: share of devices whose security counter blocks all releases with known exploitable flaws.
• Credential hygiene: products with zero shared or hard-coded credentials in the latest release scan.

Common failure patterns

• Secure boot enabled but not enforced: verification runs but a failure only logs, or the fuse that makes it mandatory was never blown.
• Signing keys without protection: keys on build servers or developer laptops. The MSI signing keys leak exposed firmware and Boot Guard private keys that customers cannot revoke.
• Signatures without anti-rollback: old, validly signed images with known flaws still install.
• Debug left open: header removed but JTAG or a UART root shell still active on production units.
• Development defaults shipped: blank root passwords, debug features and shared passwords in release images.
• No support period: devices still in service years after the last update, with nobody tracking their components.

Framework mapping

Practitioner checklist

• Produce an EMB3D assessment for each product with a target tier per relevant mitigation.
• Enforce hardware-backed secure boot from a fused key hash through every stage, with a separate key per stage.
• Hold firmware signing keys in an HSM or managed signing service and sign only from CI.
• Verify every update for authenticity and integrity before installation, with test-and-confirm or A/B recovery.
• Implement a security version counter in trusted non-volatile storage and decide whether it advances automatically or on command.
• Disable or authenticate JTAG, SWD and UART consoles on production units and verify on line samples.
• Remove debug-tweaks, shared passwords and diagnostic commands from release images; provision unique per-device credentials.
• Generate a firmware SBOM per release, publish a vulnerability disclosure policy and a support period.

Standards and references

• MITRE: EMB3D Threat Model
• ETSI: EN 303 645 V3.1.3, Cyber Security for Consumer Internet of Things: Baseline Requirements
• NIST: IR 8259A, IoT Device Cybersecurity Capability Core Baseline
• EUR-Lex: Regulation (EU) 2024/2847, Cyber Resilience Act
• MCUboot: Bootloader design
• U-Boot: Verified Boot
• Yocto Project: Making Images More Secure
• Zephyr Project: Zephyr Security Overview

Related NHI Mgmt Group resources: Firmware and Boot Security Guide · IoT Security Guide · Device and IoT Identity Guide · SBOM Guide · EU Cyber Resilience Act Guide. This guide summarises the Cyber Resilience Act's SBOM and support period expectations and is not legal advice.