zeroRISC
Zero trust has become one of the most overloaded terms in enterprise security. In the network security context it originated from, zero trust means "never trust, always verify" — no device gets implicit network access based on its location. Every connection is authenticated, every access request is evaluated against policy. The model is well understood, the tooling is mature, and enterprise adoption is well underway.
When people try to apply zero trust to embedded and IoT systems, the conversation gets more complicated — and more interesting. The challenge is not the principle, which applies just as cleanly to embedded devices as to enterprise users. The challenge is the foundation. Zero trust requires that devices have verifiable identities. For an enterprise laptop, that identity can be asserted by a certificate provisioned during MDM enrollment. For an embedded microcontroller with no operating system, no certificate store, and no key management daemon, the question of what "verifiable identity" means requires a different answer entirely.
The Identity Problem in Embedded Systems
Consider a fleet of 50,000 RISC-V-based industrial sensors deployed across a manufacturing network. Each sensor needs to authenticate to the data aggregation infrastructure. In a zero-trust model, the aggregation infrastructure should never accept data from a device it cannot verify as legitimate.
The naive approach is to provision each device with a unique shared secret during manufacturing — a per-device API key or pre-shared key. This approach has worked in constrained environments for decades, but it has serious problems at scale: key management becomes complex, key compromise affects individual devices, and there is no mechanism to verify that a device presenting a valid key is actually the device it claims to be rather than an attacker who has extracted the key.
A better approach is asymmetric cryptography: each device holds a private key in secure storage and presents a certificate chain signed by a root authority for authentication. But this immediately raises the question of what "secure storage" means on a RISC-V microcontroller. If the private key is stored in flash memory alongside the application firmware, it can be extracted by an attacker with physical access or firmware exploit access. True secure storage requires hardware isolation — a hardware security module or equivalent that prevents key extraction even under physical attack.
This is the core reason why zero trust for embedded systems is inseparable from hardware security. Without hardware-isolated key storage and hardware-anchored device identity, zero trust in embedded deployments is a policy aspiration without a technical foundation.
Attestation as the Verification Mechanism
Zero trust's "always verify" principle, when applied to embedded devices, requires the ability to verify not just device identity but device state. It is not sufficient to know that a request is coming from device #42738. In a zero-trust model, you also need to know that device #42738 is running unmodified, expected firmware, and has not been tampered with since its last known-good state.
This is what hardware attestation provides. An attestation report from a device with a hardware root of trust includes a cryptographically signed measurement of the device's firmware state. The verifier can check whether the reported firmware hash matches the expected value for that device class and firmware version. Devices running modified firmware, or devices that have not yet been provisioned with the expected firmware version, produce attestation reports that fail this check and are rejected by the zero-trust policy engine.
For RISC-V deployments, integrating hardware attestation into a zero-trust architecture requires three things: a hardware-rooted attestation capability on the device, a server-side attestation verification service, and a policy engine that gates network access on the results of attestation checks. The first two are technical infrastructure problems. The third is an architecture decision about how to integrate attestation results into the network access control flow.
Practical Implementation Path
For teams designing RISC-V products for zero-trust enterprise environments, the practical implementation path typically involves these steps:
Silicon selection: Choose a RISC-V SoC or module that includes hardware security features — specifically, hardware key storage with anti-extraction protections and the ability to generate attestation evidence signed by a hardware-anchored key. Not all RISC-V silicon is equal here; this is a non-trivial differentiator between commodity microcontrollers and security-focused designs.
Manufacturing-time provisioning: Establish a controlled provisioning process that installs device identity certificates during manufacturing, before devices leave the factory floor. The private key corresponding to the device certificate should be generated on-device and never leave the hardware security module in plaintext.
Attestation integration: Integrate device attestation into the authentication flow. When a device attempts to connect to the network, it presents both its identity certificate and a fresh attestation report. The server verifies the certificate chain and checks the attestation report against the expected firmware state for that device class.
Policy engine integration: Connect attestation results to the network access control policy. Devices with valid identity and passing attestation get normal network access. Devices with valid identity but failing attestation — indicating potential tampering or outdated firmware — can be quarantined for remediation or restricted to a limited network segment.
The RISC-V Advantage
RISC-V's open, extensible architecture provides a natural foundation for zero-trust embedded deployments. The ability to add custom security extensions to RISC-V cores means that hardware attestation capabilities can be deeply integrated into the silicon rather than bolted on as peripheral modules. The open specification model means that the attestation mechanism can be publicly documented and independently audited — which is exactly what zero-trust verifiers need to have confidence in the evidence they are evaluating.
The combination of RISC-V's architectural openness and hardware security infrastructure designed from first principles for RISC-V provides a stronger foundation for zero-trust embedded systems than any proprietary architecture can, precisely because the entire chain can be independently verified. Zero trust, by definition, requires that verification be possible. Open architecture makes verification tractable.
Interested in implementing zero trust for your RISC-V device fleet? Contact the zeroRISC team.