Why Attack Surface Management Breaks in OT (and What Actually Works)

Attack surface management has a comfortable story.

You enumerate your domains, discover the hosts behind them, fingerprint the services, find the holes, and feed the whole thing into a dashboard that refreshes on a schedule. For IT assets, that story mostly works.

Then someone hands you an industrial network, and every assumption breaks at once.

The protocols were never designed to be questioned

Most of the industrial protocols still running plants today predate the threat model we now apply to them. Modbus was published by Modicon in 1979. It has no authentication, no encryption, and no concept of a session that could be hijacked, because none of that was relevant when the device on the other end sat three meters away on a serial loop (Modbus Organization, 2012). DNP3, S7comm, and BACnet carry the same inheritance. The ISA and IEC codified the modern expectations later, in the IEC 62443 series, but the installed base does not get rewritten because a standard arrives.

This matters for attack surface management in a specific way. On an IT asset, an unauthenticated service is a finding. On an OT asset, unauthenticated is the protocol working as designed. The exposure is real, but you cannot treat the device as misconfigured and move on. You are looking at a structural property of a system that may have a fifteen year service life and a vendor contract that voids the moment you touch the firmware.

You often cannot run the scan at all

The second wall is harder. The core move of ASM is active interrogation: send a probe, read the response, infer the service. In OT, that move can take the asset down.

This is not folklore. NIST's Guide to Operational Technology Security treats availability and safety as first-order constraints and is explicit that security testing on live OT must be approached with caution, favoring passive monitoring over active interrogation wherever possible (NIST, 2023). The reason active scanning is risky is mundane:

A PLC's network stack is sized for deterministic control traffic, not for a scanner opening a thousand connections a second. The device does not misbehave because it is insecure. It misbehaves because it is busy keeping a physical process inside its safe envelope, and the scan is competing for the same scarce CPU.

So the practitioner faces a constraint with no equivalent on the IT side. The most informative tool in the kit—the active scan—is frequently the one tool you are contractually and operationally forbidden to point at the target. Many industrial environments will only grant you a span port and a packet capture.

The inventory problem compounds everything

You cannot install an agent on a relay. You cannot expect a thirty year old RTU to answer an SNMP query. There is no EDR for a turbine governor. The endpoint-centric inventory methods that IT security leans on have no purchase here, which is why so many operators genuinely do not know what is on their own networks. Dragos has reported that the large majority of OT networks still lack meaningful network monitoring, which keeps poor asset visibility among the most persistent gaps it finds across the environments it assesses (Dragos, 2026).

And the surface is not as air gapped as the org chart implies. IT and OT convergence, remote vendor access, and historian servers that bridge both worlds mean industrial assets routinely surface on the public internet. Internet-wide exposure of ICS protocols has been documented for over a decade, going back to the Project SHINE research (Radvanovsky & Brodsky, 2014), and you can still watch it live on any internet-wide scan engine today.

The incidents that followed are not hypothetical:

• Stuxnet reprogrammed centrifuge controllers (Falliere et al., 2011).
• The 2015 and 2016 attacks on the Ukrainian grid manipulated protection and switching equipment directly (Cherepanov, 2017).
• Triton targeted a safety instrumented system, the layer of last resort designed to prevent physical harm (Dragos, 2017).
• The 2021 intrusion at the Oldsmar, Florida water treatment facility, where an actor raised the sodium hydroxide dose through the SCADA interface, showed how low the bar for reaching a control system can be (CISA, 2021).

None of these required exotic protocol exploits. They required reaching devices that assumed no one hostile would ever speak to them.

What actually works, and the tools that do it

The discipline OT demands is the inverse of the ASM instinct in IT.

Lead with passive. Earn the right to be active. Default to safe.

Start passive

Start with passive discovery that never touches the plant. Internet-wide scan data from Shodan and Censys already indexes exposed ICS services by protocol, banner, and vendor, so you can map a client's externally reachable industrial footprint without sending a single packet to their network. A tool like uncover lets you query several of these engines from one interface and pull the candidate host list before deciding whether any active step is warranted at all. For the many industrial assessments that pass procurement on a passive-only attestation, this is the entire engagement.

Earn the right to go active

When active enumeration is authorized, reach for the gentlest tool that answers the question. Nmap is the right starting point, not because it is exotic but because its ICS coverage is mature and well understood. The standard NSE library already ships protocol-aware scripts such as:

modbus-discover
s7-info
bacnet-info

Digital Bond's Redpoint NSE bundle extends that to a broader device set. These do identity and version enumeration rather than register manipulation, which is exactly the line you want to stay behind. The scripts are old and the repos are dormant, but the NSE invocations are stable against current Nmap and add no new toolchain to vet.

For protocol-level detail, use a purpose-built scanner with a real safety posture. scada-scanner (MIT licensed) detects Modbus TCP, S7, DNP3, BACnet, EtherNet/IP, IEC 60870-5-104, OPC UA, and CODESYS, and ships a safe-mode flag that should be your default rather than your fallback. Protocol-specific tools such as s7scan and plcscan fill gaps when a vendor or device family needs closer attention.

The selection criterion is not coverage breadth. It is whether the tool offers a passive or read-only mode, and whether its license actually lets you use it. Several of the broadest ICS scanners carry noncommercial licenses that unfortunately disqualify them from any paid engagement.

Build the guardrails in

Build the guardrails into the workflow, not into the operator's memory:

• Safe mode on by default
• Active OT scanning gated behind explicit per-target opt-in
• Conservative concurrency and rate limits
• An audit-log line on every active probe that records what ran, against what, and with which safety settings

This is where orchestration earns its keep: when the safe configuration is the shipped default, a tired analyst at the end of a long assessment cannot accidentally fast-scan a live PLC. The point of building it into the platform, rather than leaving it to discipline, is that the safe choice becomes the path of least resistance.

The honest summary

ICS and OT attack surface management is hard not because the tools are missing but because the field's central technique is the one move you frequently cannot make. The protocols answer honestly to anyone who asks. The devices misbehave when asked too loudly. The inventory resists every agent-based shortcut.

The teams that do this well are not the ones with the most aggressive scanners. They are the ones who treat passive discovery as the default, active probing as a privilege, and safe mode as a starting position rather than a setting they remember to enable.

In OT, the most professional thing your tooling can do is know when not to send the packet.

References

• Cherepanov, A. (2017). Win32/Industroyer: A new threat for industrial control systems. ESET.
• Cybersecurity and Infrastructure Security Agency. (2021). Compromise of a U.S. water treatment facility (Alert No. AA21-042A).
• Dragos. (2017). TRISIS: Analyzing safety system targeting malware.
• Dragos. (2026). OT/ICS cybersecurity year in review.
• Falliere, N., Murchu, L. O., & Chien, E. (2011). W32.Stuxnet dossier (Version 1.4). Symantec.
• Modbus Organization. (2012). Modbus application protocol specification V1.1b3.
• National Institute of Standards and Technology. (2023). Guide to operational technology (OT) security (NIST SP 800-82 Rev. 3).
• Radvanovsky, B., & Brodsky, J. (2014). Project SHINE (SHodan INtelligence Extraction) findings report. Infracritical.

Tools referenced