By Alexander Walter (ERNI Switzerland)
Memory-safety bugs such as Heartbleed are among the most common and most expensive software defects, and they cluster in code that parses external data: exactly the code that connects a medical device to the outside world. Rust, a systems programming language with native performance and strong memory-safety guarantees, rejects most of them before the software ever runs. The rest are stopped as a defined fault instead of leaking or corrupting data. This article explains how that works, what the evidence shows and where the language pays off in medical device software. All statements about Rust’s guarantees refer to safe Rust, the language’s default mode.
Part 2 of 3 in the series Rust in medtech: Prevention beats cure. Part 1: Memory-safety bugs in medtech: The defect that waits in the field available here.
Prevention over cure
In 1847, Ignaz Semmelweis showed in Vienna that one simple discipline, handwashing, dramatically reduced deaths from childbed fever. Many colleagues rejected the idea because the rule felt like extra effort and implied that doctors themselves were spreading the disease. Today, nobody in a hospital would question it.
Rust applies a similar idea to software. C and C++ leave memory management to the developer and rely on reviews, static analysis and tests to catch mistakes after they have been written. Languages such as Java or Python avoid these errors with a managed runtime and a garbage collector, an automatic memory clean-up that is rarely an option on a microcontroller or in time-critical code. Rust’s compiler instead enforces a small set of rules on every line of code, without a garbage collector:
- Every value has exactly one owner, which releases it automatically when it is no longer needed.
- Data can be read by many or changed by one, but never both at the same time.
- When several tasks run at the same time (concurrency), shared data must be protected, for example by a lock. Because the compiler checks this, the Rust community speaks of ‘fearless concurrency’.
- A value that may be missing must be handled explicitly; there is no null pointer.
- Every possible state of a device or process must be handled wherever it is evaluated.
- Business rules can be built into the types themselves, so that the compiler rejects invalid states, for example a pump that is ‘dosing’ without a dose value.
Code that breaks these rules does not compile.
What Rust prevents, and where its limits are
Rust handles error classes in three different ways, as Figure 3 shows: some are rejected before the code can run, some are stopped safely at runtime, and some remain the job of the engineers and their processes. On a medical device, an error stopped at runtime still has to be handled by the safety concept, for example by rejecting a message or moving to a safe state. The difference is that a silent memory corruption or data leak becomes a visible, defined fault.
Figure 3: What Rust prevents, and where its limits are
The evidence: Fewer vulnerabilities, less rework
The strongest evidence comes from a major technology company’s mobile operating system, which has written more and more of its new code in memory-safe languages since 2019:
- Memory-safety bugs fell from 76% of its vulnerabilities in 2019 to 24% in 2024.
- In 2025, the company reported a memory-safety vulnerability density in its Rust code more than 1,000 times lower than in its historical C and C++ code.
- Compared with similar C++ changes, Rust changes needed about 25% less review time, and medium and large Rust changes were rolled back only about a quarter as often.
Adopting Rust does require an upfront investment. In the same company’s internal surveys, just over half of developers felt as productive in Rust as in their previous language after four months. Like handwashing, the discipline feels like extra work until it becomes routine.
These figures come from large software organisations, not from medical devices. They still transfer, because the mechanism is the same: the same defect classes, in the same languages, found in the same kind of code, especially parsers that handle untrusted data. What differs in medtech is the cost of each defect that slips through.
Where Rust pays off: Four levels
Proven, certified device software can stay as it is. Rust’s value is highest where an existing engineering trade-off has already become expensive. We find it useful to look at four architectural levels, from a single process to the architecture of a whole product family. Each level has its own typical challenge and its own Rust strength.
Figure 4: Four architectural levels where Rust can pay off
Process level: The bottleneck
In medtech, the bottleneck is often a single service: the pipeline that ingests device data, an image- or signal-processing step, or a gateway with limited hardware. If it causes unpredictable delays or high cloud costs, replacing just that service can be enough. A large chat platform for online communities did exactly this. Its state-management service, written in Go, paused roughly every two minutes for garbage collection, causing latency spikes. After a rewrite in Rust, the spikes disappeared, and the new version beat the old one on latency, CPU and memory. Another platform rewrote a heavily used service from Go to Rust and cut the processor capacity it needed from 20 cores to 4.5 at the same load. The same pattern applies to a device data pipeline or a lab-instrument gateway.
System level: The risk hotspot
Some components meet the outside world: Bluetooth and NFC parsers, network stacks, update checkers, and DICOM or HL7 interfaces. Heartbleed and URGENT/11, two of the best-known memory-safety flaws, both lived in exactly this kind of code. Here, Rust’s memory safety has the greatest effect.
A large messaging app, for example, replaced 160,000 lines of C++ media-parsing code with 90,000 lines of Rust, tests included. The new code processes untrusted files on billions of devices, with better performance and lower memory use than the original. The exposed component is rewritten behind a narrow interface, while the rest of the system stays unchanged.
Product level: Lifecycle cost
Medical devices have long lives. Over 10 to 15 years, they gain variants, receive updates and pass through many hands. Every late defect means analysis, rework and re-validation. One major web browser team calculated that keeping up with bugs in a C font library cost at least a quarter of an engineer’s time, year after year. Its Rust replacement now handles all web fonts in the browser on Linux, Android and ChromeOS, and automated testing with millions of random inputs (fuzzing) has found no security-critical bugs in it.
Rust acts as a permanent quality gate across the whole product lifecycle. If the possible device states are defined as a fixed list in the code, adding a new state in variant seven makes the compiler list every place that does not yet handle it.
Architecture level: Stack harmonisation
A modern device ecosystem often combines C firmware, mobile apps in Swift and Kotlin, and a cloud backend in yet another language. The same validation logic is then written, tested and fixed three times. A Swiss privacy-focused software company rebuilt its mobile mail apps on a shared Rust core. Almost 80% of the code is now shared between iOS and Android, and the iOS crash rate fell from 0.12% to 0.05%.
Rust runs on microcontrollers, mobile devices and servers, and in the browser (via WebAssembly). User interfaces usually stay in Swift, Kotlin or web technologies, but the critical logic can live in one shared Rust core: written, tested, qualified and fixed once.
From principle to practice
Rust complements a solid development process: it prevents or contains one of the most common and most expensive classes of defects at the source, before it can turn into a field action. Its value is highest where exposure, lifecycle cost or performance pressure already hurt – not in proven, certified code that works.
The obvious next question is how to introduce a new language into a product that has to pass IEC 62304 and an audit. Part 3 of this series covers a step-by-step adoption path, qualified toolchains, the honest limits and a controlled pilot.
If one of the four levels sounds familiar, register for our webinar.
References
Rust: mechanisms and evidence
- Ignaz Semmelweis – Wikipedia: 1847, First Obstetrical Clinic of the Vienna General Hospital
- Eliminating Memory Safety Vulnerabilities at the Source – Google Security Blog, Sep 2024: 76% to 24%, vulnerabilities concentrate in new code
- Rust in Android: move fast and fix things – Google, Nov 2025: 1,000x lower vulnerability density, review time, rollback rate
- Rust fact vs. fiction: 5 insights from Google’s Rust journey – Google Open Source Blog, 2023: productivity after four months
Examples by architectural level
- Why Discord is switching from Go to Rust – Discord: garbage-collection latency spikes
- Counter Service: how we rewrote it in Rust – Grab, 2025: 20 to 4.5 CPU cores
- Rust at scale: security at WhatsApp – Meta Engineering, Jan 2026: 160,000 lines of C++ replaced by 90,000 lines of Rust
- Improving memory safety in Chrome’s font rendering – Chrome for Developers, Mar 2025: FreeType effort and Skrifa
- The next generation of Proton Mail mobile apps – Proton: ~80% shared code, crash rate