CISA and the NSA jointly published Memory Safe Languages: Reducing Vulnerabilities in Modern Software Development on 24 June 2025. The guide discusses obstacles to adopting memory-safe languages and practical ways to address them. For firmware teams the sensible path is incremental: new components first, risky parsers next, and rewriting last.
What the agencies cover
CISA's page says the guide expands recommendations for critical infrastructure organisations in four areas: protections built into languages, supporting libraries, development tooling and developer training. I could read only the summary page, not the full PDF, so details beyond that should be checked in the guide itself.
Why embedded teams hesitate
Firmware has constraints that desktop software does not: small memory, vendor SDKs written in C, real time requirements and toolchains tied to a chip. Those are reasons to plan carefully, not reasons to do nothing.
A staged approach
These steps are my suggestions, not claims from the CISA page.
- Inventory where the risk is. Parsers for network protocols, file formats and over the air packages handle untrusted input. Start your list there.
- Write new components in a memory-safe language where your toolchain supports it. Check target support, binary size and debugging tools on your actual hardware first.
- Wrap, do not rewrite, the vendor SDK. Keep a thin C boundary and put new logic on the safe side.
- Mitigate in the meantime. For C code you keep, use compiler hardening options, static analysis, fuzzing of parsers and a review habit for pointer arithmetic.
- Train the team. The CISA summary lists developer training as one of its four areas, and a new language without practice just moves the bugs.
Questions to answer before you start
- Does the language support our processor and our real time operating system?
- How large is the resulting binary, and does it fit?
- Can we debug and profile it with the tools we have?
- What happens at the boundary with C, and who reviews unsafe blocks or equivalent escape hatches?
- Will suppliers deliver libraries we can call?
Measuring progress
Count the lines or modules that handle untrusted input and track how many are in a memory-safe language or covered by fuzzing. Report that number each release. A trend you can show is easier to defend than a plan.
A note on SBOMs
New languages bring new package ecosystems. Make sure your SBOM process records those dependencies too, so a new advisory in a crate or module is as findable as one in a C library.
Quick check
Does the CISA page say you must rewrite everything?
The page I read does not. It summarises a guide about obstacles and practical ways to adopt memory-safe languages.
Where should an embedded team start?
This post suggests code that parses untrusted input, since that is where memory errors are most exposed. That is our suggestion, not a statement from the CISA page.
Where Safeguard fits
Safeguard covers the software supply chain side of this work: SBOM and dependency scanning, policies and gates, and compliance and evidence automation. It does not replace hardware security features. A free scan is available at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
