There is a common assumption in cybersecurity that you need to run something to break it. That finding vulnerabilities means sending malicious packets, triggering exceptions, and watching a system fail in real time. For most software environments that assumption is reasonable. For industrial control system firmware protecting critical infrastructure, it is wrong — and dangerously so.

Static analysis of ICS firmware reveals security failures that dynamic testing cannot find, often for reasons that are fundamental to how critical infrastructure operates. Understanding the difference matters whether you are a security researcher, a utility operator, or an organization trying to understand your risk posture.

Dynamic testing — fuzzing, penetration testing, live exploitation — requires access to a running system. In most enterprise environments that is manageable. In ICS environments protecting electric substations, water treatment facilities, and oil and gas pipelines, it is often impossible.

Protection relays, RTUs, and SCADA controllers are not test lab equipment. They are operational systems whose failure has physical consequences. A protection relay that fails to trip a circuit breaker during a fault condition does not produce an incident report — it produces an equipment fire or a cascading grid failure. No utility operator allows a security tester to send malformed packets to live substation equipment, and no responsible security researcher should ask them to.

Dynamic testing also requires hardware. Lab reproductions of ICS equipment are expensive, often unavailable for older platforms, and may not accurately replicate the behavior of production firmware running on production hardware. Most organizations do not have spare critical infrastructure equipment sitting unused in a lab waiting to be tested.

Static analysis requires neither running systems nor lab hardware. It requires the firmware binary and the right methodology.

A firmware binary is not a black box. It is a structured artifact containing the complete logic, configuration, and security decisions of the device — frozen in time and fully available for analysis without ever powering on the hardware.

Across ICS firmware research broadly, static analysis consistently surfaces categories of findings that dynamic testing struggles to identify even with full lab access.

Security mechanisms absent by design. Some firmware implementations lack security capabilities entirely at the code level — not disabled features, not misconfigurations, but architectural absences. Absent mechanisms produce no observable behavior on a live network. They cannot be discovered by interacting with the device externally. They are only visible by examining what the binary actually contains.

Secure features disabled by default. Security capabilities are sometimes present in firmware code but inactive in the default configuration. A device tested in its default state may appear to behave securely from the outside while carrying disabled security mechanisms internally. Binary analysis reveals actual default states independent of external behavior.

Privileged operations accessible without authentication. Code-level analysis can identify pathways to sensitive device functions that bypass authentication requirements. These pathways do not manifest as observable network behavior until exploited — making them invisible to any testing methodology that relies on external interaction with the running device.

These categories appear across ICS firmware from multiple vendors and device classes. They represent structural patterns in how embedded security is implemented — or not implemented — in critical infrastructure devices.

Intellectual honesty requires acknowledging the limits.

Static analysis cannot confirm exploitability in the way a working proof of concept demonstrates. It identifies what the code contains and what the code does not contain — it does not produce a live demonstration of impact. For critical infrastructure environments this is a feature rather than a limitation, but it means findings are framed in terms of capability and risk rather than demonstrated exploitation.

Static analysis also requires deep expertise in the target architecture, operating system, and protocol stack. Embedded real-time operating systems, low-level assembly analysis, and ICS protocol implementations are specialized knowledge domains. The methodology is powerful but not accessible without significant background in these areas.

Utility operators and critical infrastructure organizations often assume that because their systems are not internet-facing, or because access requires physical presence, the attack surface is limited. Static analysis challenges that assumption by revealing what firmware actually does — independent of network topology, physical access controls, or operational constraints.

A device with a security mechanism absent at the firmware level is vulnerable regardless of what the protocol specification recommends. A device with authentication disabled by default is vulnerable regardless of network segmentation. Compensating controls applied at the network layer do not change how firmware responds to protocol traffic.

Understanding your firmware's actual security posture — not its theoretical posture based on protocol standards or vendor documentation — requires examining what the binary contains.

Static firmware analysis for ICS devices follows a consistent and repeatable methodology. Firmware acquisition from vendor sources or authorized channels. Binary unpacking and structure identification. String analysis to surface security-relevant patterns, configuration mechanisms, and protocol implementations. Disassembly and decompilation of key functions to understand authentication logic and access control at the code level. Cross-version comparison to identify how security posture changes across firmware releases.

The output is a structured assessment describing what security mechanisms exist, what is absent, and what the risk implications are for the operator — delivered without ever connecting to a live system.

For critical infrastructure operators managing firmware across device populations that may span decades of releases, this methodology provides something dynamic testing cannot: comprehensive security visibility with zero operational risk.

Ryan Sharpnack is an independent ICS firmware security researcher and founder of VulnHunter AI. He is an accepted speaker at SANS ICS Security Summit 2026. All consulting engagements are delivered remotely through static analysis requiring no live system access.