OT Red Teaming: Testing Industrial Control Systems (ICS) Safely

Introduction

Let’s be honest: if you work in manufacturing, energy, utilities, or any OT-heavy industry, cybersecurity probably feels like something handled by “the IT team upstairs.” But here’s the reality check: the systems that keep your machines running, control your production lines, and manage your remote access are all digital now, which means that they are open to vulnerabilities.

A successful cyberattack in an operational technology (OT) environment doesn’t just leak some data; it can bring down entire operations, put safety at risk, or cost you serious money.

So, how can you realistically test and improve your defences without disrupting production?

That’s where OT red teaming exercises come in. They’re not just for the tech crowd; they’re practical tools that help real-world teams figure out what’s working, what isn’t, and how to get better before something bad happens.

Let’s break it down in plain English.

What red teaming looks like in an OT environment?

A red team is a group of ethical hackers who act like real attackers to find the gaps in your defences before criminals do. If you’re new to the idea, start with our guide to what red teaming is. What changes in an OT environment is where those gaps sit, and how carefully you have to probe them without disrupting live operations.

In an OT or ICS setting, a red team might:

• Phish plant and engineering staff to see who takes the bait
• Check whether ageing workstations and HMIs are still running default credentials
• Try to reach a remote terminal or engineering interface that shouldn’t be exposed to the internet
• Test physical access to a control room or other restricted area

The value isn’t a checklist of findings, it’s an attacker’s-eye view of your specific environment. In OT, that usually surfaces three things a routine scan won’t: overlooked routes into sensitive systems, such as unsecured remote access or flat, poorly segmented networks; exposed legacy protocols that were never designed for modern threats; and human weak points, like a clicked phishing link or a shared password.

Because so much OT still runs on legacy equipment that predates today’s threats, the practical goal is to map those exposures and recommend fixes that don’t demand production downtime.

The blue team’s challenge in OT

The blue team is your defenders, the people who monitor systems, respond to incidents and try to keep everything secure and running smoothly. If you’re completely new to the concept of red team vs. blue team, check out our comparison article.

The challenge in OT is that blue teams often have to defend systems that are old and delicate and can’t afford downtime. You can’t just unplug a programmable logic controller (PLC) or reboot a live production environment like you would in IT.

OT Benefits of Blue Teaming:

Red vs blue teaming has numerous benefits, most of which can be found in our comparison article, but here are the OT-specific ones.

• Protects critical infrastructure: safeguards sensitive OT assets like PLCs, SCADA systems, and HMIs from cyber and physical threats.
• Maintains uptime and operational safety: ensures production lines, utilities, and other vital systems stay online and within safe operating limits during incidents.
• Enhances threat visibility across IT/OT: improves monitoring across both traditional IT networks and operational technology environments.
• Supports regulatory compliance: helps meet cybersecurity and safety standards (like NIST, IEC 62443, or NIS2) by tracking, logging, and reporting security events.

While the red team breaks things (on purpose) to find weaknesses, the blue team keeps the lights on and makes sure they’re hard to switch off.

How to Run These Simulations in an OT Environment?

Here’s where many OT leaders hesitate, and rightly so. The idea of “testing” security might sound risky. After all, you can’t afford to shut down a plant just to run a simulation.

But the good news is, there are ways to do this safely, carefully, and with real value. Let’s walk through five key best practices.

1. Start with Clear Goals

Before you begin, ask yourself: what are we trying to learn?

• Are we testing how fast our team can detect an incident?
• Do we want to find out if someone could access a Human Machine Interface (HMI) from outside the building?
• Are we curious about how staff would react to a phishing attempt?

Having a clear objective ensures the exercise is focused and meaningful, not just “hacking for fun.”

Just as important as the objective is agreeing the boundaries before anyone starts. Decide what is in scope, what is strictly off limits, and who has the authority to call a stop if a system behaves unexpectedly. In OT, that scoping conversation is the single most important safety control you have, and it is the same discipline that underpins a careful OT penetration test.

2.  Use Realistic, Industry-Relevant Scenarios

A generic hacker simulation won’t do much good.

Instead, build scenarios based on real threats to your sector. For example:

• In a chemical plant, simulate a breach targeting the recipe management system.
• In utilities, test what happens if a malicious actor tries to shut off remote monitoring.
• In manufacturing, simulate ransomware that locks up the production line.

Use actual threat intelligence from sources like MITRE ATT&CK for ICS or past incidents in your industry (which give a visual representation of attack patterns). This makes the exercise more relevant and more impactful.

3.  Prioritise Safety and Isolation

Your production systems are fragile and critical. So, never run tests directly on them without preparation.

Instead:

• Create mirrored test environments where you can run attacks safely.
• Use network segmentation to isolate test zones from live operations.
• Run “tabletop” simulations, which are strategic discussions where teams walk through attack scenarios without touching real systems.

Lean on passive techniques wherever you can. A skilled tester can map a network and identify devices, protocols and connections simply by listening to traffic, without sending anything that could upset a controller. You can also learn a great deal without touching a live system at all: an architecture review of how the environment is built, or a line-by-line review of your firewall rules to confirm that the segregation you believe you have is actually in place.

When hands-on testing is genuinely needed, the safest pattern is to work on site with one of your own engineers alongside the tester, agreeing every action before it happens, so nothing connects to the network without a clear go-ahead. For the full picture of how this works on live SCADA and ICS equipment, see our guide to testing live OT systems safely.

4.  Don’t Forget the People

Cybersecurity isn’t just about firewalls and software. Humans are often the weakest link, but they can also be your first line of defence.

