For decades, safety-critical software certification has meant one thing: C with MISRA C compliance. Commercial static analysis tooling. Manual audit overhead. Deviation records. Toolchain qualification work. That’s the cost of doing business.
That’s changing. In 2025 and 2026, Rust moved from evaluation into certified production. It’s now running in ICU patient monitoring software certified to IEC 62304 Class B and in industrial mobile robotics certified to IEC 61508 SIL 2. Not research projects. Production systems.
The Ferrocene safety-qualified Rust compiler toolchain is now qualified to IEC 62304 Class C, IEC 61508 SIL 3, and ISO 26262 ASIL D. The Ferrocene Language Specification (FLS) was donated to the Rust Project in March 2025 and is now maintained as an official language artefact — which closes the “Rust has no language spec” objection that has historically blocked regulated use.
This article covers Rust in safety-critical systems from a software procurement perspective. All standard references are explained in procurement language. For the regulatory momentum driving Rust adoption across enterprise software, the pillar article provides the strategic context.
What Do the Safety Standards Actually Require — and Why Has C Struggled to Meet Them?
Safety standards like IEC 61508 and IEC 62304 don’t prescribe a programming language. They prescribe development process rigour: deterministic behaviour, absence of undefined behaviour, traceable evidence of correctness.
C’s problem is structural. The language permits use-after-free, null pointer dereference, buffer overflow, and data races. Safety standards require you to prevent all of these — but C’s compiler won’t catch them. Prevention has to happen through external process: static analysis tools, coding standards, manual review.
MISRA C is the industry’s long-running response. Enforcing its roughly 143 rules means licensing commercial static analysis tools — Polyspace, PC-lint Plus, CodeSonar, Parasoft C/C++test — running analysis on every build, managing deviation records for every exemption, and qualifying the analysis tool itself under the standard. It’s expensive and it’s slow.
Rust’s structural advantage is that its ownership and borrow checker enforces memory safety at compile time. Use-after-free, null pointer dereferences, and data races are rejected by the compiler itself — not caught by a downstream tool.
Put it this way: for a C codebase with MISRA C tooling, your certification evidence says “we ran static analysis and fixed 847 rule violations.” For a Rust codebase, it says “the compiler rejected these entire error classes at build time.” That is a fundamentally stronger evidence base for a certification authority.
Is Rust Already Deployed in Production Safety-Critical Systems?
Yes — and this is the question most regulated software teams arrive with, because the answer hasn’t been clearly documented for a software procurement audience.
IEC 62304 Class B medical device deployment. One Rust developer at a medical device company put it plainly: “All of the product code that we deploy to end users and customers is currently in Rust. We do EEG analysis with our software and that’s being deployed to ICUs, intensive care units, and patient monitors.” Production software in intensive care units, under IEC 62304 Class B certification.
IEC 61508 SIL 2 industrial deployment. Sonair is using Ferrocene’s certified core subset to build ADAR — the world’s first safe 3D ultrasonic sensor for autonomous robots. The IEC 61508 SIL 2 certification is the production certification under which the system operates.
Ferrocene qualification milestones:
- January 2025: IEC 62304 Class C qualification assessed by TÜV SÜD
- December 2025: TÜV SÜD certifies Ferrocene’s libcore subset to IEC 61508 SIL 2
- ISO 26262 ASIL D: Qualified, with work underway toward IEC 61508 SIL 4
The Safety-Critical Rust Consortium, hosted by the Rust Foundation, coordinates the standards and tooling work behind these deployments. Members include Arm, Woven by Toyota, AdaCore, OxidOS, Synopsys, HighTec EDV-Systeme, TrustInSoft, and Veecle. That membership list signals deep industrial commitment — not hobbyist interest.
What Are IEC 61508 and IEC 62304 — and Which One Applies to Your Organisation?
IEC 61508 is the foundational functional safety standard for electrical, electronic, and programmable electronic systems. It applies to industrial automation, energy systems, and — relevant to FinTech — payment infrastructure. It defines four Safety Integrity Levels (SIL 1–4), where SIL 4 is most stringent. And it’s not restricted to industrial hardware: a payment card terminal, trading halt mechanism, or market risk control system may fall under its scope depending on a risk analysis of the hazard.
IEC 62304 is the domain-specific derivative for medical device software lifecycle processes. If your software processes clinical data, supports clinical decisions, or influences treatment — SaaS products included — this is the standard that applies. Three software safety classes: Class A (no hazardous contribution), Class B (non-serious injury), Class C (death or serious injury). Class B is the most common for clinical decision support software, and both Class B and Class C have certified Rust deployments today.
ISO 26262 is the automotive derivative defining ASIL A–D levels. Ferrocene is qualified to ASIL D. For HealthTech and FinTech CTOs, this is background context — it demonstrates the breadth of Ferrocene’s qualification across domains, but it’s not a standard that applies to your products.
DO-178C is the aerospace standard. Third-party Rust crate use is severely constrained at higher design assurance levels, and Rust adoption in aerospace is the least mature of the major safety-critical domains.
How Does Rust’s Compiler Replace 90% of What MISRA C Required External Enforcement to Catch?
The “90% figure” refers to the memory-safety-class MISRA C rules that Rust’s ownership and borrow checker enforces at compile time, without external static analysis tooling.
Use-after-free — MISRA C Rule 18.6. The ownership model makes use-after-free a compile-time error. If the data a reference points to is no longer alive, the code doesn’t compile.
Null pointer dereference — MISRA C Rule 11.5. Rust has no null references. The Option<T> type forces every caller to explicitly handle the case where a value might be absent. The compiler won’t allow a null dereference.
Data races — no direct MISRA C equivalent. This is where Rust goes further than MISRA C. The borrow checker prevents simultaneous mutable access across threads at compile time: if your code compiles, it is free of data races.
Buffer overflows. Out-of-bounds access is a runtime panic — defined behaviour, not undefined behaviour.
Uninitialised memory reads — MISRA C Rule 9.1. Rust’s ownership rules flag invalid access before the code runs.
What Rust does not replace. MISRA C also contains rules governing documentation, code review, and traceability — process discipline requirements that remain mandatory regardless of language. Ferrocene handles the compiler qualification component; your team still needs to build and maintain the broader safety case.
What Is the Ferrocene Language Specification and Why Does It Matter for Procurement?
The strongest objection to Rust in regulated software was this: Rust has no formal language specification. Safety standards require the language used in a certified product to be formally specified so compiler behaviour is auditable.
The Ferrocene Language Specification (FLS) closes this gap. It’s a formal, normative specification of the Rust programming language, developed by Ferrous Systems and AdaCore, donated to the Rust Project in March 2025, and now maintained under the Rust Foundation as an official language artefact. Citing the FLS in a procurement document gives Rust the same formal specification standing as Ada and C. The “no language spec” objection is closed.
Ferrocene vs the upstream Rust compiler. The upstream Rust compiler (rustc) is free and widely used — but carries no qualification artefacts. Ferrocene is built on the same infrastructure but adds TÜV SÜD assessment reports, certified test suites, and change histories. It’s 100% compatible with the upstream compiler: no code changes required when switching. Teams certifying a product to IEC 61508, IEC 62304, or ISO 26262 must use Ferrocene — or produce their own compiler qualification evidence, which most regulated teams can’t do internally.
For deeper context on the Ferrocene Language Specification’s ongoing evolution and ecosystem maturity, the ART006 article covers governance and stability.
The Async Rust Caveat Every Regulated Software Team Needs to Know
Async Rust — the async/await syntax and the runtimes that implement it — is widely used for network services, API gateways, and real-time monitoring dashboards. Many regulated software products have exactly these characteristics.
The certification status of async Rust is not the same as synchronous Rust. Ferrocene covers synchronous Rust. Async Rust introduces a runtime — Tokio, Embassy, or similar — that adds complexity the current Ferrocene qualification does not cover. The Rust Foundation’s January 2026 assessment is direct: “The async runtime and qualification story is not settled for higher-criticality use.”
Here’s the practical guidance:
- Use synchronous Rust for the software components that fall under your IEC 62304 classification
- Use async Rust for peripheral, uncertified services — API layers, logging pipelines, monitoring dashboards
- Treat the async/sync boundary as an architectural decision tied to your software safety class, and document it in your architecture decision record
This caveat isn’t disqualifying. Synchronous Rust is available, qualified, and sufficient for most certified components.
For migration planning in regulated environments, including how to structure the certified/uncertified component boundary, the ART005 article covers the practical implementation planning.
What Do the CISA, NSA, and White House Guidance Documents Mean for Regulated Software Procurement?
Memory-safe language adoption has moved from technical recommendation to regulatory pressure. The key documents:
- 2022 (NSA): Urged organisations to shift to memory-safe languages, naming Rust as a preferred option
- June 2025 (CISA/NSA joint guidance): Designated memory-safe languages as preferred for new software development, with C and C++ explicitly framed as memory-unsafe
- White House National Cybersecurity Strategy (2023, updated 2024): References memory-safe language adoption as a national security priority
- DARPA TRACTOR programme: US government-funded research into AI-assisted C-to-Rust translation — the government considers this migration urgent enough to fund at the research agency level
For medical software teams. If your product is sold to US hospital systems or federal health agencies, or processed under HIPAA or FDA oversight, your vendor questionnaires will increasingly include memory safety questions. “We use C with MISRA C compliance” is a weaker answer than “our safety-classified components are written in Rust with Ferrocene qualification.”
For financial infrastructure teams. Memory-safe language adoption is transitioning from a differentiator to a due diligence baseline. Organisations with no documented position will face procurement friction in 2026–2027 RFP cycles.
For Microsoft’s strategic commitment to memory-safe software and what it means for enterprise software broadly, the pillar article provides the full strategic context.
A Framework for Evaluating Rust in Your Regulated Environment
A procurement evaluation checklist, not a migration implementation guide.
Step 1 — Identify your certification obligations. IEC 62304 for medical software. IEC 61508 if your system has functional safety obligations. Classify your components by criticality — not all components in a regulated product share the same classification.
Step 2 — Map component criticality to Ferrocene qualification scope. Ferrocene covers IEC 62304 Class C and IEC 61508 SIL 3. Lower-criticality components can use upstream Rust with a lighter qualification burden.
Step 3 — Evaluate the async/sync split. Implement safety-classified components in synchronous Rust. Route async functionality to uncertified peripheral services outside your certification boundary. Document this in your architecture decision record.
Step 4 — Assess the MISRA C replacement argument. The memory-safety-class rules are enforced by the Rust compiler — the licensing, audit overhead, and deviation record management that covered those rules becomes redundant. What remains is process discipline: documentation, traceability, and safety case arguments.
Step 5 — Reference the FLS and Ferrocene in procurement documents. Cite the Ferrocene Language Specification (maintained under the Rust Foundation) and Ferrocene’s TÜV SÜD certification reports. These give Rust formal specification standing equivalent to Ada and C.
Step 6 — Evaluate the Safety-Critical Rust Consortium roadmap. Members — Arm, Woven by Toyota, AdaCore, Synopsys and others — are driving the standards work that will expand Ferrocene’s qualified scope. The roadmap matters for long-term architectural decisions, particularly for teams evaluating async Rust certification timelines.
The question in 2026 is not whether Rust is a viable certified language — it already is, at the highest criticality levels. The question is timing: which components do you certify first, and how do you build the safety case that uses Ferrocene as its toolchain qualification artefact.
Frequently Asked Questions
Is Rust approved for IEC 62304 Class C — the highest criticality medical device software?
Yes. Ferrocene received IEC 62304 Class C qualification in January 2025, assessed by TÜV SÜD.
Does IEC 61508 apply to FinTech companies, or only to industrial hardware manufacturers?
It applies to any system with functional safety obligations, software-only included. The standard is determined by the consequence of failure, not industry sector — conduct a hazard analysis to find out if you are in scope.
What is the difference between Ferrocene and the standard upstream Rust compiler?
The upstream compiler carries no qualification artefacts. Ferrocene adds TÜV SÜD assessment reports, certified test suites, and change histories — using the same codebase, no code changes required. Regulated teams certifying to IEC 61508, IEC 62304, or ISO 26262 must use Ferrocene.
Is Rust in safety-critical use only at low criticality levels, or has it reached high criticality?
Rust has reached high criticality in production. Ferrocene is qualified to IEC 61508 SIL 3, IEC 62304 Class C, and ISO 26262 ASIL D. These are production qualifications, not research results.
What does the Safety-Critical Rust Consortium actually do?
It coordinates standards work for Rust in certified safety-critical systems, hosted by the Rust Foundation. Members include Arm, Woven by Toyota, AdaCore, OxidOS, Synopsys, HighTec EDV-Systeme, TrustInSoft, and Veecle.
Can I use async Rust in a certified medical device product?
Not yet at higher criticality levels. Synchronous Rust is the certified path. The Embassy async runtime is not yet recommended for higher-criticality applications per the Rust Foundation’s January 2026 assessment.
Does Rust completely replace the need for MISRA C processes in a safety-critical project?
No. Rust’s compiler enforces the memory-safety class of checks — substantially reducing tooling cost — but process discipline requirements remain: documentation, traceability, deviation records, and safety case arguments.
What is the Ferrocene Language Specification and where can I find it?
A formal, normative specification of the Rust programming language, donated to the Rust Project in March 2025 by Ferrous Systems and AdaCore, now maintained under the Rust Foundation. Publicly available in the Rust Project’s official repositories.
How does Rust’s borrow checker specifically address MISRA C rule categories?
It enforces at compile time: use-after-free (Rule 18.6), null pointer dereference (Rule 11.5), data races (no MISRA C equivalent), buffer overflows (defined runtime panic, not undefined behaviour), and uninitialised memory reads (Rule 9.1). Process and documentation rules are not replaced.
What is DO-178C and does Rust apply to aerospace software?
DO-178C is the aerospace software certification standard. Its “own all code” requirement at higher design assurance levels makes third-party Rust crate use impractical without extensive qualification. Rust adoption in aerospace is the least mature of the major safety-critical domains.
Where can I find CISA and NSA guidance on memory-safe programming languages?
The joint CISA/NSA guidance was published in June 2025 and is available on cisa.gov and nsa.gov. The White House National Cybersecurity Strategy (2023, updated 2024) also references memory-safe language adoption as a national security priority.
How does ISO 26262 relate to IEC 61508 and IEC 62304 for a regulated software team?
ISO 26262 is the automotive derivative of IEC 61508, defining ASIL A–D levels. Ferrocene is qualified to ASIL D. For HealthTech and FinTech CTOs, it is background context — demonstrating the breadth of Ferrocene’s qualification, not a standard that applies to your products.
