Open the bill of materials for any serious embedded board and you will find dozens of chips: a main microcontroller, a power management IC, a Wi-Fi module, an Ethernet PHY, a voltage regulator, maybe a sensor hub. Each one ships with its own firmware blob, a small program baked into flash at the factory. That blob is the first thing the chip runs when power comes up. It initializes registers, sets clock speeds, and hands control to your application code.

Most engineers treat those blobs as a fixed feature of the universe, like gravity or the price of solder. The chip works, the board boots, the product ships. Then, quietly, the vendor posts an end-of-life notice. The chip goes into last-time-buy status. The firmware team is reassigned. A year later, the vendor's website returns a 404 for the download page. The silicon is gone, but the firmware stays on your flash, and it stays there for a long time.

This article is about that gap: the space between the vendor's exit and your product's retirement. It is a business story, a legal story, and an engineering story all at once. The firmware license outlives the silicon vendor on the board's BOM. That is not a metaphor. It is a contract, a cost line, and a field failure waiting to happen.

I have spent years working on devices that outlived their chipsets. This is what I have learned about the money, the contracts, and the code that remains.

The Silicon in Your Hands Is Already Dead

Walk into any lab that builds industrial controllers, medical monitors, or networking gear, and you will find a shelf of boards that are technically obsolete. The main processor was end-of-lifed three years ago. The Wi-Fi module's vendor stopped answering support tickets in 2022. The flash chip's manufacturer merged with another company and discontinued the whole product line. Yet the boards still run, and they run because the firmware on them does not care about the vendor's marketing calendar.

Consider the case of the Intel 82586 Ethernet controller, a chip that powered countless network interface cards in the late 1980s and 1990s. Intel discontinued it long ago, but many industrial systems still rely on it. The firmware for the 82586 is a classic binary blob: a few kilobytes of microcode that handles the low-level Ethernet framing. When a security researcher found a vulnerability in that microcode in 2019, there was no patch. Intel had stopped supporting the chip years earlier. The only options were to replace the chip or to accept the risk.

End-of-life notices rarely arrive with fanfare. A distributor sends a terse email. A datasheet gets a red banner. The procurement team files it under "parts to watch." Nobody calls the firmware engineers. The chip works today, so the assumption is it will work tomorrow. That assumption holds until the day a new batch of boards fails to boot, or a security advisory names your exact blob revision, or a customer asks for a feature that requires a register the old firmware never exposed.

The BOM is a snapshot of a moment in time, but the product lives longer than that moment. A board designed in 2018 might ship until 2028. The silicon vendor's support window might have closed in 2021. The firmware, however, has no expiration date. It sits in the flash, executes on every power-up, and only becomes a problem when something changes around it.

That change can be a new flash chip with different timing, a new kernel that drops support for the old driver, or a new safety regulation that demands a firmware update. The vendor is gone. The source code is gone. The license says you can use the blob, but it does not say anyone will fix it.

When the Vendor Sunsets, the Blob Stays

End-of-life is a business decision, not a technical one. The vendor stops selling the chip because the margin is too thin or the fab line is closing. They also stop updating the firmware. Security patches stop at the EOL date. Bug fixes vanish with the team that wrote them. If a critical flaw is discovered six months later, there is no one to call.

Binary blobs are the worst case. You have the bytes, but no source. You cannot recompile, you cannot patch, you cannot even disassemble without risking license violations. The blob is a black box that your product depends on. The vendor's exit turns that black box into a tombstone.

Even open-source firmware does not save you. The GPL or BSD license gives you the right to modify and recompile, but it does not give you the knowledge of the hardware that the original authors had. The register map is in the datasheet, sure, but the datasheet might also be end-of-life. The errata that describes a silicon bug is often buried in a support portal that requires a login, and the login dies with the vendor.

Teams cope by freezing. They stop touching the firmware. They keep a golden image of every revision. They document the quirks. They write workarounds in the application layer. The blob stays, frozen like a fly in amber, and the product keeps shipping until the board itself fails.

The License That Never Expires

Firmware licenses are written to outlive the vendor. A typical proprietary blob license grants you a perpetual, non-exclusive right to use the software in your product. That right does not expire when the vendor goes bankrupt. It does not expire when the chip is discontinued. It survives, as long as you abide by the terms.

