zeroRISC
The software security community has produced an enormous amount of valuable work on software supply chain security over the past five years. SBOMs, Sigstore, SLSA, in-toto attestation — the ecosystem for verifying what code is running and where it came from has matured dramatically. This is genuinely good progress.
But there is a problem that software supply chain security cannot solve, no matter how sophisticated the tooling becomes: an attacker who compromises the hardware layer below the software does not need to modify your code, bypass your signatures, or intercept your build pipeline. They are already underneath it all.
Hardware supply chain attacks are not theoretical. They are a documented, active threat — and they are the category of attack for which software-only defenses are fundamentally inadequate. The only credible response to hardware supply chain risk is hardware attestation: a cryptographically verifiable claim about what silicon is running, provisioned during manufacturing before the attacker's window opens.
What Hardware Supply Chain Attacks Actually Look Like
The public conversation about hardware supply chain security is often dominated by dramatic but impractical threat scenarios. Rogue chips implanted during manufacturing. Backdoored CPUs designed to exfiltrate data. These exist as real threat categories, but they are not the common case. The hardware supply chain attacks that security teams actually encounter are more mundane — and more tractable if you have the right infrastructure.
Counterfeit components: Counterfeit semiconductors are a documented, large-scale industry problem. Counterfeit microcontrollers and processors sometimes contain subtly different behavior from genuine parts — different memory layouts, different peripherals, different security characteristics. A device that ships with counterfeit silicon cannot make reliable security guarantees, because the security properties of the silicon it is actually running are unknown.
Out-of-spec components: Components that are genuine but have failed testing and been sold as passing grade are common in gray-market supply chains. From a security perspective, out-of-spec components often fail in predictable ways under stress — including security-relevant stress conditions like fault injection attacks. A device that performs correctly under normal operating conditions may be exploitable under targeted fault conditions if it contains out-of-spec silicon.
Malicious firmware provisioning: The most common hardware supply chain attack in practice is not at the silicon level at all — it is at the firmware provisioning step. Contract manufacturers provision firmware onto thousands of devices per day. A compromise of the provisioning infrastructure, or a malicious actor within the provisioning chain, can result in devices shipping with backdoored firmware. Without hardware-anchored integrity verification, this attack is essentially undetectable by downstream recipients.
Key theft during provisioning: For devices that rely on per-device cryptographic keys provisioned during manufacturing, a compromise of the provisioning infrastructure can result in mass key extraction. If those keys are used for device authentication, an attacker with stolen keys can impersonate legitimate devices indefinitely — or, worse, can sign malicious firmware updates that will be accepted as legitimate by deployed devices.
Why Software Attestation Is Not Enough
The instinctive response to hardware supply chain security concerns is to reach for software attestation: have the device report its software state, sign the report with a device-specific key, and verify the signature against a certificate authority. This approach has real value for software integrity verification, but it has a fundamental limitation when applied to hardware supply chain problems.
Software attestation proves what software is running. It does not prove what hardware is running it. An attacker who can compromise the hardware layer — by substituting silicon, by corrupting the provisioning process, or by having physical access to the device before deployment — controls the environment in which the software attestation code runs. The attestation report they generate can say whatever they want it to say.
This is not a theoretical objection. Researchers have demonstrated attacks against TPM-based attestation, secure enclaves, and similar mechanisms by exploiting the hardware layer beneath the attested software. The pattern is consistent: software attestation rooted in hardware that an attacker controls is not attestation. It is theater.
Hardware attestation addresses this by rooting the trust anchor in silicon during manufacturing, before any attacker's window opens. A hardware root of trust provisioned at the fab with a key that is never extractable in plaintext provides a device identity that is bound to that specific piece of silicon. Subsequent attestation reports signed with that key are bound not just to the software state, but to the physical device — and any substitution of that device would produce a different identity that would not match the expected certificate chain.
The RISC-V Provisioning Problem
For teams building on RISC-V, the hardware supply chain security problem has a specific wrinkle: the RISC-V ecosystem is fragmented enough that provisioning security practices vary enormously across silicon vendors, contract manufacturers, and module suppliers. The toolchain for provisioning RISC-V devices with hardware-rooted identities is less mature than the equivalent for ARM Cortex-M devices with PSA Certified implementations.
This is changing rapidly. The RISC-V security working group has been developing attestation specifications, and several RISC-V silicon vendors now offer reference hardware security modules that support TCG DICE provisioning. But the toolchain maturity is still lower than many enterprise embedded teams require, and the integration work to connect a RISC-V device with a production-grade certificate authority and attestation service is non-trivial.
The practical implication for RISC-V hardware teams is that supply chain security needs to be considered at the silicon selection stage, not treated as a firmware-layer concern. Choosing a RISC-V core that has mature hardware security module support, and choosing a contract manufacturer with a controlled provisioning environment, are decisions that cannot be retroactively corrected after tape-out.
What a Hardware-Anchored Supply Chain Defense Looks Like
A credible hardware supply chain defense for RISC-V devices involves three linked components that must all be in place for the system to provide meaningful protection:
Manufacturing-time provisioning: Each device is provisioned during manufacturing with a unique cryptographic identity, derived from a hardware secret that cannot be extracted in plaintext — typically a PUF (Physical Unclonable Function) or a hardware-fused key. The provisioning process generates a certificate chain that binds the device's hardware identity to a root of trust certificate authority controlled by the manufacturer.
Silicon-anchored boot chain: The device's boot process is cryptographically verified from the first instruction executed after power-on, with the root of the verification chain anchored in the hardware security module provisioned at manufacturing. This ensures that the device's software state can be reliably reported — because the software running at attestation time has been verified against a chain of trust that starts in hardware.
Remote attestation service: A server-side service that can verify attestation reports from deployed devices, check them against the expected certificate chain, and flag devices whose hardware identity does not match expectations. This service closes the feedback loop: it provides the mechanism for downstream operators to verify that the silicon they received is genuine, correctly provisioned, and running unmodified firmware.
All three components must be in place. Manufacturing-time provisioning without a remote attestation service provides no runtime benefit. A remote attestation service without silicon-anchored provisioning is verifying software, not hardware. And a boot chain verification that is not anchored in hardware-rooted provisioning can be bypassed by compromising the hardware layer beneath it.
The Organizational Dimension
Hardware supply chain security is not just a technical problem — it is an organizational one. The technical infrastructure described above only works if the provisioning environment itself is secure: if the certificate authority private keys are protected, if the provisioning stations are controlled, if the firmware images loaded during provisioning have been verified against a known-good reference.
This is why implementing hardware supply chain security for a RISC-V product is not something that can be delegated entirely to a silicon vendor or a contract manufacturer. It requires the device manufacturer to maintain control of the provisioning root of trust, to audit the manufacturing provisioning environment, and to maintain the attestation verification infrastructure for the life of the product.
That is a non-trivial operational commitment. But it is the commitment that genuine supply chain security requires. The alternative — accepting that you do not know whether the silicon in your deployed devices is genuine or whether the firmware on them was provisioned correctly — is an increasingly untenable position for any manufacturer whose devices handle sensitive data, operate in safety-critical contexts, or connect to critical infrastructure.
The good news is that the RISC-V ecosystem is building the infrastructure to make this commitment achievable without a large in-house hardware security team. The work being done in the RISC-V International security working group, in the OpenTitan community, and by platform providers building production-grade attestation services is lowering the barrier to implementing credible hardware supply chain security for RISC-V products. The problem is not yet solved, but the trajectory is clear.
Software supply chain security matters. But it is built on a foundation, and that foundation is hardware. Teams that secure the hardware layer first are building on solid ground. Teams that do not are hoping that no one looks underneath.
Interested in hardware supply chain security for your RISC-V product? Explore the zeroRISC platform or contact the team.
