An embedded platform that hasn’t been ported to and may be impractical to port to because it’s so different. There may be other reasons and for closed source there may be economic considerations especially since this is a migration from a previous closed source (probably source available) vendor to an in house solution.

MbedTLS has all the crypto primitives and runs anywhere.

And had so many stupid bugs that it looked like it was written by summer interns. Everybody I know who actually worries about actual security ran far, far away from it.

If, however, you just need https for web pages, it's good enough to get started.

Including the very, very limited environment of secure elements, and the capability of interfacing with the sometimes very specialized cryptographic accelerators/coprocessors required for adequate performance?

We're talking low double-digit kilobytes of persistent storage, and sometimes single-digit kilobytes of memory here.

Also, including a full TLS library seems like complete overkill if you only need some cryptographic primitives. These things are usually certified in expensive code and hardware audits; you essentially have to justify (in terms of adding complexity, and with it the possibility of vulnerabilities) and on top of that pay for every single line of code.

> Not sure why anybody feels the need to write their own crypto libraries these days

Because this is the second time they've had a security issue (the last time was even worse) because of their vendor? When your entire company is based around doing cryptography, it actually makes sense to hire enough applied cryptographers to own your own destiny.

When was the first time?

2017: https://www.yubico.com/support/security-advisories/ysa-2017-...

When was 5.7 released?

Around June of this year.