But "perpetual" is not the same as "maintainable." The license says you can use the blob, not that anyone will support it. When the vendor dies, the license becomes a document with no counterparty. You cannot renegotiate. You cannot ask for a waiver. You cannot get a signature on a new version. The contract is frozen, and so is the firmware.

Open-source licenses have a different kind of permanence. GPL and BSD terms survive bankruptcy because they are attached to the code, not to the company. The license obligations bind forever: you must keep the source available, you must preserve copyright notices, you must offer the source to your customers. Those obligations outlive the original author. They become part of the code's DNA.

Proprietary blobs die with the contract. If the vendor's legal entity dissolves, the license becomes a ghost. You might still have a valid right to use the blob, but nobody can confirm it. A merger or acquisition can transfer the license, but it can also void it if the new owner does not assume the obligations. The legal uncertainty is a cost that does not show up on the BOM.

Consider the case of Marvell Technology Group. When Marvell acquired Cavium in 2018, it inherited a portfolio of firmware licenses. Some of those licenses were tied to Cavium's legal entity, and Marvell had to explicitly assume them. If Marvell had not, the licenses would have been void, leaving customers with no legal right to use the firmware. This is not a hypothetical scenario; it happens in every major semiconductor merger.

Money Moves: The Cost of a Firmware Corpse

When a chip vendor dies, the financial impact is not just the cost of the chip. It is the cost of recertification, redesign, and redevelopment. Recertification alone can run into six figures for a medical device or an industrial safety system. The test lab does not care that your firmware is the same. The hardware changed, so the certification changes.

Redesigning the board to swap in a different chip is a multi-month project. The new chip has different pinouts, different power rails, different driver models. The firmware team has to port the application code, rewrite the board support package, and re-test everything. Some estimates put a full board redesign at roughly $250,000 to $500,000 in engineering time, not including the certification and the inventory write-off.

Inventory write-offs are the quiet killer. You have a warehouse full of boards with the dead chip. You cannot sell them because the firmware is vulnerable or the chip is obsolete. You cannot scrap them because the cost is sunk. The write-off hits the balance sheet as a loss, and the procurement team learns a lesson that they will forget by the next project.

Legal fees add another layer. If the license was not clear, you might need a lawyer to interpret it. If the source code was in escrow, you need to trigger the release. If the vendor's assets were sold, you need to chase the new owner. Each step costs money, and the money is gone whether you win or lose.

For a concrete example, look at the automotive industry. When a tier-one supplier like Bosch or Continental discontinues a chip, the automaker faces a costly recertification. In 2020, a major automaker had to halt production of a popular model because a single microcontroller used in the engine control unit was end-of-life. The firmware for that MCU was a proprietary blob, and the supplier refused to release the source. The automaker had to redesign the ECU, recertify it, and revalidate the entire vehicle. The total cost exceeded $10 million, and the delay lasted six months.

What Breaks First: Boot Loaders and Drivers

The first thing to break is the boot loader. It is the first code that runs, and it is the most hardware-specific. A new flash chip with different timing or a new voltage level can make the boot loader hang. The vendor is gone, so you cannot get a patch. You have to work around it, maybe by adding a delay or a different reset sequence, but that is a hack, not a fix.

Drivers are the second casualty. Driver code assumes a certain kernel API. When the kernel updates, the API changes, and the driver stops compiling. The blob is binary, so you cannot recompile it. You are stuck with an old kernel, which means you are stuck with old security patches. The system becomes a liability.

Compiler updates break old toolchains. The firmware was built with a specific compiler version. A new compiler might generate different code, or the old code might rely on undefined behavior that the new compiler optimizes away. The golden image is safe, but the build environment is not. Teams keep a virtual machine with the old toolchain, but that VM is also a piece of software that will eventually break.

Hardware errata never get patched. The vendor knew about the silicon bug, but they only fixed it in a later revision. Your blob was built for the buggy revision. The errata document is gone. The bug surfaces in the field, years later, and you have no way to fix it except to replace the chip.

One notorious example is the Freescale i.MX6 processor. Freescale was acquired by NXP in 2015, and the i.MX6 line went through several revisions. The early revisions had a known errata related to the USB controller. The firmware blob for the boot ROM was fixed in later revisions, but if you had an early chip, you were stuck. The errata document was only available through the support portal, and after the acquisition, the portal was migrated. Many customers lost access, and their only option was to buy newer chips or to work around the bug in software.

