Software Due Diligence for Hardware and Embedded Software

Software due diligence for hardware and embedded software is the work most deal teams underestimate, because the software risk in a hardware company is buried inside the product rather than listed in a contract register. A target that makes devices, instruments, vehicles, or industrial equipment ships software in every unit: firmware it wrote, third party components it licensed, and open source it incorporated. Each layer carries license obligations that travel with the product, and a buyer that diligences only the corporate software estate misses the exposure embedded in the thing the company actually sells.

This guide sets out how to run software due diligence for hardware and embedded software so the buyer sees every license layer inside the product, not just the enterprise tools on the corporate network. It extends the core software due diligence method and connects to post close license reconciliation. For the component level open source discipline, pair it with software due diligence on open source components.

Why software due diligence for hardware and embedded software is different

Two things set embedded diligence apart. First, the software ships in the product, so license obligations attach to every unit sold and to every unit in the field, which means a breach can scale with shipment volume rather than seat count. Second, the obligations are often royalty bearing or redistribution governed, so the question is not only whether the target is licensed but whether it owes per unit royalties, whether it can transfer the right to ship to a new owner, and whether open source copyleft terms require source disclosure. None of this appears in a standard contract register, and none of it is visible from the corporate network.

The hidden license layers in a hardware product

An embedded product is a stack of license layers. At the base sits the operating system or real time kernel, often open source with specific attribution or copyleft terms. Above it sit third party libraries and middleware, frequently licensed on a per unit royalty. Then comes the target own firmware, which raises ownership and source escrow questions. Around all of it sit the build toolchain and any field update mechanism, each with its own license. The diligence job is to enumerate every layer, identify the license governing each, and test whether the rights the target relies on actually transfer to the buyer on the deal it is doing.

Royalties, redistribution, and open source in firmware

The two exposures that move a hardware deal are per unit royalties and open source copyleft. A third party component licensed at a royalty per unit creates a liability that grows with every device shipped, and a target that under reported shipments owes a back royalty that the buyer inherits. Open source copyleft, where incorporating a component obliges the distributor to make corresponding source available, can force a buyer to disclose code it considered proprietary or to re engineer the product. Both require a software composition analysis of the actual shipped binaries, not a reliance on the target own component list, because the list is almost always incomplete.

What change of control does to embedded licenses

Deal structure decides whether the right to ship survives. Many embedded component licenses carry change of control or anti assignment terms that let the licensor withhold consent, raise the royalty, or terminate the right to distribute when the target changes hands. In an asset purchase or carve out, where contracts must be assigned, these clauses turn from theoretical into immediate, and a refused consent can stop the product line. The buyer own counsel should confirm the legal interpretation, while the commercial diligence prices the royalty and the renegotiation. Apply the same contract reading discipline set out in reading a target software contracts in due diligence to every embedded license before the deal structure is fixed.

Document the embedded estate as a transferable record

The deliverable from embedded diligence is a bill of materials for the software inside the product, mapped to the license that governs each component and the obligation it carries. This record does double duty. Before signing it lets the buyer price the royalty, redistribution, and transfer exposure as a range the deal model can absorb. After close it becomes the working list the engineering and compliance teams use to clear copyleft obligations, renegotiate royalties, and replace any component whose license will not transfer. Without it, the same analysis has to be redone under time pressure once a product release or a licensor query forces the issue.

Keep the record current as the product evolves, because every firmware release can add a component and a new obligation. A target that ships frequently can drift out of compliance between diligence and close, so the bill of materials should be refreshed against the build that actually ships at completion. That discipline turns a one off diligence artefact into a living control the combined entity can rely on, and it is exactly the kind of evidence a publisher or open source enforcer will ask for if a dispute arises after the deal.

Why an independent buyer side advisor maps the embedded estate

The embedded estate is exactly the kind of exposure a target has no incentive to surface and a reseller has no reason to examine, because it lives in engineering rather than procurement. An independent, buyer side advisor with no affiliation to any publisher or reseller analyses the shipped product, maps every license layer, and prices the royalty, redistribution, and transfer exposure the buyer is about to own. That gives the deal team a defensible number before signing and a remediation plan for the firmware and components after close.