A memory safety roadmap is a dated, prioritized plan for removing memory safety vulnerabilities from your products. CISA's Product Security Bad Practices guidance says manufacturers should develop new product lines in memory safe languages and publish a roadmap for existing products by the end of 2025.
What the guidance says
Version 2.0 of the guidance, revised on 17 January 2025, treats two things as bad practice for critical infrastructure software: building new product lines in C or C++ when memory safe alternatives are readily available, and having no published memory safety roadmap for existing products. The roadmap should outline a prioritized plan to eliminate memory safety vulnerabilities in high priority components, such as network facing code or cryptographic code, and show that it will reduce them meaningfully over time.
Products with an announced end of support date before 1 January 2030 are excepted from the roadmap point. The guidance also recognizes that migrating takes significant time and resources and suggests interim steps, including compiler or hardware controls and gradual rewrites of high risk components. A separate CISA page, The Case for Memory Safe Roadmaps, links these ideas to Secure by Design principles.
This is guidance for software manufacturers. Check whether your own contracts or sector rules say anything more specific.
Checklist
- Inventory native code. List components in C, C++ and assembly, with size and owner. Include third party libraries you ship.
- Rank by exposure. Network facing parsers, file format handlers and cryptographic code go first, as the guidance suggests.
- Set a rule for new code. New components start in a memory safe language unless an exception is approved and recorded.
- Pick a path per component. Rewrite, wrap, harden or retire. Write down which one and why.
- Add interim controls. Compiler hardening flags, library hardening modes and sanitizer runs in CI can cut risk while rewrites proceed.
- Assign owners and dates. A roadmap with no names and no quarter attached is a wish list.
- Define measures. For example, the count of native components, lines of native code in exposed components, and memory safety bugs fixed per release.
- Publish and review. Put a version and review date on it, and update it on a schedule.
Mistakes to avoid
- Promising a full rewrite with no staffing.
- Counting a safe language wrapper around the same native library as progress.
- Publishing a roadmap with figures you cannot reproduce.
Try it yourself
Click through it at your own pace, or open it full screen. Look for the components that bring native code with them, since those belong on step 1.
Quick check
Does the guidance ask for a rewrite of everything?
No. It asks for a prioritized plan for high priority components and acknowledges interim controls and gradual migration.
Safeguard's SBOM and dependency scanning can produce the component inventory that step 1 depends on, and reachability analysis helps rank which native libraries matter most.
Sources
Last reviewed: 19 October 2026.