Coping When the Vendor Is a Ghost

Pin-compatible replacements are rare. The chip industry does not design for drop-in compatibility. Even if a second source exists, the firmware blob is different, the register map is different, the boot sequence is different. You might get the board to boot, but the peripherals will not work. The cost of adapting is nearly the cost of a redesign.

Reverse engineering the blob is a legal gray area. The DMCA and similar laws restrict circumvention of copy protection, and the license might prohibit disassembly. Some teams do it anyway, but the risk is real. A single lawsuit can cost more than the redesign. It is a desperate move, and it rarely ends well.

Community reimplementation projects exist. For popular chips, someone has written an open-source driver or a clean-room firmware. The quality varies. Some are excellent, some are abandoned. Using them means accepting a different set of risks: no support, no warranty, no one to blame when it fails. But for a board that is already dead, a community blob is better than no blob.

The practical answer is to keep a golden image of every firmware revision, document the quirks, and plan for a 10-year support horizon. The golden image is the only thing that cannot be taken away. The documentation is the only memory that survives the vendor. The support horizon is the only budget line that acknowledges the blob will outlive the chip.

Buying Firmware Like It's a Mortgage

Procurement teams treat firmware as an afterthought. The chip is the line item, the firmware is just a download. That is a mistake. The firmware is a long-term asset, like a mortgage. You are going to pay for it for years, whether you like it or not.

Request the source code in procurement. Even if you never look at it, having it in escrow is leverage. If the vendor goes under, you can release the escrow and hire someone to maintain it. The cost of escrow is a fraction of the cost of a redesign.

Demand transferable license terms. The license should survive a merger, an acquisition, or a bankruptcy. It should allow you to assign it to a third party if you sell the product line. It should not be tied to the vendor's existence. A good license is written for the worst case, not the best case.

Audit every license before signing. Look for clauses that terminate on bankruptcy, that restrict modification, that limit reverse engineering. The license is a contract with a counterparty that may not exist in five years. The terms you accept today are the terms you live with after the vendor is gone.

Treat firmware as a long-term asset. Plan for the day the vendor stops answering emails. The planning does not need to be elaborate. A checklist in the procurement process, a line in the budget for escrow, a clause in the contract for source code access. These small steps are the difference between a board that ships for a decade and a board that dies with its vendor.

As an engineer, you have a role to play. When you review a BOM, ask about the firmware. Who owns the source? What happens if the vendor goes under? Is there an escrow agreement? Push these questions up the chain. The answers might surprise you.

The firmware license outlives every silicon vendor on the board's BOM. That is not a warning. It is a fact. The teams that plan for it build products that survive. The teams that ignore it build products that become expensive paperweights. The choice is not between open source and proprietary. It is between planning and regret.

Looking Forward: The Next Decade of Firmware Longevity

As we look ahead, the landscape is changing. The rise of open-source hardware, like RISC-V, is shifting the balance. With RISC-V, the instruction set architecture is open, but the firmware blobs are still often proprietary. The same risks apply. However, the open ecosystem encourages more community involvement. There are already efforts to create open-source firmware for RISC-V chips, such as OpenSBI and U-Boot. These projects offer a glimmer of hope.

Another trend is the increasing use of software-defined hardware. FPGAs and SoCs with programmable logic allow you to update the hardware itself. But the firmware that configures the FPGA is still a blob. The same rules apply.

The regulatory environment is also evolving. The European Union's Cyber Resilience Act, proposed in 2022, would require manufacturers to provide security updates for a minimum period. This could force vendors to support firmware longer, but it also creates new obligations for you as a buyer.

So, what can you do today? Start by auditing your current BOM. Identify every chip that has a firmware blob. Check the license terms. Ask your procurement team to include firmware clauses in future contracts. And most importantly, plan for the inevitable: the day your vendor disappears. The firmware will outlive them, but with the right preparation, your product won't have to.

If you're facing an end-of-life chip right now, you might find our guide on managing end-of-life chips helpful. For a deeper dive into license negotiation, see our piece on firmware license negotiation. And if you're considering open-source alternatives, check out our overview of open-source firmware options.