Can RISC-V Survive a Certification Audit?

Open ISA Architecture and the Functional Safety Frontier

At a Glance

From Cosmic Rays to Certification Audits

In our previous analysis of RISC-V in aerospace — examining how the open ISA is being deployed in radiation-hardened, mission-critical hardware — we established that RISC-V could survive the physical hostility of low Earth orbit. The question this article answers is whether it can survive a certification audit.

That is not a rhetorical contrast. It marks a genuine architectural boundary. Aerospace reliability and functional safety certification are related disciplines, but they are governed by distinct regulatory frameworks, distinct verification methodologies, and distinct commercial ecosystems. Surviving a single-event upset from a cosmic ray is a physics problem. Achieving ISO 26262 ASIL-D certification for an automotive braking controller is a process problem — one that involves not just the hardware, but the compiler that generated the firmware, the RTOS that schedules its tasks, and the documentation trail that a TÜV SÜD assessor will scrutinize.

The SELENE project — the EU Horizon 2020 initiative that built a RISC-V-based fault-tolerant multicore platform — is the strongest physical continuity artifact linking these two domains. SELENE explicitly targeted both space-grade reliability and terrestrial IEC 61508 safety certification in a single hardware platform, making it the clearest demonstration that the two problems, while distinct, share an architectural solution space.[^selene-project][^rodriguez-2020]

This article descends from the aerospace reliability question into the harder, less-glamorous problem of functional safety certification: what it requires, where RISC-V currently falls short, and why the research increasingly suggests that the ISA's openness is an asset in this process rather than a liability.

The Certification Landscape: What Safety Standards Actually Demand

Safety-critical systems across automotive, industrial, avionics, and medical domains are governed by a layered stack of standards whose demands are, at their core, variations on a common theme: prove that your system fails safely, and prove that you know how it fails.

The primary standards governing the domains this article addresses are ISO 26262 for road vehicles, IEC 61508 for generic industrial functional safety, DO-178C and DO-254 for avionics software and hardware respectively, and IEC 60880 for nuclear instrumentation software. ISO 26262 stratifies requirements across Automotive Safety Integrity Levels A through D (ASIL-A being least stringent, ASIL-D most stringent). IEC 61508 uses Safety Integrity Levels 1 through 4. The medical device domain adds IEC 62304 for software lifecycle and ISO 14971 for risk management.

What makes these standards demanding for any new processor architecture — and specifically for RISC-V — is the concept of the Safety Element out of Context (SEooC). When a silicon vendor supplies a processor for safety-critical use, the expectation is that it arrives with pre-computed documentation: failure mode and effects analysis (FMEDA) reports, failure-in-time (FIT) rate data derived from qualification testing, and a diagnostic coverage assessment showing what fraction of random hardware faults the safety mechanisms can detect. This package allows a system integrator to incorporate the processor into their own safety case without re-deriving all of the underlying failure data from scratch.

In established ecosystems — ARM Cortex-R for automotive MCUs, PowerPC for avionics — this documentation exists. For RISC-V, it largely does not, at least not at scale. Restuccia et al., in the foundational 2021 treatment of RISC-V for safety-critical systems, formally characterize this gap and make the key argument: RISC-V's open specification enables custom safety mechanism insertion at the microarchitectural level — something closed, black-box IP architectures cannot offer — but this benefit is only realized if verification and testing infrastructure matures in parallel.[^restuccia-2021]

That conditional is where the entire RISC-V safety story lives.

The CVA6 Core: Safety's Reference Design

Any serious engagement with RISC-V safety certification eventually arrives at the CVA6 core, formerly known as Ariane. Developed at ETH Zurich and the University of Bologna, CVA6 is a 6-stage, 64-bit, application-class RISC-V processor implemented as open-source RTL (Register Transfer Level) hardware description. Zaruba and Benini demonstrated a 1.7 GHz implementation of the core in 22-nm FDSOI technology, establishing its performance viability as a genuine application-class processor rather than a toy research artifact.[^zaruba-benini-2019]

