An open instruction set, customizable processors, less dependence on a single supplier: RISC-V has plenty to appeal to manufacturers and governments concerned about digital sovereignty. But the journey from downloading a specification to delivering a reliable chip remains long, expensive and fraught with dependencies. Openness provides design freedom; it does not deliver independence in a kit. Looking ahead to September 2026, the credibility of these promises will hinge on this distinction. The trajectories discussed here remain projections, based on developments already established.
What is open, and what is not
Created at the University of California, Berkeley, in 2010, RISC-V is an instruction set architecture, or ISA. In other words, it is the basic vocabulary that software uses to ask a processor to perform calculations, move data or execute a branch. This interface does not describe all the machine’s internal workings: two compatible processors can differ significantly in performance, power consumption and organization.
The RISC-V specification can be used without paying royalties for the instruction set itself. Its governance is overseen by RISC-V International, an association based in Switzerland. Contrary to a common misconception, this does not automatically make processors that implement it open source. A RISC-V core can be sold under a proprietary license, complete with a contract, access restrictions and a bill. Others are released under open licenses, which does not necessarily guarantee their readiness for industrial use.
Freedom that already appeals to industry
The interest is not theoretical. Companies such as SiFive and Andes sell RISC-V cores. Espressif has integrated them into several microcontrollers in its ESP32 family. The European PULP project explores open, energy-efficient architectures. In 2023, Qualcomm, Bosch, Infineon, Nordic Semiconductor and NXP announced a joint venture dedicated to RISC-V, which became Quintauris, with the automotive sector as its initial focus.
These initiatives illustrate a concrete advantage: choosing a common architecture while tailoring the processor to a particular task. A sensor controller does not have the same requirements as a computing accelerator. RISC-V offers a modular foundation and allows specialized extensions. For a manufacturer, this flexibility can reduce certain contractual constraints and support a long-term strategy. It does not, however, guarantee better energy efficiency or lower costs: everything depends on the implementation.
The real costs begin after the specification
Imagine a small or medium-sized company that wants to design a processor for an industrial camera. The instruction set is merely its starting point. It must select or develop a core, organize memory, add interfaces, secure the boot process and then verify that everything works together. A rare error, triggered by a particular combination of events, can become catastrophic once thousands of devices have been deployed.
Verification therefore requires substantial staffing and resources: simulations, compliance tests, formal methods and prototypes. Physical design, power consumption analysis and preparation for manufacturing come next. Electronic design automation tools remain dominated by companies such as Synopsys, Cadence and Siemens EDA. Open alternatives exist, notably those built around OpenROAD, but their suitability depends on the manufacturing process and the project’s complexity.
These expenses are compounded by peripheral intellectual property blocks: memory controllers, high-speed interfaces and analog functions. These may be proprietary even when the core is open. Saving on an architecture license therefore does not mean eliminating licenses, let alone salaries, development lead times or the risk of another manufacturing run after a correction.
The factory remains unavoidable
A RISC-V chip has to be fabricated somewhere. Like any other chip, it depends on foundry capacity, equipment, materials, and assembly and testing services. For the most advanced processes, options remain concentrated among a small number of manufacturers, including TSMC, Samsung and Intel, depending on the technologies and services available. Changing the instruction set does not change this geography.
There is, however, an essential distinction: not every application requires the smallest process nodes. An industrial microcontroller may favor a proven process that will remain available for a long time and meets its requirements. RISC-V can then support a more localized production strategy. But this possibility depends on the existence of a complete industrial ecosystem, not on some magical property of the architecture.
Trade restrictions and export controls can also affect tools, machinery or manufacturing. An accessible specification does not neutralize them. For a government, RISC-V can diversify an upstream dependency without eliminating those that remain downstream.
Software: less visible work, but decisive
For its users, a processor only truly exists when their programs run correctly. RISC-V already has solid support in Linux, GCC and LLVM. This is an important foundation, but having a compiler and a kernel is not enough. Drivers, optimized libraries, debugging tools and robust update mechanisms are also needed.
In an embedded device, the manufacturer often controls a small software stack, so migration can remain limited in scope. On a personal computer or a general-purpose server, the challenge takes on a different scale. Proprietary applications, runtime environments and legacy software each require work. RISC-V compatibility alone does not indicate whether a program makes efficient use of a given processor.
Modularity also creates a risk of fragmentation. A specific extension can accelerate a function but complicate portability if it becomes indispensable to the software. Standardized profiles and extensions are intended precisely to give developers common targets. The freedom to customize must coexist with the discipline of standardization.
Measuring autonomy rather than proclaiming it
For a public-sector buyer or a manufacturer, the right question is therefore not simply: “Is it RISC-V?” They must ask who owns the hardware description, who can modify it, who handles maintenance and what alternatives exist if a service provider disappears. An open core without usable documentation or in-house expertise can still represent a very tangible dependency.
The audit must also cover security. Openness facilitates inspection when the hardware code is actually accessible; it does not prove the absence of vulnerabilities. Quality depends on the reviews conducted, the safeguards built in and the ability to fix flaws. Finally, comparing offerings requires consideration of the full cost: development, certification, software porting, manufacturing and support throughout the product’s lifetime.
What next? Looking ahead to September 2026, the most plausible path for RISC-V would be selective growth: more controllers, embedded systems and specialized components, rather than a wholesale replacement of established architectures. Its main contribution could be to make certain choices negotiable and certain designs controllable. Turning this openness into lasting autonomy will require investment in skills, tools, production and software maintenance. The instruction set opens a door; the entire industrial supply chain still needs to be built or secured.
