Embedded and Firmware Secure Coding: MISRA, CERT C and Memory Safety for Devices

Firmware runs without most of the safety nets that protect desktop and server code, so a single out-of-bounds write in a radio parser or USB handler can give an attacker the whole device, often permanently. Many microcontrollers have no memory management unit, no address space layout randomisation and no separate kernel, and the same binary may ship to millions of units that are rarely updated. This guide covers how to write safer C and C++ for embedded targets: choosing and applying MISRA C and the SEI CERT C Coding Standard, the embedded-specific bug classes, the hardware and compiler protections worth turning on, where Rust fits, and how to prove it all in a pipeline. It is for firmware engineers, embedded team leads and product security teams. General C and C++ patterns, hardening flags and sanitizers are covered in the C and C++ Secure Coding Guide; device-level architecture is in the Embedded Device Security Guide.

Key takeaways

• Pick a coding standard and enforce it in CI. MISRA C (current edition MISRA C:2025) is the established safety-and-security subset; the SEI CERT C Coding Standard is security-focused; MISRA publishes addenda mapping its guidelines to CERT C and to CWE memory safety weaknesses.
• Treat every external byte as hostile. Radio frames, USB descriptors, sensor buses, bootloader commands and update images all cross a trust boundary; MISRA Directive 4.14 requires validating values received from external sources.
• Remove whole bug classes by design. No dynamic allocation after start-up, no recursion, fixed-size buffers with explicit lengths and checked integer arithmetic eliminate many of the faults attackers rely on.
• Use the hardware you have. An MPU, privileged and unprivileged thread modes, stack guards and execute-never regions turn silent corruption into a contained fault.
• Keep secrets out of the source. Hard-coded passwords and keys in firmware are recoverable by anyone with a device; signing keys belong in an HSM and per-device credentials in secure storage.

Why firmware code needs its own rules

Desktop secure coding advice assumes an operating system that isolates processes, randomises memory layout and can be patched weekly. Firmware often has none of that, which changes both the impact of a bug and which mitigations are available.

Choosing a coding standard: MISRA C, CERT C and MISRA C++

A coding standard turns "write safe code" into checkable rules, and both safety and product security assessors expect to see one.

They are complementary, not rival choices. MISRA publishes addenda that map its guidelines to other standards: MISRA C:2023 ADD3 covers the second edition of CERT C, ADD2 covers ISO/IEC 17961, and MISRA C:2025 ADD5 maps CWE memory safety weaknesses (CWE-1399) to MISRA guidance. A team can adopt MISRA C as its base and use the addenda to show CERT C coverage. MISRA Compliance:2020 explains how to claim compliance, including recording justified deviations, and MISRA C:2012 Permits give pre-approved deviation patterns for hardware access and generated code, both common in firmware.

Rules that matter most for security

The Zephyr RTOS project publishes the subset of MISRA C:2012 that it requires for new code, with CERT C equivalents. It is a useful, public example of the rules that carry the most security weight:

Embedded bug classes and safe patterns

• Length fields from the wire: the most common firmware vulnerability is trusting a length or count in a received packet (CWE-120, CWE-787). Parse into a fixed-size structure, check the declared length against both the buffer size and the bytes actually received, and reject rather than truncate.
• Integer overflow before allocation or copy: count * size or offset + len can wrap on 16-bit and 32-bit targets (CWE-190). Use unsigned fixed-width types from stdint.h, check before the arithmetic, and keep the essential type rules on.
• Interrupt and DMA races: data shared between an interrupt service routine and the main loop must be volatile and updated in a critical section or with atomic operations. Check DMA transfer lengths against the destination buffer, because the peripheral will happily write past it.
• Stack exhaustion: with no recursion and no variable-length arrays, worst-case stack use becomes computable. Use the toolchain's stack usage output and size each task's stack with a margin, then confirm with a stack guard or watermark at run time.
• Use after free in static pools: even without malloc, block pools and message queues can hand out a buffer that is still referenced. Clear ownership rules (one owner, explicit hand-off) prevent it.
• Error paths and fault handlers: a hard fault handler that simply resets the device can be used to bypass checks or loop a device into denial of service. Log the fault cause to persistent storage and decide deliberately between safe state and reset.
• Debug and test code in production: UART consoles, test commands and unlocked JTAG or SWD ports left enabled are a direct way in. Build them out with configuration options and verify the production image. Zephyr's guidance is that rarely used features stay off by default and must be explicitly enabled.

Hardware and compiler protections for firmware

The OpenSSF Compiler Options Hardening Guide explicitly includes embedded and IoT targets in its audience. Some flags need runtime support that bare-metal C libraries do not provide, so test each one on the target rather than copying a Linux flag set.

Where Rust fits

Rust removes most memory safety bugs in safe code, and the Embedded Rust Book, maintained by the Rust Embedded Working Group, covers bare-metal development on microcontrollers using Arm Cortex-M examples and how to mix C and Rust in one project. MISRA C:2025 ADD6 assesses how MISRA C guideline issues apply to Rust. A practical route for existing products is to write new parsers, protocol handlers and update logic in Rust, keep vendor drivers in C, and review every unsafe block like C. See the Rust Security Guide and the Memory Safety Roadmap Guide.

