zeroRISC
Every zeroRISC platform explanation eventually leads to the same question: "What is OpenTitan, and why does zeroRISC build on it?" It is a fair question. OpenTitan is not a household name even in hardware security circles, but it represents one of the most important developments in silicon security of the past decade. Understanding what it is and why it matters provides the context to understand what zeroRISC is doing and why the approach is different from anything that came before.
What Is a Root of Trust?
Before explaining OpenTitan, it is worth being precise about what a "root of trust" actually is, because the term is overloaded in security marketing.
A root of trust (RoT) is a hardware component that is trusted by assumption, not by proof. Every security architecture requires a foundation that is simply assumed to be correct — at some point, the chain of verification has to stop. In a computer system, the root of trust is the component that everything else ultimately derives its trust from. If the root of trust is compromised, every security guarantee built on top of it is invalid, regardless of how sound the rest of the architecture is.
In practical terms, a silicon root of trust typically provides: a secure identity (a unique, hardware-bound cryptographic key that cannot be extracted), a verified boot mechanism (the ability to cryptographically verify firmware before executing it), a set of cryptographic primitives (hardware-accelerated AES, SHA, ECDSA, and similar), and an attestation capability (the ability to generate a signed report about the device's current security state). The hardware security module in modern phones, the TPM in enterprise laptops, the Secure Enclave in Apple Silicon — these are all examples of hardware roots of trust.
What Makes OpenTitan Different
Before OpenTitan, every commercial hardware root of trust was proprietary. The Infineon TPMs, the NXP SE05x family, the Apple Secure Enclave — all are closed-source hardware implementations. Their security claims rest on their vendor's reputation and third-party certification, not on public auditability of the design itself.
OpenTitan, launched by Google in 2019 as an open-source project under the OpenTitan coalition (which includes ETH Zurich, lowRISC, G+D Mobile Security, and others), was designed from first principles as a fully open-source hardware root of trust. The register-transfer level (RTL) hardware description is public. The firmware is public. The threat model is published. The security architecture review history is available. Every cryptographic interface is documented.
This matters for several reasons that go beyond philosophical preference for open source:
Independent auditability: OpenTitan has been reviewed by security researchers, academic institutions, and enterprise security teams in ways that proprietary implementations simply cannot be. When OpenTitan makes a security claim — "this key cannot be extracted without destroying the chip" — that claim can be independently verified by examining the RTL. When a proprietary HSM makes the same claim, you are trusting the vendor.
Vulnerability discovery by defenders: Open-source hardware security designs have their flaws found by the security community, which can then fix them. Proprietary designs have their flaws found by adversaries, who do not publish them. The history of proprietary hardware security architectures that were "secure" until they were publicly reverse-engineered is long and instructive.
No vendor lock-in: Because the RTL is open, OpenTitan can be implemented by any silicon vendor. This means customers are not dependent on a single silicon vendor's continued support, pricing decisions, or corporate decisions. For critical infrastructure applications with 15-20 year deployment horizons, this matters enormously.
OpenTitan's Architecture
OpenTitan is built around a RISC-V CPU core (the Ibex core, developed by ETH Zurich and lowRISC). This is not a coincidence — RISC-V's open architecture and OpenTitan's open security design are philosophically and practically complementary. Using a proprietary ISA at the core of an open-source security design would introduce an auditing gap precisely where auditability matters most.
The OpenTitan hardware block includes the Ibex RISC-V core, hardware-accelerated cryptographic modules (AES, SHA, HMAC, KMAC, RSA, ECDSA), a key management unit with hardware key derivation, Physical Unclonable Function (PUF) interfaces for hardware-unique identity, alert and watchdog mechanisms, and a secure boot ROM. These components are designed to work together as an integrated security subsystem that can be embedded in a larger SoC design.
The key provisioning model uses a hierarchical key structure derived from the PUF. The root key is never exposed outside the hardware security block; all higher-level keys are derived from it using hardware key derivation functions. This means that even with physical access to the device and knowledge of the key derivation algorithm (which is public, as part of the open architecture), an adversary cannot derive the root key without access to the specific PUF response of that exact silicon die.
What zeroRISC Adds
OpenTitan is a hardware design — specifically, an IP block intended to be integrated into a larger SoC. It is not a complete enterprise security platform. The gap between "hardware security IP block" and "enterprise-deployable security infrastructure for RISC-V fleets" is large and requires substantial engineering work that is distinct from the hardware design itself.
zeroRISC closes that gap. Our platform extends OpenTitan's hardware root of trust with the software infrastructure required for production deployment: the attestation service that fleet operators use to verify device integrity at scale, the SDK that firmware engineers use to integrate root of trust functionality into RISC-V applications, the key management infrastructure that handles device identity throughout the device lifecycle from manufacturing to end-of-life, and the fleet management console that gives operators visibility into the security posture of their entire device fleet.
Importantly, we extend OpenTitan's open-architecture philosophy into the software layer. The attestation protocols we implement are based on open standards (TCG DICE, IETF RATS). Our SDK is designed against documented interfaces that customers can audit. The threat model for our full stack is published. We are not adding a proprietary black box on top of an open hardware foundation.
Why This Matters for RISC-V Teams
For hardware teams building on RISC-V, the combination of OpenTitan's open silicon root of trust and zeroRISC's enterprise platform creates something that has not previously existed: a fully open, fully auditable, enterprise-ready security stack for RISC-V embedded systems.
This is not just about technical merit. It is about what enterprise customers and regulatory bodies increasingly require. The EU Cyber Resilience Act, NIST's IoT security guidance, and enterprise procurement requirements in regulated industries are all converging on the same expectation: hardware security claims need to be verifiable, not just asserted. Open architecture makes verification tractable. Proprietary architecture makes it impossible.
OpenTitan changed what was possible for hardware root of trust design. zeroRISC is building the infrastructure to make that possibility accessible to every RISC-V hardware team, without requiring each team to independently solve the engineering problems between "hardware security IP" and "production enterprise deployment."
Want to learn more about OpenTitan and the zeroRISC platform? Explore the platform overview or contact the team.