In cybersecurity, a paper written more than twenty years ago can easily feel obsolete. Tools change, architectures evolve, terminology changes, and threats become more sophisticated.
But Sandia National Laboratories’ 2005 paper, “Penetration Testing of Industrial Control Systems,” by David P. Duggan, Michael Berg, John Dillinger, and Jason Stamp, is surprisingly different.
The report was published in March 2005. Duggan-07 Yet much of its advice could appear in an OT penetration-testing methodology written today.
What makes it particularly interesting is not the tools it mentions. It is the mindset behind the testing.
Before “OT Security” Became the Language We Use Today
There is an interesting historical detail here.
The report uses Industrial Control Systems (ICS) in its title, but inside the paper the authors largely speak in terms of SCADA, EMS, DCS, PCS, and industrial control systems. Duggan-07
What we now commonly discuss as the broader discipline of OT cybersecurity was not yet expressed using today’s mature OT-security vocabulary.
There was no modern ecosystem of “OT security platforms,” “OT SOCs,” “OT EDR,” “attack-path management,” or the extensive commercial OT-security market we know today.
Yet the fundamental problem was already clearly understood:
Industrial systems are not simply another type of IT system.
That principle runs through the entire paper.
And twenty-one years later, it remains one of the most important lessons for anyone performing security assessments or penetration testing in industrial environments.
The Physical Process Changes Everything
The paper begins with a warning: penetration testing an industrial control system should not be taken lightly.
Why?
Because these systems control real-world equipment and processes.
Incorrect instructions can result in waste, damaged equipment, injuries, or even death. Duggan-07
The authors provide three striking examples.
During a ping sweep of a SCADA network controlling nine-foot robotic arms, one of the arms unexpectedly activated and rotated 180 degrees. Fortunately, the person in the room was outside its reach.
In another case, a ping sweep on a process-control network caused a semiconductor manufacturing system to hang, destroying approximately $50,000 worth of wafers.
And in a third case, an IT security consulting company performing a corporate penetration test crossed into a network directly connected to SCADA. The testing locked up the SCADA system and prevented a gas utility from sending gas through its pipelines for four hours. Duggan-07
These stories are over twenty years old.
But the lesson could be printed on the first slide of an OT penetration-testing course today:
The security test itself can become a process hazard.
IT Pentesting Logic Cannot Simply Be Copied into OT
Traditional penetration testing tends to encourage interaction.
Discover the hosts.
Scan the ports.
Enumerate the services.
Identify vulnerabilities.
Exploit where permitted.
In a conventional IT environment, an unstable server might be restarted or restored. Industrial systems are different because their actions interact directly with physical processes, some of which are time-critical. Duggan-07
The Sandia paper therefore asks an excellent question before discussing tools:
Why is penetration testing necessary for this system?
The authors suggest first understanding the threats being investigated. Are we concerned about malicious people, rogue hosts, accidental actions, or something else? More importantly, will penetration testing actually identify vulnerabilities relevant to those threats? Duggan-07
I think this remains extremely relevant.
Sometimes security teams begin with:
“What can we scan?”
The better question is:
“What are we trying to learn, and what is the safest way to learn it?”
That is a very different mentality.
Passive Before Active
One of the strongest parts of the paper is the table comparing normal IT penetration-testing techniques with preferred approaches for SCADA environments.
Instead of immediately using a ping sweep to discover systems, the authors recommend alternatives such as examining switch CAM tables, router configurations and routing tables, physically tracing connections, and passively listening to network traffic.
Instead of port scanning operational devices, they suggest local port verification or scanning duplicate, development, or test systems.
Instead of running vulnerability scanners directly against production systems, they suggest obtaining version information locally, comparing it against known vulnerabilities, or scanning representative test equipment. Duggan-07
The principle behind the table is more important than the individual techniques:
Avoid generating unnecessary traffic against an operational industrial system.
The authors explicitly argue that traditional penetration-testing activities are only one way of obtaining the required information. Less intrusive approaches can often provide much of the same knowledge without introducing unnecessary operational risk. Duggan-07
Today we might describe this using terms such as passive asset discovery, safe assessment, representative testing, offline analysis, digital twins, testbeds, or controlled validation.
The technology has evolved.
The principle has not.
Operations Must Be Part of the Security Test
Another sentence deserves attention.
The paper says operations personnel must know when testing is occurring and must be prepared to respond immediately if something goes wrong. If manual control is possible, personnel capable of taking manual control should be present during security testing. Duggan-07
This is remarkably close to what we now consider good OT penetration-testing governance.
An OT pentest is therefore not merely:
Pentester → Network → Target
It is closer to:
Security + Operations + Engineering + Process Knowledge + Safety + Testing
The tester needs to understand not only whether an action is technically possible, but also what that action might mean to the process.
Legacy Systems Were a Problem Then — and They Still Are
The report also discusses another familiar OT problem: longevity.
Industrial systems can remain operational far longer than normal IT systems. Consequently, processors may be generations behind contemporary hardware, networks may operate at relatively low speeds, and active testing can overwhelm devices or network stacks. Duggan-07
Again, this sounds remarkably contemporary.
Twenty-one years later, security professionals still encounter legacy controllers, old operating systems, fragile protocol implementations, long equipment lifecycles, unsupported components, and devices that cannot safely tolerate aggressive scanning.
Modern tools may be better at recognizing industrial equipment and controlling scan intensity.
But “safer scanner” does not mean “safe under every process condition.”
Understanding the system still comes before touching it.
The IT/OT Connectivity Problem Was Already Visible
The paper also recognized the architectural tension that continues today.
Complete separation between SCADA and IT systems offers strong protection from external influences, the authors argue, but complete separation is often impractical because industrial information is required for business decisions.
Their answer was therefore to develop secure mechanisms for exchanging information while avoiding unnecessary direct connectivity between IT and SCADA components. Duggan-07
Today the architecture is much more complicated.
We have cloud connectivity, historians, remote vendors, IIoT, edge computing, remote operations, analytics platforms, AI systems, and increasingly interconnected supply chains.
But the architectural question remains almost identical:
How do we obtain the business value of connectivity without allowing that connectivity to create uncontrolled paths into the industrial process?
The technology surrounding the problem has changed dramatically.
The fundamental problem has not.
What I Think This 2005 Paper Gets Right
For me, the most valuable lesson in this short report is that OT penetration testing is not primarily about pentesting tools.
It is about consequence-aware testing.
The paper essentially tells the tester:
Understand what you are testing.
Understand why you are testing it.
Understand the process behind it.
Understand what your traffic could do.
Prefer passive information gathering when possible.
Use test or duplicate systems where practical.
Coordinate with operations.
And never allow the security assessment itself to become the incident.
The report closes with a memorable warning: no security tester wants to become known as the person who turned off the lights in a city, flooded a valley, or released toxic chemicals. Duggan-07
That may have been written in 2005.
It could just as easily have been written in 2026.
Twenty-One Years Later
Reading old cybersecurity research is useful because it helps distinguish between problems created by today’s technology and fundamental engineering problems that technology has never solved.
This paper belongs to the second category.
We now have better OT visibility tools, better asset identification, specialized industrial IDS platforms, improved vulnerability intelligence, sophisticated testbeds, threat intelligence, IEC 62443 practices, MITRE ATT&CK for ICS, and much greater awareness of industrial cybersecurity.
But a modern OT penetration tester still needs to answer essentially the same question Sandia was asking in 2005:
Can I obtain the security information I need without creating unacceptable risk to the physical process?
Perhaps that is the most important takeaway.
In IT penetration testing, we often think first about what a system will allow us to do.
In OT penetration testing, we should first think about what the process can safely allow us to do.
That distinction was understood more than two decades ago.
It is still worth teaching today.
Want to Get Started with OT Penetration Testing?
If you’re new to OT/ICS security and want to understand the basics before going deeper, I have a practical introductory course covering the fundamentals of OT cybersecurity and OT penetration testing, including hands-on exposure using LabShock.
It’s a good starting point for understanding how OT pentesting differs from traditional IT pentesting and how to approach industrial environments safely.
Start with the basic course:
OT/ICS Penetration Testing Basics
If you’re interested in joining my upcoming OT/ICS Penetration Testing course, register your interest below. I’ll notify you when the next course details, dates, and registration information are available.
Register your interest:
OT/ICS Penetration Testing Course Registration
Reference
Duggan, D. P., Berg, M., Dillinger, J., & Stamp, J. (2005). Penetration Testing of Industrial Control Systems. Sandia National Laboratories, SAND2005–2846P, March 2005. Duggan-07