IoT & Edge

Hardware Security for IoT and Edge Devices: What Architects Need to Know

IoT edge devices mounted in industrial rack enclosure

The convergence of RISC-V adoption and the scale-out of IoT and edge computing creates a hardware security challenge unlike anything the embedded industry has previously encountered. When a device fleet numbers in the millions and spans geographically distributed, physically exposed deployment sites, the security architecture choices made in chip design have consequences that play out over decades.

Most IoT security architecture discussions focus on network-layer controls: TLS for transport, API authentication, cloud-side access control. These controls matter, but they are fundamentally insufficient when an adversary can extract private keys from a physically accessible device and impersonate it on the network. Hardware security is not an alternative to network security — it is the foundation that makes network security meaningful.

The Unique Threat Profile of IoT and Edge

IoT and edge devices face a threat profile that datacenter hardware does not:

Physical access is the baseline assumption: An industrial sensor on a factory floor, a utility meter in an outdoor cabinet, or a medical device in a hospital room are all accessible to a motivated adversary. The security architecture cannot assume physical security.

Update cycles are slow or nonexistent: Many IoT devices have firmware update mechanisms that are infrequently used or entirely absent. Software vulnerabilities that would be patched overnight in a cloud environment may persist for years in an IoT fleet. The security architecture must be resilient to software vulnerabilities, not dependent on their absence.

Scale makes individual device inspection impossible: A fleet of one million sensors cannot be individually audited. Security verification must be automated and cryptographically sound — which requires hardware-rooted attestation.

Power and cost constraints are real: Unlike server hardware, IoT devices operate under strict bill-of-materials and power constraints. Security architectures that require a separate discrete secure element may be unaffordable for sensors targeting a $2 device cost.

RISC-V's Role in This Picture

RISC-V is increasingly the processor architecture of choice for new IoT and edge silicon designs. The economics are compelling: no royalties, full customizability, and a growing ecosystem of IP blocks and development tools. For security architects, this creates both opportunities and obligations.

The opportunity is that RISC-V designs can incorporate security primitives at the silicon level with precision that was previously only available at the price point of high-end ARM cores with TrustZone. Integrated PMPs, hardware-isolated security subsystems, and on-chip HSMs are all feasible in RISC-V SoC designs targeting IoT price points.

The obligation is that RISC-V does not prescribe these security features — chip designers must make deliberate choices to include them. A RISC-V chip that omits hardware security primitives to reduce die area will be less secure than an equivalent chip that includes them. The flexibility of the RISC-V ecosystem is a double-edged sword: it enables better security outcomes, but only if the design team prioritizes security as a first-class requirement from the outset.

A Minimum Hardware Security Baseline for IoT

Based on our work across IoT and edge deployments, we recommend the following minimum hardware security baseline for RISC-V IoT devices:

For devices in higher-risk deployments (medical, critical infrastructure, defense), additional capabilities including fault injection countermeasures, side-channel resistance, and physical tamper detection should be considered.

Regulatory Landscape Driving Change

The regulatory environment for IoT security is shifting rapidly. The EU Cyber Resilience Act, which enters enforcement in 2027, imposes baseline security requirements on connected devices sold in Europe — requirements that include unique device identifiers, authenticated firmware updates, and disclosure of known vulnerabilities. Similar requirements are taking shape in the US through the FCC's IoT labeling program and sector-specific mandates in healthcare (HIPAA device security guidance), critical infrastructure (CISA guidance), and automotive (UN Regulation 155).

For RISC-V-based IoT products targeting these markets, hardware security is no longer optional — it is a compliance requirement with a timeline. The design decisions made in silicon today will determine whether products launched in 2026-2028 meet these requirements out of the box or require costly redesigns.

The Supply Chain Dimension

IoT hardware security has an often-overlooked supply chain dimension. A device's security properties are established at manufacturing time: key injection, initial firmware provisioning, and certificate enrollment all happen before the device reaches its deployment site. A compromised manufacturing step can undermine every downstream security control.

For RISC-V IoT designs, we recommend on-device key generation where silicon constraints allow: generating keys on the device during a provisioning step using on-chip entropy means that raw key material never needs to leave the device. This eliminates the highest-risk step in many IoT provisioning workflows, where keys generated externally are transported to and injected into devices on the manufacturing line.

Cost-Conscious Implementation

The objection most commonly raised against comprehensive hardware security in IoT is cost. A discrete secure element adds $0.50-$2.00 to the bill of materials, which is significant at IoT scale. But this analysis misses two important points.

First, RISC-V SoCs can integrate security subsystem functionality on-die at minimal additional cost relative to the total die area. The investment is in design time, not in silicon area that scales linearly with unit volume. For a production run of 10 million units, amortizing a 6-month security architecture investment is trivial compared to adding a discrete secure element to every board.

Second, the cost of a security incident in a deployed fleet far exceeds the hardware security investment. The 2016 Mirai botnet, which compromised millions of IoT devices due to weak default credentials, caused infrastructure damage estimated in the hundreds of millions of dollars. A firmware extraction attack that enables product cloning or competitive intelligence extraction can be far more costly to the affected company. Security investment at the hardware layer is also insurance against the growing cost of regulatory non-compliance.

For a hardware security architecture review tailored to your IoT or edge product, contact the zeroRISC team.