SCADA System Security: Threats, Safe Assessment and Choosing a Provider

Start with a hypothetical scenario. It is invented for illustration and does not describe any real incident or project. A fictional water utility orders a "standard infrastructure pentest." The tester follows a familiar IT playbook: a wide address range, active host discovery, service version detection and automated vulnerability scanning. Unnoticed, the range includes a data historian with network interfaces in both the corporate network and the process segment. The scan carries on through it, reaching pump station controllers and an older communication module.

What happens next rarely happens on an office network. The communication module stops answering polls, pressure values on the operator HMI freeze, and the shift crew can no longer tell whether the screen reflects the real state of the process. Operators switch to manual control. The chief engineer demands that the work stop, but the contract does not say who has the authority to call a halt or how to notify the tester. Recovery takes hours: there is no current backup of the module's configuration, and the equipment vendor is reachable only through a service ticket.

This example shows why the tester's competence must include an understanding of the industrial process and its constraints. Poor preparation can disrupt availability in an ordinary IT pentest too. In SCADA/OT, the consequences can additionally affect a physical process, endanger people and corrupt the data that operational decisions rely on. That is why an industrial control system security assessment starts not with choosing a scanner but with an inventory of the process, trust boundaries, rules of engagement, stop authority and recovery readiness.

What follows is a practical framework for CISOs, CTOs and heads of operations: what counts as OT, how threat paths run from the corporate network and remote access into operational zones, which assessment tiers are safe, how to record evidence and what to ask vendors and providers.

What counts as OT and why NIST SP 800-82 Rev.3 is the starting point

The final version of NIST SP 800-82 Rev.3 was published in September 2023. It addresses the security of operational technology while taking into account its unique performance, reliability and safety requirements. Its notion of OT is broad: programmable systems and devices that interact with the physical environment or manage devices that do. That includes industrial control systems, SCADA, building automation systems, transportation systems and physical access control systems.

In practice this means two things. First, the assessment boundary rarely matches the boundary of the "SCADA server room." It takes in operator HMIs, SCADA servers, engineering workstations, data historians and remote access gateways, and sometimes building management or entry control systems if they share the same infrastructure. Second, familiar IT priorities change places: the availability and predictability of control systems often matter more than confidentiality, and any intervention is judged by its consequences for the process.

Guidance, not a certificate

NIST SP 800-82 is guidance, not a universal certification scheme and not a mandate to be audited on a fixed cadence. Citing it in a contract or internal policy is useful as a shared vocabulary and reference point, but on its own it does not mean conformity with anything. As of September 21, 2026, the next revision, Rev.4, existed only as an initial public draft, so it should not be treated as a final replacement for Rev.3.

Technology-neutral frameworks belong alongside SP 800-82. The NIST Cybersecurity Framework 2.0 helps organizations understand and improve their management of cybersecurity risk. For the operational segment, it is practical to describe a current and a target profile and map the gaps to NIST informative references. Sector standards series, such as IEC 62443, should be reviewed separately and in light of the requirements of the specific industry. If an organization operates critical information infrastructure, it helps to understand in advance what evidence an audit will expect; that is the subject of our article on critical information infrastructure audit methodology.

Asset and process inventory

Without an inventory you can neither assess risk nor plan an assessment safely. In OT, however, a list of IP addresses and equipment models is not enough. You need to know which process function each node performs, what happens if it becomes unavailable and who is responsible for operating it.

It makes sense to start with what does not require touching devices: design and as-built documentation, network diagrams, configuration exports, account lists and service contracts. Passive discovery, which observes traffic that already exists, lets you learn about connected equipment with less interaction than active scanning. Its results should be checked against the documentation: discrepancies between "as designed" and "as actually running" are valuable findings in their own right.

What to record beyond a device list

• The node's role in the process and the consequences of its failure: shutdown, fallback to manual control, distorted readings, impact on safety functions.
• The operations owner and the person responsible for process safety, plus the equipment vendor contact.
• Software and firmware versions, whether a restart is acceptable and the windows in which maintenance is possible at all.
• Whether backups of configurations, controller logic and workstation images exist and how current they are.
• Network relationships: which nodes communicate across zone boundaries and over which channels, including remote access.

This inventory underpins every later step. Trust boundaries, the list of exclusions in the rules of engagement and the recovery plan all depend on it.

Trust boundaries and remote access in SCADA

A trust boundary is a point where data or control passes between zones with different levels of risk: from the corporate network into the process network, from the internet to a vendor portal, or from a contractor's engineering laptop to a controller. For each such boundary you need to answer several questions. What exactly is allowed to cross it? Who controls that? How is it logged? How quickly can access be revoked?

Typical weak points cluster at the seams. They include servers with interfaces in two segments, shared accounts, historians queried by analysts in the office, file exchanges for reports, and VPNs or remote access gateways left switched on "just in case." The external part of this surface, meaning portals, gateways and services visible from the internet, is worth testing separately using an external attack surface assessment methodology. That kind of review does not touch process devices directly and often yields valuable findings with minimal risk to the process.

