Memory-Safe-by-Default: The US Federal Push and What It Does to Your Stack

For decades, the answer to “what language should I write systems software in?” had a boring, safe default: C, or C++ if you wanted objects. Nobody got fired for it. It was the tide, and you swam with it.

That tide just changed direction. Not because of a language war on Hacker News, but because the US federal government wrote down its opinion and put a date on it. As of January 1, 2026, CISA and the FBI say that shipping a product in a memory-unsafe language like C or C++, without a published memory-safety roadmap, is a documented bad practice that “significantly elevates risk to national security, national economic security, and national public health and safety.”¹That is not a blog post. That is the country's cyber defense agency naming your default the risky choice.

If you are starting a new C++ project in 2026, you are now swimming against the current. Let me walk through what actually happened, what it does to your stack, and why the data behind it is more convincing than the politics.

What the guidance actually says

The document is CISA and the FBI's “Product Security Bad Practices,” part of the Secure by Design effort, first released in October 2024. It is written for software manufacturers, the people who build and sell products, not for your internal tooling team. And it does not demand a finished rewrite. What it demands is a published memory-safety roadmap by January 1, 2026.¹

Here is the part that closes the escape hatch. The roadmap expectation carves out exactly one category: products with an announced end-of-support date before January 1, 2030. Everything else is in scope. So if your C or C++ product is actively supported and you plan to keep supporting it past 2030, the guidance says you should have a roadmap. In practice that is nearly every serious C or C++ product on the market.¹

Read that carefully, because the framing is clever. They did not set an impossible “rewrite everything” bar that everyone would ignore. They set a “have a plan” bar, which is achievable, and which quietly makes “we have no plan and no intention of making one” the indefensible position. A missing roadmap is now something an auditor, a customer, or a plaintiff's lawyer can point at.

Why they picked this hill

The reason is not ideology, it is arithmetic. In June 2025, CISA and the NSA released a joint Cybersecurity Information Sheet, “Memory Safe Languages: Reducing Vulnerabilities in Modern Software Development.” It reaffirms a number the industry has repeated for years: roughly two-thirds of reported vulnerabilities in memory-unsafe languages are memory-related, and memory bugs drive an estimated 66 to 75 percent of CVEs on major platforms.²

Think about what that means. If a single class of bug, buffer overflows, use-after-free, out-of-bounds reads, accounts for two out of every three vulnerabilities, then a language that makes that class structurally impossible does not shave a few percent off your risk. It removes the majority of it. This is the rare case where the security win is not marginal, it is categorical.

The same sheet names the languages the government considers memory-safe: Rust, Go, C#, Java, Swift, Python, and JavaScript. And it is specific about strategy. It does not say “rewrite the world.” It says start new projects in memory-safe languages, and incrementally rewrite the high-risk components first, the network-facing services and the cryptographic code.² That is the pragmatic version of the migration, and it is the one that actually gets done.

The Android numbers are the receipt

Policy is easy to dismiss when there is no proof it works. The proof is Android. Google has been folding Rust into the Android platform for years, and in November 2025 it published the results, and they are hard to argue with.

Memory-safety vulnerabilities in Android fell below 20 percent of total vulnerabilities for the first time, down from roughly 70 to 76 percent in 2019.³ In raw counts, that is 223 memory-safety vulnerabilities in 2019 dropping to fewer than 50 in 2024.³ And here is the kicker: this happened while Google was writing more code, not less. The bug count went down as the codebase grew, because the new code was going into Rust instead of C++.

The density number is even more striking. Google measures its Rust code in Android at roughly a 1000x lower memory-safety vulnerability density than its C and C++, about 0.2 versus roughly 1,000 vulnerabilities per million lines of code.³ That is not a tuning improvement. That is three orders of magnitude, the kind of gap you only get when you remove the whole failure mode rather than patching instances of it.

The part that surprised me: safer turned out to be faster

The old objection to Rust was always about cost. Sure it is safer, but it is slower to write, the borrow checker fights you, your team needs to learn it. You trade velocity for safety. That was the accepted wisdom, and Google's data blows a hole in it.

Rust changes in Android ship with a roughly 4x lower rollback rate than C++, spend about 25 percent less time in code review, and need about 20 percent fewer revisions.³Google summarized it in one line: “the safer path is now also the faster one.”³ Think about why that would be true. A change that the compiler has already proven cannot corrupt memory is a change a reviewer can trust faster. Fewer whole-classes-of-bug to hunt for in review means fewer rounds, fewer reverts, less time.

