ESP32-C6 Becomes the First RISC-V MCU to Earn PSA Level 2 Security Certification

ESP32-C6 Becomes the First RISC-V MCU to Earn PSA Level 2 Security Certification

Espressif announced on March 6, 2025, that the ESP32-C6 had achieved PSA Certified Level 2, making it the first RISC-V-based product to reach that certification level. The milestone is useful because it adds independent laboratory evaluation to the security claims around an inexpensive, broadly connected microcontroller.

The precise scope is as important as the headline. PSA Certified Level 2 evaluates the chip's PSA Root of Trust against scalable software attacks. It does not mean every product built around the chip is secure, and it is not a claim that the device withstands every invasive physical technique. It is evidence that a defined security foundation was tested against a published assurance level.

A root of trust is the small collection of hardware and trusted software that the rest of a security system relies upon. If that foundation cannot protect identities, verify software, or enforce lifecycle rules, protections higher in the stack become much less meaningful.

What PSA Certified Level 2 means

PSA Certified is a security evaluation program created for connected devices. Its framework helps chip and product makers define security functions and submit implementations for independent assessment.

Level 1 begins with documentation review and a questionnaire-based assessment of security practices. Level 2 adds laboratory testing of the PSA Root of Trust. Evaluators examine whether the implementation resists practical, scalable software attacks within the certification's threat model.

"Scalable" is useful language here. A remotely repeatable software exploit can threaten an entire fleet without an attacker physically handling each device. Level 2 focuses on raising the barrier against that class of attack. More advanced physical resistance belongs to a different level and threat model.

Certification is therefore not a trophy for vague security. It describes an evaluated target, version, configuration, and set of claims. Product teams should consult the certificate and its report when making assurance decisions, not rely solely on a logo or press-release sentence.

Why the RISC-V milestone matters

RISC-V is an open instruction set architecture. It defines the instructions a processor executes while allowing implementers to design compatible cores and systems around it. The ESP32-C6 uses a 32-bit RISC-V processor, so its Level 2 result showed that a product built on the architecture could support an independently evaluated IoT root of trust.

That does not imply that RISC-V is inherently secure or insecure. Security depends on the complete implementation: privilege controls, memory protection, boot process, cryptography, debug policy, firmware, and lifecycle management. The milestone is important because it supplies concrete evidence for one shipping implementation rather than an architectural promise.

It also broadens the choices available to designers. Security-sensitive connected products no longer need to treat an open instruction set and recognized assurance as opposing goals.

The ESP32-C6 is built for connected devices

ESP32-C6 integrates Wi-Fi 6, Bluetooth 5 Low Energy, and IEEE 802.15.4 connectivity. IEEE 802.15.4 provides the radio layer used by Thread and Zigbee, making the chip relevant to Matter accessories, smart-home controllers, sensors, lighting, and gateways.

Multiple radios create useful product options, but connectivity also increases exposure. A device may accept data from a local IP network, a nearby phone, and a low-power mesh. Each parser and protocol adds code that could contain a flaw. A protected root of trust gives the system an anchor for secure boot, device identity, key protection, and verified updates even as the application surface grows.

Espressif's separate ESP-TEE work on the C6 follows the same defense-in-depth direction. A trusted execution environment divides sensitive services from ordinary application code. Certification and isolation are not interchangeable, but together they show how the hardware and software security story can be layered.

What the certificate does not secure for you

A certified chip can be used in an insecure product. Developers still decide whether secure boot is enabled, whether flash encryption is configured correctly, how credentials are provisioned, which debug interfaces remain open, and how quickly field updates are delivered.

The surrounding board plays a part too. External flash, exposed test pads, a weak power design, or unprotected secrets in another component can undermine the intended model. Cloud services and mobile applications are part of the system too. A strong root of trust cannot repair an account-recovery flow that gives an attacker control of the device.

Certification also does not freeze risk. New vulnerabilities can be found after evaluation. Teams need a vulnerability intake process, software bill of materials, supported update path, and clear maintenance lifetime.

The right question is not "Is the ESP32-C6 secure?" It is "Which security properties were evaluated, and how does our product preserve them?"

How product teams can use the result

Begin by downloading the public certification information and recording the exact evaluated target. Match the chip revision and relevant security configuration to the planned design. If a requirement names PSA Certified Level 2, confirm that the certificate's scope satisfies it rather than assuming any C6-based module inherits every claim automatically.

Create a threat model before the schematic and firmware become difficult to change. List valuable assets, likely attackers, exposed interfaces, and the consequences of failure. Decide which functions belong in the root of trust or a trusted environment, and keep those interfaces narrow.

During development, enable the security features required by the design and lock them in a controlled production flow. Test signed update acceptance, rejection of altered images, rollback behavior, key provisioning, factory reset, and debug restrictions. Keep development keys separate from production credentials.

Finally, document what certification covers in customer-facing material. Precise claims build more trust than implying the whole product is invulnerable.

Why this is useful for makers too

Most hobby projects do not need formal certification, but the result offers an accessible platform for learning professional security concepts. A maker can explore secure boot, signed OTA updates, protected storage, privilege separation, and device identity on hardware that also supports familiar wireless projects.

The lesson is broader than one chip. Security works best when it begins with a trustworthy foundation, continues through carefully designed firmware, and remains supported after deployment. Independent evaluation strengthens one layer of that chain.

The ESP32-C6 milestone gave RISC-V a visible place in the certified IoT market and gave Espressif customers evidence that its security foundation had faced more than an internal review. It should be read as a meaningful assurance signal with defined boundaries. Used that way, PSA Certified Level 2 is not marketing shorthand. It is one well-specified tool for building a product whose security story can be examined, tested, and maintained.

For hobby projects, I read this certification as a learning opportunity: a chance to practice secure boot and signed updates on affordable hardware.

Sources and image credits

Add new comment

Restricted HTML

  • You can align images (data-align="center"), but also videos, blockquotes, and so on.
  • You can caption images (data-caption="Text"), but also videos, blockquotes, and so on.