wolfSSL now builds and runs on CHERI purecap RISC-V, with all of the supporting fixes merged upstream. This brings one of the most widely deployed TLS/SSL and cryptography libraries to a hardware-enforced memory-safety architecture, a natural pairing for the kind of security-critical embedded code wolfSSL is built for.
This work was contributed by William Beasley of The Capable Hub, who integrated wolfSSL into the meta-cheri Yocto layer and upstreamed the changes in PR #10272. We first met the team at CHERI Blossoms earlier this year, and we are pleased to see wolfSSL running on CHERI as a result.
About CHERI
CHERI (Capability Hardware Enhanced RISC Instructions) extends a processor’s instruction set so that pointers become capabilities: hardware-enforced, unforgeable tokens that carry not just an address but also bounds, permissions, and a validity tag. The hardware checks every memory access against the capability’s bounds and permissions, so a large class of memory-safety bugs, including out-of-bounds reads and writes, become hardware faults at the point they occur rather than silent corruption or a latent vulnerability waiting to be exploited.
Why this matters
Memory-safety defects remain the single largest source of serious security vulnerabilities in C and C++ software, consistently accounting for the majority of critical CVEs across the industry. They are also the hardest to find: code can be functionally correct, pass its tests, and ship for years before a memory-safety bug is discovered, often by an attacker rather than a defender. CHERI changes that equation by enforcing memory safety in hardware, deterministically turning whole categories of exploit into a clean fault rather than a foothold.
For a TLS and cryptography library this is especially significant. The crypto and TLS layer sits directly on the network boundary and is one of the most exposed and most attacked parts of any connected product. Running that layer on CHERI means the component handling untrusted input is backed by hardware that will not let a memory-safety bug become a remote compromise.
CHERI and the EU Cyber Resilience Act
This also lands at a useful moment for anyone building connected products for the European market. The EU Cyber Resilience Act (CRA) entered into force in December 2024, with vulnerability-reporting obligations beginning in September 2026 and full application from December 2027. From that point, products with digital elements placed on the EU market must meet mandatory cybersecurity requirements, centred on secure-by-design development, reducing and handling vulnerabilities, and maintaining security across the product’s whole lifecycle.
Memory safety goes to the heart of those expectations. A device whose most exposed software runs on a memory-safe foundation has, by construction, eliminated the dominant class of exploitable vulnerabilities rather than relying on finding and patching each one after the fact, which is exactly the kind of secure-by-design posture the CRA is pushing manufacturers towards. CHERI is not a compliance checkbox on its own, but pairing a memory-safe hardware architecture with a TLS stack like wolfSSL is a strong, demonstrable step towards the security baseline the CRA requires, and towards reducing the vulnerability-handling burden over a product’s supported life.
wolfSSL is already helping customers prepare for the CRA, and CHERI support is a welcome addition to that toolkit for teams who want memory safety designed-in from the silicon up.
Try it
The fixes are merged into wolfSSL upstream, and a CHERI build is available today through the meta-cheri Yocto layer. The Capable Hub has also published a detailed technical walkthrough of the port on their blog, which we recommend for anyone interested in the specifics.
This is the initial step, and work to bring wolfSSL to the wider CHERI ecosystem, starting with CHERIoT, is already underway.
If you have questions about any of the above, please contact us at facts@wolfSSL.com or support@wolfSSL.com, or call us at +1 425 245 8247.
Download wolfSSL Now