ICS & SCADA Penetration Testing: How to Test Live OT Systems Safely

Most industrial operators know they ought to test their control systems, whilst also worrying that testing could be the very thing that knocks a process offline. That worry is absolutely fair, and a clumsy test against a sensitive controller can cause genuine problems.

The reassuring part is that SCADA and ICS penetration testing, a subsection of OT penetration testing, carried out by companies like Fortifi who understand these environments, can be done without putting your operation at risk.

What is SCADA and ICS penetration testing?

If you work in OT, you will already know that SCADA (supervisory control and data acquisition) and ICS (industrial control systems) are the systems that monitor and control physical processes.

SCADA gathers data from sensors and lets operators control equipment, often across large or remote sites. ICS is the broader family that includes SCADA, PLCs and the other controllers that keep a plant running.

SCADA penetration testing is a controlled attempt to break into these systems as a real attacker would, while ICS penetration testing applies the same approach across the wider control estate. The aim is to find the routes an intruder could take to reach equipment that moves, heats, mixes or pumps something in the real world.

Related Reading: Network Penetration Testing: A Comprehensive Guide

Why testing live OT systems feels risky

Like everything in OT penetration testing, SCADA and ICS pentests are daunting prospects for operators and pentesters alike. Plenty of control systems are old, running software that the vendor no longer supports, and sending the wrong packet to a fragile PLC can break it, which, in a live plant, is a very dangerous possibility.

On a normal network, a mistake costs data or time, whereas in an industrial environment, a controller that behaves unexpectedly can move machinery, open a valve, or change a process in the physical world, which can put people at risk of serious injury. (We cover why the wider IT-versus-OT difference matters in our OT penetration testing guide.)

A lot of operators have heard, first- or second-hand, a story about a security tool that crashed a controller during a routine scan, and those stories are not exaggerated. The sort of network scan a tester would run on an office network without thinking twice can overwhelm a fragile legacy device and bring it down, simply because the device was never built to handle that kind of traffic. So when a penetration test is suggested, the instinct is to push it back and pray that you’re not targeted.

The fear of letting someone test the environment is reasonable, and a good provider treats it that way rather than dismissing it. What rarely gets weighed against it is the far larger risk of never having the environment looked at at all.

An OT network that nobody has been allowed to touch for years tends to be one where patches have slipped, user accounts have built up, and small misconfigurations have gone unnoticed. The very fear that keeps testers out is what allows the environment to decay unseen, and if an attacker does find a way in, there is little left to slow them down.

Related Reading: We’ll Test Once We’re More Secure: The Jekyll & Hyde Approach to Penetration Testing

Can a penetration test cause downtime?

If done poorly, any OT penetration test, including a SCADA or ICS penetration test, can absolutely cause downtime. A tester who treats an OT network like a corporate IT network, by pointing noisy automated tools at live controllers, can absolutely cause penetration testing downtime and, in the worst cases, serious injury.

An OT penetration testing specialist, like Fortifi, does not work that way. Safe penetration testing in OT rests on understanding what each system can tolerate and shaping the approach to match.

In practice, that often means working on site rather than remotely, with one of your engineers alongside the tester, and agreeing on every action before it happens. It can mean passive techniques that listen to traffic rather than injecting anything into it, and when active testing does take place, it proceeds slowly and only within an agreed window, with someone who knows the plant ready to step in.

The risk of downtime is real, but it comes down to who you hire and how they work, not to testing itself.

A safe SCADA penetration testing methodology

A sound SCADA penetration testing methodology is built around protecting the process first, which is why a typical engagement runs through several stages.

It opens with scoping, where you and the tester agree exactly what will be touched, when, and what is completely off limits. We often say that scoping is the most important stage of the process, and nowhere is that more apparent than in OT.

After scoping, you get passive reconnaissance. The tester maps the network and identifies devices, protocols and connections without sending anything that could upset a controller. A surprising amount of useful detail can be gleaned simply by watching the traffic.

If any active testing is appropriate, it follows carefully and in small increments. A good tester works on-site with one of your engineers, agrees on each step before taking it, and connects nothing to the network without a clear go-ahead. In some engagements, the consultant never plugs into the network at all and instead asks the on-site engineer to run a command or use an existing tool and hand back the output.

The engagement closes with a clear remediation report that provides a ranked list of what was found, what it means for safety and uptime, and what to fix first.

Related Reading: Automated vs. Manual Penetration Testing: A Comprehensive Guide

When the safest test means not touching the network

Sometimes, the right call in an OT environment is to carry out no active testing at all. That is a genuinely legitimate way to test, and not a way of avoiding the hard part. If a process truly cannot tolerate any risk, a great deal can still be learned without going near a live controller.

For example, an architecture review examines how the environment is built and where the weak points are, or a firewall config review takes the rules meant to separate your control network from everything else and checks, line by line, whether they really do. Plenty of operators are certain their manufacturing network is fully segregated, or even air gapped, right up until someone reads the rules and finds the gap.

Additionally, a structured threat modelling session, run almost like a tabletop exercise but with genuine visibility of your systems, works through one simple question: if an attacker got inside, how would they have managed it, what could they reach, and what would stop them?

