zeroRISC
NIST finalized its first post-quantum cryptography standards in August 2024 — ML-KEM (CRYSTALS-Kyber), ML-DSA (CRYSTALS-Dilithium), and SLH-DSA (SPHINCS+). The standards are now definitive, and the industry migration has begun. For software systems, the migration path is challenging but tractable: update the cryptographic libraries, update the protocols, redeploy. For hardware systems, particularly embedded systems with decade-long deployment lifetimes, the problem is considerably more complicated.
The challenge is not that post-quantum algorithms are difficult to implement on hardware. RISC-V's extensible ISA provides a natural path to hardware acceleration for lattice-based cryptography. The challenge is that embedded devices already in the field may be running hardware security implementations — roots of trust, key provisioning infrastructure, attestation protocols — that are deeply tied to classical cryptographic primitives. Migrating those systems to post-quantum algorithms requires not just software updates but hardware changes that, for already-deployed silicon, are simply not possible.
This is why post-quantum readiness for hardware is not a future problem. It is a present design decision. Hardware teams designing RISC-V systems today that will be deployed for the next five to fifteen years are making commitments that will determine whether those systems can be migrated to post-quantum cryptography when the need becomes urgent — which NIST, NSA, and virtually every major standards body say will happen within a decade.
What "Harvest Now, Decrypt Later" Means for Embedded Hardware
The immediate quantum threat to encrypted data is the "harvest now, decrypt later" attack: adversaries with the motivation to do so are collecting encrypted communications today, with the plan to decrypt them once cryptographically-relevant quantum computers exist. For data with long-term confidentiality requirements, this is an active threat today, not a future threat.
For embedded hardware systems, the relevant attack surface is not encrypted communications per se but the cryptographic keys that underpin device identity and firmware integrity. If an adversary can harvest the attestation evidence from a fleet of embedded devices today, and later decrypt the key material that anchors device identity, they gain the ability to forge attestation reports and impersonate legitimate devices. For critical infrastructure applications, this is not a theoretical risk.
The implication is that hardware security systems designed today for high-security applications should either use post-quantum algorithms now, or be designed with cryptographic agility — the ability to migrate to different algorithms without hardware replacement. The first option is increasingly practical for new designs given the availability of efficient lattice cryptography implementations. The second is a design philosophy that affects architecture decisions at every level of the hardware security stack.
Cryptographic Agility in Silicon
Cryptographic agility in hardware means designing security-critical components so that the cryptographic algorithms they use are not permanently baked into the silicon. In practice, this involves several architectural choices:
Algorithm-agnostic key derivation: Key derivation functions and key hierarchies that are not tied to a specific underlying primitive. A hardware root of trust that generates all device keys using ECDH-based derivation cannot be migrated to ML-KEM-based derivation without hardware changes. A root of trust designed with algorithm-agnostic key derivation infrastructure can support multiple algorithms without silicon changes.
Updatable firmware with verified boot: The cryptographic algorithms used in attestation protocols, TLS handshakes, and firmware verification signatures should be implemented in firmware that can be updated, not in ROM that cannot. This requires a verified boot chain that itself is cryptographically agile — which creates a bootstrapping problem that must be addressed in the hardware root of trust design.
Separating identity from algorithm: Device identity should be designed as an abstraction that is algorithm-independent. A device that "is" an ECDSA key is tightly coupled to ECDSA. A device with a hardware-rooted identity that can be presented via multiple signature schemes has much more flexibility for algorithm migration.
Hardware acceleration designed for algorithm family, not specific algorithm: Hardware accelerators for cryptographic operations are most future-proof when designed for a class of operations — polynomial multiplication for lattice cryptography, hash operations for hash-based signatures — rather than for a specific algorithm. RISC-V's extensibility makes this practical: custom instructions that accelerate polynomial arithmetic useful for ML-KEM/ML-DSA are also useful for future lattice-based algorithms that may supersede the current NIST standards.
The RISC-V Advantage for Post-Quantum Migration
RISC-V's open, extensible ISA provides structural advantages for post-quantum cryptography migration that proprietary architectures cannot match.
The ability to add custom ISA extensions allows RISC-V silicon designers to add hardware acceleration for lattice cryptography operations — specifically the Number Theoretic Transform (NTT) and polynomial multiplication that are the computational bottlenecks in ML-KEM and ML-DSA — without waiting for a proprietary vendor to add those capabilities in a future chip revision. Research implementations of NTT hardware accelerators for RISC-V already exist, and commercial implementations are increasingly available.
More importantly, the open-source nature of RISC-V hardware implementations means that post-quantum algorithm support can be developed, reviewed, and integrated into open hardware designs in ways that are simply not possible for proprietary silicon. The OpenTitan project, which the zeroRISC platform extends, has active work on post-quantum readiness for its hardware root of trust implementation. That work benefits the entire community, not just a single vendor's customers.
Practical Steps for Hardware Teams
If you are designing RISC-V hardware today for deployment timelines extending past 2030, here is the practical post-quantum checklist:
Audit your algorithm dependencies. Every place where a specific classical algorithm is hardcoded into your security architecture is a migration risk. Identify all of them: the algorithm used in your root of trust attestation key, the algorithms in your firmware signing infrastructure, the algorithms in your secure boot chain verification, the algorithms in your key derivation functions.
Design for firmware-level algorithm migration where possible. Any algorithm that is implemented in firmware — rather than hardwired into ROM — can potentially be migrated via firmware update. Ensure your verified boot infrastructure itself is designed to support algorithm migration at the firmware level, not just the application level.
Plan for hardware root of trust algorithm migration. This is the hard part. A hardware root of trust that uses classical algorithms for its fundamental key generation and attestation signing will eventually need to migrate. If you cannot migrate the root of trust via firmware update, you need a plan for how devices in the field will be transitioned — which may mean hardware replacement for long-lifetime deployments in high-security applications.
Start evaluating hybrid classical/post-quantum approaches now. For new designs, hybrid approaches — using both classical and post-quantum algorithms simultaneously, with security dependent on the stronger of the two — provide defense in depth during the transition period. The IETF and ETSI have both published guidance on hybrid key exchange and signature approaches that can be applied to embedded security protocols today.
The quantum computing timeline is genuinely uncertain. Cryptographically-relevant quantum computers may arrive in five years or fifteen. But the lead time for hardware design, certification, and deployment means that the decisions made in RISC-V hardware designs shipping in 2026 will determine the post-quantum posture of devices still in the field in 2040. The time to make those decisions correctly is now.
Questions about post-quantum readiness for your RISC-V hardware security architecture? Get in touch with the zeroRISC team.