What makes CVA6 specifically significant for safety is not its performance but its architecture. It was designed with formal verification hooks built into the microarchitecture from early iterations. It implements the full privileged ISA specification, enabling RTOS environments relevant to safety applications such as FreeRTOS and RTEMS. And crucially, because it is open-source RTL, every internal signal, every pipeline stage, and every state machine transition is available for inspection, modification, and formal analysis — a property that proprietary alternatives cannot match.

Dessì et al. extended the CVA6 analysis by quantifying the overhead cost of inserting hardware safety mechanisms — lockstep execution, ECC, parity — directly into the core's microarchitecture, demonstrating concretely that the open RTL enables safety mechanism integration at the level where diagnostic coverage is maximized.[^dessi-2022]

The OpenHW Group, a nonprofit hardware consortium, has formally adopted CVA6 and initiated a safety-oriented verification program targeting IEC 61508 SIL-2 and ISO 26262 ASIL-B as initial milestones. Whether the qualification program has achieved formal third-party certification as of mid-2026 is currently unverified; the program was active through the research period for this article, but final sign-off timing requires confirmation against OpenHW Group official release notes and the RISC-V International Safety SIG page.[^cva6-repo]

Lockstep Execution: The Dominant Safety Architecture Pattern

The primary hardware-level safety mechanism being adapted for RISC-V is dual-core lockstep (DCLS). The concept is straightforward: two identical processor cores execute the same instruction stream in parallel, offset by one or two clock cycles, and a comparator circuit checks their outputs continuously. Any divergence between the two cores — caused by a random hardware fault, a soft error, or a systematic design flaw — triggers a fault signal that the safety system can act on.

DCLS is not a new idea. ARM's Cortex-R series and Texas Instruments' TMS570 safety MCU family implement it extensively in automotive and avionics applications. The unresolved question for RISC-V was whether the ISA's modularity — the same property that makes it attractive for custom implementations — introduced synchronization complexity that proprietary architectures had already solved internally, behind closed doors.

Cabo et al. answered this question directly in their 2020 DATE Conference paper.[^cabo-2020] Their DCLS implementation on top of a RISC-V core found that the ISA's open RTL actually simplifies comparator integration relative to black-box processor IP. The reason is straightforward: with a proprietary core, you can only compare at the output boundary — the signals the vendor exposes. With open RTL, you can insert comparator logic at any internal pipeline stage, comparing intermediate state vectors as well as outputs, thereby achieving higher diagnostic coverage without additional latency. The area overhead lands at approximately 2× logic, consistent with theoretical expectations for DCLS and with implementations in proprietary architectures — but the diagnostic coverage achievable at that overhead cost is potentially higher with RISC-V because the comparison can be applied deeper in the pipeline.

This is the finding that the broader industry narrative misses. The dominant framing is that RISC-V's openness creates certification liability — multiple implementations, no single reference, fragmented documentation. The Cabo et al. result inverts this: proprietary means harder to verify, not easier. The opacity that makes ARM's Cortex-R feel well-documented is the same opacity that prevents an integrator from inserting safety logic at the microarchitectural level where it would be most effective.

A complementary approach for area-constrained applications is temporal DCLS or time-redundancy: a single core executes the instruction stream twice and compares results, trading silicon area for time overhead. Giuffrida et al. demonstrated selective Triple Modular Redundancy (TMR) for RISC-V processors as a soft-error mitigation strategy, addressing the overlap between the aerospace radiation-hardening problem and the terrestrial functional safety problem — another thread connecting this article to the prior aerospace analysis.[^giuffrida-2022]

Formal Verification: Proof-Based Safety at the ISA Level

Testing is necessary but not sufficient for high-integrity safety certification. At IEC 61508 SIL-3/4 or ISO 26262 ASIL-C/D, standards require formal methods — mathematical proof that the hardware or software behaves according to its specification for all possible inputs, not merely the tested subset. This requirement is where RISC-V's architectural properties become genuinely distinctive.

