Why do routers and IoT devices matter in supply chain attacks?

Why This Matters for Security Teams

Routers and IoT devices matter because they often sit outside the visibility of standard endpoint and identity controls, yet they can still carry sensitive traffic, preserve access, and support covert operations. In supply chain attacks, that makes them attractive as durable footholds or proxy layers rather than simple one-off compromise targets. Guidance from CISA cyber threat advisories consistently shows that attackers prefer infrastructure that is difficult to inventory, patch, and monitor.

The security risk is not only initial compromise. These devices can be reused to mask command-and-control, relay malicious updates, or route traffic through trusted-looking networks. That changes the incident from a perimeter issue into an integrity and trust issue across procurement, vendor onboarding, and operations. Security teams often over-focus on laptop and server telemetry, while the compromise already exists in unmanaged network gear and embedded systems that were never included in continuous assurance. In practice, many security teams encounter this only after unusual traffic patterns or third-party breach notifications have already exposed the compromise.

How It Works in Practice

Attackers usually look for weak administration, exposed management interfaces, default credentials, outdated firmware, or insecure supply chain dependencies in the device ecosystem. Once inside, they may install lightweight persistence, redirect traffic, or use the device as a relay node to hide their source. The result is a distributed infrastructure layer that is resilient, low-cost, and hard to attribute.

From an operational standpoint, defenders need to treat routers and IoT devices as part of the attack surface, not just as assets that support it. That means segmenting them, limiting outbound communication, enforcing unique administrative access, and verifying firmware provenance before deployment. It also means building detection around behaviour, not just signatures, because many of these devices cannot run traditional EDR or full agent-based monitoring. Mapping likely abuse paths to the MITRE ATT&CK Enterprise Matrix helps teams identify where credential theft, proxying, remote services, or persistence may appear in the kill chain.

• Inventory all connected routers and IoT assets, including unmanaged or lightly managed devices.
• Restrict management access to approved administrative networks and strong authentication paths.
• Apply firmware validation, update governance, and secure boot where the hardware supports it.
• Monitor for abnormal DNS, routing, outbound proxy, and beaconing behaviour.
• Use network segmentation to prevent a single embedded device from becoming a lateral-movement bridge.

For AI-enabled environments, the issue expands further because embedded devices may also support automated workflows, telemetry, or agentic tooling that depends on trusted network paths. Where those paths are compromised, security teams may inherit an identity and trust problem as well as a network one. These controls tend to break down in highly distributed environments with long hardware replacement cycles because device ownership, patchability, and telemetry coverage are inconsistent.

Common Variations and Edge Cases

Tighter control over routers and IoT devices often increases operational overhead, requiring organisations to balance resilience against patch cadence, vendor constraints, and service uptime. There is no universal standard for every embedded environment yet, especially when devices are managed by third parties or embedded in critical operations. Current guidance suggests prioritising compensating controls when firmware updates are slow or unsupported.

Some environments create additional edge cases. Industrial, retail, healthcare, and remote branch deployments may rely on devices that cannot support modern agents, full logging, or frequent reboot cycles. In those cases, network-level enforcement and procurement standards matter more than endpoint tooling. For AI and automation stacks, device trust can also intersect with model orchestration and non-human identity governance if a compromised router or gateway is used to redirect service credentials or API traffic. That is where NHI controls become relevant even in a mostly cyber-focused question, because the device may be supporting machine-to-machine trust relationships. Security teams should also consider vendor lifecycle risk, spare-part sourcing, and whether a device is still receiving security fixes from the manufacturer.

For broader control mapping, NIST control guidance such as NIST SP 800-53 Rev 5 Security and Privacy Controls remains useful for hardening, monitoring, and access governance, while ENISA Threat Landscape materials help teams understand how embedded and network devices are used in real campaigns.

Related resources from NHI Mgmt Group

• Why do supply chain attacks matter to NHI governance?
• How should security teams reduce the risk of secret theft from npm supply chain attacks?
• Why do npm supply chain attacks often become NHI governance failures?
• Why do supply chain breaches matter to NHI programs?