Vendor and contractor access

Remote access by vendors and integrators is a trust boundary of its own and should be managed as a separate risk. You need to know which contractors have permanent or temporary access, through which mechanisms, with what authentication, who approves sessions and where the logs are kept. The same approach applies to assessing the vendors themselves: requirements and evidence for them are easy to structure using a third-party risk security assessment.

Threat paths from the corporate network to operational zones

Threats to SCADA are easier to model as paths than as a list of vulnerabilities: where misuse could begin and which boundaries it could cross to reach control functions. In practice, at least three starting zones are considered. The first is the corporate network: a compromised workstation, a shared server or an over-privileged account. The second is remote access: VPNs, gateways and cloud portals. The third is the vendor zone: service connections, update channels and contractors' engineering tools.

For each path, you assess which controls sit on each boundary, which of them have actually been verified and what happens if a control fails. In OT the consequences go beyond a data leak. Weaknesses that lead to system takeover or data theft in IT can, in an operational environment, lead to the loss of supervisory control functions or to untrustworthy data on the operator's screen. For an industrial site, that is often more critical than any leak.

Web components of HMIs and portals

If operators work through a browser-based HMI, dashboards, historian portals, REST APIs or a vendor remote access portal, part of the attack surface runs over HTTP. Web security standards apply directly here. HTTP does not keep state between requests, so sessions rely on cookies and authentication mechanisms. HTTP/1.1 provides an Upgrade mechanism that switches a connection to WebSocket, which is often how live data updates are delivered. During acceptance of such components, it is worth checking Content Security Policy, which helps detect and mitigate certain attacks including XSS and data injection, as well as CORS, CORP and Permissions Policy settings, session cookie handling and authentication.

For requirements and procedures, the OWASP projects work as a set: the Top 10 as an awareness document on critical web application risks, ASVS as a basis for verifying technical controls and secure development requirements, and WSTG as a set of testing procedures. ASVS recommends citing requirements with a version tag, such as v5.0.0-1.2.5, because identifiers can change between versions. Web testing still follows OT rules: a test copy of a portal is preferable to a live node that polls controllers.

Root-cause classes instead of chasing CVEs

The MITRE CWE Top 25 highlights the most dangerous and prevalent classes of software weakness, and MITRE notes that root-cause analysis helps eliminate entire classes of defect, such as memory safety and injection. CISA's Secure by Design alert series covers eliminating OS command injection, cross-site scripting, directory traversal and buffer overflows; on the last of these, CISA issued a warning jointly with the FBI. For SCADA programs, this provides a shared vocabulary with vendors. It is more productive to ask which defect classes have been eliminated architecturally than to discuss individual vulnerability identifiers for which a live environment may never have a safe update window.

Safe assessment tiers for SCADA security

The key difference between assessment methods in OT is the degree of interaction with live devices. Active scanning adds traffic to the network and interacts directly with in-scope devices. It may destabilize devices or interfere with process state, which means it can potentially affect safety and integrity. Passive discovery lets you learn about connected equipment with less interaction.

That sets the order of preference. First come passive discovery, configuration and architecture review, and offline analysis. Next come representative test systems and digital twins, and planned outages. Only after that, if it is genuinely necessary and explicitly approved, comes active testing of live production.

Why active scanning is a separate decision

Active testing should not be treated as a default mode that is simply switched on more carefully. Active scans should be scheduled during planned OT outages whenever possible. CISA and ICS-CERT guidance on control system assessments advises avoiding active scans of production control systems because they can cause operational issues or denial of service, and notes that passive activity may be sufficient. If production systems are tested actively anyway, local personnel should perform the tests at the assessment team's direction. A credible substitute or test system should also be considered.

The practical takeaway for the client: do not expect exploitation depth that cannot be achieved safely, and do not trust anyone who promises it. The least intrusive adequate evidence is often the best evidence. A weak setting confirmed from a configuration export is worth more than a risky demonstration on a running controller.

Rules of engagement and stop authority

Written rules of engagement (ROE) are the central document of any SCADA/OT assessment. According to CISA and ICS-CERT guidance, they define permitted activities, systems, operators, stop conditions and notification protocols. For OT, it is important to add specific people: named owners from operations and process safety, emergency contacts, and explicit approval of each active technique individually rather than of "active testing" as a whole.

1. Passive foundationDocumentation, architecture and passive discovery build a picture of assets and links without affecting the process.
2. Offline and benchConfigurations, backups and logic are analyzed offline; risky techniques are rehearsed on a test system or digital twin.
3. Recovery readinessBefore any active step, current backups, recovery steps and vendor availability are confirmed.
4. Decision per techniqueOperations and safety owners approve in writing the specific technique, system, window and stop conditions.
5. Planned window and local staffActive steps run in a planned outage where possible; on production, local staff perform them at the team's direction.

Minimum contents of the rules of engagement

