Quick summary
Roughly two-thirds of serious software vulnerabilities come from a single, avoidable source: memory-unsafe code. Cybersecurity authorities now urge manufacturers to adopt memory-safe languages, and EU regulation pushes the same way through secure-by-design rules. This article explains the memory-safety problem, why it matters most in embedded and industrial software, and how to move towards safer code without rewriting everything.
Most of the software running inside industrial equipment, energy systems and connected products is written in C or C++. These languages are fast, well understood and close to the hardware, which is exactly why they have dominated embedded development for decades. They also share a dangerous trait: they let a program access memory in ways the developer never intended, and that single class of mistake is behind a large share of the world's most serious security flaws.
This is no longer just an engineering preference. Cybersecurity authorities have begun publishing formal guidance urging manufacturers to move towards memory-safe languages, and EU regulation increasingly expects products to be secure by design. For companies building connected hardware for energy and industrial markets across the EU, memory safety has become both a security question and a compliance one.
A memory-safety bug happens when a program reads or writes memory it should not, by overrunning a buffer, using memory after it has been freed, or accessing a location that was never allocated to it. In memory-unsafe languages, nothing stops this at the language level, so a small coding error can become a foothold for an attacker.
The scale of the problem is striking. According to CISA, around two-thirds of reported vulnerabilities in memory-unsafe languages still relate to memory issues, despite decades of effort to train developers and add tooling (CISA, 2023). The reason this matters is that these are not exotic, hard-to-find flaws, they are the single most common vulnerability class, and they recur in product after product because the language itself offers no built-in protection against them.
Memory safety is not a niche concern, it is the most prevalent source of exploitable software vulnerabilities.
Takeaway: Memory-unsafe code is responsible for roughly two-thirds of serious vulnerabilities, and better discipline alone has not solved it.
Governments and standards bodies have concluded that the problem needs a structural fix rather than more careful coding. CISA, the NSA and international partners published "The Case for Memory Safe Roadmaps" in 2023, and CISA and the NSA followed in 2025 with detailed guidance on adopting memory-safe languages, arguing that language-level protections, not developer discipline, are what eliminate this class of vulnerability (CISA and NSA, 2025).
The pressure is consistent with the direction of EU regulation. The Cyber Resilience Act requires manufacturers of products with digital elements to build in security from the design stage and to manage vulnerabilities across the product lifecycle (European Commission, 2024). Memory-unsafe code sits directly in tension with that expectation, because it ships a known, recurring vulnerability class into every product by default. The implication is that, over time, building safety-critical connected products in memory-unsafe languages without a clear mitigation plan will be harder to defend, both technically and to regulators.
Takeaway: Memory safety has moved from a coding preference to an expectation backed by cybersecurity authorities and secure-by-design regulation.
The push towards memory safety lands awkwardly in embedded development, precisely where C and C++ are most entrenched. Industrial controllers, energy devices and firmware are overwhelmingly written in these languages, often run on constrained hardware with little room for heavy runtime protections, and stay in service for a decade or more.
That combination raises the stakes. A memory-safety flaw in a substation controller or an industrial gateway is not a crashed web page, it is a vulnerability in critical infrastructure that may be hard to reach and slow to patch. At the same time, these are exactly the systems where rewriting everything is least realistic, because the existing code is mature, certified in some cases, and deeply tied to specific hardware. The reason this matters is that the highest-stakes software is also the hardest to migrate, which is why a pragmatic strategy matters more than an absolutist one.
The systems where memory safety matters most are also the ones where wholesale rewriting is least feasible.
Takeaway: Embedded and industrial software faces the sharpest memory-safety risk and the highest cost of change, so strategy beats purity.
The encouraging news is that memory safety does not require throwing away working code. Memory-safe languages such as Rust bring the same low-level control embedded developers rely on while preventing whole categories of memory error at compile time, and they can interoperate with existing C and C++.
The practical approach, recommended by the same authorities pushing the change, is incremental. New components and new products start in a memory-safe language, while existing systems are migrated selectively, prioritising the highest-risk parts such as code that parses untrusted input or handles network traffic. The results can be dramatic when sustained: Android reduced the share of memory-safety vulnerabilities in its codebase to around 24 percent by 2024 by writing new code in memory-safe languages rather than rewriting the old (Google, 2024). The implication is that a steady, prioritised transition delivers most of the security benefit without the risk and cost of a full rewrite.
Takeaway: Starting new code in memory-safe languages and migrating the riskiest existing components captures most of the benefit without a full rewrite.
Moving towards memory safety is an organisational change, not just a language swap. Teams need tooling that fits embedded targets, training so developers are productive in the new language, and a clear way to interoperate with the large body of existing C and C++ that will not disappear soon.
The most effective framing is a memory-safe roadmap: an explicit plan setting out where new code will be memory-safe, which existing components will be migrated and in what order, and how progress will be measured. This turns a vague aspiration into something a development organisation, and a regulator or customer, can actually hold to account. For manufacturers across the Nordics, DACH and Benelux preparing for the Cyber Resilience Act, that roadmap doubles as evidence of the secure-by-design approach the regulation expects.
Takeaway: A written memory-safe roadmap turns the transition into a measurable plan that also serves as secure-by-design evidence.
Memory-unsafe code has been the quiet source of a large share of software vulnerabilities for decades, and the consensus among cybersecurity authorities is now clear: the durable fix is to adopt languages that prevent these errors by design. EU secure-by-design regulation points the same way.
For embedded and industrial software, where the risk is highest and the installed base is largest, the answer is not a panicked rewrite but a deliberate, prioritised transition. Manufacturers that start new development in memory-safe languages, migrate their riskiest components, and document the plan will steadily eliminate an entire class of vulnerability while staying ahead of where regulation is heading.
A memory-safe language prevents programs from accessing memory incorrectly, for example by overrunning a buffer or using memory after it has been freed. It does this through language-level protections rather than relying on developers to avoid mistakes. Languages such as Rust offer memory safety while keeping the low-level control that embedded development needs, whereas C and C++ are memory-unsafe by default.
Because they are both common and exploitable. They are the most prevalent class of disclosed software vulnerability, and they let attackers read or alter memory in unintended ways, which can lead to data theft, crashes or full system compromise. In critical infrastructure such as energy and industrial systems, the consequences of exploitation can be severe.
No current regulation mandates a specific language, but the direction is clear. Cybersecurity authorities including CISA and the NSA strongly recommend adopting memory-safe languages and publishing memory-safe roadmaps, and the EU Cyber Resilience Act requires secure-by-design development and lifecycle vulnerability management, which memory-unsafe code works against.
No. The recommended approach is incremental: write new code and new products in a memory-safe language, and migrate existing code selectively, starting with the highest-risk components such as those handling untrusted input or network traffic. Memory-safe languages can interoperate with existing C and C++, so the transition can be gradual.
Yes. Memory-safe languages such as Rust are designed to work without a heavy runtime and can target microcontrollers and other constrained devices while preserving low-level control. The main challenges are tooling maturity for specific targets, developer training, and interoperability with existing embedded codebases.