Subscribe to the Non-Human & AI Identity Journal

What do security teams get wrong about IoT botnets and relay abuse?

They often assume IoT compromise only matters when it causes immediate disruption, but relay abuse can persist quietly for months. That turns small devices into covert infrastructure for traffic routing, mining, or later attacks. The control gap is poor segmentation, weak remote management hygiene, and incomplete device inventory.

Why This Matters for Security Teams

IoT botnets are often treated as a nuisance problem until they become an availability event, but relay abuse changes the risk profile. A compromised camera, sensor, gateway, or small appliance may not look like a priority asset, yet it can provide persistent routing, proxying, or staging capacity that blends into normal traffic. That makes the impact less visible than classic ransomware, but often more durable. The NIST Cybersecurity Framework 2.0 remains a useful baseline because it pushes teams to inventory assets, manage exposure, and detect anomalous behaviour across the full environment, including overlooked edge devices.

What teams frequently miss is that IoT botnet activity is not limited to noisy scans or obvious denial-of-service traffic. Relay abuse can support credential theft, command forwarding, traffic laundering, and later-stage intrusion paths. If monitoring is focused only on endpoint malware or user accounts, the device layer becomes a blind spot. In practice, many security teams encounter relay abuse only after unusual egress, third-party complaints, or abuse reports have already confirmed the infrastructure has been active for some time, rather than through intentional detection.

How It Works in Practice

Botnet operators usually compromise IoT devices through weak passwords, exposed management interfaces, outdated firmware, or reused vendor defaults. Once inside, they rarely need full interactive control. A device that can relay traffic, forward commands, or host lightweight tooling is often enough. The key security mistake is assuming that the device must be “important” to matter. In reality, low-power systems can be attractive because they are rarely monitored and are often exempt from standard EDR coverage.

Operationally, good defence combines visibility, containment, and egress control. Teams should maintain an accurate inventory, identify ownership, and classify devices by function and exposure. Network segmentation matters because relay abuse thrives when IoT systems can reach internal services or external command infrastructure without restriction. Device management hygiene also matters: credential rotation, firmware patching, secure remote administration, and disabling unnecessary services reduce the attack surface. Detection should focus on behaviours such as new outbound destinations, unusual DNS patterns, long-lived sessions, unexpected port use, and traffic volume that is inconsistent with the device’s normal purpose.

MITRE ATT&CK is useful for mapping how initial access and persistence show up across the environment, especially where attackers leverage valid accounts or living-off-the-land techniques around the device management plane. CISA guidance also reinforces the need to reduce exposed services and harden remote administration paths, particularly for devices that sit outside conventional endpoint tooling. For more on attack-pattern mapping, see MITRE ATT&CK and CISA.

These controls tend to break down when organisations cannot separate device ownership from network admission, because unmanaged IoT assets then remain reachable even after they are known to be high risk.

Common Variations and Edge Cases

Tighter network isolation often increases operational friction, requiring organisations to balance containment against uptime, remote support, and vendor maintenance constraints. That tradeoff is especially difficult in facilities, retail, healthcare, and industrial environments where devices are embedded in daily operations. Best practice is evolving for many of these settings, and there is no universal standard for every IoT category, which is why control design should reflect device criticality and business tolerance for outage.

Relay abuse is also harder to spot when the device is not malware-ridden in the conventional sense. Some environments see abuse through legitimate remote access tools, cloud-managed controllers, or misconfigured VPN tunnels rather than classic botnet implants. In those cases, detection depends less on signature matching and more on anomaly detection, identity review, and network policy enforcement. Where devices perform safety or time-sensitive functions, aggressive isolation may not be practical, so compensating controls like strict allowlisting, separate management planes, and alerting on unusual egress become more important.

For environments that process sensitive data or support regulated services, the strongest outcome usually comes from tying device governance to broader security architecture. That means applying NIST CSF 2.0 to asset visibility and response, then extending monitoring into attack-path analysis so relay abuse cannot hide behind “just another device.”

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and CIS Controls set the governance and control requirements practitioners need to meet.

Framework Control / Reference Relevance
NIST CSF 2.0 ID.AM-1 IoT botnet risk rises when assets are missing from inventory and ownership records.
MITRE ATT&CK T1090 Relay abuse commonly uses proxying and traffic forwarding to conceal attacker infrastructure.
CIS Controls Control 1 Asset inventory is the first step to finding and constraining exposed IoT systems.

Build and maintain a complete asset inventory so unmanaged IoT devices can be governed and monitored.