• The list of in-scope systems and explicit exclusions, including safety systems and nodes without backups.
• Permitted and prohibited activities, with separate approval for each active technique.
• Named operations and process safety owners, and emergency contacts on both sides.
• Stop conditions and a person who can call a halt at any moment without the tester's agreement.
• A notification protocol: whom to inform, how and when about the start of work, deviations and completion.
• A reference to the recovery plan and confirmation that backups have been verified.

A simple rule: if you cannot find within a minute who stops the work and how to report it, the ROE is not ready. In the hypothetical scenario at the start of this article, that was exactly the missing item.

Recovery readiness before any testing begins

In OT, recoverability is a scope constraint, not an item for later. Before planning even passive work on a live system, it helps to answer a few questions. Are there current backups of configurations, controller logic and workstation images? Has restoring from them been tested, and how long does it take? Which vendors are needed for recovery, and how quickly are they available? Which nodes cannot be restarted without stopping the process?

The answers determine which methods are acceptable at all. A node without a verified backup becomes a candidate for exclusion from any active work until a backup exists. Sometimes the most useful outcome of preparing for an assessment is discovering that a critical component cannot be restored quickly. That is a real risk whether or not anyone finds a vulnerability.

Evidence, reporting and remediation

The value of a SCADA assessment is determined by the quality of its evidence, not by the number of issues found. Each finding should show where and by which method it was identified, at what level of interaction the evidence was obtained, which threat path it belongs to, what the possible consequences for the process are and what is proposed given operational constraints. It helps to map findings to CWE classes, to versioned ASVS requirements where web components are involved, and to the target CSF profile the organization has defined for itself.

NIST SP 800-115, published in September 2008, helps with method. It describes planning and conducting technical tests, analyzing findings and developing mitigation strategies, but states explicitly that it is not a comprehensive testing program. Its process guidance remains useful, while specific techniques for OT need to be weighed against SP 800-82 and the constraints of the environment.

In OT, remediation is often not possible right away: an update needs a window, vendor agreement or re-acceptance. Each finding should therefore record interim compensating measures and a criterion for verifying the fix. We cover how to track, verify and prove fixes in our article on vulnerability remediation control.

An assessment is not a certification

A SCADA/OT pentest or security assessment is not a certification, a statutory attestation or an assurance opinion on the adequacy of protection. The report describes what was tested, by which methods, within which limits and what remained untested. If the results are needed for audit preparation, the scope and evidence format are best agreed in advance; see our guide to penetration testing for audit readiness.

Procurement and questions for OT vendors

Much of SCADA security is built in at procurement. Under Secure by Design, CISA's position is that customer security should be a core business requirement rather than a technical option. Products should be secure out of the box, and multi-factor authentication, logging and single sign-on should be available at no extra cost. For OT owners and operators, CISA published the guide "Secure by Demand: Priority Considerations for Operational Technology Owners and Operators when Selecting Digital Products." There is also a general Secure by Demand guide for discussions with resellers and service providers, guidance on safe software deployment, and guidance produced with Australia's ACSC on choosing secure and verifiable technologies.

The Secure by Design Pledge that software manufacturers sign is a good-faith commitment to work toward seven key goals and publish progress reports, not a certification. It is sensible to treat it as a signal and back it with contractual requirements. MITRE notes that fewer vulnerabilities during development mean fewer issues after deployment. Procurement requirements are therefore usually more rational than costly retrofitting of an installed system.

The matrix below works both for buying a product and for choosing an assessment provider.

How to choose a SCADA/OT assessment provider

A good provider starts with questions about the process, not with a list of tools. They ask which functions are critical, which nodes must not be touched, whether a test system exists, who owns operations and safety, and how recovery works. Their methodology traces back to the stages of planning, execution, analysis and mitigation strategy, and their work plan clearly separates passive, offline, bench and active activities.

Warning signs include promises of a "full compromise" of the production environment, active scanning of live production without a plan or stop conditions, no formal authorization process, guaranteed results, and reports that list individual vulnerabilities without root causes or recommendations. Any claims about cost, timelines or results should be checked against the contract.

Before starting, ask for an anonymized sample report and a work plan for an OT environment, and clarify which work happens only on a bench and who on the client side approves each active technique. If you need to assemble an assessment scope around these constraints, meaning systems, exclusions, windows and expected evidence, start with preparing your pentest scope on Pentest.red. It helps separate in advance what can be tested safely from what requires a separate decision by the owners.

Conclusion: SCADA system security as a managed cycle

SCADA system security is built not around one product or one test but around a cycle. It covers process inventory, trust boundaries, threat paths, safe assessment tiers, rules of engagement with clear stop authority, recovery readiness, evidence-based reporting and remediation control, followed by procurement requirements that reduce defect classes in new systems. NIST SP 800-82 Rev.3 sets the general reference point for OT, CSF 2.0 helps link findings to target outcomes, and CISA guidance shows how to keep an assessment from becoming an incident.

The core principle is simple: process safety, integrity, availability, vendor constraints and recoverability are scope conditions just like a list of IP addresses. The least intrusive adequate evidence is often the best.