Where identity fits: secrets and keys in firmware

• No shared default passwords: CISA's Secure by Design pledge names default passwords, universally shared across a product, as a goal to eliminate. Generate a unique credential per device at manufacture or require one at first use (CWE-798 Use of Hard-coded Credentials; NIST SP 800-53 IA-5(7) No Embedded Unencrypted Static Authenticators).
• Per-device identity, not a fleet key: a key compiled into every image is extracted once and works everywhere. Provision per-device keys into secure storage. See the IoT Device Identity with TPM and DICE Guide.
• Cloud tokens on devices: devices that call cloud APIs should use short-lived, scoped tokens obtained with the device identity, not long-lived API keys in flash.
• Signing keys are the crown jewels: in the MSI signing keys leak, a ransomware group published firmware source code alongside image signing keys for 57 products and Intel Boot Guard keys for 116, meaning modified firmware could in principle pass verification. Keep signing keys in an HSM, separate from source repositories and build servers. See the Code Signing Security Guide.

Implementing it: a phased approach

1. Baseline: choose the standard (MISRA C:2025 or the edition your tools support, with CERT C mapping via the addenda) and write a short project profile listing which guidelines are required, which are advisory and how deviations are approved.
2. Tooling in audit mode: run a MISRA-capable static analyser and compiler warnings on the existing code without failing the build. Record the baseline count per rule.
3. Fix the high-value rules first: external input validation, pointer arithmetic, string bounds, essential types and dynamic allocation. These map most directly to exploitable bugs.
4. Gate new code: fail CI on new violations of required rules, while existing findings burn down. Each deviation needs a written justification and reviewer sign-off under MISRA Compliance:2020.
5. Add dynamic testing: fuzz parsers on the host with sanitizers, using the same source compiled for the PC, and fuzz interfaces on hardware where possible. See the Fuzzing Guide.
6. Enable protections on target: configure the MPU, stack guards and compiler hardening in a test build; measure code size, timing and power; then enable in a pilot product line.
7. Lock production builds: strip debug commands, disable or lock debug ports, verify no secrets in the image, and sign the release. Roll back by shipping the previous signed image through the normal update path; never by re-enabling debug access in the field. See the IoT Secure Firmware Update Guide (SUIT, signed OTA).

Decision guidance

• Safety-certified product: MISRA is normally expected; add CERT C coverage through ADD3 for the security case.
• Connected consumer or industrial device without a safety case: start with the security-critical subset above and CERT C rules for integers, memory and strings, then widen.
• Small team, one product: adopt an existing published subset (such as Zephyr's) rather than writing your own profile.
• Large portfolio: one organisation-wide profile and shared deviation register, with per-product additions, so findings are comparable across teams.
• New component on a capable MCU: consider Rust for parsers and protocol code; keep C where vendor SDKs require it.

Measuring it

• Open required-rule violations per thousand lines, trending down release by release.
• Deviation count and age: approved deviations, with any older than one release reviewed.
• Fuzzing coverage of external input handlers, and crashes found per month.
• Memory safety defects found after release, by CWE class.
• Production image checks passed: debug locked, no hard-coded secrets, signature verified, for every release.

Framework mapping

Common failure patterns

• Standard on paper only: a MISRA claim with thousands of unreviewed violations and no deviation records will not survive an assessor and does not prevent bugs.
• Blanket deviations: suppressing a rule project-wide because vendor headers trigger it hides real violations in your own code; scope deviations to the file or line.
• Testing only the happy path: parsers that were never given malformed input are where field exploits come from; fuzz every interface that accepts external data.
• Debug left on: production units with an open SWD port or a hidden UART menu make every other control irrelevant.
• Fleet-wide secrets: one hard-coded key or password extracted from a single device compromises the whole installed base.
• Signing keys on the build server: as the MSI case shows, keys stored alongside source can leave with it.

Practitioner checklist

• Adopt MISRA C (edition supported by your tools) or CERT C, with a written project profile and deviation process.
• Run static analysis on every merge and fail the build on new required-rule violations.
• Validate every externally received length, count and command against buffer sizes and allowed ranges.
• Ban dynamic allocation after start-up and recursion; compute worst-case stack per task.
• Enable the MPU, stack guards and suitable compiler hardening on target builds.
• Fuzz parsers and protocol handlers on the host with sanitizers.
• Remove debug commands and lock debug ports in production images, and verify it per release.
• Remove hard-coded passwords and keys; provision per-device credentials into secure storage.
• Keep firmware signing keys in an HSM, separate from source and build infrastructure.
• Track violations, deviations and post-release memory safety defects as release metrics.

Standards and references

• MISRA: MISRA C
• MISRA: Publications (addenda, Compliance:2020, Permits)
• Carnegie Mellon SEI: SEI CERT C Coding Standard
• Zephyr Project: Coding Guidelines
• Zephyr Project: Secure Coding
• OpenSSF: Compiler Options Hardening Guide for C and C++
• Rust Embedded Working Group: The Embedded Rust Book
• CISA: Secure by Design Pledge

Related NHI Mgmt Group resources: C and C++ Secure Coding Guide · Embedded Device Security Guide · Firmware and Boot Security Guide · Memory-Safe Languages Guide · Secure Software Development Lifecycle (SSDLC) Guide