The RISC-V Sail model is a formal, executable specification of the RISC-V ISA written in the Sail ISA description language developed at the University of Cambridge.[^sail-model] Armstrong et al. demonstrated in their POPL 2019 paper that the Sail framework can produce machine-checked formal specifications for RISC-V (alongside ARMv8-A and CHERI-MIPS), enabling a mathematically grounded reference against which hardware implementations can be formally compared.[^armstrong-2019]

The significance for safety certification is direct: the Sail model provides a golden reference that is machine-verifiable. A hardware implementation of a RISC-V core can be formally proved to conform to the Sail specification; any deviation is a certification-relevant finding. Proprietary ISAs have no equivalent. Their specifications are prose documents, subject to interpretation, with ambiguities that make formal comparison between spec and silicon impossible to automate.

This formal specification infrastructure is what makes the CHERI-RISC-V extension particularly relevant to safety-critical contexts. CHERI (Capability Hardware Enhanced RISC Instructions) adds hardware-enforced memory safety at the ISA level — spatial and temporal memory protection, compartmentalization — that maps directly onto the isolation requirements of mixed-criticality systems where ASIL-D and quality-managed (QM) code share silicon.[^watson-cheri-2019] The CHERI-RISC-V work, supported by DARPA's MORPHEUS program and the UK government's Digital Security by Design initiative, is discussed further in the forward-looking section below.[^darpa-morpheus][^dsbd]

Mixed-Criticality Systems: The SoC-Level Problem

Modern safety-critical SoCs do not run a single application at a single criticality level. An automotive SoC might simultaneously execute an ASIL-D electronic stability control task, an ASIL-B ADAS perception pipeline, and a QM infotainment stack. A fault or timing violation in a lower-criticality partition must not propagate to or starve resources from a higher-criticality partition. This is the Mixed-Criticality Problem, and it is arguably the hardest systems engineering challenge in automotive silicon design.

RISC-V provides natural isolation primitives through its hardware privilege levels (M-mode / S-mode / U-mode) and Physical Memory Protection (PMP) mechanism. Research on extending these for mixed-criticality workloads is active. Martínez et al. present a hardware/software approach for real-time isolation on RISC-V using PMP and hardware performance monitoring extensions to enforce both spatial and temporal isolation between criticality partitions. [^martinez-2023] Note: The Martínez et al. 2023 IEEE paper citation is drawn from the research dossier and has not been independently confirmed beyond that source; readers should verify the full citation against IEEE Xplore.

The ratified RISC-V Hypervisor Extension v1.0 adds hardware-assisted virtualization, enabling hypervisor-based isolation between mixed-criticality workloads on a single core.[^riscv-hypervisor] Whether any commercial automotive RISC-V SoC has achieved ISO 26262 ASIL-D certification for a mixed-criticality configuration as of mid-2026 is currently unverified; multiple vendors including Andes Technology, SiFive, and Nuclei System Technology have announced roadmaps, but certification status requires verification against official vendor announcements or assessor records from bodies such as TÜV SÜD or SGS-TÜV Saar.[^uv-02]

The Hypervisor Extension is architecturally significant because it enables a clean separation between the hypervisor safety domain and the guest OS domain at the hardware level, rather than relying solely on software-based partitioning. For safety cases, hardware-enforced isolation reduces the verification burden on the software partitioning layer — each hardware-enforced boundary is a fault that the software no longer needs to detect and handle.

The Medical and Industrial Frontiers

Medical Devices: IEC 62304 and the Open ISA Advantage

RISC-V's relevance to medical device applications emerges through two vectors. The first is ultra-low-power sensing: GreenWaves Technologies has deployed RISC-V GAP architecture in wearable medical sensing applications, as demonstrated in the GAP-8 SoC designed for AI inference at the edge of IoT and medical wearables.[^flamand-2018]

