The vulnerability class this eliminates by construction
A large share of serious security vulnerabilities across decades of software — buffer overflows, use-after-free, and similar memory-management bugs — trace back to languages like C and C++ that require developers to manage memory manually and correctly, every time, with no safety net if they don't. Memory-safe languages like Rust build the safety net into the language itself, catching entire categories of these bugs at compile time instead of relying on every developer getting manual memory management right, every time, forever.
What CISA and NSA actually recommend
Joint guidance from CISA and NSA frames memory-safe language adoption around four safeguards: language-level protections, library support, robust tooling, and developer training. Notably, the published guidance stops short of a hard universal deadline — but it's explicit that this is a strategic expectation for vendors in critical infrastructure or competing for government contracts, not an optional best practice buried in a recommendations appendix.
The absence of a fixed date is doing less work than it looks like. Procurement requirements referencing memory safety are increasingly showing up piecemeal across contracts and RFPs rather than as one sweeping mandate — meaning the practical deadline is different for every vendor, arriving quietly through the contracts they're already trying to win rather than through a single government-wide cutoff.
Where this actually matters for a new build
- New systems handling untrusted input. Anything parsing external data, network protocols, or file formats is exactly the surface area where memory-safety bugs historically show up — a new build is the cheapest point to make this choice, far cheaper than migrating later.
- Vendors selling into regulated or government-adjacent sectors. If procurement requirements are already starting to reference memory safety, being ahead of that curve is a genuine competitive point in a proposal, not just a defensive move.
- Long-lived infrastructure and systems software. Code that will run for a decade carries memory-safety risk for that entire decade — the earlier in a system's life the safer language choice gets made, the more of that risk gets avoided rather than just delayed.
Where it's not the deciding factor
Not every project needs this consideration to drive the language choice. A typical web application's attack surface usually isn't dominated by memory-safety bugs the way a network daemon's or an embedded system's is — for a lot of custom software and SaaS work, other factors (team familiarity, ecosystem maturity, hiring pool) reasonably outweigh this one. The point isn't "use Rust for everything" — it's knowing when the risk profile actually calls for it.
| Higher priority | Lower priority |
|---|---|
| Systems parsing untrusted external input directly | Applications where a mature framework already handles that boundary |
| Long-lived infrastructure and network-facing services | Short-lived internal tools with a small, trusted user base |
| Vendors selling into regulated/government-adjacent markets | Products where the buyer never asks about the language at all |
Choosing a stack for a security-conscious build?
We help teams pick the right language and architecture for their actual risk profile — not a one-size-fits-all default.
Frequently asked questions
Does this mean we should rewrite existing C/C++ systems in Rust?
Not automatically — a full rewrite carries its own risk and cost. The more common, lower-risk approach is writing new components in a memory-safe language and migrating the highest-risk existing surfaces incrementally, rather than a wholesale rewrite.
Is Rust the only memory-safe language that matters here?
No — Go, Java, C#, and several others are memory-safe in the relevant sense. Rust gets particular attention because it achieves memory safety without a garbage collector, making it viable for systems-level and performance-sensitive code that previously had no memory-safe alternative.
Does memory safety mean a language is secure overall?
No — memory safety eliminates one significant, historically serious vulnerability class. Logic errors, authorization bugs, and misconfigurations are still possible in any language, memory-safe or not.
Is this relevant outside government-adjacent industries?
The compliance pressure is concentrated there, but the underlying engineering argument — fewer entire classes of bugs, caught earlier — is relevant to any long-lived system handling untrusted input, regardless of who the customer is.