Topic starter
23/10/2026 12:47 am
TL;DR: Firmware and dependency risk now sits inside xOT devices, with Dragos noting that network visibility will not reveal what is embedded in firmware and binaries. Provenance checks must reach the code under the asset, or operators cannot tell whether a build is trusted.
Editorial analysis by NHI Mgmt Group, based on content published by Dragos: “Software and Supply Chain Security Can’t Be an Afterthought in xOT Anymore”.
Key questions
Q: Why do long-lived xOT devices make supply chain risk harder to govern?
A: Long-lived devices widen the gap between the moment code was built and the moment it is still being used.
Q: How do security teams know whether SBOM and policy controls are working?
A: They should see complete component inventory, consistent policy enforcement in CI/CD, and fast tracing from a released artefact back to its dependencies.
Q: What breaks when firmware provenance is not tracked in xOT programs?
A: Programs lose the ability to distinguish a trusted build from one that contains abandoned libraries, hardcoded credentials or poisoned dependencies.
Practitioner guidance
- Establish binary-level provenance review Inspect compiled firmware and software images before deployment so embedded libraries, hardcoded credentials and unsafe components are visible before they reach production.
- Pair SBOMs with runtime validation Use SBOM generation as a starting point, then re-check what is actually running on the device and what changes when patches or firmware updates land.
- Classify supply chain findings by operational urgency Apply a risk tier to provenance findings so urgent issues are handled before deployment and lower-value noise does not stall the programme.
Bottom line: xOT supply chain risk is no longer a future concern, because firmware and dependencies can carry hidden exposure that network visibility will never reveal.
Glossary terms: Firmware Provenance, Software Supply Chain Risk, SBOM, Provenance Trust Gap
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 6 days ago by NHI Mgmt Group
23/10/2026 9:49 am
Software provenance is now part of machine governance, not just build hygiene. xOT operators can no longer treat firmware and open-source provenance as a vendor-only concern because compromised dependencies and embedded secrets become part of the operational trust model the moment a device is deployed. The governance issue is not whether a scan exists, but whether the programme can answer what is inside the binary at build, runtime and update time. Practitioners should treat provenance as a lifecycle control.
A few things that frame the scale:
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: What should xOT teams do when a vendor’s firmware update introduces new supply chain risk?
A: They should treat the update as a trust event, not a routine patch. That means checking what changed in the binary, whether the new dependency path is credible, and whether the update creates exposure that did not exist in the previous image. If the answer is unclear, the update should be held until the provenance question is resolved.
👉 Read our full editorial: Software and supply chain security now defines xOT risk
This post was modified 6 days ago by NHI Mgmt Group