None of this puts a single device at risk, whilst still telling you, with real confidence, whether the defences you think you have are the defences you actually have. These same no-touch reviews sit at the heart of a careful OT penetration test, and a structured attacker walk-through is also the basis of OT red teaming.

SCADA pentesting tools: why manual control matters

There is no single toolkit for OT penetration testing, and the better question is often how little tooling you can get away with. The instinct of a good OT tester is to lean on tools as little as possible.

Kieran, Fortifi’s founder and head of penetration testing, keeps automated tooling to a minimum and prefers to maintain direct, manual control of the entire process. This is because an automated tool runs at its own pace and can do something unexpected before a human has a chance to step in. So, when the system on the other end controls physical machinery, he would rather make every move himself and watch the result than hand any part of the job to software that might behave in a way he cannot predict.

When a tool is the right choice, it is adapted for the environment, runs slowly, and is used only once the on-site engineer agrees it is safe to point at a given device.

Automation is great in so many ways, but when it comes to OT penetration testing, manual testing, while slower, is much safer and has increased value.

Why so few companies offer OT penetration testing

Start asking around for an OT pentest, and you quickly find that most penetration testing firms will not do it. They will gladly test your IT, but the moment a live industrial process is on the table, they decline. The stakes that make OT testing daunting for operators make it daunting for testers too, and a team that does not work in these environments regularly has no business learning on your plant.

That is why finding a provider who genuinely does OT, and does it properly, matters so much. At Fortifi, the most demanding engagements are run by Kieran himself, the firm’s founder and most experienced tester. We go into what to look for in detail in our OT penetration testing guide.

ICS penetration testing in practice

Picture a plant where the office network and the control network were never properly separated. During an ICS penetration testing engagement, the tester begins from a position that an attacker might reach through a phishing email on the business side.

From there, they find a path onto the control network, come across an engineering workstation with a weak password, and reach a point where they could, in theory, send commands to a PLC. Then, instead of disrupting the process, they prove the path exists, document it, and stop.

That single finding tells the operator that the separation they believed existed was not actually there, and that closing it removes a route a real attacker could have used to cause harm. This attack-path thinking, following a route all the way through rather than testing devices in isolation, is exactly what OT red teaming sets out to do across people, process and technology.

In 2021, the ransomware attack on Colonial Pipeline in the United States shut down a major fuel supply line, while a separate, widely reported 2021 incident at a water treatment plant in Florida involved an attempt to remotely alter chemical levels. Both showed how exposed OT becomes when access controls are weak.

Related Reading: The Importance of Retesting After Fixing Cybersecurity Vulnerabilities

What to do after SCADA or ICS security testing

As with anything penetration testing-related, the test is as good as useless if the remediation advice is not acted upon. Once your SCADA or ICS penetration test is complete, the value comes from acting on the report, fixing the identified vulnerabilities and retesting to ensure they were fixed appropriately.

Fix the highest risk issues first, retest to confirm the fixes actually worked, because a fix nobody verified is really just an assumption, and then build what you have learned into how you run and change your systems, so the same gaps do not reopen over time. Our OT penetration testing guide sets out this act-fix-retest cycle in more detail.

If downtime fears have been holding you back from testing your control systems, the way forward is to pick a provider for whom safety is the starting condition.

Talk to Fortifi about SCADA and ICS penetration testing.

Or check out one of our OT penetration testing case studies to understand exactly how we work, and how we can help you.

Related Reading: Legacy Equipment: Understanding the Risks and Challenges

SCADA and ICS penetration testing FAQs

What is the difference between SCADA and ICS penetration testing?

SCADA penetration testing focuses on the supervisory systems that gather data and let operators control equipment, often across large or remote sites. ICS penetration testing applies the same approach across the wider control estate, including PLCs and the other controllers that keep a plant running. Both are a subsection of OT penetration testing, and in practice the two overlap heavily.

Can a SCADA or ICS penetration test cause downtime?

It can if it is done badly. Pointing noisy automated tools at a fragile, unsupported controller can knock it over, and in a live plant that is dangerous. Done properly, the risk is managed: the tester works on site with your engineer, agrees every action in advance, uses passive techniques where possible, and only carries out active testing within an agreed window. The risk comes down to who you hire and how they work, not to testing itself.

Can you test live OT systems without taking them offline?

Yes. A great deal can be learned without disrupting anything, from passive reconnaissance that simply listens to traffic, to architecture and firewall-rule reviews that check your segregation line by line, to a structured threat-modelling session. When a process truly cannot tolerate any risk, this no-touch approach is a legitimate test in its own right, not a way of avoiding the hard part.

Do you need to connect tools to our network?

Not necessarily. A good OT tester keeps tooling to a minimum and prefers manual control, because an automated tool can do something unexpected before a human can step in. On some engagements the consultant never plugs into the network at all, instead asking your on-site engineer to run a command or use an existing tool and hand back the output. Any tool that is used is introduced slowly and only once your engineer agrees it is safe.

How does SCADA and ICS penetration testing relate to OT penetration testing?

SCADA and ICS penetration testing is the part of OT penetration testing that deals specifically with the control systems running physical processes. For the broader picture, including how OT testing differs from IT, what risks it uncovers, and how to choose a provider, start with the OT penetration testing guide and use this article for the SCADA and ICS detail.