What should security teams do first when IoT devices are being used as proxy infrastructure for attacks?

Why IoT Proxy Abuse Changes the First Response

When IoT devices are being used as proxy infrastructure, the issue is not only the attack traffic you can see, but the devices that are quietly providing reach, relay capacity, or masking for that traffic. The first response must therefore focus on exposure discovery and containment, because a compromised or unmanaged device can turn a local hardware problem into an external attack path.

The practical implication is that teams should treat the device estate as part of the attack surface, not as passive equipment. That means identifying what is connected, whether it can be reached remotely, and whether it still has the trust assumptions that allowed it to be deployed in the first place.

Inventory is the starting point because without it you cannot distinguish a harmless sensor from a device that can be repurposed as a relay. Weak authentication, default credentials, and stale firmware are the common conditions that make that misuse possible, especially when devices remain internet-reachable or segmented only by convention rather than by enforced policy.

For device trust and lifecycle handling, the first question is whether the device can still be authenticated, updated, and monitored in a way that supports continued connection. NHIMG’s Device and IoT Identity Guide aligns closely with that decision point because secure onboarding, default password bans, and device trust are what separate manageable endpoints from latent proxy risk.

How to Contain the Relay Path Without Guessing

Once likely abuse candidates are identified, containment should target the paths that make them useful to an attacker. That usually means isolating or quarantining devices that can be remotely abused, reducing outbound routes they do not need, and separating them from sensitive systems that should never be reachable through a consumer or embedded device.

The most important operational shift is to stop thinking in terms of a single infected device and start thinking in terms of network placement and privilege. A device that cannot be patched quickly is not just outdated, it is a standing dependency that can be converted into a covert relay unless its network reach is sharply constrained.

Default credentials and untrusted remote administration channels are especially dangerous because proxy abuse often depends on persistence rather than noisy exploitation. If a device can still be managed with factory defaults or weak shared credentials, the attacker does not need sophisticated malware to keep using it as infrastructure.

Good containment also includes traffic review, because proxy use usually leaves a pattern: unusual outbound destinations, repeated small connections, protocol tunneling, or devices communicating far outside their normal business function. Those signals matter more than trying to prove the full intrusion chain before acting.

For broader threat and response context, CISA’s cyber threat advisories are useful when teams need to align containment with current adversary activity, while the CISA Industrial Control Systems resources are relevant when IoT devices sit inside operational or critical environments.

What Teams Should Do First, and What Comes Next

The correct first move is to triage by exposure and abuse potential, not by device type alone. Start with devices that are externally reachable, unpatched, using default or weak authentication, or showing suspicious outbound behaviour, then decide whether they can be remediated safely or must be removed from the environment.

• Prioritise inventory: build a current list of connected IoT devices, owners, and network locations before making assumptions about risk.
• Verify management state: confirm which devices can be patched, credentialed, and monitored reliably.
• Segment aggressively: isolate anything that does not need broad network access, especially devices with internet exposure.
• Escalate unrecoverable devices: if a device cannot be trusted to stay updated or authenticated, it should not remain connected to sensitive networks.

NHIMG’s The 52 NHI Breaches Report is useful here as a reminder that weak authentication, exposed secrets, and lateral movement are recurring patterns whenever a device or machine account becomes part of an attack path.

Risk and Threat Considerations

IoT proxy abuse is risky because the device is not only compromised, it can become a reusable relay that obscures attacker origin and extends reach into environments that were never designed to trust it. The main hazard is delayed detection, since the device may keep functioning normally while silently supporting outbound abuse or staged access.

Failure mechanism: weak authentication, old firmware, and poor segmentation let an attacker persist on the device, then use its network position to relay traffic, hide source attribution, or pivot toward more sensitive systems.

Impact: organisations can lose visibility into attack paths, expose adjacent systems to lateral movement, and end up with an embedded asset that must be treated as untrusted until fully remediated or retired.

Practitioner Guidance

What to prioritise: focus first on devices with external reach, default credentials, or no reliable patch path. Those are the ones most likely to be converted into proxy infrastructure rather than simply being noisy endpoints.

What to verify: confirm whether each device has a known owner, current firmware, and enforced network boundaries. If any of those are missing, assume the device can be abused again even after a short-term cleanup.

Common mistake: teams often hunt for the attacker’s full path before they remove the relay. In this scenario, containment comes before certainty, because the device’s network role is the real risk multiplier.

Practitioner takeaway: if an IoT device can still be reached, managed, and trusted only by hope, it should be treated as a potential proxy node, and the safer default is to isolate first and justify re-entry later.

Related resources from NHI Mgmt Group

• What should security teams do first when widely used open-source dependencies become critical infrastructure risks?
• What should security teams do first when OAuth abuse is used to bypass MFA in business email compromise attacks?
• Why are NHIs a critical concern for security teams?
• What steps should security teams take to prevent Shadow AI risks?