Almost every control an OT security program puts in place rests on one premise: traffic reaching a controller is suspect until proven otherwise. Segmentation enforces it, allowlists enforce it, and the zones and conduits model of IEC 62443 formalizes it.
Firmware updates are the deliberate exception. An update is the one operation where a plant intentionally allows arbitrary code to be written into the most consequential device on the network, on the authority of a file that arrived from outside. The workstation performing it is trusted by design. The vendor that produced the image is trusted by contract. The maintenance window is a period when alarms are expected, devices reboot, and unusual traffic is scheduled rather than merely tolerated.
That is why update infrastructure is worth an adversary's patience. It is not a way around the trust boundary. It is the trust boundary, operating as designed, carrying something it was never asked to verify.
Why the Update Path Is Structurally Weak
The weakness is not primarily cryptographic, though signing gaps are real. It is that the update path has more participants than anyone tracks, and most sit outside the plant's control.
A PLC firmware image originates with the controller vendor, but it is assembled from components the vendor did not write: a commercial real time operating system, a third party TCP/IP stack, cryptographic libraries, open source packages pulled during the build. The 2020 Ripple20 disclosures made this concrete when researchers at JSOF found vulnerabilities in the Treck TCP/IP stack that had propagated into devices from hundreds of manufacturers, many of which did not know they shipped that code. URGENT/11 and NAME:WRECK repeated the pattern in other embedded stacks. A single upstream defect became a multi vendor firmware problem, and asset owners had no bill of materials to tell them they were exposed.
From there the image travels a distribution path that is rarely uniform: a vendor portal, a systems integrator under service contract, removable media carried by a field engineer, an attachment from a distributor. Each has different custodians, and the plant rarely knows what happened to the file before it arrived.
It then lands on an engineering workstation: the machine that runs the vendor programming environment, holds project files and controller passwords, and reaches devices nothing else in the plant can. It is also, very often, a Windows host on extended support running software that will not tolerate an EDR agent. The final step leaves the least evidence of all. The workstation opens a session to the controller over a proprietary vendor protocol, and writes.
The most common failure is not a forged signature. It is that nobody verified there was one. Many OT devices in service today accept firmware with no image signing at all, and where signing exists, the check often runs on the workstation rather than on the controller. A check performed by the same machine an attacker already controls is not a check.
What the Historical Record Actually Shows
Two incidents define this problem, and they are worth separating because they are usually conflated.
Stuxnet, discovered in 2010, is the canonical case of an attack reaching controllers through the engineering path. It propagated to Windows hosts running Siemens Step 7 and intercepted the library the programming software used to talk to S7-300 and S7-400 controllers, modifying the logic being written down and replaying recorded process values back to the operator interface so the change stayed invisible. The lesson is not that a nation state built a sophisticated implant. It is that the engineering workstation is the position from which controller code can be modified without touching any network control a plant relies on.
The SolarWinds compromise, disclosed in December 2020, showed the other half: a trusted vendor's build pipeline can be subverted, and the signed artifact will be installed by careful organizations precisely because it is signed. Malicious code entered the Orion build process, the output carried a valid signature, and roughly 18,000 organizations installed it through normal patch management. Every downstream verification worked correctly. The artifact was authentic. It was also malicious.
The threat model follows. An attacker need not break signing when they can compromise either the machine that performs the update or the process that produces the thing being signed. Both end with a controller running code the asset owner believes is legitimate. What the record does not yet show is an OT controller vendor's signing infrastructure being compromised and a malicious signed image reaching plants at scale. That is a gap in the record, not evidence of impossibility.
Regulation Is Moving Faster Than the Installed Base
IEC 62443-4-1 governs the secure development lifecycle for suppliers, 62443-4-2 sets component requirements for software integrity and authenticity, and 62443-2-3 covers patch management on the asset owner side. The EU Cyber Resilience Act, in force since December 2024 with main obligations from December 2027, makes an SBOM and a vulnerability handling process legal requirements for products sold into the EU. NIS2 pushes supply chain obligations onto operators themselves.
All of that improves equipment shipped after the requirements bite. It does little for the controller commissioned in 2013 and scheduled to run until 2033. Regulation changes the flow of new equipment, not the stock, and the stock is what a plant defends.
Controls That Work Against the Installed Base
Constrain who can write. The set of hosts that should ever write firmware or logic to a controller is small, static, and known: in most plants, a handful of engineering workstations. That set belongs in an enforced allowlist at the conduit boundary, and the workstations in a dedicated zone with no internet reachability and no general purpose use. This is the highest value control available, because it requires no device to be replaced.
Verify the artifact independently of the machine that installs it. Where the vendor publishes hashes, check them from a system other than the engineering workstation before staging the file. Where the vendor provides an SBOM, keep it: it turns the next Ripple20 style disclosure from a month of vendor emails into a database query. Where neither exists, that absence is a procurement finding worth raising at contract renewal, the one moment an asset owner has real leverage over a vendor.
Establish what a legitimate update looks like, so an illegitimate one is visible. Most programs skip this, and it is what catches the cases where the first two controls were bypassed.
What an Update Looks Like on the Wire
Firmware delivery is not subtle traffic. Industrial controllers have narrow behavioral envelopes: a small peer set, a stable protocol mix, request sizes in tens of bytes, a poll cadence with jitter in the low milliseconds. A firmware update is a large sustained transfer followed by a reboot, violating nearly all of those at once. That makes it one of the more detectable events in an OT environment, provided anyone watches for it.
The observable sequence is consistent across vendors even though the protocols differ. A session opens from a host to a controller over a vendor management protocol rather than the process protocol that host normally speaks: S7comm or S7comm-plus block download function codes on Siemens equipment, CIP file transfer service codes on EtherNet/IP, a proprietary maintenance channel elsewhere. Transfer volume rises by orders of magnitude over baseline. The session terminates. The controller stops responding for a period consistent with a reboot. When it returns, its identity response has changed, and often its timing signature with it, because different firmware does not schedule its scan cycle identically. That last property is a fingerprint an attacker cannot easily suppress: it emerges from how the code runs, not from what the code reports.
Detecting this requires decoding rather than counting. Flow telemetry such as sFlow or NetFlow shows that a large transfer happened between two hosts, a useful trigger, but it cannot separate a firmware download from a project upload or a diagnostic dump, and that distinction is the finding. Full packet inspection from a SPAN or mirror port resolves the vendor protocol service codes and makes the sequence legible. Passive collection matters here for its own sake: no plant engineer will accept an active scanner probing a controller during a maintenance window, which is exactly when this needs watching.
Checks worth running continuously: any firmware or program download to a controller from a host outside the approved engineering set; any such session outside an approved maintenance window; a controller identity or firmware revision that changes with no matching change record; a scan cycle timing signature that shifts after a reboot; and an engineering workstation opening a management session to a controller it has never touched.
The Question Worth Asking
The uncomfortable version of this problem is that a plant can absorb a firmware supply chain compromise and generate no alert at all. The change ticket exists. The maintenance window is approved. The engineer is legitimate. The workstation is authorized. The vendor is real. Every process control functions as written, and the controller ends up running attacker code.
What breaks that chain is not a stronger approval process. It is an independent record of what the devices actually did, kept outside the approval chain and not editable by anyone in it.
Three questions test whether that record exists. Which hosts issued a firmware or program download to a controller in the last twelve months, and does that list match the change tickets. When a controller's firmware revision changes, does anything notice within minutes rather than at the next audit. And if a controller came back from a reboot behaving differently, would that be a detection or an anecdote someone mentions later.
All three are answerable from passive observation of traffic already crossing the network. None require replacing a controller, upgrading a workstation, or waiting for signed firmware for a device that reached end of support years ago.