These devices often run embedded SDKs, receive slow or inconsistent patching and remain internet-exposed long after their original deployment assumptions have changed. That combination makes them durable entry points for opportunistic exploitation. Once compromised, they can be reused for scanning, proxying or denial-of-service activity unless teams actively inventory, isolate and retire them.
Why these devices stay attractive after the first compromise
IoT and networking gear is built to stay on, stay reachable and survive for years, which is exactly why it is so often abused as infrastructure rather than just broken as a single endpoint. A device that is still reachable from the internet, still running old services and still trusted by the surrounding network can be an enduring botnet foothold long after the original deployment assumptions have expired.
Attackers do not need perfect reliability from these devices. They only need enough continuity to keep a population of exposed hosts available for scanning, proxying, credential capture or volumetric abuse. That is why even low-end devices with weak management features can remain useful to operators once compromise is achieved.
When teams understate the device as “just an appliance”, they often skip the controls that would make reuse difficult: explicit inventory, constrained reachability, identity-aware segmentation and a defined retirement path. Device identity matters here because unmanaged trust is what lets a compromised box keep functioning inside the environment.
What turns exposure into a botnet foothold
The conversion usually follows a familiar pattern: the device is internet-exposed, the software stack is stale or inconsistent across fleets, and the attacker finds a weak default setting, known flaw or management interface that was never intended to face hostile traffic. Once the device is in, it becomes a durable relay point that can support distributed scanning, command-and-control traffic or denial-of-service activity.
Botnet operators favor devices that are inexpensive to compromise and hard to evict. A device with outdated firmware, shared admin paths or flat network access gives them persistence even when one exploit route closes, because the broader operational condition remains unchanged.
That is why this problem is not solved by patching alone. Where patch cycles are slow, exposure stays public and service ownership is unclear, the attacker only needs one weak condition to keep turning the device into reusable infrastructure.
What breaks first in real environments
The failure is rarely a single technical defect. It is usually the combination of poor asset visibility, weak configuration discipline and an assumption that the device can be left alone after installation. That combination creates a gap between what the team believes is deployed and what is actually reachable from the public internet.
Exposed devices on flat or lightly segmented networks are especially vulnerable because compromise in one place often gives the attacker enough lateral freedom to keep the foothold useful. If the device can still reach internal services, act as a pivot or speak to management interfaces without tight controls, the compromise is no longer just local.
Vendor and platform guidance helps, but the practical question is whether the device still has a business justification for being online at all. If not, the safest outcome is often isolation or retirement rather than continued exposure with promises of future patching.
Risk and Threat Considerations
These devices matter to attackers because they are widely distributed, rarely monitored as closely as servers and often accepted as “normal” background infrastructure. That makes them ideal for building resilient botnets that can survive partial takedown, absorb churn and keep generating scanning or denial-of-service capacity.
Failure mechanism: Internet exposure plus inconsistent patching and weak lifecycle control leave a reachable service path that attackers can repeatedly exploit, then reuse for relay, scanning or traffic generation.
Impact: The organization loses control of a device that may still sit on a trusted network segment, and the compromise can create outward-facing abuse, internal pivot risk and reputational or legal fallout if the device participates in attacks.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-1 — Inventory and Control of Enterprise Assets | Exposed IoT footholds persist when devices are not fully inventoried. |
| CIS-12 — Network Infrastructure Management | Device reachability and segmentation are central to reducing botnet reuse. | |
| Recommendation — Maintain complete asset inventory and remove unmanaged exposed devices from service. Segment internet-facing devices and restrict their management and service paths. | ||
| NIST SP 800-53 Rev 5 | CM-8 — System Component Inventory | Inventory is required to find and govern exposed devices before compromise repeats. |
| SC-7 — Boundary Protection | Isolation and constrained connectivity limit how compromised devices can be reused. | |
| Recommendation — Track all device components and confirm ownership, exposure and lifecycle status. Enforce boundary controls that restrict exposed devices to necessary traffic only. | ||
| ISO/IEC 27001:2022 | A.8.8 — Management of technical vulnerabilities | Slow patching and outdated firmware are core enablers of recurring compromise. |
| Recommendation — Apply vulnerability management to exposed devices and verify remediation is complete. | ||
Practitioner Guidance
What to prioritise: Start with exposed-device inventory, because you cannot retire, segment or patch what you cannot reliably enumerate. Focus first on devices that have public reachability, weak admin interfaces or unclear ownership.
What to verify: Confirm whether each device still needs internet exposure, whether firmware is still maintained, and whether the device can be isolated without breaking a business process. If the answer is no, treat retirement or replacement as the control, not an optional improvement.
Common mistake: Teams often patch the obvious CVE but leave the broader exposure pattern unchanged. That leaves the same class of device available to the next opportunistic campaign, which is why repeated compromise is so common.
Practitioner takeaway: The durable fix is to reduce the device’s trust and reach, not just to chase individual exploits, because botnets thrive where exposure, longevity and weak ownership overlap.