TL;DR: xOT programs can no longer treat software and supply chain risk as a future concern, because AI-assisted development, compromised open-source dependencies and regulator scrutiny are shifting the attack surface into firmware and binaries, according to Dragos. Inventory and network monitoring are no longer enough when the vulnerable code lives underneath the asset itself.
At a glance
What this is: This is Dragos’s analysis of why xOT software and supply chain security can no longer sit behind network visibility, with firmware and binary-level provenance now treated as core risk.
Why it matters: For practitioners, the governance change is that xOT security now has to account for what is embedded in firmware and software supply chains, not just what appears on the network.
Context
Software supply chain risk in xOT is really a governance problem about what security teams can prove they know about the assets they run. Network visibility and patching still matter, but they do not surface hardcoded credentials, abandoned dependencies or poisoned build inputs buried in firmware and binaries.
That gap matters because xOT devices live longer, are changed less often, and often inherit upstream build decisions that the operator never sees. The identity angle is indirect but real: embedded credentials, code provenance and update trust all sit inside a broader machine and supply chain governance problem.
Key questions
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. Network monitoring can still show the device is online, but it cannot prove the code underneath remains trustworthy. That leaves operators blind to risks that only appear after deployment, during update cycles or when a dependency turns hostile.
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. The longer that gap, the more likely a dependency is abandoned, a maintainer disappears, or a vulnerability is discovered after deployment. Governance has to cover the full lifecycle, not just the initial build.
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. If teams still cannot answer what entered the build, where it came from, or why it was approved, the controls are not yet effective.
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.
Technical breakdown
Firmware provenance and binary inspection in xOT
Firmware provenance is the record of where compiled code came from, what it contains, and whether it was altered before deployment. In xOT, that matters because the operator often receives binaries rather than source code, so the real question becomes what secrets, libraries, or unsafe functions are already embedded in the device image. Binary inspection and SBOM enrichment try to recover that visibility after build, but they cannot change the fact that trust was established upstream. The mechanism is therefore defensive inference, not perfect assurance.
Practical implication: treat firmware provenance as a control surface, not an audit artefact, and inspect compiled images before they reach production.
Why SBOMs alone do not govern supply chain risk
An SBOM lists components, but it does not tell you whether those components are still trusted, whether a maintainer abandoned them, or whether a dependency was poisoned after the build. That is why a one-time SBOM check becomes stale quickly in xOT environments with long asset lifecycles. Governance has to span build time, runtime, and update time, otherwise the programme assumes that a clean compile remains clean forever. That assumption breaks when dependencies, maintainers, or threat conditions change.
Practical implication: pair SBOM generation with provenance checks, runtime validation and update-time review.
Supply chain findings need risk scoring, not blanket blocking
Not every dependency issue warrants the same response. In xOT, the useful pattern is triage, where findings are scored against operational context so teams can separate urgent exposure from low-value noise. That mirrors the logic behind risk-based maintenance programmes: if every issue is treated as critical, the programme stalls; if only a small fraction are escalated, the team can act before deployment or during a controlled change window. The key technical point is to connect code provenance to response priority, not just to detection.
Practical implication: align provenance findings to a risk tier so remediation is tied to operational urgency rather than alert volume.
Threat narrative
Attacker objective: The attacker wants to turn trusted firmware or dependencies into a persistent foothold inside xOT environments.
- Entry occurs when compromised open-source code, a poisoned dependency, or embedded hardcoded credentials reaches the firmware or software build pipeline.
- Escalation follows when that code is deployed into long-lived xOT assets that are monitored at the network layer but not at the binary or provenance layer.
- Impact is achieved when the malicious or unsafe component is exercised in production, creating a durable path for compromise or unsafe device behaviour.
Breaches seen in the wild
- GitHub code signing certificate theft 2022: A machine account's compromised token cloned GitHub's Desktop and Atom repos, exposing encrypted signing certificates later revoked.
- Shai Hulud npm malware campaign: Shai Hulud campaign: npm malware exposed secrets on GitHub.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
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.
Now, Next, Never works only if supply chain findings are risk-scored before deployment. The article is right to connect xOT supply chain risk to operational triage because not every code issue deserves the same response. What matters is whether a finding affects a deployed asset, a planned update, or a dormant dependency that will never execute in production. Practitioners should align provenance scoring to response urgency, not to tool noise.
Binary-level visibility closes the gap between inventory and trust. Traditional asset inventories tell you what exists, but they do not tell you whether the code running on those assets still reflects the assumptions made at compile time. That creates a provenance trust gap, where the operator believes the build is stable while the actual firmware may include abandoned libraries or hardcoded credentials. Practitioners should close that gap with continuous provenance review.
xOT security now intersects with identity governance through embedded credentials and update trust. Even though this is not an IAM article, the control failure is recognisable to identity teams: credentials buried in software, or update channels that cannot be trusted, create machine access paths outside normal lifecycle governance. The lesson for NHI and IAM programmes is that machine identity risk does not stop at certificates or tokens; it extends into how firmware and dependencies are introduced and refreshed. Practitioners should bring NHI-style lifecycle discipline to device software provenance.
Regulatory pressure is pushing xOT from visibility toward assurance. NERC CIP, NIS2 and TSA pipeline expectations are moving the question from where an asset sits to what it contains and how it was built. That shifts the control conversation from monitoring to evidence of provenance, patchability and update integrity. Practitioners should prepare for board and regulator questions about what is embedded in deployed code, not just whether the network is segmented.
From our research library:
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
- Read next: AI Supply Chain Security and AI-BOM Guide
What this signals
Provenance trust gap: xOT programmes now have to govern what is embedded in firmware, not just what is visible on the network. That means asset inventory, patching and monitoring are necessary but insufficient when binary contents can carry hidden risk across long device lifecycles.
The next programme boundary is update governance. If teams cannot verify what changes when firmware or dependencies change, they are managing exposure reactively rather than controlling it at the point of introduction.
For practitioners
- 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.
- Add supplier build trust questions to procurement Require answers about dependency provenance, maintainer continuity and update integrity when evaluating vendors for long-lived xOT assets.
Key takeaways
- xOT supply chain risk is no longer a future concern, because firmware and dependencies can carry hidden exposure that network visibility will never reveal.
- The operational challenge is not just knowing what assets exist, but proving what code and credentials are embedded inside them.
- Provenance review, SBOMs and update validation need to work together if operators want to limit risk before it becomes a production issue.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The article explicitly highlights hardcoded credentials and embedded secrets in firmware. |
| NHI-07 — Long-Lived Secrets | Long-lived device software makes stale credentials and dependencies persist far beyond build time. | |
| Recommendation — Scan firmware and build artefacts for embedded secrets before deployment and revoke exposed credentials immediately. Apply lifecycle controls to secrets and update channels so stale credentials do not survive into production images. | ||
| MITRE ATT&CK | TA0006;TA0010 — Credential Access; Exfiltration | The article’s risk model includes embedded credentials and malicious code inside supply chain artefacts. |
| Recommendation — Map build-pipeline risk to credential access and exfiltration techniques to prioritise provenance monitoring. | ||
| CIS Controls v8 | CIS-15 — Service Provider Management | The article focuses on vendor firmware, dependencies and procurement trust. |
| Recommendation — Assess supplier build practices and update assurance under service provider management controls. | ||
| NIST CSF 2.0 | PR.DS-10 — Integrity | Binary integrity and trusted updates are central to the article’s assurance problem. |
| Recommendation — Verify firmware integrity and update provenance before accepting devices into production. | ||
Key terms
- Firmware Provenance: Firmware provenance is the ability to trace a deployed device image back to the exact source components, build steps, and signing process that produced it. It gives teams evidence that a patch was actually built, validated, and delivered rather than merely accepted upstream.
- Software Supply Chain Risk: Software supply chain risk is the chance that code, build, deployment, or dependency paths are altered in ways that affect downstream systems. For AI code assistants, this risk rises when the tool can change source, trigger pipelines, or influence infrastructure definitions.
- SBOM: A software bill of materials is an inventory of components, dependencies, and often transitive packages used in an application or build. It gives defenders visibility into what entered the software supply chain and helps spot risky or newly introduced dependencies.
- Provenance Trust Gap: A provenance trust gap exists when a system trusts the source of stored data but fails to distinguish whether the content itself is safe to execute. In AI workflows, this gap appears when retrieved records or documents can influence agent actions without validation of origin, intent, or trust level.
Deepen your knowledge
The NHI Foundation Level course covers NHI governance, machine identity security, secrets management and workload identity through an accredited practitioner programme. It is designed for teams that need to connect identity governance to broader security operations.
Published by the NHIMG editorial team on October 16, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org