Should organisations use tabletop exercises or live red team testing for IoT and OT resilience?

Why both methods belong in an IoT and OT resilience programme

IoT and OT resilience is not a single control test. Live red team activity answers a technical question, can an adversary reach, misuse, or persist in the environment despite prevention and detection controls? Tabletop exercises answer an operational question, can the organisation coordinate containment, escalation, and recovery without creating unsafe side effects in plant, field devices, or dependent business processes?

The distinction matters because the same weakness can fail in different ways. A technical exploit may be blocked, but the response path can still be too slow, too ambiguous, or too IT-centric for OT conditions. Conversely, a well-drilled response team may still be blind to a realistic attack path if no one has validated the actual control gap in a live environment.

For OT-heavy environments, NIST SP 800-82 Rev 3, OT Security Guide is the stronger baseline for understanding why segmentation, control-zone design, and system-specific constraints change how you test resilience.

What live red team testing validates that a tabletop cannot

Live testing is the better way to validate adversary technique, control coverage, and actual blast radius. It can show whether an exposed remote path, weak authentication path, unsafe engineering workstation, or fragile segmentation rule is exploitable in the real environment rather than only on paper.

In IoT and OT settings, that depth matters because assumptions are often embedded in vendor defaults, legacy protocols, and operational exceptions. A live exercise can reveal whether detection engineering, network segmentation, jump-host design, and account controls really hold when the attack sequence is chained end to end.

Use live testing when you need evidence about exploitability, detection quality, and whether your environment behaves safely under realistic attacker pressure. CISA Industrial Control Systems is useful background for aligning those tests with industrial-environment constraints and advisory-driven priorities.

What tabletop exercises validate that live testing usually does not

Tabletops are the better tool for testing decision-making, escalation, communications, authority, and cross-functional coordination. In OT incidents, the hardest failure is often not technical breach containment but deciding who can stop a process, isolate a segment, notify operations, and approve a safe shutdown without creating an even worse availability or safety issue.

That is why tabletops should include not just security and IT, but plant operations, engineering, safety, facilities, and third-party support paths. They surface whether the organisation knows its decision thresholds, who owns the final call, what evidence is needed before action, and how IT and OT teams avoid working at cross purposes during a fast-moving event.

If your programme already performs live tests, a strong tabletop still adds value because it exposes procedural gaps, unclear authority, and recovery sequencing that technical testing cannot prove. FIRST incident response standards are a useful anchor for that coordination mindset.

How to combine them into one resilience programme

The practical answer is to pair them in sequence, not to treat them as interchangeable. Use tabletops first to define safe rules of engagement, escalation paths, and stop conditions, then use live red or purple team work to validate the most important attack paths, control failures, and detection blind spots.

For mature programmes, the strongest design is a closed loop: tabletop findings refine response playbooks, live findings refine control architecture, and both feed remediation tracking. That gives you evidence across people, process, and technology rather than a one-dimensional scorecard.

Where cyber and OT teams already operate with separate tooling or vendor boundaries, a combined exercise also tests handoffs. That is often where resilience fails, because containment steps that are routine in IT can be unsafe, delayed, or partially ineffective in OT.

Risk and Threat Considerations

IoT and OT environments carry a material risk of unsafe containment, prolonged outage, and incomplete visibility when exercises are not designed around real operational dependencies. Live testing can also create unintended disruption if scope, timing, and safety constraints are not tightly controlled.

Failure mechanism: The organisation validates either technical exploitability or human coordination in isolation, so the real failure path, attacker access plus weak escalation plus unsafe response sequencing, is never exercised end to end.

Impact: Teams may overestimate resilience, miss unsafe response steps, and discover critical gaps only during a real incident, when recovery is slower and the blast radius is larger.

Practitioner Guidance

What to prioritise: Start by mapping the highest-consequence OT and IoT scenarios, then decide which ones need live technical validation and which ones mainly need decision, authority, and recovery testing. Safety-critical or production-sensitive environments usually need both, but not on the same assumptions or at the same depth.

What to verify: Before trusting a test result, confirm that the exercise covered the actual operating constraints, including vendor dependencies, shutdown authority, maintenance windows, and the handoff between IT security and OT operations. If those were absent, the result is incomplete even if the technical outcome looked strong.

Practitioner takeaway: Resilience improves fastest when live testing proves what an attacker can do and tabletops prove what the organisation can safely do next; either one alone leaves an important blind spot.

Related resources from NHI Mgmt Group

• How should organisations use live-fire cyber readiness exercises to improve defender resilience against identity-driven attacks?
• What breaks when AI security testing is done only in scheduled red team exercises?
• How should security teams run tabletop exercises for lateral movement prevention in IoT and OT environments?
• How should security teams use red team and blue team exercises to improve attack-surface control?