What breaks when SBOMs do not match deployed firmware?

Why This Matters for Security Teams

An SBOM is only useful when it can be tied to the exact firmware actually running in the field. When the recorded component list describes one build while devices run another, teams lose evidence of exposure, patch status, and compensating controls. That is especially dangerous for embedded fleets, where firmware drift can persist long after a release is declared current. NIST Cybersecurity Framework 2.0 frames this as a visibility and asset integrity problem, not just a documentation issue.

NHIMG research shows why the gap matters in real environments: only 5.7% of organisations have full visibility into their service accounts, and the same visibility problem often appears in device estates where build provenance is weak. Incidents such as the Schneider Electric credentials breach and HPE Aruba Hard-Coded Secrets show how quickly trust breaks when deployed reality diverges from what security teams think they have. In practice, many security teams encounter exposure after an audit or incident confirms the fleet was never on the version they believed was deployed, rather than through intentional verification.

How It Works in Practice

When SBOMs do not match deployed firmware, the failure is usually in the chain from build to device. A release SBOM may describe the intended image, but manufacturing re-spins, field updates, regional variants, rollback events, or vendor-signed hotfixes can create multiple live versions that share the same label. Once that happens, vulnerability scanning becomes probabilistic because the team is comparing advisories against an assumed state rather than the actual binary on each device.

Practitioners usually need four linked controls:

• Firmware provenance, so each image is signed, versioned, and traceable from build to deployment.
• Device-level inventory, so the fleet reports the active firmware hash or release identifier at runtime.
• Release-to-deployment reconciliation, so the SBOM is mapped to the exact shipped artefact, not just the source build.
• Exception handling, so deviations such as emergency patches or hardware-specific builds are documented and reviewed.

This is where NIST Cybersecurity Framework 2.0 and supplier assurance practices help, but they only work if the organisation can verify what is actually running. For embedded and OT environments, the best practice is evolving toward signed attestations, immutable build metadata, and continuous comparison between the firmware manifest and the deployed image. That operational discipline also aligns with broader NHI governance lessons from the Ultimate Guide to Non-Human Identities, because provenance and visibility matter whenever machine identities and machine code are trusted to act on their own. These controls tend to break down when devices are offline for long periods because the inventory trail goes stale before the next verification cycle.

Common Variations and Edge Cases

Tighter firmware verification often increases operational overhead, requiring organisations to balance evidence quality against field support constraints. That tradeoff is most visible in mixed estates where older devices cannot report hashes, vendors provide incomplete manifests, or rescue images differ from production images.

There is no universal standard for this yet. Some teams treat the SBOM as a release artifact and rely on attestations to bridge the gap, while others require per-device firmware reporting before they accept a vulnerability assessment. Current guidance suggests the safest approach is to treat mismatched SBOMs as a control failure until proven otherwise, especially when third-party components, custom bootloaders, or unsigned rollback paths are present.

This matters in multi-vendor environments because the same model may ship with different component sets by region or contract, and that makes a single static SBOM misleading. In those cases, security teams should use the SBOM as one input, not the source of truth, and keep a separate record of the deployed firmware lineage for each asset class.

Related resources from NHI Mgmt Group

• What breaks when attackers use trusted authentication flows for initial access?
• What breaks when payroll identities are not tied to current employment status?
• What breaks when verification APIs and tokens are not governed as non-human identities?
• What failure mode does PAM not solve when identity state breaks?