Part: Two
In the first article in this two-part series, we laid out what the EU Cyber Resilience Act requires and the two deadlines that matter. Here’s the part most people miss: the structural head start hiding inside it.
Every now and then, a regulation quietly reshapes the competitive landscape.
We’re seeing it happen now. The EU’s Cyber Resilience Act (CRA) is, on its face, a compliance obligation — a set of rules every company selling digital products to Europe must meet. But regulators don’t choose how you meet their requirements. They only define the outcome. And that gap between “what the law requires” and “how you choose to get there” is where real advantage is won.
One choice matters more than any other right now: which language you build in. The strongest teams aren’t treating the CRA as a burden to be minimized — they’re treating it as a compliance head start.
The war the CRA is actually targeting
To understand why, look at what the CRA is really asking for. It demands secure-by-design software and fast, transparent handling of vulnerabilities. It’s not prescriptive about tools — the law never mentions a single programming language. It cares about outcomes.
And here’s the uncomfortable truth underneath those outcomes: the majority of the most serious vulnerabilities trace back to a single, stubborn class of bug.
We’re talking about memory-safety errors — use-after-free, buffer overflows, double frees. These are the flaws that have haunted C and C++ codebases for decades. In large ecosystems, they account for roughly seventy percent of the most serious vulnerabilities. They’re the reason “security patch” has become a permanent fixture of our digital lives.
For security teams, chasing this class of bug has been a losing war. You find one, patch it, and three more surface elsewhere. The problem isn’t discipline — it’s that the tool itself makes catastrophic mistakes too easy to make.
The tool that refuses to let the error exist
Now imagine a language that eliminates most of this entire class of bug at the moment of compilation — before the software ever runs.
That’s the promise of memory-safe languages, and the most prominent among them is Rust.
Rust’s compiler enforces memory and thread safety at compile time. It doesn’t merely detect many memory-safety errors — it prevents them from ever being written. For security-critical software, this is a structural shift, not an incremental one.
The evidence is no longer theoretical. It comes directly from large-scale production adoptions:
- Google’s Android wrote that memory-safety vulnerabilities fell below twenty percent of total vulnerabilities for the first time — and, in Google’s own words, that its Rust code is seeing a “1000x reduction in memory safety vulnerability density compared to Android’s C and C++ code” (Google Android Security Blog). Google also reports Rust changes with a 4x lower rollback rate and 25% less time in code review.
- Amazon’s Firecracker, the virtualization engine behind AWS Lambda and Fargate, is written in Rust — chosen in part for the security and performance it delivers (Firecracker — AWS).
- Microsoft has spoken openly about adopting Rust for new core infrastructure components, citing the same memory-safety data, even as it maintains its large existing C++ codebases (The New Stack).
- In safety-critical domains, Rust is already moving from experimentation into production: the Rust Foundation’s own research on safety-critical systems quotes a company deploying IEC 62304 Class B medical software to intensive care units, and a IEC 61508 SIL 2 mobile-robotics system, both written in Rust (Rust Foundation — safety-critical report).
This isn’t evangelism. It’s measured, documented adoption at the largest scale in the industry.
Why this converges with the CRA
This is where the story gets genuinely strategic.
The pressure to move to memory-safe languages isn’t coming from one place. It’s converging from three directions at once:
- American security agencies. The NSA and CISA have jointly urged the industry toward memory-safe languages, and the White House has asked developers to adopt them. Government guidance on memory safety is now mainstream.
- European law. The CRA enforces secure-by-design software and fast, accountable vulnerability handling — creating structural pressure in the same direction, even though it never names a language.
- The economics of breach. Every memory-safety exploit is a cost center: an incident, a patch, a reputational hit, a customer lost. Reducing that class of flaw reduces cost — permanently.
When the outcome demanded is “fewer vulnerabilities, faster handling,” the how — the language and architecture you choose — becomes a decisive variable.
A team that builds in Rust doesn’t just check a compliance box. It starts with a structural head start that C/C++ peers have to buy back with tooling, process, and endless patching. On top of that, memory-safe foundations make the CRA’s continuous reporting and maintenance obligations cheaper and less frequent to satisfy.
To be clear, this advantage is entirely fair: it’s the result of a better engineering choice, not a barrier competitors can’t cross. What it provides is real — a lower cost of compliance, fewer incidents, and faster time-to-market with CRA-ready products — but it’s a head start, not an uncopyable wall.
What smart builders should do now
If you’re a founder, a builder, or an investor, the CRA isn’t a reason to freeze. It’s a reason to move.
If you’re starting something new
Build on memory-safe foundations from day one. For greenfield systems software, security-critical components, and performance-hungry infrastructure, Rust is increasingly the default choice — not for its hype, but for its measured results. Starting secure is dramatically cheaper than retrofitting security later.
If you have an existing codebase
You don’t need to rewrite everything. The most pragmatic strategy mirrors what the big platforms did: write new, high-risk code in a memory-safe language, and migrate the highest-risk components first. Over time, the security posture of the whole product improves without a risky big-bang rewrite. The CRA rewards exactly this kind of steady, measurable improvement.
If you’re an investor (or evaluating a company)
Ask about the engineering stack. A team building on memory-safe, secure-by-design foundations isn’t just more secure — it’s likely to have lower ongoing remediation costs, fewer incidents, and an easier path through regulation. In a market where trust is currency, that’s a real edge.
The bigger picture
Step back, and the CRA stops looking like a regulation and starts looking like a statement about the future.
We are moving from a world where software security was a feature you could skip to a world where it is a floor you must stand on. The three great forces reshaping the industry — American security guidance, European law, and the relentless economics of breach — are all converging on the same destination: software that is safe by default.
The builders who internalize this early won’t treat the CRA as a burden to be minimized. They’ll treat it as a tailwind — building products that are trusted precisely because they’re secure.
In a digital economy starving for trust, that is the ultimate premium.
This article reflects the authors’ analysis and does not constitute legal advice. The CRA is language-neutral; the discussion of memory-safe languages reflects industry research and measured adoption outcomes, not a requirement of the regulation.
Want to go deeper? In our first article, we walked through the CRA’s requirements, scope, and the two deadlines that matter. Read it here: The Cyber Resilience Act: What the EU’s New Software Law Means for Every Digital Product
Sources (primary)
- Google — “Rust in Android: move fast and fix things” (Android Security Blog)
- Firecracker microVM — official documentation (AWS)
- The New Stack — Microsoft’s Rust adoption
- Rust Foundation — “What does it take to ship Rust in safety-critical?”
- CISA / NSA — “Memory Safe Languages” joint guide
- White House / ONCD — “Back to the Building Blocks”
- European Commission — Regulation (EU) 2024/2847 (CRA)
