Firmware is part of the BOM. Treat it like one.

The processor is still orderable, the memory is still in production and the board has passed every electrical test. Then a security update, toolchain change or discontinued programming service makes the product impossible to support. The failed lifecycle assumption was not in the component list. It was in the code and infrastructure wrapped around it.

Firmware should be managed as a product dependency with an owner, version, source, build route and recovery plan. For connected and long-life equipment, that record is as important as the manufacturer part number.

Availability is wider than the physical part

A lifecycle review normally starts with the bill of materials. That remains necessary, but it misses bootloaders, binary blobs, device configuration, compiler versions, signing certificates, debug tools and supplier utilities. Any one of these can prevent a replacement build or a secure field update.

NIST Special Publication 800-193 frames firmware resilience around protection, detection and recovery. Although written for platform firmware, the practical test travels well: can the product prevent an unauthorised change, detect corruption and recover to a known state?

Put firmware into the change process

For every programmable device, record the approved firmware version, repository, build instructions, toolchain, programming fixture, configuration data and the person or team responsible. Keep the source release with the hardware revision that uses it. A generic link to the latest vendor package is not a reproducible build record.

A component substitution should trigger a firmware impact check even when the replacement is described as pin compatible. Device identifiers, initialisation sequences, timing, memory maps, calibration and error handling may differ. If the design depends on a closed supplier library, record its licence and long-term availability too.

Plan for keys and recovery

Secure boot and signed updates improve resilience, but they add dependencies. Signing keys need controlled ownership, backup and succession. Certificates and cryptographic algorithms can expire or become unacceptable during a long product life. The update mechanism should also tolerate interruption and provide a tested route back to a known-good image.

Design managers should ask for evidence that recovery works on production hardware, not only in a development environment. Buyers should ask whether the chosen device, security service and programming route have lifecycle commitments that match the end product.

The approval record changes

A robust lifecycle decision now covers the physical component, the executable code and the infrastructure needed to build, sign, load and recover it. Recording those dependencies early makes obsolescence work faster because the team can see whether an alternative is a parts purchase, a firmware change or a full platform decision.