Mbed TLS needs new maintainers ready to take over by April 2027 or its TLS and X.509 libraries will stop receiving security fixes and releases. The existing team announced its planned departure on October 8, 2026. For developers choosing a library for products they expect to support beyond that date, the unresolved handover belongs in the dependency decision now.
The warning is several weeks old. Its deadline is conditional: successor maintainers could preserve support, and the team is seeking engineering help or funding. The announcement does not identify a replacement team.
Which components face the cutoff
Mbed TLS is a C library for TLS and DTLS connections and X.509 certificate handling. Its current README describes a small footprint suitable for embedded systems. It also includes TF-PSA-Crypto, a separate repository implementing the PSA Cryptography API.
That separation matters here. The maintenance notice says the existing maintainers will continue developing TF-PSA-Crypto. Continued cryptography maintenance therefore doesn't establish continued support for the TLS protocol and certificate libraries that use it.
The documented build produces libtfpsacrypto, libmbedx509 and libmbedtls. The TLS library depends on both of the others, while the X.509 library depends on TF-PSA-Crypto. For a dependency audit, that gives developers a concrete starting point: identify whether their application uses cryptographic operations alone or also relies on the affected connection and certificate code.
A support decision before the handover
An October 27 GitHub issue asks for the maintenance announcement to appear prominently on the project site and README so new users can make an informed choice. That request concerns visibility of the notice; it doesn't establish that a successor has been found.
For an existing product, the component dependencies suggest checking the actual build before planning a migration. Teams using TLS or X.509 should ask whoever supplies their library updates how fixes would reach the product after April, and allow time to evaluate another implementation if that answer remains unsettled.
Watch for a named successor team and a defined security-response arrangement before the April deadline. The outgoing maintainers have offered to help replacements take over; the next consequential update is whether someone accepts that responsibility.