EU Cyber Resilience Act — Guide for Firmware & Embedded Software Developer

Firmware in connected products — routers, IoT sensors, industrial controllers, medical devices — falls squarely within the CRA's scope as software that enables a product's primary function. Article 13 requires manufacturers to ensure products conform to Annex I across their entire lifecycle, which includes the firmware layer. Developers must treat security as a first-class design requirement rather than a post-shipping concern. Specific obligations relevant to firmware include: shipping without known exploitable vulnerabilities, enabling secure configuration by default, limiting attack surface to what is required for declared functionality, and ensuring the product can be updated securely after deployment. Firmware that ships with default credentials, open debug interfaces, or unpatched library code will constitute non-conformity.

Annex I Part I requires that products be designed to minimise the number of exploitable vulnerabilities. For firmware written in C or C++, this means applying rigorous coding standards — MISRA C, CERT C, or equivalent — that eliminate classes of memory safety bugs including buffer overflows, use-after-free, and format string vulnerabilities. Where the codebase cannot be migrated to memory-safe languages such as Rust, compensating controls must be documented: stack canaries, address space layout randomisation, read-only memory sections, and static analysis integrated into the build pipeline. The technical file must record which standards were applied and include evidence of static analysis runs. Regulators will scrutinise firmware products closely because memory corruption vulnerabilities in embedded code commonly result in full device compromise.

Annex I Part I requires that security updates be delivered with integrity and authenticity protections. For firmware, this means every release build must be cryptographically signed using a key held in a hardware security module or equivalent protected storage, and devices must verify that signature before applying any update. Secure boot — where each stage of the boot sequence verifies the next using a root of trust anchored in hardware — provides the complementary assurance that only authorised firmware runs on the device. Developers must document the key management lifecycle: key generation, storage, rotation, and revocation procedures. If a signing key is compromised, the manufacturer must be capable of re-keying the device population, which requires planning during the hardware design phase.

Firmware frequently incorporates dozens of open-source libraries — FreeRTOS, lwIP, mbed TLS, BusyBox — plus vendor-supplied SDKs and silicon manufacturer libraries. Annex I Part II requires manufacturers to identify and document all components in a machine-readable SBOM. For firmware, generating this SBOM automatically is challenging because embedded build systems vary widely. Developers should integrate SBOM generation into the Yocto, BuildRoot, or CMake build pipeline using tooling that can extract component names, versions, and licence information from the dependency tree. The SBOM must be updated with every firmware release. When CVEs are published against listed components, developers must assess whether the vulnerable feature is compiled in and whether the call path is reachable in the product's configuration.

Start by inventorying all third-party and open-source components in the firmware build and generating an initial SBOM in CycloneDX or SPDX format. Run the SBOM against NVD to identify any known vulnerabilities in current components and triage each finding. Enable compiler security flags — stack protectors, FORTIFY_SOURCE, PIE — if not already active, and integrate a static analyser such as Clang Static Analyzer or Coverity into the CI pipeline. Verify that the firmware update mechanism validates signatures before applying any image. If secure boot is not yet implemented, raise it as an architecture task with a defined completion milestone. Record all of these measures in the product's technical file and set a recurring review cadence tied to each firmware release.