The clearest signal is in what Google is actually doing, not just measuring. By the first three quarters of 2025, net Rust code additions slightly surpassed C++ for first-party Android platform development.³ In 2020 that would have been unthinkable. The company that wrote Android in C and C++ is now adding more Rust than C++ to it, by choice, because it costs them less.

Microsoft is on the same path, at a different scale

This is not one company's bet. Microsoft has long attributed roughly 70 percent of the CVEs it patches to memory-safety bugs in C and C++, the same two-thirds-plus figure that shows up everywhere.⁴ And it has been quietly acting on it: about 36,000 lines of the Windows kernel and roughly 152,000 lines of DirectWrite have already been rewritten in Rust.⁴

In December 2025, Microsoft distinguished engineer Galen Hunt described an internal research effort to use AI agents and code-graph infrastructure to translate C and C++ to Rust at a target pace of “1 engineer, 1 month, 1 million lines of code,” with an aspiration to replace C and C++ across Microsoft by 2030.⁴ I want to be careful here, because it is easy to overhype: Hunt framed this as a research project, not a mandated company-wide transition. The 2030 date is an aspiration, not a committed roadmap.

But even as a research project, the direction is the tell. The two biggest platform vendors on earth are both spending serious engineering budget on getting off C and C++. When Google and Microsoft independently decide the migration is worth it, and the federal government writes the same conclusion into guidance, that is three arrows pointing the same way. The individual claims are debatable at the edges. The direction is not.

The language market is already repricing

You can see the shift landing in the popularity data, which usually lags real adoption by years. Rust entered the TIOBE Index top 10 for the first time in July 2026, climbing from No. 18 in July 2025 to No. 10 and displacing Delphi and Object Pascal.⁵That is a big jump in one year for a language with Rust's reputation for a steep learning curve.

Do not misread this as C and C++ dying. They held the No. 2 and No. 3 spots on that same index.⁵ There are billions of lines of C and C++ running the world, and they are not going anywhere for decades. The point is not death, it is default. The default for new systems code is moving. C and C++ are becoming the languages you choose for a specific reason, hardware constraints, an existing codebase, a library you cannot replace, rather than the languages you reach for because that is what everyone reaches for.

The “unsafe Rust is just as bad” objection, addressed

The sharpest pushback on all of this is: Rust has an unsafe keyword, and any Rust codebase of size uses it, so you have not actually escaped memory bugs, you have just hidden them behind a keyword. It is a fair thing to raise, and the 2025 data has a clean answer.

Take CVE-2025-48530, a vulnerability with a CVSS score of 8.1 that was found in unsafe Rust code in Android. It was rendered non-exploitable by the Scudo memory allocator and never shipped.³ That is the whole point in one example. Even an unsafe block in Rust sits inside far more surrounding protection than the equivalent C or C++, the safe defaults, the allocator hardening, the small blast radius you can audit. Unsafe Rust is not equivalent to C. It is a small, marked, auditable region inside an otherwise-safe program, which is a completely different risk profile than a whole codebase where every line is unsafe by default.

What this actually does to your stack

So you are a team lead, or a founder, or the person who has to sign off on the tech choices. What changes for you? A few concrete things.

• New code has a new default. If you are greenfielding a network service, a parser, or anything crypto-adjacent, the burden of proof has flipped. Picking C++ now requires a justification you write down, because the government named the alternative as the safer path and the biggest vendors agree.
• Existing code needs a roadmap, not a rewrite. The federal ask is a published plan, and the recommended shape is incremental: new components in a safe language, high-risk pieces rewritten first. You do not have to boil the ocean. You have to be able to show you have a direction.
• Procurement is downstream of this.Secure by Design language has a way of migrating into government contracts and then into enterprise vendor questionnaires. “Do you have a memory-safety roadmap” is the kind of checkbox that shows up on an RFP two years after it shows up in guidance.
• It is not just a US problem.The original 2023 “The Case for Memory Safe Roadmaps” was co-authored by CISA, the NSA, the FBI, and the cyber agencies of Australia, Canada, the UK, and New Zealand.⁶This is a Five Eyes-aligned position. If you sell across those markets, you are dealing with a coordinated stance, not one country's preference.

The way I read all of this: the memory-safety debate is over as a debate. What is left is a migration, and migrations take a decade and happen component by component. The interesting question is no longer whether to move, it is which of your components are network-facing or parsing untrusted input, because those are the ones worth moving first, and those are the ones a roadmap should name.

If you are still writing new, unjustified C++ in 2026, you are not wrong exactly. The code will compile and run. But you are swimming against a current that now includes the US government, the Five Eyes, Google, Microsoft, and the raw vulnerability math. That is a lot of water moving the other way. At some point, fighting the tide stops being a principled stand and starts being a maintenance liability you signed up for on purpose.