Enterprise procurement has improved markedly at one specific question. Buyers now routinely ask vendors for a software bill of materials — an inventory of the components inside a product, so that when a widely used library turns out to have a serious defect, the buyer can determine within hours rather than weeks whether they are exposed.
The inventories being produced are genuinely useful, and they almost all stop at the same place. They describe the application, its dependencies, and usually the operating system underneath. They rarely describe the firmware: the code that runs on the storage controller, the network interface, the baseboard management processor, the power supply, the sensor. That code is beneath the operating system, boots before it and, in security terms, outranks it.
The provenance runs out two tiers down
The reason it is missing is commercial rather than technical. Firmware is typically written by whoever manufactured the component, several tiers down a supply chain, and licensed onward to the integrator who sold the finished machine. The integrator often does not hold the source, cannot answer questions about what is in it, and has no contractual right to publish an inventory of somebody else's product. Asked for firmware provenance, a vendor is frequently not being evasive. They genuinely do not know.
That would matter less if the update path were healthy. It is not. Applying a firmware update commonly requires taking the device out of service, sometimes requires physical access, and on a meaningful share of industrial and medical equipment requires a vendor engineer to attend. The result is a large installed base carrying defects that have been public for years, not because nobody noticed but because the remediation costs more than the organisation has decided the risk is worth.
Long-lived equipment is where this concentrates. A server is replaced on a cycle measured in years. A building management controller, an infusion pump, a substation relay or an industrial sensor is replaced on a cycle measured in decades, and its firmware was written against assumptions about network exposure that stopped being true long ago. Anything bought with the expectation of a fifteen-year life was bought with an implicit assumption that somebody would keep patching it, which was never in the contract — the same trap as a hospital device with a software end date.
What is beginning to move the question is not regulation and not procurement. It is underwriting. Insurers pricing operational-technology cover have started asking for firmware inventories and update commitments as a condition, and unlike a buyer, an insurer can price the absence of an answer rather than accept it — the same discipline now reaching software procurement through model contracts. That is the mechanism that has already worked once, when cyber insurers became the de facto regulators of corporate security by making specific controls a condition of cover.
The practical ask is narrower than a full inventory and considerably more useful. Buyers who have made progress are not demanding source code. They are requiring three things in the contract: a named component list to the controller level, a committed support horizon with an end date stated in writing, and a defined update mechanism that does not require an engineer on site. None of that is exotic, and all of it is far easier to obtain before signing than after — which is precisely the lesson open-source maintenance already taught the procurement function.
