When a water utility installs a sensor array to monitor pressure and flow across its distribution network, the procurement conversation typically centers on reliability, compatibility, and cost. Security may appear on the checklist — does the device support encrypted communications? does the vendor offer a support contract? — but the conversation almost never reaches the question that matters most: what is actually inside this device, where did those components come from, and who else has access to them?
That question is the supply chain provenance problem, and it is the most structurally underaddressed vulnerability in critical infrastructure cybersecurity today. It is invisible not because it is subtle, but because the incentive structures governing procurement, deployment, and operations have never required anyone to look. Further, because of market competition and need for speed to market pressures, providers can be demotivated to self-inspect/self-regulate to a sufficiently comprehensive depth.
The Multi-Vendor Stack Few Organizations Audit
A single IoT device — a sensor, a controller, a remote terminal unit — is not a monolithic object. It is a layered and interconnected system. The hardware substrate may come from one manufacturer. The operating system or firmware from another. The wireless protocol stack — Zigbee , LoRaWAN , cellular, etc — from a third. The business logic that governs what the device actually does with data may be licensed from a fourth vendor or written by a systems integrator who no longer supports the deployment. Cloud management functions may route through infrastructure the end operator neither owns nor controls or even has visibility into.
Each of those layers is a potential insertion point for malicious code, unauthorized access capability, or exploitable vulnerability. More importantly, each of those layers typically comes with its own update cadence, its own end-of-support timeline, and its own security disclosure practices — none of which are coordinated, and none of which the end operator is necessarily tracking.
Most operators interact with IoT devices at the interface level. They see readings, alarms, and dashboards. They do not see firmware version histories, component manifests, or the provenance of the cryptographic libraries handling their communications. This is true for many software libraries. When the device works — that green LED turns on or a parameter is successfully read — nobody looks inside. When it fails, the investigation focuses on restoring function, not on what the failure revealed about the underlying stack.
This is not negligence in the ordinary sense. It reflects a procurement model built for a pre-connected world — in a market of intense competition — applied to infrastructure that is now deeply networked and actively targeted.
Why Provenance Is So Hard to Establish
The concept of a Software Bill of Materials — a structured inventory of software components in a given product, analogous to an ingredient list — has gained regulatory traction following the Biden administration’s 2021 executive order on cybersecurity and subsequent CISA guidance. While SBOMs are a meaningful step, they are also far from universally implemented, inconsistently formatted, and largely absent from the OT and embedded device space where the risk is highest. While participation is still mandated for federal acquisitions, CISA’s general guidance remains voluntary. (The 2021 order was partially rolled back by the subsequent administration. CISA reached out for public comment on updated guidance in 2025, but that has not yet been made a regulatory requirement.)
The number of possible IoT component providers can grow quickly. Let’s say we use 10 components from the IoT Component Provenance Stack. For the sake of illustration, let’s say each component of a single IoT device is contributed to by three different providers. This could be in the form of small applications, library dependencies, frameworks, etc. At that point — only one layer down — that means that there could be 10 x 3 = 300 different potential providers of software, software components, possibly hardware, etc. Then go a layer down from there and say that each of those supporting components can also have three different supporting providers. So that means that the device could have 10 * 3 * 3 = 900 different potential providers. Then go one more layer down and say that that last provider also has three different potential providers of software components. So now we’re at 10 * 3 * 3 * 3 = 2,700 different potential providers.
Even in the first case of one layer down — 300 — that’s a lot of components to track and get attestations for. In doing this math, you can of course vary the number of inputs per layer and the number of layers. But even if you used something small like two layers down and two potential sub-providers per layer, you still get 10 * 2 * 2 = 40. That’s still a lot of software, components, libraries, and other items over which to garner provenance. And it is more likely, not less, to have multiple layers and multiple components. Software libraries alone are rich with dependencies on other libraries — often of unknown provenance — and this quickly compounds the “layers.”
The challenge is that getting attestation (or testing) for any one of those components is non-trivial. It takes labor, time, skillsets, and other resources to do this investigation and research. That is time not spent researching, developing, marketing, or selling the device. So a high level of provenance chasing can quickly become seemingly unfeasible in a competitive market with pressure for speed of deployment.
The operational technology sector compounds the problem. OT procurement has historically been governed by engineering departments optimizing for uptime, interoperability, and cost — not by security teams with supply chain visibility requirements. Devices installed five or ten years ago were evaluated against a threat model that did not include nation-state adversaries systematically pre-positioning in US infrastructure. Those devices are still running. And because there are a lot of them and it’s very resource intensive to get to them — think on towers, in machine rooms, in boiler rooms, underground — it is not easy or cheap to swap them out, and that fact demotivates system owners to do so.
Further, their component provenance was never documented at the time of purchase and cannot be reconstructed now without physical disassembly and firmware analysis that most organizations lack the expertise or resources to perform.
I made this argument before the U.S.-China Economic and Security Review Commission in 2018, and the core dynamic has not changed: the gap between what critical infrastructure operators know about what is inside their systems and what a sophisticated adversary can know about those same systems is wide, persistent, and growing. What has changed is that the adversary’s capability and intent are no longer speculative. And this is of course greatly exacerbated by the explosion of AI.
Artificial Intelligence, Mythos, and the Accelerating Provenance Problem
The supply chain provenance problem described above has existed for years. What has changed, abruptly and materially, is the speed at which adversaries can exploit it. The April 2026 announcement of Anthropic’s Claude Mythos model — and the concurrent launch of Project Glasswing, a restricted-access initiative involving twelve named launch partners plus more than forty major additional organizations — made explicit what security researchers had been warning about in more theoretical terms: AI systems have crossed a capability threshold that fundamentally changes the offensive threat calculus for critical infrastructure.
Mythos does not merely discover vulnerabilities; it autonomously builds exploits for them and chains those exploits together, executing what security researchers call full system takeovers with a substantial success rate on first attempt. For critical infrastructure operators already struggling to account for what is running inside their IoT and OT systems, this development carries a specific and uncomfortable implication: the opacity that made supply chain provenance a manageable background risk now makes it an acute foreground one. An adversary equipped with Mythos-class capability does not need to know in advance which components in your sensor array are vulnerable. It can find out faster than your security team can respond.
As AI scientist Dan Hendrycks has noted, models like Mythos make it dramatically easier for non-state actors — not just sophisticated nation-states — to target critical infrastructure. That observation matters for supply chain risk in a specific way: the barriers to exploiting obscure firmware vulnerabilities in legacy OT devices, which previously required deep specialist knowledge and significant time investment, are collapsing. The risk is particularly acute for operational technology environments in energy, utilities, manufacturing, water, and transportation — sectors where many systems are decades old and cannot be effectively patched. These are precisely the systems whose component provenance is most difficult to establish and whose security posture is most dependent on the assumption that finding and chaining their vulnerabilities requires effort that most attackers will not invest. That assumption no longer holds.
The defensive dimension of Mythos is real and should not be dismissed. Anthropic claims the model identified thousands of zero-day vulnerabilities across critical software in the weeks preceding its announcement, many of them decades old — vulnerabilities that had persisted undetected through every prior generation of security tooling. Project Glasswing represents a serious attempt to apply that capability defensively before adversaries develop equivalent offensive tools. The problem, as one analyst framed it, is that Project Glasswing will initially touch only a tiny percentage of the world’s vulnerable infrastructure — and the IoT and OT devices embedded in critical infrastructure will likely not be prioritized by a coalition of major technology firms scanning their own software stacks.
The net effect for supply chain provenance is this: AI-enabled vulnerability discovery has inverted the time asymmetry that operators have historically relied upon. The implicit assumption behind deferred patching, incomplete asset inventories, and unaudited component stacks was that turning latent vulnerability into active exploitation required time and expertise that constrained the threat. Discovery is now accelerating exponentially while remediation still moves at human speed. That asymmetry is the defining cybersecurity challenge of the next decade — and it hits hardest precisely where provenance is weakest.
(Note: much of the performance data comes from Anthropic itself and independent verification and validation is ongoing.)
The PRC Dimension
Chinese-origin components are not rare in the global IoT supply chain. They are dominant. This is not a function of covert insertion — it is a function of market share. Chinese manufacturers produce a substantial proportion of the world’s chipsets, sensors, wireless modules, and embedded controllers. Devices sold under Western brand names routinely contain Chinese-origin components at the hardware and firmware level. This is legal, documented in import records, and almost never surfaced in end-operator security assessments.
The concern is not that every Chinese-origin component contains a backdoor. The concern is structural: under China’s Military-Civil Fusion policy, Chinese technology firms operate under legal obligations to the state that have no equivalent in Western jurisdictions. Firms can be compelled to cooperate with intelligence and security services, to preserve access capabilities, or to provide technical assistance on demand. The legal framework that governs these obligations is real, enforced, and incompatible with the assumption of vendor neutrality that Western procurement has historically made.
The risk this creates is not a specific backdoor in a specific device. It is a pervasive opacity — a condition in which the components most likely to be present in critical infrastructure are also the components whose security properties are most difficult to independently verify, and whose vendors operate under the most permissive legal framework for state-compelled cooperation. That opacity is a strategic asset for an adversary conducting long-horizon infrastructure pre-positioning. It does not require active exploitation to be valuable. It simply needs to persist.
That opacity also facilitates PRC operations such as Volt Typhoon where US, and other countries’, critical infrastructure is quietly compromised for future use, most likely in conjunction with other cyberattack or even aspects of kinetic attack.
What Mitigation Actually Requires
The honest answer is that fully resolving the supply chain provenance problem is not currently possible at scale. The global IoT component supply chain is too fragmented, too opaque, and too deeply embedded in deployed infrastructure to be audited retrospectively in any comprehensive way. What is possible is a structured reduction in exposure — which requires accepting that reduction has real costs and organizational friction.
SBOM adoption as a procurement condition is the necessary starting point. Any new IoT or OT device entering critical infrastructure should come with a machine-readable component manifest. This will not happen voluntarily at scale; it requires regulatory mandate and procurement policy with teeth. The current voluntary framework is insufficient given the threat environment. CISA’s SBOM resources provide a starting point for organizations ready to move ahead of the regulatory curve.
Network segmentation that does not assume device integrity is the operational complement. If you cannot fully verify what is inside a device, you can constrain what that device can reach. Flat network architectures — in which IoT sensors have unfettered connectivity to enterprise systems, or in which OT networks are accessible from IT environments without effective control — are an invitation to lateral movement regardless of what is or is not in the device firmware. Segmentation is not particularly sexy. It is also not optional.
Continuous monitoring fills the gap that perimeter security and procurement controls cannot close. Behavioral anomaly detection in OT network traffic — baselining what normal communication patterns look like and alerting on deviations — is the primary mechanism for detecting exploitation of supply chain vulnerabilities after the fact. This requires OT-specific tooling and, more critically, the human expertise to interpret what the monitoring surfaces. That expertise is in short supply, which is its own compounding problem.
Zero-trust architecture], applied at the device and communication level rather than just the network perimeter, represents the direction of travel for mature deployments. Devices should authenticate before they communicate. Communications should be encrypted even on internal networks. Access should be scoped to what the device operationally requires, not what is convenient to configure and maintain. None of this is technically exotic. All of it is organizationally difficult in environments where operational continuity has historically taken precedence and where security has been perceived as friction.
The Policy Gap
Technology controls alone will not close the provenance gap because the provenance gap is not primarily a technology problem. It is a governance problem. Procurement standards that do not require component transparency create markets that do not supply it. Regulatory frameworks that treat IoT security as an afterthought — or that apply only to specific sectors while leaving others unaddressed — leave predictable gaps that adversaries can map and exploit.
The federal government has moved in the right direction with executive orders, CISA advisories, and the emerging SBOM regulatory landscape. The National Cybersecurity Strategy and NSM-22 both signal a policy direction that takes supply chain risk seriously. The pace of that movement does not match the pace at which sophisticated actors are mapping and pre-positioning in US infrastructure. Volt Typhoon’s confirmed multi-year presence in American critical infrastructure was not achieved through exotic zero-day exploitation. It was achieved through patience, legitimate credentials, and the structural opacity of systems whose operators could not fully account for what was running inside them.
Conclusion
The weakest link in critical infrastructure cybersecurity is not the device that fails the penetration test. It is the component inside the device that nobody thought to examine, sourced from a vendor nobody thought to audit, running firmware that has not been updated since the Obama administration or before. It is invisible not because it is hidden, but because the systems we have built — procurement, operations, regulation — were not designed to see it.
Making it visible requires accepting that security and operational convenience are in genuine tension, that the supply chain problem cannot be solved by individual operators acting alone, and that the threat environment has already adapted to the opacity we have normalized. The question is whether policy will adapt at comparable speed.
Further Reading
CISA Advisory AA24-038A — PRC State-Sponsored Actors Compromise and Maintain Persistent Access to U.S. Critical Infrastructure (Volt Typhoon). Cybersecurity and Infrastructure Security Agency, February 2024. https://www.cisa.gov/news-events/cybersecurity-advisories/aa24-038a
Benson, Chuck. Managing IoT Systems for Institutions and Cities. Taylor & Francis/CRC Press, 2019. The foundational practitioner framework for understanding IoT data pipeline risk, including supply chain exposure across the full sensor-to-output stack. Available through most research libraries.
CISA. Software Bill of Materials (SBOM) Resources. Cybersecurity and Infrastructure Security Agency. https://www.cisa.gov/sbom — The authoritative federal resource on SBOM standards, formats, and implementation guidance for critical infrastructure operators and vendors.
