The IoT supply chain is the longest, most opaque attack surface in modern computing. It begins with silicon designed in one country, manufactured in another, flashed with firmware from a third, integrated into a finished device by a fourth, sold through a fifth, and connected to cloud services run by a sixth. Each handoff is an opportunity. In 2026, attackers have learned to take advantage of every one of them.
Three news cycles from May 2026 make the point with uncomfortable clarity.
On May 4, attackers breached the network of West Pharmaceutical Services, disrupting manufacturing, shipping, and receiving operations across multiple global facilities. Days later, Foxconn confirmed that the Nitrogen ransomware group had stolen 8TB of data — more than 11 million files — including, by the group's own claims, "hardware schematics and component details tied to customer projects" for major hardware partners. As one researcher quoted in the same report observed, the Foxconn breach "moves the ransomware conversation from operational disruption to long-term architectural risk." Once an adversary holds the schematics, the firmware images, and the network topology of the devices being built, supply chain compromise stops being theoretical.
The second hook is even closer to the IoT developer's everyday workflow. Beginning May 22, 2026, researchers at Socket Security disclosed the TrapDoor campaign — a coordinated multi-ecosystem supply chain attack spanning npm, PyPI, and Crates.io, with approximately 34 malicious packages across 384 or more versions. The payload validates AWS and GitHub tokens via live API calls, persists itself via cron, systemd, Git hooks, and SSH lateral movement, and even plants hidden AI configuration files designed to manipulate AI coding assistants into exfiltrating secrets during normal development sessions. This is not a hypothetical threat to IoT firmware pipelines. It is the modern shape of one.
The third hook is the dependency that has always been the weakest link: the device firmware itself. On May 12, 2026, threat actors began mass-exploiting CVE-2024-9643 — hard-coded administrative credentials in Four-Faith F3x36 industrial cellular routers, with no vendor-confirmed patch available. On May 17, a separate botnet (RondoDox) began re-weaponizing a 2018 ASUS router vulnerability against legacy devices that never received the original fix. The supply chain failure here is not a sophisticated zero-day. It is a credential baked into a firmware image years ago, sitting unpatched in production environments today.
Three stories, three layers of the same problem: firmware, dependencies, and the cloud-connected delivery infrastructure that ties them together.
The Three Layers of IoT Supply Chain Risk
Layer 1 — Firmware. Embedded firmware is where IoT supply chain risk is most concentrated and least visible. A typical industrial sensor, router, or PLC bundles dozens of open-source components, vendor SDKs, and proprietary blobs into a single image that is signed (sometimes), shipped to the device once, and then frequently forgotten. Hard-coded credentials, debug interfaces left open, outdated cryptographic libraries, and unpatched dependencies are the rule, not the exception. The Four-Faith and ASUS cases are not anomalies — they are this category's representative samples.
Layer 2 — Software dependencies in the build pipeline. Every modern IoT device is built by a development team that pulls thousands of transitive dependencies from public registries. The TrapDoor campaign demonstrated how dangerous that pipeline has become. An npm package compromised today can flow into a firmware build tomorrow, sign with the manufacturer's keys, and ship to millions of devices. The payload doesn't need to be obviously malicious — it just needs to be small, useful, and able to call home later. This is the layer that gets the most attention from sophisticated defenders and the least from device vendors operating on thin margins.
Layer 3 — The cloud and update infrastructure. IoT devices increasingly depend on cloud services for management, telemetry, and over-the-air updates. Every cloud endpoint, every API, every update server is part of the supply chain. A breach at the update server is a breach of every device that trusts it. A leaked signing key compromises every firmware image. The Foxconn data theft is troubling not because Foxconn itself runs IoT clouds, but because the stolen hardware schematics and network topology data accelerate every subsequent attack against the devices that depend on them.
What Regulators Are Doing — And Where the Gaps Remain
The EU Cyber Resilience Act has put the software bill of materials (SBOM) at the center of supply chain security. By December 2027, every manufacturer placing software-containing products on the EU market must generate, maintain, and provide SBOMs to surveillance authorities in machine-readable formats like SPDX or CycloneDX. The intent is right — defenders need to know what's actually inside the devices they operate, and incidents like Log4j showed exactly how much pain a missing inventory creates.
An SBOM is a flashlight, not a fire suppression system. It shows you what's in the device. It doesn't tell you whether the firmware is behaving normally, whether a dependency is silently calling out to an unexpected endpoint, or whether a router has just started accepting POST requests it didn't accept yesterday. SBOMs are necessary. They are nowhere near sufficient.
What Operators Should Actually Do
Five things matter more in 2026 than they did even twelve months ago.
1. Treat every device as untrusted, including the new ones. A device fresh out of the box is not clean. It is shipped with the firmware, credentials, and dependencies the manufacturer chose, which may include vulnerabilities the manufacturer doesn't yet know about. Onboarding workflows should assume compromise as the baseline and require behavioral evidence before granting trust.
2. Monitor behavior, not just inventory. SBOMs tell you what is supposed to be in the device. Network behavioral analysis tells you what the device is actually doing. The Four-Faith botnet activity, the RondoDox campaign, and most credential-theft supply chain payloads are detectable from network behavior long before they are detectable from inventory diffs. A device that suddenly starts beaconing to an unexpected destination is the same signal whether the compromise came from firmware, a dependency, or the cloud.
The reality of CVE-2024-9643 in industrial routers and CVE-2018-5999 in ASUS hardware is that vendor patches are not coming for many affected devices. Operators must compensate at the network layer — segmentation, monitoring, and autonomous containment of devices that begin behaving abnormally. Hoping the vendor ships a fix is not a strategy.
3. Assume legacy devices won't be patched. Build the operational response — segmentation, behavioral monitoring, automatic containment — into the assumption that vendor patches will arrive late, partially, or never. Plan the defense accordingly.
4. Inventory the cloud side of the supply chain too. Every cloud service the device connects to is part of the attack surface. Telemetry endpoints, configuration APIs, update servers — all should be inventoried, monitored, and segmented. A device cloud breach is a device fleet breach.
5. Build for SBOM, but operate for behavior. The CRA deadline is real and worth investing in. But the operational defense in 2026 and 2027 is behavioral — the ability to detect that a known device is doing unknown things, no matter where in the supply chain the compromise was introduced.
Ready to Secure Your OT Network?
Get a free risk assessment of your industrial environment.
Request Free AssessmentThe Defender's Bottom Line
The supply chain is too long and too opaque to be secured one link at a time. The defenders who do best in 2026 are the ones who stop trying to inspect every component and start watching every device.
Sources:
- Ransomware attacks on West Pharmaceutical and Foxconn — Industrial Cyber (May 2026)
- Vulnerability Intelligence Report (TrapDoor, Four-Faith, RondoDox) — Threat Modeling (May 25, 2026)
- EU CRA SBOM Requirements — Anchore (May 2026)
- Daily OT Security News — Viakoo (May 21, 2026)
- Does your business need an SBOM? — IT Pro (May 2026)