RISC-V Sovereign Open Hardware for European Regulated Sectors

Processor architecture is a sovereignty question, not merely a performance question. When a regulated European organisation runs its workloads on a CPU designed and manufactured under foreign jurisdiction, it accepts that the firmware, microcode and hardware security features of that processor were developed outside its legal reach, audited (if at all) by bodies it does not control, and subject to export-control regimes it cannot influence. The RISC-V ISA (Instruction Set Architecture) is an open, royalty-free specification that changes this equation by allowing European organisations, chipmakers and public-sector buyers to specify, audit and eventually manufacture a CPU architecture without a licensing dependency on any single vendor or jurisdiction.

Why CPU Architecture Is a Data Sovereignty Problem

Supply-chain risk in server hardware runs deeper than where a chassis is assembled. It lives in the microcode, the firmware, the management engine and the undocumented hardware features that operating systems and hypervisors cannot inspect.

Approximately 90% of server CPUs shipped in 2023 were x86 architecture, according to IDC Worldwide Server Tracker data published in 2024, meaning they originate from Intel or AMD, both headquartered in the United States. ARM Holdings, which licenses the architecture used in a growing share of cloud and edge silicon, is incorporated in the United Kingdom and owned by Japan’s SoftBank, but its architecture licences remain subject to US export-control law because of the technology’s US-origin content. For a European hospital, a national tax authority or a systemically important financial institution, this creates three concrete problems.

First, the US Export Administration Regulations (EAR) and the International Traffic in Arms Regulations (ITAR) give US authorities leverage over the supply of advanced silicon to entire categories of buyers, as demonstrated by the successive rounds of semiconductor export controls applied from 2022 onward. Second, the Intel Management Engine and AMD Platform Security Processor are always-on subsystems with ring-minus-3 access to system memory, and their firmware is proprietary and not subject to independent security audit by European authorities. Third, NIS-2 Article 21 requires essential and important entities to manage supply-chain security risks, including hardware vendors and their security practices. A CISO who cannot obtain the source code or audit logs for the firmware running on production servers has limited ability to meet that obligation in a documentable way.

What RISC-V Is and What EU Projects Are Building on It

The RISC-V ISA is a free and open instruction-set architecture, originally developed at UC Berkeley and now governed by RISC-V International, a non-profit incorporated in Switzerland. The specification is publicly available, extensions are ratified through an open process, and no entity holds a proprietary gate over its use. RISC-V International reported more than 4,000 members across 70 countries as of 2023, reflecting broad industrial and governmental engagement rather than a niche academic exercise.

The EU has funded several projects that translate the open ISA into deployable infrastructure:

RISER (Horizon Europe) is particularly relevant for regulated cloud buyers because its scope includes full-stack integration: RISC-V processors running Linux, KVM and OpenStack-compatible workloads, with the explicit goal of demonstrating that commodity cloud software can run on European-designed silicon without re-engineering. DARE (EuroHPC JU) targets the higher-end HPC segment and is relevant for scientific and public-sector computing infrastructure where large-memory and floating-point workloads dominate. Neither project has produced commercially available server products as of mid-2024, but both have working silicon and reference platforms that procurement officers can reference when engaging with vendors.

As Luca Benini, Professor of Digital Circuits and Systems at ETH Zurich and University of Bologna and co-architect of the PULP RISC-V platform, stated at RISC-V Summit Europe 2023: “Open-source hardware is the next logical step after open-source software. If you cannot inspect and verify the silicon, your software security guarantees rest on an unaudited foundation.”

Evaluating RISC-V Against Proprietary Alternatives: Sovereignty Assurance Criteria

Procurement officers comparing RISC-V options against Intel- or AMD-based alternatives should apply structured sovereignty criteria rather than generic performance benchmarks alone.

The ENISA Cloud Cybersecurity Market Analysis and the emerging EU Cloud Sovereignty Framework SEAL criteria identify hardware control as a distinct assurance dimension. A practical evaluation framework draws on three axes: jurisdictional independence (is the hardware supply chain free from non-EU export-control leverage?), auditability (can the firmware, microcode and hardware security documentation be reviewed by the buyer or a trusted third party?), and operational continuity (can the buyer obtain replacement hardware and security patches without dependency on a single foreign vendor?). RISC-V hardware, once available from EU-based foundries, scores strongly on the first two axes. Until EU-manufactured RISC-V server silicon is broadly available, buyers must weigh the current maturity gap against the strategic dependency of locking in x86 infrastructure on multi-year contracts.

Firmware, Boot-Chain and TPM Controls for Open Hardware

Hardware sovereignty is not established by processor architecture alone. A RISC-V server with an unverified boot chain offers no meaningful sovereignty advantage over a proprietary x86 server. Regulated workloads require a hardware root-of-trust that can be independently verified.

The minimum controls for servers hosting data subject to GDPR Article 32, NIS-2 Article 21 or DORA Article 9 are: a TPM 2.0 module conforming to ISO/IEC 11889:2015, a measured and verified boot chain (either UEFI Secure Boot with auditable keys, or an open-firmware implementation such as coreboot with verified boot), remote attestation capabilities so that infrastructure orchestration layers can verify boot-chain integrity before scheduling workloads, and firmware update processes that are authenticated, logged and reversible. On RISC-V platforms specifically, the OpenTitan project (lowRISC, Cambridge) provides an open-source silicon root-of-trust design whose RTL code is publicly auditable. This is a qualitative improvement over proprietary TPMs, where the internal logic is not available for inspection.

