Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

The White House is not ordering an immediate ban on C or C++. In a February 2024 technical report, the Office of the National Cyber Director (ONCD) urged software makers to use memory-safe programming languages for new products where feasible and to prioritize high-risk parts of existing systems for migration.

What the White House report actually recommends

The ONCD report, Back to the Building Blocks: A Path Toward Secure and Measurable Software, frames programming-language choice as one way to reduce a significant class of software vulnerabilities. It is a technical policy argument, not a universal rewrite order: use memory-safe languages when practical, especially for new products, and focus legacy migration on components whose failure or compromise would carry the greatest risk.

The report also calls for progress in hardware architecture, formal methods, and better ways to measure software security. It cautions that cybersecurity has no single cure: “There are no ‘silver bullets’ in cybersecurity.”

Why C and C++ are in focus

C and C++ are widely used in critical systems, but they do not provide the same built-in protections against many unintended memory operations that memory-safe languages do. Memory-safety errors occur when software accesses, writes, allocates, or frees memory in unintended ways. Two important categories are:

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.
  • Spatial errors: accessing memory outside an object’s bounds, such as reading beyond the end of an array.
  • Temporal errors: accessing an object after its valid lifetime or state has ended, such as using memory after it has been freed.

When a language prevents broad classes of these operations by construction, developers can avoid many defects rather than relying solely on testing or later detection. The ONCD report says: “Using memory safe programming languages can eliminate most memory safety errors.” That is a claim about memory-safety errors, not a promise to eliminate every kind of vulnerability.

How large is the memory-safety problem?

The ONCD report says industry analysis found that, in some cases, up to 70 percent of security vulnerabilities in memory-unsafe languages that were patched and assigned a CVE were due to memory-safety issues. The report’s endnote points to a July 2019 Microsoft Security Response Center analysis. The figure is qualified: it is not a universal share of all vulnerabilities, nor does it describe every codebase or vulnerability database entry.

What should happen to existing C and C++ code?

The report does not call for replacing every legacy codebase at once. A complete rewrite can be costly and introduce migration risks of its own. Instead, it describes a hybrid approach: identify critical functions or libraries, assess their risk, and migrate the highest-priority areas first.

Its example risk criteria include whether the software is widely used, sits on a network boundary, performs a critical function, and is written in a memory-unsafe language. That makes migration a risk-based engineering decision rather than a language-wide deadline.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Does the report say to replace C++ with Rust?

Rust is one memory-safe option discussed in the report, not a mandated replacement for C or C++. The ONCD says Rust has the properties it identifies for space systems, but also notes that its suitability had not yet been proven in those use cases as of the report’s February 2024 publication. The report calls for further toolchain work, workforce education, and fielded case studies.

For any project, the choice depends on the system’s constraints and the team’s readiness. The report highlights factors such as close-to-kernel interaction, deterministic timing, garbage-collection requirements, available expertise, and evidence from systems already deployed in the intended environment. It does not establish one language as the right replacement for every C or C++ application.

What other safeguards does the report discuss?

Memory-safe hardware

Memory tagging can check pointer validity before use and report invalid pointers. The report treats this as a way to detect bugs, not as a comprehensive means of preventing every exploit. It also discusses CHERI, a capability-based hardware approach intended to change how software accesses memory and reduce vulnerabilities associated with historically unsafe languages. Such hardware measures can complement migration, particularly where legacy code cannot be replaced quickly.

Formal methods

Formal methods use mathematical techniques to assess whether software meets specified security properties. The report names sound static analysis, model checking, assertion-based testing, compiler-integrated proofs, and formally verified core components. These techniques can address vulnerabilities beyond memory safety, but the report notes that adoption remains limited and some methods face computational scaling constraints.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Better software-security measures

The report separately argues for more empirical ways to measure software cybersecurity quality. Better measures could help developers, buyers, and policymakers make more informed decisions. This is part of its broader policy argument, distinct from the recommendation to favor memory-safe languages where feasible.

Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Support on Ko-Fi

What the 2024 report does—and does not—establish

The report supports a practical direction: choose memory-safe languages for new work when they fit, and reduce exposure in legacy systems by prioritizing high-risk components. It does not establish that all federal or private-sector software has migrated, that C and C++ are universally prohibited, or that the report itself imposed an immediate implementation mandate. Its publication in February 2024 also should not be read as a new 2026 order or as evidence of later federal implementation status.

Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.