In October 2026 the Mbed TLS team announced that its current maintainers will stop working on the TLS and X.509 libraries in April 2027, one month after the 3.6 LTS branch reaches end of life. We covered what that means for shipping products in Mbed TLS After April 2027: What It Means for Your Product. In short, if your product depends on Mbed TLS, you need a TLS stack with a clear support plan.
wolfSSL is stepping in to fill that gap. Our Mbed TLS to wolfSSL Migration Guide already walks you through a port to the native wolfSSL API. For teams that would rather not touch their TLS code at all, we are now building an Mbed TLS 4.x compatibility layer in wolfPSA, designed as a drop-in replacement for Mbed TLS 4.x. The goal is simple: an application written for Mbed TLS 4.x links libwolfpsa.a in place of libmbedtls, libmbedx509 and libtfpsacrypto, and builds without source changes. It is the same approach as wolfSSL’s long-standing OpenSSL compatibility layer, now for Mbed TLS users.
Already in place: TF-PSA-Crypto compatibility
Mbed TLS 4.x moved its cryptography into TF-PSA-Crypto, and wolfPSA already covers the core of it:
- The PSA Certified Crypto API 1.4 plus the PQC extension, implemented on wolfCrypt
- TF-PSA-Crypto’s mbedtls/pk.h key parsing (RSA and EC keys, PEM or DER, traditional or PKCS #8), mbedtls/platform.h and tf-psa-crypto/build_info.h
- The TF-PSA-Crypto threading API, with a thread-safe build: make MBEDTLS_THREADING_C=1
- PSA_WANT_* macros generated from your wolfCrypt configuration, so a feature you did not enable fails at compile time, not at run time
- A Zephyr PSA Crypto provider, announced earlier, that keeps Mbed TLS crypto out of the image
More of the TF-PSA-Crypto mbedtls_* API, such as md, asn1, base64 and the rest of pk, is on the way.
Coming next: TLS, X.509 and networking
The new layer adds the Mbed TLS TLS, X.509 and network API on top of wolfSSL, enabled with make MBEDTLS_COMPAT=1:
- Same names: mbedtls_ssl_*, mbedtls_x509_*, mbedtls_net_* and mbedtls_pem_*, with the same headers, structs, return codes and feature macros. They are real functions, not macros, so code that looks them up by name, such as language bindings, works too.
- TLS 1.2 and TLS 1.3, client and server, with certificate verification, host name checks, session resumption and your own I/O callbacks through mbedtls_ssl_set_bio()
- X.509 certificate parsing from memory, files and directories, in PEM or DER
- Thread-safe TLS with MBEDTLS_THREADING_C
Next on the roadmap are verify callbacks and MBEDTLS_SSL_VERIFY_OPTIONAL, session tickets and session save and load, key exporters, PSK and DTLS. Every known difference from Mbed TLS behavior is documented, so you know up front what to check in your port.
Tested against Mbed TLS’s own code
We measure the layer against Mbed TLS itself, not just our own tests:
- Mbed TLS’s sample programs build unchanged and run against the wolfSSL example client and server
- Mbed TLS’s TLS test suite is being ported to run against the layer, so we can report exactly which of its tests pass
- curl, built for Mbed TLS, runs its TLS tests against the layer
Mbed TLS 4.x first
We are starting with Mbed TLS 4.x, the API that Zephyr 4.4 and ESP-IDF 6.0 ship today. Still on Mbed TLS 3.6 LTS? Let us know, since your input decides what comes next.
Once your application runs on wolfSSL, the rest of the stack is within reach: DTLS 1.3, post-quantum key exchange and authentication, FIPS 140-3 and commercial support from the team that writes the code.
Get Started
Development is happening in the open in the wolfPSA repository on GitHub, starting with the X.509 API, with TLS and networking to follow.
Want early access, or have an Mbed TLS application you would like us to try? Contact us at facts@wolfssl.com or +1 425 245 8247.
Download wolfSSL Now