Chips Act 2.0 and KDT JU: The Commercial Availability Timeline

The European Chips Act, in force since September 2023, establishes a EUR 43 billion mobilisation target for the European semiconductor ecosystem by 2030, combining public investment with matched private capital. The Act creates three pillars: a research and innovation pillar (the Chips for Europe Initiative), a supply security pillar supporting new or expanded fabrication capacity, and a monitoring and crisis response pillar.

The Key Digital Technologies Joint Undertaking (KDT JU), which co-funds TRISTAN and ISOLDE among other RISC-V-related projects, bridges the gap between research silicon and industrialised production by funding projects that develop reusable IP, design tools and process design kits compatible with European foundry processes. The European Commission’s Directorate-General for Internal Market, Industry, Entrepreneurship and SMEs has noted: “The European Chips Act provides the legal and financial framework, but the real sovereignty dividend comes when European organisations can specify the hardware architecture in their procurement contracts and have domestic suppliers who can fulfil that specification.”

A realistic timeline based on current project roadmaps and foundry investment announcements places broadly available, commercially supported RISC-V server products from EU-based manufacturers in the 2027 to 2029 window. This is not a reason to defer planning: it is a reason to begin qualification testing, engage with RISER and DARE project outputs now, and structure current tenders to include RISC-V evaluation criteria so that procurement cycles align with product availability.

Procurement Language for Open and Auditable Hardware

EU procurement law under Directive 2014/24/EU prohibits specifying brand names but permits detailed technical requirements. Regulated buyers can include the following in tender specifications without violating non-discrimination principles:

Require that all CPU firmware and microcode be published under an OSI-approved open-source licence or be available for third-party security audit under a binding contractual arrangement with the contracting authority. Require that hardware security documentation, including threat models and security boundary definitions, be submitted as part of the technical offer and subject to assessment by the buyer’s security team or a nominated auditor. Require that the instruction-set architecture have no mandatory proprietary extensions that are not fully publicly documented, effectively requiring ISA openness without naming RISC-V. Require that the supplier provide a written statement of the export-control jurisdiction governing the hardware’s core IP, enabling buyers to assess jurisdictional risk explicitly. Require a documented supply-chain continuity plan covering how the buyer receives security patches and replacement hardware if the primary vendor is subject to trade sanctions or market exit.

These requirements are architecture-neutral in their legal form but operationally favour open, auditable designs. They also create a documented compliance trail that supports NIS-2 Article 21 supply-chain risk management obligations and DORA Article 28 ICT third-party risk assessments.

FAQ

Is RISC-V hardware ready for production deployment in regulated EU environments today?

Not at scale for general enterprise workloads. As of 2024, RISC-V server silicon is at TRL 6-7 for HPC workloads in projects such as DARE and RISER, meaning prototype and pre-production systems exist but broadly available, support-contracted server products are still two to four years away for most regulated buyers. Organisations should begin proof-of-concept procurement and embed RISC-V preference language in tenders now to influence the supply chain.

Does using RISC-V hardware automatically resolve CLOUD Act or FISA 702 jurisdictional exposure?

Hardware architecture alone does not determine jurisdictional exposure. A RISC-V server running in a US-owned data centre is still subject to US court orders. Sovereignty requires the combination of open hardware, EU-based hosting, EU-controlled operational staff and EU-governed software. RISC-V removes the microcode and firmware dependency on US vendors, which is one important layer of the overall sovereign stack.

What is the difference between RISER, DARE, OpenCUBE, TRISTAN and ISOLDE?

These are distinct but complementary EU-funded projects. RISER (Horizon Europe) targets RISC-V for cloud and edge server infrastructure. DARE (EuroHPC JU) focuses on high-performance computing processors. OpenCUBE addresses open-source cloud building blocks including RISC-V acceleration. TRISTAN and ISOLDE, both supported by the Key Digital Technologies Joint Undertaking (KDT JU), work on RISC-V chip design toolchains and industrial-grade IP cores. Together they cover the full stack from silicon IP to deployable systems.

How does a procurement officer reference open hardware requirements in a tender without violating EU procurement law?

Procurement rules under Directive 2014/24/EU prohibit naming specific brands but permit specifying technical characteristics. Officers can require that CPU firmware and microcode be fully published under an OSI-approved licence, that hardware security documentation be submitted for third-party audit, and that the instruction-set architecture have no single-vendor proprietary extensions that are not publicly documented. These criteria are architecture-neutral in letter but effectively prefer open ISA designs such as RISC-V.

What TPM and secure-boot requirements apply to RISC-V servers hosting data classified under NIS-2 or GDPR Article 32?

Regardless of CPU architecture, servers hosting high-sensitivity regulated data should implement a hardware root-of-trust using a TPM 2.0 module (ISO/IEC 11889:2015), measured boot with UEFI Secure Boot or an equivalent open-firmware chain such as coreboot with verified boot, and remote attestation so that the infrastructure management layer can verify boot-chain integrity before workloads are scheduled. On RISC-V platforms, the OpenTitan project provides an open-source root-of-trust silicon design that is auditable in a way proprietary TPMs are not.