How do security teams stop IoT devices from becoming lateral movement footholds?

Why This Matters for Security Teams

IoT devices rarely start as the “main” target, but they are often the easiest path into a flat environment once an attacker lands on one device. Their mix of weak patching, embedded credentials, vendor services, and limited telemetry makes them ideal lateral movement footholds. The practical problem is not just compromise, but what the device can reach next. Security teams need to think in terms of containment, not trust, because broad internal reach turns a single device into an enterprise-wide pivot point. Guidance from the MITRE ATT&CK Enterprise Matrix remains useful here because discovery, remote services, and internal traversal are common post-compromise behaviours. In practice, many security teams encounter the problem only after an IoT device has already been used to scan internal subnets or proxy traffic into a more valuable environment, rather than through intentional segmentation design. That is exactly the failure mode to avoid. The NHI lesson applies as well: NHI Management Group notes that only 5.7% of organisations have full visibility into their service accounts, which mirrors the visibility gap that often exists for devices with identity-like access.

Effective containment starts with treating each IoT device as a narrowly scoped workload identity, not a general-purpose endpoint. The device should only be able to reach the specific management plane, broker, update service, or application API it truly needs. Everything else should be denied by default at the edge. This is why per-device policy is more durable than broad VLAN trust or “guest” network exceptions.

Operationally, teams should combine network segmentation with behaviour monitoring. That includes alerting on internal discovery attempts, unexpected DNS patterns, remote administration services, and outbound connections to destinations the device has never needed before. For environments with heavier control requirements, policy should be expressed in a way that can be reviewed and enforced consistently, rather than hidden in ad hoc firewall rules. The State of Non-Human Identity Security highlights how weak NHI hygiene drives compromise at scale, and the same pattern shows up in IoT when credentials, privileges, and exposure are left broad.

• Limit east-west movement by default, not after first alert.
• Define allowlists by device type and business function, not by convenience.
• Separate device management traffic from production application paths.
• Watch for scanning, service enumeration, and unusual outbound sessions.

Where possible, tie device identity to authenticated enrollment and short-lived access decisions. That reduces the value of stolen certificates or embedded tokens and makes reuse harder across fleets. These controls tend to break down in brownfield industrial and healthcare networks where legacy protocols, shared credentials, and uptime constraints prevent consistent segmentation.

How It Works in Practice

Tighter containment often increases operational overhead, requiring organisations to balance attack-surface reduction against device support and uptime constraints. In practice, the strongest pattern is to combine network enforcement with identity-aware policy, so a device gets only the access required for its current role and nothing more. That aligns with the way modern intrusion paths unfold: attackers do not need full administrative control if they can exploit one permissive path into a larger environment. The 52 NHI Breaches Analysis is a useful reminder that compromise often spreads through over-privileged or poorly monitored non-human access rather than through a single dramatic exploit.

A practical implementation stack usually includes:

• Per-device network policy at the edge or microsegmentation layer.
• Explicit allowlists for management, update, telemetry, and business APIs.
• Separate trust zones for IoT, user endpoints, and server workloads.
• Detection for lateral movement patterns such as port sweeps, SMB, RDP, SSH, or unusual internal DNS queries.
• Short-lived credentials or certificates where device platforms support them.

For environments that can support it, device identity should be anchored in cryptographic proof, not just IP address or MAC address. That makes policy more resilient when devices move, reboot, or change network location. Teams should also review what “normal” looks like for each device class. A camera, thermostat, badge reader, or building controller should not share the same internal permissions simply because they live on the same subnet. Current guidance suggests that baseline segmentation is necessary but not sufficient; policy must also account for the device’s expected protocol set and lifecycle state. This is where monitoring and access control reinforce one another: a device that suddenly starts reaching file shares or admin services is not just noisy, it is likely compromised.

These controls tend to break down when legacy OT gateways, vendor remote support channels, or hardcoded peer-to-peer discovery protocols require broad east-west reach because the environment cannot easily express narrow policy.

Common Variations and Edge Cases

Stricter device isolation often improves containment, but it can also interfere with firmware updates, vendor diagnostics, and regulated operational workflows, so organisations have to balance security with maintainability. The hardest cases are not consumer IoT devices but “embedded” systems that behave like infrastructure: printers, badge systems, building controls, lab instruments, and industrial sensors. They often use proprietary protocols, depend on shared service accounts, or require temporary vendor access that is difficult to model cleanly.

Best practice is evolving for these edge cases. Some teams move to a brokered access model where the device never speaks broadly to the internal network and instead reaches only a controlled relay or management gateway. Others use one-way telemetry paths, strict maintenance windows, and separate administrative enclaves. For high-risk fleets, combining this with the lessons from TruffleNet BEC Attack — Stolen AWS Credentials and the Schneider Electric credentials breach shows why stolen credentials and overly broad trust are such persistent footholds across machine identities and devices alike. The main exception is environments where device safety or uptime overrides normal segmentation rules. In those cases, the right answer is not to remove controls, but to add compensating monitoring, stricter vendor gating, and faster revocation paths.

There is no universal standard for this yet across every IoT class, but the direction is clear: narrow access, verify behaviour, and make lateral movement expensive.

Related resources from NHI Mgmt Group

• How should security teams stop lateral movement after a SharePoint compromise?
• How should security teams stop lateral movement after an initial foothold?
• Why are NHIs a critical concern for security teams?
• What steps should security teams take to prevent Shadow AI risks?