Include tests that challenge the human layer:

• Phishing simulations
• Physical access challenges (e.g., tailgating into control rooms)
• Policy checks like whether staff are following password or USB protocols

You’ll quickly find where your people need support, training, or clearer policies.

5.  Always Run a Post-Mortem (Purple Teaming)

Once the exercise is over, don’t just say “good job” and move on. This is often referred to as purple teaming, which you can learn more about in our comparison article.

Bring everyone together, red team, blue team, operations and leadership, and review:

• What the attackers did
• How defenders responded
• What went well
• What needs improvement

Update your incident response plans, adjust monitoring tools, and invest in training where gaps are revealed.

This is where the real transformation happens. You’re not just reacting, you’re getting ahead of the curve.

A real-world wake-up call: Colonial Pipeline and TRITON

Nowadays, OT environments aren’t isolated like they used to be. From systems that once ran on their own are now connected to the internet. Every cloud platform and remote-access tool is a door an attacker can try. Ransomware gangs, nation-state groups and even insiders have targeted OT organisations in recent years, sometimes with serious physical and financial consequences. Two incidents show why this isn’t theoretical:

Colonial Pipeline (2021). A ransomware attack forced the operator to shut down one of the largest fuel pipelines in the United States, disrupting supply across much of the East Coast. Tellingly, the malware never touched the pipeline’s control systems directly. Instead, it was a compromise on the business side that was enough to halt all physical operations.

TRITON / TRISIS (2017). Malware discovered at a petrochemical plant was built to target the facility’s safety instrumented systems (SIS), which are the controllers whose entire job is to shut a process down safely before it becomes dangerous. It was the first known malware designed to attack safety systems directly, raising the prospect not just of downtime, but of physical harm.

The lesson from both is the same: in OT, unlike a lot of cyberattacks, a cyber incident doesn’t stay digital. It stops production, threatens safety, and hits the bottom line much harder in almost any other industry. Regular red and blue team exercises won’t prevent every attack, but they show you, long before an adversary does, exactly where those doors are, and whether your team would notice someone opening one.

Getting started with OT red teaming

You don’t need to overhaul your security programme to begin, and you definitely don’t need to touch a live production system. The most useful first step is usually the smallest: a scoped tabletop exercise, or a targeted test of a single high-risk scenario run against a mirrored environment rather than the plant floor. The five practices in the section above walk through how to do that safely.

What matters more than scale is getting the right people in the room. The strongest OT exercises bring IT, engineering and operations, and executive leadership together, because in a real OT breach, those are exactly the teams who’d have to respond as one. You don’t need to be a cybersecurity expert to take part; you just need to be willing to ask the right questions.

If a full engagement feels like a lot for a first pass, a micro red team tests your highest-risk scenarios in a shorter, lower-cost format, a practical way to prove the value before committing to more. And if you’d rather confirm specific technical weaknesses in your control systems first, an OT penetration test is the narrower, more technical counterpart to a red team exercise. If you’re still mapping out the fundamentals, our guides to what red teaming is and red team vs blue team are good places to start.

When you’re ready to test your OT defences for real, take a look at our red and purple teaming services or book a call and we’ll help you scope an exercise that fits your environment without disrupting operations.

FAQ’s

What’s the main difference between the red and blue teams?

The red team plays the attacker, probing your OT environment for ways in; the blue team is your defenders, detecting and responding to those attempts. The dynamic is the same as in IT, but the stakes are physical because a successful attack can affect production and safety, not just data. For a fuller breakdown, see our guide to red team vs blue team vs purple team.

How often should OT organisations run red team exercises?

An annual full engagement is a sensible baseline for most OT organisations, with smaller, targeted tests in between. They are particularly useful after a major change like a new remote-access setup, or an acquisition that connects new systems to your network. High-risk or heavily regulated sites often test more frequently, but the right cadence depends on how fast your environment changes and what your compliance framework (such as IEC 62443 or NIS2) expects.

How can we test an OT environment safely, without causing downtime?

The principle is to get realistic results without touching anything you can’t afford to disrupt. In practice that means:

• Defining clear boundaries, i.e., what’s in scope, what’s strictly off-limits, and who can call a stop
• Testing against mirrored or lab environments rather than live production systems
• Using network segmentation to keep critical systems isolated during testing
• Favouring tabletop exercises and passive techniques for the most fragile assets, like live PLCs and SCADA controllers

Our guide to testing live OT systems safely covers how this works in practice on SCADA and ICS equipment.

Can you red team OT systems without disrupting production at all?

Yes, and that’s the entire point of the safety measures above. A good OT red team works around the constraint that you can’t reboot a PLC or take a production line offline: sensitive scenarios are run in test environments or as tabletop walkthroughs, while only genuinely safe checks are performed against live systems. Scoping is where this is agreed, before any testing begins.

What’s the difference between OT and OT penetration testing?

Red teaming is a broad, goal-led adversary simulation: it tests people, processes and physical access alongside technology, and measures whether your team would detect and respond to a real attacker. OT penetration testing is narrower and more technical, focused on finding and safely proving specific vulnerabilities in your control systems. Many OT operators use both: a penetration test to confirm which weaknesses are real, and a red team exercise to see how far an attacker could get and whether anyone would notice.

Do we need to involve our equipment vendors or OEMs?

Often, yes, as any OT systems are maintained under vendor warranties or support agreements, and some are sensitive enough that the original manufacturer should be aware of testing. Flagging this during scoping avoids breaching a support contract and helps you test safely around equipment that can’t simply be taken offline.