RECENT BLOG NEWS
wolfSSL visits Radiona in Zagreb
We at wolfSSL would like to thank Goran Mahovlic and the entire Radiona team for inviting us to their headquarters in Zagreb, Croatia! We enjoyed the opportunity to present information on one of our flagship products, wolfBoot, during the recent OpenHardware Meet-up. The hospitality was outstanding and greatly appreciated!
Radiona is home to the awesome ULX3S FPGA + ESP32 board, first introduced to the general public by our friends over at the Crowd Supply Campaign and now available from Mouser Electronics.
Radiona embodies the true STEAM Spirit. So much more than the open source hardware is the community of passionate makers, students, engineers, and more. These people from all over the world participate in the Zagreb Makerspace and FER: the Faculty of Electrical Engineering and Computing at the University of Zagreb in Croatia.
A new and exciting board is also in the works from the collaboration between Radiona and Intergalaktik: the ULX4M! This is another open source FPGA board that has a CM4 connector for the many Raspberry Pi Carrier boards that accept a Compute Module.
The ULX3S is the only board (that we know of!) that is not only open source, but includes both open source FPGA and ESP32 projects, all on one board. Check out some of the many projects available.
New and exciting features will soon be added to the ULX3S, leveraging some of the features of the ESP32-S3. See the development README doc.
There’s extensive wolfSSL support for the ESP32, including not only Espressif ESP-IDF with optional Managed Components but also Arduino, PlatformIO, and more.
[gojimmypi] has several blogs on using wolfSSL with the ULX3S: Perhaps you’d like to SSH into the ESP32 on your ULX3S? That example leverages the core Espressif wolfSSH in the wolfssl-examples SSH-to-UART project.
The ULX3S could also be integrated into the Apple HomeKit ecosystem.
Interested in getting Started with wolfSSL on the ESP32? Check out our YouTube video:
See our prior blog about using the ULX3S FPGA to create your own soft-core RISC-V, the same Hazard3 core used on the Raspberry Pi Pico 2 RP2350.
Meet Us at Events:
- Upcoming wolfSSL events
- CYSAT Europe | May 14-15
- Barcelona Cybersecurity Congress | May 21-23
- Upcoming Radiona events
For more information:
- wolfSSL Docs
- wolfSSL Manual
- Other ESP32 blogs
- Learn more about Radiona and wolfSSL.
Post Quantum
Do you have code that can be upgraded to Post Quantum? Read our recent blog to learn more!
FIPS Certified!
When you are ready to move on to the next step, wolfSSL will be there for you! Need to have your project NIST Certified? Recently we announced that wolfSSL is the First in the World to offer FIPS 140–3 Automated Submission with our NIST Certificate #4718.
Find out more:
If you have any feedback, questions, or require support, please don’t hesitate to reach out to us via facts@wolfSSL.com, call us at +1 425 245 8247, or open an issue on GitHub
Download wolfSSL Now
wolfBoot release: v.2.5.0
We are pleased to announce the release of wolfBoot 2.5.0, the newest version of our universal secure bootloader. This release marks another milestone in the continued evolution of wolfBoot, reinforcing its relevance as a cutting-edge secure boot solution for embedded systems. WolfBoot 2.5.0 brings expanded hardware support, major new features, and a host of improvements to performance and security, all while maintaining the simplicity and robustness our users expect.
New hardware targets and platform enhancements
wolfBoot 2.5.0 expands its hardware compatibility, adding support for several new platforms and improving existing targets. Notable additions and enhancements include:
- New target support: wolfBoot now supports the Raspberry Pi RP2350 microcontroller, NXP’s MCX family (including the MCXA153 and MCXW716 series), and the STMicroelectronics STM32F1 series. These additions extend wolfBoot’s reach from the latest Pi Pico 2 board to NXP’s advanced Cortex-M33 based MCUs and even legacy STM32F1 devices (like the popular “blue-pill” board), demonstrating once again our team’s commitment to maximize device coverage.
- Enhanced support: Existing platform ports have been refined for better stability and performance, notably for the Xilinx UltraScale+ MPSoC (ZynqMP), Renesas RX family, and Infineon AURIX TriCore TC3xx microcontrollers. Developers using ZynqMP devices will benefit from smoother integration (e.g. improved standalone boot support and exception level handling), while updates to the Renesas RX and AURIX TC3xx ports include more efficient flash management and boot-time reliability improvements. These platform enhancements make it easier and more efficient to deploy wolfBoot on a wider range of hardware.
Major new features and enhancements
Version 2.5.0 introduces several important features aimed at both simplifying the developer experience and strengthening security:
- Non-contiguous ELF section support: wolfBoot can now load and verify firmware images with non-contiguous (scattered) ELF sections. In practical terms, this means the bootloader handles images that are split across multiple memory regions, accommodating complex memory maps and multi-part firmware layouts. This feature adds flexibility for projects that utilize segmented flash or RAM areas for their application code and data.
- Streamlined PQC integration: Post-Quantum Cryptography support in wolfBoot has been simplified and updated. WolfBoot 2.5.0 includes the latest PQC algorithm support from wolfCrypt (such as the recently standardized ML-DSA) and makes it easier to configure PQC-based signature verification. By refining the integration of PQC algorithms, we continue to help users prepare for a post-quantum future without sacrificing ease of use.
- Static library build option: In addition to the traditional standalone bootloader binary, wolfBoot can now be built as a static library (libwolfboot.a). This gives developers the flexibility to integrate wolfBoot’s secure boot functionality directly into their applications or custom boot frameworks. The static-lib build simplifies certain use cases — for example, linking wolfBoot into a monolithic firmware image or using wolfBoot features in an RTOS environment — by allowing wolfBoot to be called like a library rather than a separate bootloader image.
- Glitch attack mitigation (IAR toolchain): Security against hardware fault-injection attacks (glitches) has been further hardened in this release. We’ve extended our glitch mitigation techniques to better support the IAR Embedded Workbench toolchain, ensuring that builds compiled with IAR include additional countermeasures against timing and voltage glitch attacks. These low-level improvements make the secure boot process even more resilient to physical attack attempts, protecting the integrity of the firmware verification steps.
Build system and documentation improvements
wolfBoot 2.5.0 comes with numerous build system refinements and documentation updates to streamline development. We have refactored the CMake build system to improve cross-platform support and clarity, making it easier to compile wolfBoot for various targets and toolchains. This includes cleaner integration for IAR and other compilers, as well as a more organized project structure for out-of-the-box builds. Additionally, our documentation has been improved across the board – from updated user manuals and API references to new examples and guides – to help both new and experienced users get the most out of wolfBoot. Whether you’re configuring a multi-slot update scheme or integrating wolfBoot with a TPM, the clearer documentation will guide you through the process more smoothly. (As always, detailed change logs and usage instructions can be found in the README and docs accompanying the release.)
Bug fixes and updated modules
As with every release, wolfBoot 2.5.0 includes key bug fixes that enhance stability and reliability. Various minor issues identified in the previous version have been addressed, resulting in a more robust bootloader across all supported platforms. In particular, fixes were applied to edge cases in flash memory handling and update workflows to ensure consistent behavior in all update scenarios.
Moreover, the cryptographic and secure hardware modules underlying wolfBoot have been updated to their latest versions. wolfBoot 2.5.0 is powered by wolfSSL 5.8.0 – bringing in the newest optimizations and post-quantum enhancements from the wolfCrypt engine – and it can integrate with wolfTPM 3.9.0 for TPM-based secure boot use cases. By using the latest wolfSSL v5.8.0 and wolfTPM v3.9.0 releases, wolfBoot ensures compatibility with the most up-to-date security features and fixes from those libraries. This means developers get improved performance, up-to-date cryptographic algorithms, and continued FIPS 140-3 readiness through wolfCrypt.
wolfBoot’s security is, as always, built on wolfCrypt, which allows the boot process to leverage FIPS-certified crypto and even meet safety standards like DO-178C when required. Upgrading to wolfBoot 2.5.0 brings all these benefits into your secure boot process.
Getting wolfBoot 2.5.0 and support
wolfBoot 2.5.0 is available for download now, and we encourage everyone to try out the new features and improvements. You can find the source code and release package on our GitHub repository and the wolfSSL download page. Documentation for this release, including an updated user manual and examples, is available on our website to help you get started quickly.
If you have any questions about wolfBoot 2.5.0 or need help with integration, please contact us at facts@wolfSSL.com or call us at +1 425 245 8247. The wolfSSL team offers commercial support and consulting services for those who require dedicated assistance or custom features. Whether you are upgrading an existing project or designing a new device with wolfBoot, our team is here to ensure your secure boot implementation is successful.
Download wolfSSL Now
Test Certificates in Production: KeyPlug’s WolfSSL Misconfiguration Leads to Infrastructure Exposure
Summary
A critical security incident exposed KeyPlug malware infrastructure due to the improper use of wolfSSL test certificates in production. The 24-hour exposure revealed sophisticated attack tools linked to the RedGolf/APT41 threat group, demonstrating how poor certificate management can compromise even advanced threat actors’ operations.
The Certificate Failure
The compromised server was identified through its WolfSSL test certificate:
Subject Common Name: www[.]wolfssl[.]com Subject Organizational Unit: Support_1024 Issuer Organizational Unit: Consulting_1024 SHA-256: 4C1BAA3ABB774B4C649C87417ACAA4396EBA40E5028B43FADE4C685A405CC3BF
Critical Issues
- Test Certificate Misuse
- Production use of wolfssl.com test domain
- Weak 1024-bit keys (indicated by “_1024” suffix)
- Certificate sharing across multiple attack servers
- Security Impact
- Exposed Fortinet exploitation tools and C2 infrastructure
- Enabled infrastructure correlation through shared certificates
- Compromised operational security of advanced threat actors
Best Practices for WolfSSL Implementation
To avoid security lapses like the one described, it’s critical to follow best practices when deploying wolfSSL in production environments. The following guidelines focus on certificate requirements, security controls, and monitoring techniques:
Production Deployments
- Certificate Requirements
- Use only trusted CA-issued certificates
- Implement minimum 2048-bit RSA keys
- Maintain proper validation chains
- Security Controls
- Never use test certificates in production
- Implement certificate pinning
- Regular certificate rotation
Monitoring and Detection
- Certificate Auditing
- Regular infrastructure scans
- Certificate inventory management
- Automated validation checks
- Warning Signs
- Domains containing “wolfssl.com”
- Organizational units with test indicators
- Key sizes below 2048 bits
- Invalid trust chains
Recommendations
To mitigate risk and ensure strong certificate hygiene, both WolfSSL users and security teams should take immediate action. Below are tailored recommendations for each group:
Immediate Actions
- For WolfSSL Users
- Audit all certificates
- Remove test certificates
- Implement CA-issued certificates
- Verify proper key lengths
- For Security Teams
- Monitor for test certificate usage
- Implement certificate validation
- Regular infrastructure scanning
- Maintain certificate inventory
Conclusion
Organizations must maintain strict separation between development and production certificates and implement proper certificate management policies to prevent similar exposures.
Please do not use wolfSSL test certificates in production because the corresponding private keys are published as part of the wolfSSL source code package, so by design, these certificates are insecure. The test certificate private keys are public!
Source:
- KeyPlug-Linked Server Briefly Exposes Fortinet Exploits, Webshells, and Recon Activity Targeting a Major Japanese Company
- Exposed KeyPlug Malware Staging Server Contains Fortinet Firewall and VPN Exploitation Scripts
If you have questions about any of the above, please contact us at facts@wolfSSL.com or call us at +1 425 245 8247.
Download wolfSSL Now
Announcing wolfMQTT v1.20.0: Now with WebSocket Support
We are excited to announce the release of wolfMQTT v1.20.0, which introduces WebSocket support as its headline feature. This release continues our commitment to providing a lightweight, secure, and feature-rich MQTT client implementation for embedded systems and IoT applications.
What’s New in v1.20.0
The wolfMQTT v1.20.0 release includes several significant enhancements:
WebSocket Support
The most notable addition in this release is comprehensive support for MQTT over WebSockets. This feature allows wolfMQTT clients to connect to MQTT brokers through WebSocket endpoints, which is particularly valuable in environments where traditional MQTT ports might be blocked or when integrating with web applications.
Both standard WebSockets and secure WebSockets (WSS) are now supported, providing flexibility for various security requirements:
- Standard WebSockets: Connect to brokers using the WebSocket protocol without encryption
- Secure WebSockets: Use TLS to encrypt the WebSocket connection for enhanced security
Secure WebSocket CI Testing
To ensure the reliability of the new WebSocket functionality, we’ve added continuous integration testing specifically for secure WebSockets. This testing helps maintain the high quality and stability that users expect from wolfMQTT.
Improved CMake Support
This release includes improvements to the CMake build system:
- Enhanced duplicate component checking in CMake builds
- Better compatibility with the latest Managed Components
Additional Improvements
- Updated examples for the latest Managed Components
- Fixed an issue with OQS’s Mosquitto being out of date
About wolfMQTT
wolfMQTT is a lightweight, embedded MQTT client implementation written in C that supports SSL/TLS via the wolfSSL library. It was built from the ground up to be multi-platform, space conscious, and extensible. The library supports:
- MQTT v3.1.1 and v5.0 protocols
- MQTT-SN (MQTT for Sensor Networks)
- Quality of Service (QoS) levels 0-2
- TLS encryption via wolfSSL
- Non-blocking communications
- Multithreading for parallel operations
- Integration with popular IoT platforms (AWS IoT, Azure IoT Hub, IBM Watson IoT)
Getting wolfMQTT v1.20.0
The wolfMQTT v1.20.0 release is available now on our download page and GitHub.
Release 1.20.0 has been developed according to wolfSSL’s development and QA process and successfully passed the quality criteria.
Check out the ChangeLog for a full list of features and fixes, or contact us at facts@wolfSSL.com with any questions.
While you’re there, show us some love and give the wolfMQTT project a Star!
You can download the latest wolfMQTT release from our website or clone directly from our GitHub repository.
If you have questions about any of the above, please contact us at facts@wolfSSL.com or call us at +1 425 245 8247.
Download wolfSSL Now
Live Webinar: Advanced libcurl with Daniel Stenberg
Looking to master libcurl beyond the basics? Join Daniel Stenberg, creator of curl, for a live webinar on May 8th at 10 AM PT, focused on advanced libcurl techniques for real-world use.
This live webinar is ideal for developers integrating libcurl into performance-critical applications or anyone ready to explore libcurl APIs in depth.
Register Now: Advanced libcurl
Date: May 8th | 10 AM PT
What You’ll Learn:
- Libcurl debugging best practices
- Setting up complex transfer configurations
- Using transfer control for precision workflow
- Managing concurrent transfers with the Multi API
- Sharing resources through the Share API
- Simplifying URLs with the URL API
- Managing HTTP headers through the Headers API
This practical session will help you optimize, debug, and scale your data transfers. Whether you’re looking to manage concurrent transfers or dive into advanced libcurl APIs, this webinar will provide the expert guidance you need.
Register now to reserve your spot and learn from the creator of curl.
As always, our webinar will include Q&A throughout. If you have questions about any of the above, please contact us at facts@wolfSSL.com or call us at +1 425 245 8247.
Download wolfSSL Now
Chimera Certificate Standards Compliance
In the evolving landscape of cryptographic security, supporting multiple signature algorithms within a single certificate has become increasingly important. These certificates are known as Chimera certificates, a moniker coined by the X9.146 banking standards team. They provide enhanced security, flexibility, and agility, especially for the transition to post-quantum cryptography. As well, wolfSSL also understands the new TLS 1.3 CKS extension as defined by the X9.146 banking standard draft.
Chimera certificates are X.509 certificates that contain two public keys and signatures. These certificates are implemented through the use of three extensions:
- Subject Alternative Public Key Info (SAPKI): Contains an alternative public key
- Alternative Signature Algorithm: Specifies the algorithm used for the alternative signature
- Alternative Signature Value: Contains the actual bitstring of the alternative signature
In X.509 certificates, extensions can be marked as either “critical” or “non-critical.” Critical extensions MUST be understood and processed by the certificate validator. If a validator doesn’t recognize a critical extension, it MUST reject the certificate. Non-critical extensions can be safely ignored if not understood.
Before release 5.8.0, wolfSSL’s dual algorithm certificate implementation did not properly support the parsing of these extensions if they were marked as Critical. This was because the whole purpose of these extensions was to facilitate migration by allowing unmigrated systems to ignore the alternative public key and signatures. In that context, marking these extensions as critical made no sense.
That said, these extensions are standardized in the 2019 edition of the ITU-T X.509 standard. In that document, under recognition that there might be other future applications for these extensions, marking these extensions as critical is permitted.
The addition of critical extension support for Chimera certificates extensions represents an important compliance step. Without standards, interoperability would not be possible.
As the cryptographic landscape continues to evolve, especially with the ongoing transition to post-quantum algorithms, enhancements such as Chimera certificate support will become increasingly valuable. wolfSSL continues to demonstrate its commitment to providing a robust, standards-compliant, and forward-looking cryptographic library.
If you have question about any of the above, please contact us at >a href=”mailto”facts@wolfssl.com”>facts@wolfSSL.com or call us at +1 425 245 8247.
Download wolfSSL Now
wolfProvider Integration with nginx: Secure Your Web Server with wolfSSL FIPS Cryptography
Securing web servers with robust cryptography is essential in today’s threat landscape. wolfProvider offers a seamless way to enhance nginx security by integrating wolfSSL’s high-performance cryptographic implementations through OpenSSL’s provider framework. This integration allows nginx to leverage wolfSSL’s FIPS cryptography without modifying code.
What is wolfProvider?
wolfProvider is an OpenSSL provider that integrates the wolfCrypt FIPS cryptographic library with OpenSSL’s provider framework. It allows applications using the OpenSSL API, such as nginx, to seamlessly leverage wolfSSL’s FIPS approved cryptographic implementations without modifying application code.
Supported nginx Versions
Our continuous integration testing confirms compatibility with the following nginx versions:
nginx master branch
nginx release-1.27.4
Key Benefits for nginx users
- Enhanced Security: Access to wolfSSL’s FIPS 140-2/3 validated cryptographic modules for compliance requirements
- Optimized Performance: Benefit from wolfSSL’s highly optimized cryptographic implementations
- Seamless Integration: No modifications to nginx or openssl, a simple config file change enables new wolfProvider integration
- Comprehensive Algorithm Support: Full suite of modern cryptographic algorithms including:
- AES (128/192/256-bit with ECB, CBC, CTR, GCM, CCM modes)
- RSA, RSA-PSS for signing, verification, and key operations
- ECC with ECDSA and ECDH support
- SHA-1, SHA-2, and SHA-3 family hash functions
Testing and Verification
Our GitHub Actions workflows automatically test the integration to validate the following functionality:
TLS handshakes complete successfully
HTTP/2 connections work properly
Stream and mail modules function correctly
All cryptographic operations perform as expected
Stay updated with wolfProvider for ongoing enhancements! If you have questions about any of the above, please contact us at facts@wolfSSL.com or call us at +1 425 245 8247.
Download wolfSSL Now
wolfSSL Inc. SP800-140C, SP800-140D and Post-Quantum efforts update!
This is an update to previous post wolfSSL Inc. SP800-140C and Post-Quantum efforts update!
The National Institute of Standards and Technology (NIST) has recently updated its guidelines, enabling the certification of several post-quantum cryptographic algorithms through the Cryptographic Module Validation Program (CMVP). Notably, the digital signature algorithms ML-DSA (CRYSTALS-Dilithium), SLH-DSA, LMS, and XMSS are now fully certifiable under the updated SP800-140C standards. Similarly ML-KEM (CRYSTALS-Kyber) is fully certifiable under the updated SP800-140D standards!
In response to these developments, wolfSSL Inc. is proactively planning submissions to the CMVP for all except SLH-DSA. (If you would like to see SLH-DSA included please let us know sooner than later before we submit!)
wolfSSL Inc. has a strong track record in cryptographic module validation, having previously achieved FIPS 140-3 Certificate #4718 for its wolfCrypt Module, the world’s first SP 800-140Br1 validated certificate.
By staying ahead of regulatory changes and actively engaging in the certification process, wolfSSL continues to demonstrate its commitment to providing robust and compliant cryptographic solutions in the evolving landscape of post-quantum security.
As a reminder, be sure the January 1st, 2026 ESV soft transition does not catch you unprepared. The deadline for mandatory ESV validation across all FIPS modules is rapidly approaching. Leverage wolfSSL’s proven expertise to navigate this critical shift. Engage our staff now to architect a robust roadmap and guarantee a successful post-2026 FIPS compliance strategy!
We’d love to hear your feedback or input on this subject please do not hesitate to contact us at support@wolfSSL.com or fips@wolfSSL.com anytime!
If you have questions about any of the above, please contact us at facts@wolfSSL.com or +1 425 245 8247.
Download wolfSSL Now
wolfBoot Now Supports NXP’s New MCX A and MCX W Microcontrollers
wolfSSL is excited to announce that wolfBoot, our secure bootloader, now supports NXP’s MCX A and MCX W microcontroller families. This means developers can bring wolfBoot’s robust secure boot and firmware update capabilities to NXP’s latest low-power and wireless-enabled chips. The MCX A and MCX W series are NXP’s next-generation Arm Cortex-M33 based MCUs, designed for edge and IoT applications. Some topics we will explore today include:
- Secure boot and firmware authentication
- MCX A and MCX W series support in wolfBoot
- TrustZone-M support: supervising security
- Quantum-resistant cryptography
- Hybrid Dual-signature authentication
The MCX A series delivers a cost-effective, small-footprint MCU solution with autonomous, low-power peripherals for a wide range of industrial and IoT uses?.
The MCX W series, on the other hand, builds on that foundation by adding integrated wireless connectivity – a unified, pin-compatible platform supporting standards like Matter, Thread, Zigbee, and Bluetooth LE.?
Notably, the MCX W devices also incorporate NXP’s EdgeLock secure enclave technology, providing a built-in hardware security core (a hardware root-of-trust) for key storage and cryptography.?
These new MCUs combine efficient performance, ultra-low power operation, and advanced security features, making them an ideal match for wolfBoot’s secure boot capabilities.
With wolfBoot now running on MCX A and MCX W devices, manufacturers and developers using these chips can ensure that only authenticated, trusted firmware runs on their hardware. wolfBoot performs cryptographic signature verification of firmware at boot time, preventing unauthorized or malicious code from taking control of the device. This addition expands wolfBoot’s platform support and underscores our commitment to securing even the most resource-constrained embedded systems.
Coming soon, WolfSSL will further integrate wolfBoot with the TrustZone-M and hardware security features of the MCX family. In practical terms, this upcoming enhancement will allow wolfBoot to act as the TrustZone-M secure supervisor on these microcontrollers – running in the isolated secure world while the main application runs in the non-secure domain. By leveraging TrustZone, wolfBoot can maintain control over critical security resources: for example, cryptographic keys and operations can be confined to the secure domain. wolfBoot uses this isolation to implement a kind of lightweight hypervisor, meaning applications in the non-secure domain can invoke cryptographic functions without ever directly accessing the secret keys?.
This architecture greatly enhances security – even if an application or network-exposed code is compromised, the attacker cannot extract or misuse the most sensitive assets. Additionally, wolfBoot will make use of the MCX hardware root-of-trust capabilities (such as the EdgeLock secure enclave on the MCX W series) to anchor the boot process in silicon. This hardware-based trust anchor will let wolfBoot verify firmware authenticity using keys stored in tamper-resistant memory and even interface with secure key management services?.
The result is an extremely robust secure boot chain that takes full advantage of the MCX series’ built-in security features.
Another key advantage of wolfBoot on NXP MCX is its forward-looking cryptography, which is increasingly important for longevity in IoT products. wolfBoot already supports several post-quantum cryptography (PQC) signature algorithms – the kinds of digital signatures designed to withstand attacks by quantum computers. This includes hash-based signature schemes like LMS (Leighton-Micali Signature) and XMSSML-DSA, the newly standardized module-lattice-based signature algorithm (derived from the CRYSTALS-Dilithium PQC scheme)?.
These algorithms are quantum-resistant, meaning that unlike RSA or ECC, they are not known to be breakable by quantum computing. This is a critical consideration for future-proofing devices: experts warn that a sufficiently powerful quantum computer could one day defeat classical cryptography by solving the mathematical problems underpinning RSA/ECC much faster than a classical computer?.
By adopting PQC signatures, wolfBoot ensures that devices can remain secure even in a post-quantum future where older algorithms might be vulnerable.
What’s more, wolfBoot supports a hybrid dual-signature approach to firmware authentication.
In hybrid mode, each firmware image can be signed with both a traditional algorithm (e.g. ECDSA or RSA) and a post-quantum algorithm (like LMS or Dilithium). wolfBoot will verify both signatures, and it only boots the new firmware if both cryptographic checks pass. This dual-signing strategy provides defense-in-depth during the transition to PQC. Even if one of the signature algorithms were to be compromised (for instance, a future quantum breakthrough against ECC, or an unforeseen weakness in a new PQC scheme), the second signature still stands as a guardrail. Hybrid signatures also help with adoption: they allow new devices to be compatible with existing classical cryptography infrastructure while gradually introducing PQC, offering a graceful migration path?. wolfBoot’s support for hybrid authentication means developers don’t have to choose between today’s standards and tomorrow’s security – they can have both, ensuring firmware updates are secure against both conventional and quantum threats.
By extending wolfBoot to the NXP MCX A and MCX W families, WolfSSL is empowering developers to build the next generation of connected devices with strong confidence in their boot security. These MCUs are built to drive innovation in smart home gadgets, industrial sensors, wearables, and more – and with wolfBoot, each of those devices can boot up safely, verify its software integrity, and even perform field updates securely with minimal overhead. The combination of NXP’s silicon (with its low-power efficiency, wireless connectivity, and built-in security) and wolfBoot’s advanced secure boot features (from TrustZone supervision to post-quantum signatures) offers a powerful platform for long-term, resilient IoT deployments. As support for TrustZone-M and hardware root-of-trust on MCX devices rolls out, wolfBoot will fully harness the security architecture of these chips – essentially acting as a guardian in the secure world that oversees and protects the entire system from reset to runtime. With optional post-quantum and hybrid signature verification, wolfBoot on MCX is not only securing today’s devices but also future-proofing them for the cryptographic challenges of the years ahead.
WolfSSL’s focus remains on providing easy-to-use, strong security solutions for embedded developers. If you are developing on NXP’s MCX microcontrollers or are interested in bolstering your device’s boot security (with features like TrustZone isolation or quantum-resistant crypto), now is a great time to explore wolfBoot. Feel free to reach out to us at facts@wolfSSL.com to learn more, get sample projects for MCX A/W, or discuss how wolfBoot can help secure your next project. We’re excited to see what innovations the community will build on these new NXP platforms – and even more excited that wolfBoot will be there to keep those devices secure from the moment they power on.
If you have questions about any of the above, please contact us at facts@wolfSSL.com or call us at +1 425 245 8247.
Download wolfSSL Now
Partner Webinar: wolfSSL and Weston Embedded: Interoperability Partners in the IoT Space
Join us on May 1st at 10 AM PT for an insightful webinar, wolfSSL and Weston Embedded: Interoperability Partners in the IoT Space. Hear from wolfSSL Senior Software Developer Anthony Hu, Weston Embedded President and Co-Founder Janos Magasrevy, and Network Stack Lead and Co-Founder Yanko Sosa as they delve into the integration of secure and efficient MQTT communication within embedded systems, showcasing the collaboration between wolfSSL and Weston Embedded.
Register Now: wolfSSL and Weston Embedded: Interoperability Partners in the IoT Space
Date: May 1st | 10 AM PT
Unlock the power of Cs/NET, a commercial TCP/IP stack based on Micrium’s trusted technology. Its MQTT client module supports multiple broker connections for secure and scalable IoT communication.
Harness lightweight TLS with wolfSSL, built for embedded and RTOS environments. Pair it with wolfMQTT, a compact MQTT client supporting v3.1.1, v5.0, and MQTT-SN for secure, high-performance messaging.
What You’ll Learn:
- Company Introduction: wolfSSL and Weston Embedded
- Product Overview: wolfMQTT and Cs/NET
- Build and Setup Demonstrations: Step-by-step guidance on configuring wolfMQTT and Cs/NET
- Live Demo: Showcasing interoperability between wolfMQTT and Cs/NET
- Interactive Q&A Session
Don’t miss this opportunity to gain valuable insights into secure MQTT integration for embedded systems.
As always, our webinar will include Q&A throughout. If you have questions about any of the above, please contact us at facts@wolfSSL.com or Call us at +1 425 245 8247.
Download wolfSSL Now
Weekly updates
Archives
- May 2025 (17)
- April 2025 (24)
- March 2025 (22)
- February 2025 (21)
- January 2025 (23)
- December 2024 (22)
- November 2024 (29)
- October 2024 (18)
- September 2024 (21)
- August 2024 (24)
- July 2024 (27)
- June 2024 (22)
- May 2024 (28)
- April 2024 (29)
- March 2024 (21)
- February 2024 (18)
- January 2024 (21)
- December 2023 (20)
- November 2023 (20)
- October 2023 (23)
- September 2023 (17)
- August 2023 (25)
- July 2023 (39)
- June 2023 (13)
- May 2023 (11)
- April 2023 (6)
- March 2023 (23)
- February 2023 (7)
- January 2023 (7)
- December 2022 (15)
- November 2022 (11)
- October 2022 (8)
- September 2022 (7)
- August 2022 (12)
- July 2022 (7)
- June 2022 (14)
- May 2022 (10)
- April 2022 (11)
- March 2022 (12)
- February 2022 (22)
- January 2022 (12)
- December 2021 (13)
- November 2021 (27)
- October 2021 (11)
- September 2021 (14)
- August 2021 (10)
- July 2021 (16)
- June 2021 (13)
- May 2021 (9)
- April 2021 (13)
- March 2021 (24)
- February 2021 (22)
- January 2021 (18)
- December 2020 (19)
- November 2020 (11)
- October 2020 (3)
- September 2020 (20)
- August 2020 (11)
- July 2020 (7)
- June 2020 (14)
- May 2020 (13)
- April 2020 (14)
- March 2020 (4)
- February 2020 (21)
- January 2020 (18)
- December 2019 (7)
- November 2019 (16)
- October 2019 (14)
- September 2019 (18)
- August 2019 (16)
- July 2019 (8)
- June 2019 (9)
- May 2019 (28)
- April 2019 (27)
- March 2019 (15)
- February 2019 (10)
- January 2019 (16)
- December 2018 (24)
- November 2018 (9)
- October 2018 (15)
- September 2018 (15)
- August 2018 (5)
- July 2018 (15)
- June 2018 (29)
- May 2018 (12)
- April 2018 (6)
- March 2018 (18)
- February 2018 (6)
- January 2018 (11)
- December 2017 (5)
- November 2017 (12)
- October 2017 (5)
- September 2017 (7)
- August 2017 (6)
- July 2017 (11)
- June 2017 (7)
- May 2017 (9)
- April 2017 (5)
- March 2017 (6)
- January 2017 (8)
- December 2016 (2)
- November 2016 (1)
- October 2016 (15)
- September 2016 (6)
- August 2016 (5)
- July 2016 (4)
- June 2016 (9)
- May 2016 (4)
- April 2016 (4)
- March 2016 (4)
- February 2016 (9)
- January 2016 (6)
- December 2015 (4)
- November 2015 (6)
- October 2015 (5)
- September 2015 (5)
- August 2015 (8)
- July 2015 (7)
- June 2015 (9)
- May 2015 (1)
- April 2015 (4)
- March 2015 (12)
- January 2015 (4)
- December 2014 (6)
- November 2014 (3)
- October 2014 (1)
- September 2014 (11)
- August 2014 (5)
- July 2014 (9)
- June 2014 (10)
- May 2014 (5)
- April 2014 (9)
- February 2014 (3)
- January 2014 (5)
- December 2013 (7)
- November 2013 (4)
- October 2013 (7)
- September 2013 (3)
- August 2013 (9)
- July 2013 (7)
- June 2013 (4)
- May 2013 (7)
- April 2013 (4)
- March 2013 (2)
- February 2013 (3)
- January 2013 (8)
- December 2012 (12)
- November 2012 (5)
- October 2012 (7)
- September 2012 (3)
- August 2012 (6)
- July 2012 (4)
- June 2012 (3)
- May 2012 (4)
- April 2012 (6)
- March 2012 (2)
- February 2012 (5)
- January 2012 (7)
- December 2011 (5)
- November 2011 (7)
- October 2011 (5)
- September 2011 (6)
- August 2011 (5)
- July 2011 (2)
- June 2011 (7)
- May 2011 (11)
- April 2011 (4)
- March 2011 (12)
- February 2011 (7)
- January 2011 (11)
- December 2010 (17)
- November 2010 (12)
- October 2010 (11)
- September 2010 (9)
- August 2010 (20)
- July 2010 (12)
- June 2010 (7)
- May 2010 (1)
- January 2010 (2)
- November 2009 (2)
- October 2009 (1)
- September 2009 (1)
- May 2009 (1)
- February 2009 (1)
- January 2009 (1)
- December 2008 (1)