The branch file says 2029. The maintainers say April 2027.
Open the Mbed TLS repository today and read BRANCHES.md. It still promises that the 4.1 LTS branch, released in March 2026, "will be supported until March 2029."
Now read the announcement Janos Follath sent to the Mbed TLS lists on 8 October 2026. The existing maintainers "will cease their involvement in their development and maintenance of Mbed TLS from April 2027." Then the sentence that matters: "Unless new maintainers have joined the project and ramped up by that time, security incident response, security fixes, and releases will cease from April 2027."
Both documents are live. One of them is wrong. Paul Lajoie-Mazenc of Schneider Electric flagged the contradiction on the list on 12 October, and a month later the file still says 2029. Believe the email.
It made Hacker News on 3 November and barely registered. Most people never knowingly installed Mbed TLS. That's the whole problem. You didn't install it. Your devices did.
What stops and what keeps going
Mbed TLS 4.0 split the project in two. The cryptography moved into its own repository, TF-PSA-Crypto. TLS and X.509 stayed behind in Mbed TLS. The announcement cuts along exactly that line. TF-PSA-Crypto "remains an actively maintained part of the project." TLS and X.509 are the part looking for a new home.
So AES and ECDSA keep getting fixes. The code that parses the certificate your server sends and decides whether to trust it may not.
That's the worst half to lose. An X.509 parser chews on attacker-controlled bytes from the network before any trust exists. It's where the bugs are.
If you're on 3.6, nothing changed. Its LTS was always due to end in March 2027. The people who got burned are the ones who did the work to move to 4.x for the longer runway. Fabio Alessandrelli of the Godot engine project put it bluntly on the list: they had "just updated to version 4 to match the release and support schedule," and now that work looks wasted. Follath answered that the team "weren't aware that this was going to happen" when they announced the end of 3.x.
Why a server team should care
You run nginx on OpenSSL and have never typed mbedtls into a terminal. Look at who connects to you. Mbed TLS is the TLS stack under a big chunk of the embedded world.
Espressif's ESP-IDF, the SDK behind ESP32 chips, builds its TLS on it. Asked about the announcement on its GitHub tracker, Espressif said on 28 October "We will have more visibility by Q2 next year on this topic" and closed the issue.
Zephyr integrated Mbed TLS 4.1 and TF-PSA-Crypto 1.1 in Zephyr 4.4 this spring.
OpenWrt made mbedtls its default crypto library in 23.05. One of its reasons, verbatim: "mbedtls consistently provides updates via its Long Term Support (LTS) branch." That aged badly. An OpenWrt issue about it has sat open since 19 October.
The Matter smart-home SDK opened a tracking issue on 6 November. It also admits the bundled copy is still on 2.28, a branch whose last release shipped in March 2025.
Every one of those is a TLS client to somebody. Sensors posting telemetry to your API. Payment terminals calling your backend. Thermostats pulling firmware from your CDN. They check your certificate with Mbed TLS's X.509 code, and plenty of them will run whatever version they shipped with until the hardware dies.
After April 2027 those clients are frozen. And a frozen client becomes the tightest constraint on every certificate decision you make. Chrome updates itself every four weeks. A thermostat from 2026 will still be validating your chain in 2034 with exactly the code it has today.
Find the Mbed TLS clients that talk to you
You can't fingerprint a TLS library perfectly from the server. You can get close enough to build a list.
From your server logs
Embedded clients offer short, odd cipher and curve lists, and a lot of them keep their SDK's default user agent. ESP-IDF's HTTP client sends ESP32 HTTP Client/1.0 unless the firmware overrides it. Log TLS parameters next to the user agent for a week:
log_format tls_clients '$remote_addr "$http_user_agent" '
'$ssl_protocol $ssl_cipher '
'curves=$ssl_curves ciphers=$ssl_ciphers';
server {
listen 443 ssl;
# ... your existing config ...
access_log /var/log/nginx/tls-clients.log tls_clients;
}
Then count what's left once the browsers are filtered out:
awk -F'"' '{print $2 " |" $3}' /var/log/nginx/tls-clients.log \
| sort | uniq -c | sort -rn | grep -viE 'mozilla|chrome|safari' | head -30
The curve and cipher lists give them away. Browsers offer long lists, and Chrome mixes in GREASE values. A microcontroller offers four or five ciphers and maybe two curves.
On hosts and images you own
On Linux, Mbed TLS also ships as an ordinary shared library, and tools like curl and OpenVPN can be built against it:
dpkg -l 'libmbed*' 2>/dev/null | grep '^ii' # Debian / Ubuntu
apk info 2>/dev/null | grep -i mbedtls # Alpine, newer OpenWrt
opkg list-installed 2>/dev/null | grep -i mbedtls # older OpenWrt
curl -V | head -1 # shows mbedTLS/x.y.z if curl uses it
For firmware images and static binaries, grep for the version string. In 3.x it lives in libmbedcrypto, so it only shows up if the version module got linked in. On unstripped builds the symbol names are a decent fallback:
grep -aoE 'Mbed TLS [0-9]+\.[0-9]+\.[0-9]+' firmware.bin | sort -u
nm -C ./some-binary 2>/dev/null | grep -c 'mbedtls_ssl_'
Put what you find in the same inventory as your certificates. If that inventory is a spreadsheet nobody trusts, fix that first.
Test your certificate changes against an Mbed TLS client
Most teams test a new certificate in a browser and with openssl s_client. Those are the two most forgiving clients you'll ever meet. Mbed TLS is much stricter.
The Mbed TLS source tree ships a test client called ssl_client2. It builds in a couple of minutes and makes a good stand-in for your devices:
git clone --depth 1 --branch mbedtls-3.6.7 --recurse-submodules \
https://github.com/Mbed-TLS/mbedtls.git
cd mbedtls
python3 -m venv .venv && . .venv/bin/activate
pip install -r scripts/basic.requirements.txt
cmake -S . -B build -DENABLE_TESTING=OFF
cmake --build build --target ssl_client2 -j4
build/programs/ssl/ssl_client2 server_name=api.example.com server_port=443 \
ca_file=/etc/ssl/certs/ca-certificates.crt auth_mode=required
When it fails, you get an actual X.509 reason. Point it at incomplete-chain.badssl.com and it fails with The certificate is not correctly signed by the trusted CA, while a desktop browser that fetches missing intermediates loads the page without complaint.
Two flags get you closer to a real device. force_version=tls12 shows what a client that never got TLS 1.3 ends up with. max_frag_len=4096 asks for smaller records, the way a RAM-starved device would. Better still, swap ca_file for the exact CA bundle compiled into your firmware. Your laptop's trust store is irrelevant here. The device's is the one that decides.
Make this part of the checklist for any CA switch or chain change. Running it after the support tickets arrive is just debugging.
Three things that break frozen clients first
A missing intermediate
Mbed TLS doesn't fetch intermediates over AIA. Serve an incomplete chain and the device fails where Chrome quietly patches it up. We covered the browser side in missing intermediates. Now that CAs can leave out the AIA extension entirely, sending the full chain yourself is the only sane default anyway.
A root the device has never heard of
The device trusts the roots compiled into its firmware, full stop. When your CA moves you onto a new hierarchy, browsers catch up in weeks. A device whose TLS stack is abandoned is also a device whose CA bundle nobody will ever touch again. Watch your issuer chain as closely as you watch expiry dates, and keep at least one endpoint serving a chain the old fleet trusts. The mobile version of this problem is the same story with better-funded clients.
A chain that no longer fits
Embedded builds often shrink MBEDTLS_SSL_IN_CONTENT_LEN below its 16384-byte default to save RAM. Your certificate message has to fit in that incoming buffer. Add a cross-signed root, or move a leaf from ECDSA back to RSA, and you can push a handshake over a limit you didn't know existed. Older clients are worse off: before 3.6.3, Mbed TLS couldn't reassemble a handshake message split across several TLS records at all, and its changelog says that caused failures "especially with TLS 1.3 in practice." Keep device-facing chains short. Use ECDSA leaves.
One more failure has nothing to do with your certificate. CVE-2025-27809 showed that Mbed TLS clients which never call mbedtls_ssl_set_hostname() skipped the hostname check, so any certificate from a trusted CA could impersonate any server. Fixed in 3.6.3 and 2.28.10. A fleet frozen below those versions can be impersonated today. After April 2027, the next bug like it may never get a fix.
Your options before April
There are three. All of them cost something.
You can wait for new maintainers. The announcement asks organisations for engineers or money, and Schneider Electric said it's talking to partners about exactly that. Maybe it works out. But "maybe" is not a plan for a product that ships in 2027 and stays on a wall until 2037.
You can migrate. The HN thread kicked around wolfSSL, BearSSL and rustls, and each comes with a catch. wolfSSL's licensing needs reading. BearSSL has no TLS 1.3. Whether rustls fits on your microcontroller is something you'll have to test yourself. Be wary of the vendor posts telling you to switch to their library. They might be right. They're also selling.
Or you can own it: pin a version and pay engineers to backport fixes yourself. Realistic for a big vendor. Fantasy for an agency with forty client devices in the field.
Follath's own advice to a firmware engineer asking about new designs: evaluate alternatives anyway. If he started a project today he "would give a chance to Mbed TLS with some contingency planning." When the maintainer tells you to have a plan B, have a plan B.
What to do this quarter
If you build firmware, put the TLS library in your end-of-life register next to the chip and the RTOS. Pick your exit before Espressif and Zephyr pick one for you.
If you only run the servers those devices talk to, your job is smaller and more urgent. Find the clients. Build ssl_client2 once and wire it into your certificate change checklist. Serve full chains. A planned CA migration or root change is a fleet compatibility project now, and it deserves the same lead time as one.
This is also where automation needs a guardrail. With certificate lifetimes shrinking toward 47 days, your certificates will change far more often than your devices ever will. Every automated renewal that switches chain or key type is an unannounced test against clients that can't adapt. Somebody should look at the result before the thermostats do.
Frequently asked questions
Is Mbed TLS being discontinued? Not formally. The current maintainers stop working on the TLS and X.509 libraries from April 2027, and security fixes and releases stop then unless new maintainers have joined and ramped up. TF-PSA-Crypto, the separate cryptography library, stays actively maintained.
Does the March 2029 support date for Mbed TLS 4.1 still apply? Treat it as void unless new maintainers take over. BRANCHES.md in the repository still lists March 2029, but the 8 October 2026 announcement says security fixes stop in April 2027 without new maintainers, and the maintainer who sent it confirmed on the list that migration work to 4.x is now at risk.
Do I need to change my servers if I don't use Mbed TLS myself? You need to know which of your clients use it. Those devices will keep validating your certificates with an X.509 stack that may never be patched again, which makes them much less forgiving about incomplete chains and unfamiliar roots than any browser.
Can I detect an Mbed TLS client from the server side? Not with certainty. Logging the ciphers and curves a client offers next to its user agent, which nginx exposes as $ssl_ciphers and $ssl_curves, usually separates embedded clients from browsers well enough to build a list, and SDK default user agents such as ESP-IDF's often name the device outright.
Should new hardware projects still use Mbed TLS? Mbed TLS's own maintainer suggested evaluating alternatives either way and said he would only start a new project on it with contingency planning in place. If your device will still be in the field after 2027, decide now who patches its TLS stack and put that in the budget.