The second vector is more architecturally significant: independent third-party formal verification of implantable device firmware. Because the full RISC-V ISA semantics are publicly available, tool developers can build formal verification tools without negotiating access to proprietary ISA documentation. For Class III medical devices — implantables, life-sustaining equipment — where the FDA's scrutiny of Software as a Medical Device (SaMD) is intensifying, the ability to independently verify firmware behavior against a machine-checkable ISA specification has concrete certification value. Whether any specific FDA 510(k) or PMA clearances citing RISC-V processor use have been granted as of 2026 is not confirmed; this is an active tracking task requiring a direct search of the FDA 510(k) database.

Industrial Control: The IEC 61508 PLC Frontier

Programmable Logic Controllers and industrial safety controllers are governed by IEC 61508, the foundational functional safety standard from which most sector-specific derivatives — ISO 26262, EN 50128 for rail — are drawn. The push toward IEC 61508 SIL-3 certified RISC-V-based safety controllers is most active in European research, driven in part by EU Chips Act funding.

The SELENE project (Horizon 2020, 2019–2022) remains the clearest demonstration of RISC-V's potential in this domain. Its explicit goal was a RISC-V-based multicore platform for mixed-criticality applications in both space and industrial domains, bridging space-grade reliability requirements and terrestrial safety standards in a single hardware architecture — the most tangible expression of the continuity between the aerospace reliability problem and the functional safety certification problem.[^selene-project][^rodriguez-2020]

The Toolchain Gap: The Problem Nobody Is Talking About

A processor core is only as certifiable as the tools that compile code for it. For safety-critical systems, tool qualification is mandatory under every major standard: you must demonstrate that the compiler, linker, and debugger do not introduce errors into the system under certification. This requirement applies to the entire toolchain, not just the silicon.

The RISC-V toolchain landscape presents a clear gap. The GCC riscv-gnu-toolchain — the most widely deployed RISC-V compiler — is unqualified for safety use. LLVM's RISC-V backend is more modular and some vendors have pursued partial qualification, but full qualification at ASIL-D or SIL-3 levels does not exist at the maturity of established alternatives such as the Green Hills INTEGRITY RTOS and compiler stack for ARM Cortex-R. IAR Systems has announced RISC-V support for Embedded Workbench, and TASKING (Altium) is an established automotive C compiler vendor, but the full safety qualification status of both for RISC-V remains unverified as of this writing.[^rtems-riscv][^benedetti-2023]

The RTEMS real-time operating system has an active RISC-V port — RTEMS has established heritage in space applications, and a Safety Certification Profile is in development. Its trajectory is the most credible near-term path toward a qualified RTOS for RISC-V safety applications.

Benedetti et al. address this directly in their 2023 work on a certified RISC-V toolchain for safety-critical systems.[^benedetti-2023] Researchers at BSC and ETH Zurich have expressed the view, in the context of this body of work, that compiler qualification represents a more significant near-term bottleneck than the hardware certification gap: silicon can be taped out with safety mechanisms; a qualified compiler stack for RISC-V safety MCUs does not yet exist at the maturity level that safety-critical integrators require. This is a researcher opinion drawn from the literature rather than a citable empirical finding in its own right, and should be read as such.

The risk profile is real. A hardware team can demonstrate a DCLS-protected CVA6 core with formal verification against the Sail model. Without a qualified compiler to generate the firmware that runs on it, the system cannot achieve high-integrity safety certification regardless of the silicon's properties. The toolchain is the last mile, and it remains unpaved.

Patent Landscape: Fragmented but Directional

The patent landscape around RISC-V safety mechanisms is less consolidated than the ARM or MIPS-era safety IP ecosystem, but several clusters indicate where commercial investment is concentrating.

Lockstep and Redundant Execution. US Patent 11,080,157, assigned to Western Digital, describes a configurable dual-execution mode enabling a single RISC-V processor to switch