Security was one of the busiest tracks at RISC-V Summit Europe 2026 — and for good reason. As RISC-V moves from microcontrollers into servers, automotive, and confidential computing, its security model has to scale with it. The good news: because the ISA is open, that model is auditable end to end. Here is how RISC-V security works, from privilege levels to confidential VMs.
Privilege Levels: The Foundation
RISC-V defines a clean hierarchy of privilege modes, the bedrock of all isolation:
- Machine mode (M) — the most privileged. Runs firmware and the SBI (Supervisor Binary Interface). Always present.
- Supervisor mode (S) — runs the OS kernel; manages virtual memory.
- User mode (U) — runs applications, the least privileged.
A minimal microcontroller might implement only M (or M+U). A Linux-capable chip implements M+S+U. The separation is enforced in hardware: lower modes cannot touch higher-mode state, and crossing modes happens through controlled traps.
This is also why RISC-V boot is distinctive: M-mode firmware (OpenSBI) starts first, then hands off to the S-mode kernel — a flow you see directly when booting RISC-V Linux in QEMU.
Physical Memory Protection (PMP)
Not every system has full virtual memory — microcontrollers and secure subsystems often run physical addresses directly. RISC-V’s answer is Physical Memory Protection (PMP).
PMP lets M-mode firmware define a set of address regions and the read/write/execute permissions that S- and U-mode code has for each. It is the standard hardware primitive for:
- Sandboxing untrusted code on an MCU
- Carving out a secure region inaccessible to the OS
- Building trusted execution environments without an MMU
ePMP (enhanced PMP) tightens this further, including restrictions on machine-mode execution itself — important for defense-in-depth.
The Hypervisor Extension (H)
The H extension adds hardware virtualization, introducing guest supervisor (HS/VS) and guest user (VU) modes. This is what lets RISC-V run hypervisors like KVM efficiently, with two-stage address translation isolating guests from each other and from the host.
The H extension is now mandatory in the RVA23 profile — a signal that virtualization is considered table-stakes for application-class RISC-V. I cover RVA23 in RISC-V Profiles and RVA23 Explained. Virtualization is also foundational to the datacenter and cloud story.
The Isolation Toolbox
A recurring Summit theme was that RISC-V offers not one isolation mechanism but a toolbox that composes:
- PMP / ePMP — physical memory regions
- SPMP — supervisor-level PMP for finer S-mode control
- Privilege levels — execution control
- Page-based virtual memory — scalable address isolation
- Hypervisor extension — virtualization
- Worlds / Supervisor Domains — hardware-enforced compartmentalization
These layer to fit everything from a resource-constrained microcontroller to a server running confidential workloads. The emerging Supervisor Domains direction explores finer-grained isolation within supervisor mode itself — moving beyond coarse privilege separation toward modular, composable execution domains.
Cryptography Extensions
Security needs fast crypto. RISC-V provides dedicated extensions rather than leaving it to slow software:
- Scalar crypto (
Zkne,Zknd,Zknh,Zbkb…) — AES and SHA acceleration in the base core. - Vector crypto (
Zvkn,Zvbb…) — crypto built on the vector unit for high throughput. - Entropy source (
Zkr) — a standard interface for hardware random numbers.
And looking ahead, post-quantum cryptography research (well represented in the Summit poster session) is exploring how RISC-V can accelerate lattice-based schemes for future-proof security — including for constrained devices like electronic travel documents.
Confidential Computing on RISC-V
The frontier is confidential computing — protecting workloads so that even privileged software (the hypervisor, the cloud operator) cannot read or tamper with them. RISC-V’s approach builds on the isolation toolbox:
- CoVE (Confidential VM Extension) — a framework for confidential virtual machines, analogous to other vendors’ confidential-VM technologies, layered on the H extension.
- Roots of trust, secure boot, and attestation — increasingly part of the server platform requirements.
- Supervisor Domains — the architectural direction enabling trusted domains beyond the classic M/S/U split.
For sovereignty-sensitive deployments, the ability to audit all of this — because the ISA and much of the firmware are open — is a major advantage, as I discuss in RISC-V and European Digital Sovereignty.
Open ISA, Auditable Security
The deepest security argument for RISC-V is structural: there is no proprietary black box at the ISA level. Researchers can inspect the specification, formally verify implementations (the Summit featured automated functional-safety hardening and Sail-model verification), and build trust from the ground up. Open-source cores like CVA6 and XiangShan extend that transparency into the microarchitecture.
Practical Takeaways
- On MCUs, reach for PMP/ePMP to sandbox code — no MMU required.
- On Linux systems, rely on S-mode virtual memory plus the H extension for virtualization.
- For confidential workloads, track CoVE and Supervisor Domains as they mature.
- Use the crypto extensions instead of hand-rolled software crypto where available.
The Bottom Line
RISC-V security is not a single feature but a composable, open toolbox — privilege levels, PMP, virtualization, compartmentalization, crypto, and confidential computing — that scales from a milliwatt sensor to a confidential cloud VM. As the ISA pushes into high-stakes domains, that openness is its strongest security credential: you can verify it yourself.
Part of my RISC-V series. See also RISC-V Extensions Explained and RISC-V in Automotive and Functional Safety.
