Do mining machines need an SBOM for their firmware?

Yes. A haul truck, a conveyor controller or a ventilation panel runs firmware built from third-party components, and you cannot judge its risk without a list of what is inside. Ask each supplier for a bill of materials, covering software and hardware, and for a written patch process.

Why does a mine care about a component list?

Mines run operational technology: programmable systems that interact with the physical environment. NIST describes OT that way in its guide to OT security, SP 800-82 Rev. 3, and says securing it has to account for performance, reliability and safety. That last word matters. A patch that reboots a controller during a shift is a safety decision, not only an IT one.

You already track the model and serial number of every machine. You probably do not track the embedded Linux version, the TLS library or the web server inside its maintenance port. When a vulnerability is announced in one of those, you have no way to ask "do we own it?"

What is an HBOM, and how is it different from an SBOM?

An SBOM lists software components. A hardware bill of materials (HBOM) lists physical parts plus the firmware and configuration tied to them. CycloneDX describes its HBOM capability as a way to inventory hardware components for IoT, industrial control systems and other embedded and connected devices, and names manufacturing and critical infrastructure as places where hardware affects operational safety.

For a mine you want both, delivered together per machine model and firmware version. The software list answers "which libraries." The hardware list answers "which controller board and which firmware revision runs them."

Which standards give you something to point at?

The ISA/IEC 62443 series is written for several roles, and each role gets its own part:

• Asset owners, the mine: ANSI/ISA-62443-2-1 covers security program requirements.
• Service providers who maintain equipment on site: ANSI/ISA-62443-2-4.
• Product suppliers: ANSI/ISA-62443-4-1 covers a secure product development lifecycle, and 4-2 covers technical requirements for components.
• Patch management in the IACS environment has its own report, ISA-TR62443-2-3.

You do not need to certify anything to use these. Quoting the part numbers in a purchase specification gives a supplier a concrete document to answer against.

What should the contract say?

Keep it short and testable. Ask for:

• A machine-readable bill of materials for each firmware release, in SPDX or CycloneDX.
• A named contact and a time limit for telling you when a component in that list has a known vulnerability.
• A statement of how patches are tested and delivered, and what the supplier does when a patch cannot be applied during operations.
• Notice before the supplier ends support for a firmware line.

What to do

1. List your machines and controllers by model and firmware version. A spreadsheet is fine to start.
2. Request a bill of materials from the top ten suppliers by safety impact, not by spend.
3. Load what you receive into one inventory so you can search it by component name.
4. Check each list against known vulnerability data, and sort the results by what the equipment can affect physically.
5. Write down, per machine, who may approve a patch and what safe state the machine needs first.
6. Add the contract language above to the next purchase and the next maintenance renewal.

Where does Safeguard fit?

Safeguard generates and analyzes SBOMs in SPDX and CycloneDX, and its CLI can scan an SBOM file you receive from a supplier. That covers the software list. It does not replace the supplier's duty to publish accurate data, or your site's safety review before a patch.

Quick check

Sources

• NIST SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security
• ISA/IEC 62443 series of standards
• CycloneDX Hardware Bill of Materials capability

Last reviewed: 18 October 2026.