Somewhere in your shipped microcontroller binary is FreeRTOS, lwIP, FatFs, mbedTLS or wolfSSL, a USB stack, maybe a vendor BLE library, and possibly a GPL or LGPL component someone ported years ago.
You pinned those versions and shipped. Since then, CVEs could have landed against the exact versions you're running, and license obligations you didn't know about may never have been satisfied. Nobody on your team is watching either one. We are.
"We have no idea which CVEs affect the firmware we already shipped."
The MCU world has the same third-party-component CVE problem as Linux, with almost none of the same tooling or awareness. No SBOM, no version record, no CVE-tracking habit. "Pinned and shipped years ago" is exactly the condition that quietly accumulates exposure in your network stack, TLS library, and RTOS.
"Nobody tracked the licenses on the code we ported to our chip."
Many embedded libraries are GPL or LGPL. The moment someone modified one to run on your microcontroller, they created a derivative work, and its obligations attached, usually without anyone realizing it. This is the part almost nobody offers to check, and it's the one that bites in an acquisition or a customer's diligence review.
The components are physically in your image. The obligation is real. No build pipeline will ever surface it for you.
LGPL lets you keep your code proprietary provided the user can relink against a modified library. On a statically-linked, microcontroller binary, there's often no way for anyone to relink, which can mean the terms were never actually satisfied, regardless of intent.
A GPL utility or driver ported into the firmware can carry copyleft obligations straight into code your team assumed was proprietary.
Chip-vendor SDKs and example code bundle components under several licenses, some with notice requirements that never made it into your shipped documentation.
Even MIT, BSD, and Apache code usually requires the license text and copyright notice to ship with the product. Most embedded products ship none.
The pressure is rising from both directions: the EU Cyber Resilience Act's SBOM expectations, and acquirers, customers, and procurement teams who increasingly ask for a license bill of materials, not just a vulnerability one. A firmware build that can't produce either is a liability in a sale, an audit, or a customer onboarding.
Four areas, scored, in a structured report you can hand to a manager or an acquirer's diligence team
What third-party code is actually in the firmware: RTOS, network stack, filesystem, crypto/TLS, USB, bootloader, vendor middleware, and at what version. On MCU projects the version is the hard part, because nobody recorded it. This is the deliverable you almost certainly don't have.
Each component and version matched against published CVEs and if affects your product. A CVE in a TLS feature you don't compile in is noise; one in your network stack's packet parser on an internet-facing device is critical.
For each component: its license, whether it was modified, and what obligations that combination creates for your product as shipped. You get a license bill of materials and a prioritized list of risks and remedies.
Can you even ship a fix? Do you have a working build, a bootloader that supports update, and signed-image capability? Plus config hygiene: TLS settings, RNG sourcing, debug interfaces left enabled, secrets in flash. A vulnerability you can't patch is the real exposure.
A fixed-fee assessment of one firmware project. Genuinely valuable on its own, whether or not anything comes after it.
The license review is an engineering-led identification of obligations and risks, with a recommendation to confirm anything that turns legal with qualified IP counsel. It is not legal advice, and CLI Systems is not a law firm.
Tell us about your product and we'll let you know if we're a fit, usually within one business day.
Can't even build the firmware to patch it? Start with an MCU and firmware rescue first. Shipping on embedded Linux instead? The same component problem on the Linux side is BSP maintenance.