The one place where “open” is a security feature
RISC-V security tends to trip people over one instinct: surely open hardware is easier to attack? It is the exact opposite, and understanding why is the key to the whole subject. A design you can inspect is a design you can trust, and RISC-V pairs that openness with a proper toolkit of hardware protections.
Open is not the weakness you think it is
The nervous question always comes up. If anyone can read the design, does that not hand attackers a map? It feels right and it is wrong, and cryptographers settled the argument well over a century ago. Kerckhoffs’s principle says a system should stay secure even if everything about it except the keys is public. Security that depends on nobody looking is not security, it is a bluff waiting to be called.
Closed silicon asks you to take two things on faith: that the security actually works, and that nobody slipped a backdoor into the parts you cannot see. Open silicon lets you check both. That is not a consolation prize for going open, it is the single strongest security argument RISC-V has, and it is why the flagship open root-of-trust project exists at all.
OpenTitan: trust you can read
OpenTitan is an open-source silicon root of trust, built on a RISC-V core, designed from the start to be transparent and auditable. It provides the things every secure device needs at its foundation: an immutable secure-boot ROM, cryptographic engines, and a key manager that guards the device’s secrets. The difference from a conventional secure element is simply that the design is out in the open for anyone to scrutinise, which for a component whose entire job is to be trustworthy is a rather large difference.
The counterintuitive bit, plainly: “open means insecure” is backwards. A closed chip asks you to trust that its security works and that nobody left a backdoor. An open one like OpenTitan lets you verify it. That is Kerckhoffs’s 1880s principle rendered in silicon, security by verification rather than by obscurity.
The hardware toolkit
Underneath the philosophy sits real machinery. The foundation is Physical Memory Protection, the mechanism that lets the most privileged code wall off regions of memory so nothing else can touch them. On top of that, the hypervisor extension, now mandatory in RVA23, allows trusted and untrusted software to run on the same core with hard separation between them. The crypto extensions accelerate the maths of AES, SHA and their kin, both in scalar and vector form. And newer control-flow-integrity features, landing pads and a shadow stack, blunt whole classes of exploit at the hardware level.
Together these give a device a chain of trust: a root of trust verifies the first code that runs, that code verifies the next, and so on, so the machine only ever executes software it can prove is genuine. Secure boot built this way is no longer optional either, since recent IoT security frameworks treat it as a baseline requirement for any device claiming to be reasonably secure.
The layers, and where RISC-V provides them
| Layer | What it does | RISC-V mechanism |
|---|---|---|
| Isolation | Walls off memory between tasks | Physical Memory Protection (PMP) |
| Separation | Trusted and untrusted worlds on one core | Hypervisor extension, WorldGuard |
| Cryptography | Fast AES, SHA and signing | Scalar and vector crypto extensions |
| Exploit defence | Stops control-flow hijacking | Landing pads, shadow stack (CFI) |
| Root of trust | Verifies the first instruction on | OpenTitan, secure-boot ROM |
| Secure execution | Isolated enclaves for secrets | Keystone, MultiZone TEEs |
An honest caveat sits in that last row. RISC-V never had a single standard equivalent to Arm’s TrustZone, so trusted execution is a spread of open projects rather than one tidy answer. That is messier for now, but it is open and maturing fast, and the mandatory hypervisor gives the newer designs a firmer footing.
Identity: the other half of trust
Protecting a device is only useful if you also know which device it is. That is where the secure element earns its keep, holding the keys and credentials that give a device a provable identity. For anything on a cellular network, that identity increasingly lives in an eUICC, the embedded secure element that replaces the removable SIM and stores network credentials safely on the chip.
At fleet scale, those identities have to be issued and switched remotely, because nobody is visiting ten thousand deployed sensors to swap a SIM. The SGP.32 eSIM provisioning standard handles exactly that, letting operators provision and manage credentials over the air. Put it together and you have the full picture: an open, auditable root of trust on the device, a secure element holding its identity, and a standard way to provision that identity across a whole deployment. That trust foundation is what the harsher environments in industrial IoT and the mass consumer scale of Matter smart-home devices both depend on, and it underpins the whole argument of the RISC-V and IoT cornerstone.
Last updated 23 August 2026. Sources: RISC-V security building blocks including Physical Memory Protection, the hypervisor extension and scalar/vector crypto extensions per RISC-V International; open-source TEE frameworks such as Keystone (Berkeley), with commercial approaches including WorldGuard (SiFive) and MultiZone (Hex Five), per academic surveys, 2025-2026; OpenTitan open-source silicon root of trust built on a RISC-V Ibex core per the OpenTitan project and lowRISC; control-flow-integrity options (landing pads, shadow stack) in the RVA23 profile per RISC-V International.
