Your PLC trusts the protocol, not the person
A maintenance engineer on the night shift at a water treatment plant watches an S7-300 controller accept a logic download. On the face of it, nothing is wrong. The function is valid, the block parses, the PLC accepts it and keeps the dosing pumps running. When he checks the engineering workstation back in the office, nobody is logged in.
That single scene is the S7comm trust problem. The protocol that carries Siemens PLC traffic was built on one assumption: if you could reach the controller, you belonged there. It carries no identity. It does not ask who sent the download. A logic block that looks valid is valid, whether it came from your licensed engineering station or from a script on a compromised IT host that pivoted onto the OT network.
What S7comm is, and what it assumes
S7comm is the application-layer protocol Siemens controllers use to talk to engineering stations, HMIs, and each other. Legacy S7comm runs in plaintext over TCP port 102, wrapped in an ISO transport layer that dates to a time when a plant network was a cable between a programming terminal and a rack of controllers, physically inside the same locked cabinet.
The protocol was designed for that world. It has functions for everything an engineer needs: read and write data blocks, download and upload logic blocks, start and stop the CPU, pull the diagnostic buffer. What it does not have is a field for who is asking. No authentication token, no cryptographic signature, no role. The newer S7commPlus variant added integrity protection and anti-replay checks, but the core assumption survives: the network is trusted, so the sender is trusted.
That assumption held for years. It does not hold anymore. Plant networks are no longer islands.
The functions that do real work, with no identity
Consider what an attacker can do with nothing more than network reach to a controller and a working knowledge of the protocol.
A logic download rewrites what the PLC does. It can change a comparison threshold, alter a trip condition, or quietly remove an interlock from the running program. A data-block write moves a setpoint. A CPU stop command halts the controller entirely. Every one of these is a legitimate, documented function. There is nothing malformed about any of them. An open-source library like snap7 can issue them all from a laptop in a few lines of code.
This is not hypothetical. Stuxnet, discovered in 2010, used the S7 protocol to reach Siemens S7-315 and S7-417 controllers and modify the logic that managed centrifuge drive frequencies. It did not crash the controllers. It quietly edited the program so the equipment damaged itself while the operator’s screen reported normal. More than a decade later, researchers still document man-in-the-middle techniques that intercept S7comm traffic between a SCADA system and a PLC and modify values in transit. And this year, security researchers flagged AI-generated exploit scripts aimed at internet-exposed S7 controllers.
Why a valid block download evades signatures
The industry’s default detection model is signature-based: a known exploit payload, a byte pattern, a CVE with a detection rule. That model is not useless. It catches malformed packets, protocol violations, and known exploit traffic.
But the S7comm trust problem is not a malformed-packet problem. The dangerous action arrives as a perfectly valid block download from a source the controller accepts. There is no exploit to fingerprint, because no exploit is used. The bytes are correct by definition. A signature engine looking for “bad” traffic sees only “good” traffic.
This is the signature gap in its purest form. Signatures only catch what has been seen before. A logic download that nobody wrote and no alarm caught has no signature to match.
What the controller actually sees
Walk through a specific case. An S7-300 controls the sodium hydroxide feed at a water treatment plant. Every Tuesday at 10:00, the process engineer downloads a tested block change from her workstation, the only host that has talked to that controller in months. It happens inside a scheduled maintenance window, after a change-management approval.
One night at 03:14, the controller receives a logic download from a host it has never talked to, on a subnet it has never seen traffic from. The block raises the upper pH setpoint so the dosing pump keeps feeding lye past the safe limit, and it disables the high-pH alarm so nobody sees it happening.
The controller cannot tell the difference between these two downloads. Both are valid. Both are accepted. The difference lives entirely in context: who sent it, when, from where, and whether that matches everything this network has done for the last six months. That context is not in the packet. It is in the history of the network.
Learning the normal, then noticing the deviation
A signature cannot answer “is this download expected,” because the answer depends on what this network normally does. That is a behavioral question, and it is answerable with a passive sensor that has been listening.
A network detection platform that learns the normal can know that this controller receives logic downloads only from the process engineer’s workstation, only during maintenance windows, only after approval. It can know which hosts talk to which controllers, on which ports, with which functions, at what times. A 03:14 download from an unknown host is not a subtle signal against that baseline. It is a loud one, flagged not because the bytes are bad but because the behavior does not fit the normal.
This matters more than it might seem. Mandiant’s M-Trends 2026 report puts the global median dwell time at 14 days. A leading OT threat-intelligence vendor’s 2026 year-in-review found that 30% of incident-response engagements began not with a detection alert but with someone in operations noticing something seemed wrong. Attackers are inside long enough to act, and the tools often do not see them. The behavioral baseline is how you shorten that window for the specific valid-command attacks that signatures will never catch.
The question worth asking
S7comm will not be rewritten. The installed base of S7-300 and S7-400 controllers is enormous, and industrial hardware refresh cycles run in decades, not years. Authentication will not be retrofitted onto controllers whose design assumed a trusted floor.
The question worth asking is different: can you tell when a valid S7comm function is unexpected? A download from a host that has never touched that controller. A CPU stop outside a maintenance window. A write to a data block from a device that has no business writing to it. That shifts the burden from the protocol, which offers no help, to the network, which holds the answer if you have been watching it closely enough to know what normal looks like.
Maigadi — the OT/ICS network detection & response (NDR) platform that passively learns your network’s normal and detects the novel, signature-less attacks others miss. On-premise. Explainable. Sovereign by design.