How should security teams run tabletop exercises for lateral movement prevention in IoT and OT environments?

Why This Matters for Security Teams

Tabletop exercises for lateral movement in IoT and OT need to test more than whether participants can name an incident. They must reveal whether network segmentation, asset visibility, and isolation authority actually hold up when a field device, engineering workstation, or vendor jump path becomes the pivot point. The attack surface is often not a single system but a chain of exposed services, weak trust relationships, and unmanaged credentials, which is why the MITRE ATT&CK Enterprise Matrix is useful for mapping realistic movement paths.

This matters because IoT and OT environments often mix safety, uptime, and business continuity constraints. Security teams may know what “should” happen, but the exercise should prove whether plant staff, IT, and third parties can act fast enough under pressure without creating a larger outage. NHIMG research shows how often identity and credential weaknesses drive real compromise, and cases like 52 NHI Breaches Analysis show that pivotable access is rarely obvious until an incident exposes it.

In practice, many security teams discover that segmentation diagrams and response playbooks look stronger on paper than they behave during a live pivot attempt.

How It Works in Practice

Run the tabletop as a sequence of decisions, not a discussion of general preparedness. Start with a believable foothold such as a phishing event against an engineer, stolen vendor credentials, or a dual-homed workstation that bridges IT and OT. From there, force the room to answer who detects the movement, what telemetry confirms it, who can isolate a cell or subnet, and which business owner must approve disruption if production is affected. The best exercises use the same asset names, network zones, vendor relationships, and escalation contacts that exist in production.

A good tabletop should also test whether defenders can distinguish between benign OT chatter and suspicious pivoting. For example, a maintenance laptop should not be able to reach every controller simply because it is trusted on the floor network. Use scenarios that include jump servers, remote support tools, PLC engineering stations, historians, and cloud-managed IoT fleets. Then challenge participants to explain how they would contain movement without breaking process control or safety dependencies. For path realism, align the scenario with MITRE ATT&CK techniques such as remote services, credential dumping, and lateral tool transfer.

• Confirm which telemetry exists on OT endpoints, switches, firewalls, and remote access gateways.
• Test whether zone isolation can be executed by operations staff, not only by central security.
• Require participants to name the exact approval path for shutting down a vendor tunnel or plant segment.
• Include degraded conditions, such as partial logging loss or an unavailable OT asset inventory.

Ground the scenario in lessons from Schneider Electric credentials breach and Storm-2949 Azure Breach, where access paths and identity trust were central to the blast radius. These controls tend to break down when the exercise assumes instant containment in an environment where engineering access, uptime commitments, and vendor dependencies are tightly coupled.

Common Variations and Edge Cases

Tighter isolation often increases operational overhead, requiring organisations to balance containment speed against process availability and safety constraints. That tradeoff is unavoidable in OT, and the exercise should make it explicit rather than hiding it behind “best effort” language. For example, a plant network may permit temporary risk acceptance for one line while a hospital or utility control environment may not tolerate the same response.

Guidance is still evolving on how much automation should be used for OT containment. Current guidance suggests pre-approving a limited set of actions, such as blocking vendor access, disabling a jump host, or quarantining a workstation, while leaving high-impact shutdown decisions to designated operators. Exercises should also include legacy devices that cannot host agents, remote sites with intermittent connectivity, and third-party support arrangements that lack clean identity boundaries.

One useful variation is to test “gray zone” movement through shared services, such as historians, domain controllers, or backup systems that connect both enterprise and operational networks. Another is to simulate an insider-enabled action where the attacker uses legitimate tools rather than malware. The question is not whether a team can narrate the threat, but whether it can interrupt movement before the adversary reaches safety-critical assets. NHIMG’s broader NHI guidance remains relevant here because exposed service credentials and third-party access often determine whether lateral movement becomes a full environment compromise.

Related resources from NHI Mgmt Group

• How should security teams prioritise NHI remediation in cloud environments?
• How should security teams run access reviews for non-human identities?
• How should security teams govern non-human identities in cloud environments?
• How should security teams limit identity-driven lateral movement in hybrid environments?