Why do supplier SBOMs not fully prove OT device security?

What supplier SBOMs can tell you, and what they cannot

A supplier SBOM is useful evidence of declared software ingredients, but it is not a security certificate for the OT device itself. It can tell you what the vendor says is in scope, yet it does not prove how the firmware was built, what was left out, or whether the delivered image matches the reviewed bill of materials. The same gap matters whether you are buying a controller, gateway, HMI, or embedded appliance.

An SBOM is strongest when it is paired with device-specific evidence, such as signed firmware, release provenance, and a validated update path. For that reason, OT procurement teams should treat the SBOM as one input to assurance rather than the final proof of security, and they should validate the delivered device against the stated build and release artefacts.

Supplier-facing SBOM practice is best understood as part of a broader OT assurance process, not a standalone control. NHIMG’s SBOM operations guide focuses on intake validation, per-release storage, matching, and triage states, which are the follow-on tasks that turn an SBOM into something operationally useful.

Why OT device security can still be weak even with an SBOM

OT devices often fail in the places an SBOM cannot inspect. A device may ship with exposed management services, insecure defaults, undocumented components, stale firmware, or a later replacement image that diverges from the vendor’s declared component list. That means the real risk sits in the delivered state, not only in the declared parts list.

OT environments also rely heavily on firmware lifecycle discipline. If firmware updates are unsigned, poorly validated, or inconsistently applied, the device can remain exposed even when the component inventory looks complete. In other words, component transparency helps, but it does not establish operational security, especially where field devices are deployed for long periods and may be difficult to inspect directly.

For a wider procurement lens, NHIMG’s OT Product Procurement Guide explains how buyers should ask for evidence, not just declarations, when evaluating OT security claims.

What to verify on the actual device before trusting the supplier evidence

The practical question is whether the installed device behaves like the supplied evidence says it should. That means checking the firmware image, update mechanism, exposed interfaces, configuration baseline, and vulnerability status on the device that will actually operate in the plant, not only in the lab or sales process.

Where possible, compare the vendor SBOM to the firmware hash, release manifest, and signed update package. Then confirm whether management ports, remote access paths, and hardening settings align with the device’s intended role. If the device is already in service, use the SBOM to support vulnerability matching, but use on-device validation to decide whether the device is trustworthy enough to remain connected.

OT asset context matters here because the same SBOM may mean very different things on different hardware, firmware branches, or site configurations. NHIMG’s OT Asset Visibility Guide is relevant because it frames inventory, firmware awareness, and KEV matching as part of continuous device oversight.

Practitioner Guidance

What to verify: Require the delivered firmware image, signed update evidence, and a device-level configuration check before accepting a supplier SBOM as meaningful assurance. If you cannot compare the running device to the declared build, the SBOM should be treated as informational only.

Decision rule: If the device exposes a management interface, accepts firmware updates, or can affect a production process, prioritise firmware provenance, patchability, and hardening validation over component completeness. If those controls are weak, the SBOM should not lower your security rating on its own.

Practitioner takeaway: An SBOM improves visibility into what was declared, but OT security is proven by the shipped firmware, the update path, and the device’s live configuration, not by the parts list alone.

Related resources from NHI Mgmt Group

• Device Security
• What is the difference between device security and identity governance in ot?
• What do security teams get wrong about supplier SBOMs?
• Why do organisations struggle to prove endpoint security controls are effective across every device?