· Security · 24 min read
The Firewall Is Not Defense in Depth: The S7 Joint Advisory, Step by Step
Five federal agencies told operators to get their S7 controllers off the Internet and behind a boundary. That instruction is right, and it carries more weight than its place in a seven-item list suggests — because several of the device-side mitigations beside it do less than their labels promise.
On 18 August 2026 the NSA, CISA, FBI, DOE and EPA issued a joint advisory on active threat activity against Siemens S7 series PLCs: reconnaissance and capability development against Internet-exposed controllers, using AI-generated scripts built on public automation libraries. It closes with seven groups of hardening steps. This page walks those seven, in order, against what this series measured on real hardware and distilled into a companion decision-tree checklist — where the advisory is exactly right, where a device-side control does less than its label, and the one dimension the advisory never mentions at all. Its central instruction, to get these controllers off the Internet and behind a boundary, is the one we agree with most emphatically, and for a reason the rest of the list understates.
- 1. Where this fits
- 2. What the advisory says
- 3. One distinction to carry through: "S7comm" is two protocols
- 4. The seven steps, one at a time
- 5. The dimension the advisory never mentions: TLS and authentication
- 6. Where the checklist is the narrower document
- 7. A note on disclosure
- 8. Where to go next
- 9. About
1. Where this fits
This page is a response to a specific document, and it is the shortest way into the series. The measurements it summarizes live in Three Doors into the Same Controller, which maps the protocols an S7 CPU actually answers on; Read Access Doesn’t Mean Read-Only, on what the global protection levels and the named-user model gate; and Encrypted, but Not Authenticated, on what TLS is and is not worth on the native channel. Its practical counterpart is the hardening checklist — the same conclusions as a commissioning decision tree, which this page reads the advisory against, step by step. The checklist itself is still being reworked and will follow as a separate article.
Everything below was measured on real hardware — S7-1500, S7-1200 and S7-1200 G2 controllers, plus an S7-300 — with our own protocol driver. Where a claim is not ours, it is attributed. Where we have no measurement, the text says so rather than guessing.
2. What the advisory says
The short version, and it is worth reading the original rather than my summary of it.
Threat actors are scanning for Internet-exposed Siemens S7 controllers using commercial scanning services, then using AI assistance to generate exploitation scripts built on snap7 / python-snap7 — a well-established open source S7 library — disguised as legitimate monitoring tools. The activity observed is read and write access to data blocks, assessed as reconnaissance and pre-positioning rather than immediate effects. The targeted models span S7-200, S7-300, S7-400, S7-1200 and S7-1500, including F-series safety controllers.
The advisory then gives seven groups of mitigations: inventory, patch, segment, strengthen access controls, log and monitor, apply S7-specific hardening, and contact Siemens. The rest of this page takes them in that order.
Two things about this are worth saying plainly before I disagree with any of it. It is a threat advisory rather than a hardening study, and it is doing that job well: the threat is real, the tooling is public, and "AI lowers the expertise needed to weaponize known weaknesses" is exactly the shift that makes a decade of Internet-exposed PLCs newly dangerous. And its central recommendation is right.
3. One distinction to carry through: "S7comm" is two protocols
Before the steps, one distinction the advisory blurs and this page leans on repeatedly.
The advisory speaks throughout of S7comm on TCP port 102, and the tooling it names — snap7 and python-snap7 — speaks legacy S7Comm, the 0x32 protocol. A modern S7-1200 or S7-1500 does not use that protocol for its own engineering and HMI traffic. It uses S7CommPlus (0x72), a different protocol on the same port, which the advisory never names. One port, two protocols, different reach — and it cuts both ways:
On an S7-300 or S7-400, legacy S7Comm is the native protocol. The advisory’s threat model fits those generations exactly, and they have no meaningful device-side answer to it.
On a 1200 or 1500, legacy S7Comm reaches the CPU only if PUT/GET is enabled, and even then it addresses classic blocks by absolute address — it cannot see optimized-block tags at all. An operator who has PUT/GET switched off and uses optimized blocks is substantially out of reach of the specific tooling described.
That is not the same as being safe. The second door — S7CommPlus — is still there. Disabling PUT/GET does not restrict it, and the client that speaks it is not exotic: it is what every HMI panel and every modern engineering station already uses.
That distinction reshapes the advisory’s access advice (step 4) and its detection advice (step 5). Hold onto it.
4. The seven steps, one at a time
For each group: where the bench agrees, where a control does less than its label, and where the checklist would add or reorder something.
4.1. Steps 1 and 2 · inventory, and patch
Agree, and below this page’s altitude. Inventory and patching are right, and they are operational rather than configuration — the checklist is a settings tree and assumes both. Two footnotes from the bench. First, you cannot set a ceiling on a controller you have not inventoried, and the most useful inventory question this page can hand you is which of your CPUs have PUT/GET enabled, and what still needs it — step 4 is where that pays off. Second, not everything measured in this series is patchable: that read access is not read-only is by design, not a bug, so no firmware update closes it. Patch anyway — it closes the CVEs the advisory is really about — but do not expect it to change the device-side gaps below.
4.2. Step 3 · verify segmentation, and block TCP/102
Strong agree — this is the one control that fully works. Mitigation 3 says to verify segmentation, ensure PLCs are not accessible from the Internet and block TCP port 102 at perimeter firewalls entirely.
That is the correct instruction, and this series arrived at it from the opposite direction. The advisory reaches it from incident telemetry — this is what is being attacked. We reached it by working through the controller’s own protections one at a time and finding how little survives contact with a client that is already on the network. The last node of the checklist, arrived at after everything else had been measured, reads: deploy behind a firewall — the only full protection.
The distinction that matters is not whether to do it. It is that a boundary is usually sold as one layer of defense in depth, with device-side controls as the layers behind it. On an S7 CPU that mental model is wrong, because most of the layers behind it are thinner than their names suggest. The boundary is not the outermost of several controls. It is close to the only one that fully works.
That is a stronger claim than the advisory makes, and the rest of this page is why.
The honest limit on the claim, which the checklist spells out: a firewall keeps an attacker off the CPU entirely, but only an attacker who is outside it. Compromise the engineering laptop, the SCADA server or the HMI that is permitted through the boundary and the attacker inherits that access, because the traffic genuinely comes from an approved source. Read "firewall" as stateful filtering plus segmentation plus host hygiene, never as an IP allow-list on its own. |
4.3. Step 4 · review and strengthen access controls
Mixed — the widest gap on the list sits here. Mitigation 4 bundles several controls, and they are not equal.
"Enable PLC password protection" — yes, unreservedly. It is the precondition for the only protection level that gates tag access, and an unauthenticated CPU is indefensible. Know what it is worth, though, in two places it is weaker than it reads: an active man-in-the-middle on the PG/HMI channel relays the login without ever learning the password — we built one — and on firmware in the SHA-1 legacy authentication band, a login that travels outside a TLS envelope puts a replay-ready, password-equivalent credential on the wire for any passive listener. The setting that closes that plaintext door is a whole dimension the advisory omits; it has its own section below.
"Configure protection levels (such as write protection and read/write protection)" — the key oversell. The four global protection levels in TIA read like the main access control on the controller, and the two the advisory names by example — write protection, read/write protection — are precisely the ones that leave runtime data open. Measured rung by rung, those levels gate the engineering and block surface, meaning program and data blocks moved through the engineering tool. They do not gate runtime tag data, which is a separate column in Siemens' own matrix and stays open at every level except the strictest. Set against the threat the advisory describes — an actor "conducting read/write operations on data blocks" — that matters directly: a CPU set to read access is not read-only to a client speaking the HMI protocol. Only Complete protection plus a password gates native-channel tag access at all, and it earns a second benefit while doing so — it forces PUT/GET off, closing the legacy door the advisory’s own tooling depends on. Its ceiling is that it gates access behind a credential rather than eliminating it. If you act on one line of this page, make it that one: the protection level the advisory gestures at is not the protection level that helps here. Read Access Doesn’t Mean Read-Only measures each rung, including the named-user model that replaces the levels on the newest CPUs.
"Restrict TIA Portal access by MAC/IP allowlisting" — right, but it is a network control. The advisory lists this among device access controls, but an S7 CPU cannot refuse a client whose certificate it does not know — the PG/HMI channel never asks for a client certificate, there is no trusted-clients list and no CA to point it at. So MAC/IP allowlisting is enforced by your firewall and switches, not by the controller; it belongs behind the boundary of step 3, not as a device setting. Do it — it is good — but know where it actually lives. (The same CPU does enforce trusted clients on its OPC UA server, which is exactly what makes the omission on the native channel conspicuous.)
And the access posture has a trap built into it, which is the deepest point on this page.
4.4. Step 5 · enable logging and monitoring
Agree in spirit — with one protocol-shaped blind spot. Mitigation 5 is sound: ICS-aware intrusion detection, log every S7comm connection with timestamps and source IPs, baseline legitimate behavior and alert on deviations, watch for off-hours activity. Do all of it.
But two of its specific detections — monitor engineering workstations for snap7 imports and alert on unauthorized PUT/GET operations — only see the legacy protocol. A modern client on S7CommPlus imports no snap7, issues no PUT/GET, and trips neither. The advisory’s detection guidance catches the tooling it names and misses the protocol every HMI already speaks; it is sound against the threat in front of it and blind to the more capable client beside it.
And what that modern protocol hands an unauthenticated client is worth spelling out, because it is the recon the advisory is worried about.
S7CommPlus browses. A client can walk the controller’s address space and enumerate what is there — not as byte offsets, but under the names the engineer gave them. That is a good feature: symbolic addressing is why the modern protocol is pleasant to work with, what lets an HMI be configured against meaningful names and a historian discover a controller’s own tag list. Nobody should want it removed. It does, however, change what an unauthenticated client walks away with.
Over legacy S7Comm, an attacker who has reached a classic block sees that
DB42.DBW10contains0x0BB8. Nothing about that says whether it is a setpoint, a totalizer, a timer preset or the number of crates on a conveyor. Turning it into knowledge means obtaining the program, or a slow campaign of correlating values against plant behavior — the expensive, patient, genuinely expert part of an attack.Over S7CommPlus, the same client asks the controller what it has, and is answered in the plant’s own vocabulary.
Set that against what the advisory says the actors are doing: reconnaissance, "leveraging read access to understand target environments." Understanding the target environment is exactly the step a symbolic browse collapses. It also lands on the advisory’s headline claim, that AI "dramatically reduces the technical expertise and time required." A language model handed a few thousand raw byte offsets can do very little with them; handed a few thousand engineer-authored symbol names, it is being asked to do the one thing such models are unambiguously good at — read a domain vocabulary and explain what it describes. Semantic reconnaissance against an S7 was always possible for a determined expert. A browsable symbol table alongside a language model is what makes it cheap. So an unauthenticated S7CommPlus surface does not merely expose process data; it hands over a self-describing map of the process, and your tag names are on the wrong side of the boundary.
For an operator working through the advisory, this inverts a priority. "We enabled PUT/GET years ago for the historian" is not a statement about one legacy protocol and a handful of classic data blocks. It is a statement about the controller’s entire access posture — data, and the names that explain what the data means. It also makes the audit concrete: establish which of your controllers have PUT/GET enabled and what still needs it. Where the answer is "nothing, it was for a system we retired," turning it off is not merely closing a legacy protocol — on a classic CPU it is the precondition for ever reaching Complete protection, and on a G2 it is what lets you retire the anonymous user. |
4.5. Step 6 · implement S7-specific hardening
Mixed — one control it under-weights, one it oversells. Mitigation 6 groups several device settings.
Disable web servers and unused protocols — agree. Turn off what you do not use; each open service is attack surface. And the standards-based door it tells you to disable is, when you do use it, one of the better-behaved things on the device: both the OPC UA server and the Web API authenticate their clients and enforce a per-account rights model, and OPC UA is the one surface on the CPU that can require an x509 client certificate. Where a third-party integration needs data, steering it there and firewalling it off the native channel is a real improvement rather than a lateral move. Turn the web server off if you do not use it; if you do, pin its certificate.
A control the list omits and should not: per-DB write protection. Mark a data block write-protected in the device and the controller refuses writes to it on the wire, regardless of which channel asked, with no password anywhere in the exchange — enforced by the CPU rather than the tool. Where a plant has data the controller should publish but nobody should modify, that is the setting that delivers it, and it holds against precisely the kind of client this advisory is about. It is not in the advisory’s list. It should be.
"Enable know-how protection" — oversold. It is genuine intellectual-property protection: it stops somebody opening your logic in TIA Portal and reading it. But the attacker here runs Python against a protocol library and never opens TIA — with know-how protection enabled on a data block, that block still browses and its tags still read and write without the password. And the protection it does provide, over the block’s contents, lives in the tool, not the controller: a know-how-protected block opens in TIA with the PLC powered off, so the password is checked entirely in the engineering tool, against a block the controller stores in a transformed, unreadable form and serves without ever seeing the password. That makes it an offline control — an attacker who has pulled the block guesses the password on their own hardware, with nothing in the device to notice, slow or lock out the attempts. Its strength is only the password’s: a strong one buys real time, a weak one is a weekend’s work. Treat it as a deterrent against casual copying, not a barrier a determined attacker cannot get past. Security That Lives in the Tool, Not the PLC is the full account.
"Complete restart protection" — we have not measured it, and make no claim.
5. The dimension the advisory never mentions: TLS and authentication
Across all seven steps, the advisory says nothing about the transport. On modern firmware the native PG/HMI channel can be wrapped in TLS — and whether it is, whether that TLS authenticates anything, and whether the controller’s private key is even secret are decisions the checklist opens with (its first four steps) and the advisory never raises.
Start with the setting that closes the plaintext door: "Only allow secure PG/PC and HMI communication." Left unticked — the default on the firmware that offers it — the CPU serves both the TLS-protected and the plaintext variant of the native protocol and lets the client choose. The encryption is opt-in for the attacker. Ticking it is the single setting that closes the clear-text door; it has real breakage attached — anything that cannot speak TLS-wrapped S7CommPlus stops connecting — so plan it. On an S7-1200 G2 there is nothing to do: it is mandatory and grayed out.
Even ticked, the envelope is only half of what TLS normally gives you. It is encrypted, but the endpoints are not authenticated in the direction that would keep a stranger out — an active man-in-the-middle relays the whole exchange. The one direction of authentication actually available to you is to pin the controller’s certificate fingerprint on the client, which defeats a proxy presenting its own certificate — and that in turn assumes the controller’s key is still secret, which is what the confidential-configuration-data protection guards. None of this is a small omission: it is the difference between a channel a passive listener reads outright and one that at least resists a substitute-certificate proxy. Encrypted, but Not Authenticated is the whole story.
6. Where the checklist is the narrower document
The reverse is worth stating just as plainly. This page has spent most of its length on where the advisory’s device-side steps do less than their labels — but the advisory is the broader document, and the checklist is deliberately the narrower one. Inventory, patching, logging and monitoring, incident reporting, coordinating across security and engineering and plant operations: that is an OT-security program, and the advisory covers it. The checklist is only the device-configuration slice — the settings you touch on the controller — and it is silent on the rest.
So none of this is a reason to deprioritize the advisory’s list. Patch, inventory, allow-list engineering stations, log S7comm connections, disable unused services: all of it is sound, and none of our findings make any of it less worth doing. The argument is about ordering and expectation. If you read the seven mitigation groups as seven layers and assume the device-side ones will hold when the network-side one fails, the bench says otherwise. Do the device-side hardening — but do it as hygiene behind a boundary you are actually relying on, not as the fallback for when that boundary is breached.
A small observation offered as an observation. The advisory’s S7-1200 list — 1211C, 1212C, 1214C, 1215C, 1217C — reads as the classic line, with no G2 variant named. Whether that reflects what was seen in the wild or simply how the list was written, we do not know and are not going to speculate. If you run G2 hardware, do not read its absence as scope. |
7. A note on disclosure
One further article in this series is finished and is not published here. It concerns a control on the S7 platform that was reported to Siemens ProductCERT under coordinated disclosure, and it will go out when their advisory is issued. Nothing in it changes any conclusion on this page.
I mention it rather than leaving a gap because a security series with an unexplained hole in it invites worse guesses than the truth. Coordinated disclosure is the right process and we are following it.
8. Where to go next
Three Doors into the Same Controller — the map. Two unrelated protocols sharing TCP/102, the OPC UA server and the web server beside them, and why a setting that closes one door leaves another wide open. Read this first if you read only one.
Read Access Doesn’t Mean Read-Only — the four global protection levels and the named-user model, measured rung by rung. Where the advisory’s "configure protection levels" lands, and why it lands short.
Encrypted, but Not Authenticated — TLS on the native channel: genuine confidentiality, no endpoint authentication in the direction that would keep a stranger out, and a login an active man-in-the-middle relays without ever learning it.
9. About
ToddySoft Connect is an industrial connectivity library: a set of protocol drivers that let applications read, write, browse and subscribe to data on automation hardware. Everything measured in this series was measured with it — the S7 driver first, and later the S7 Web API driver, which began as a way to verify a single claim in these articles and turned into a second Siemens driver in its own right. The bench behind the numbers is real hardware: S7-1500, S7-1200 and S7-1200 G2 controllers, plus an S7-300 for the cases where the answer is "that generation does not do this at all".
Christofer Dutz has spent more than a decade on industrial protocols and IT/OT integration, much of it in open source. Questions, corrections and war stories are welcome — particularly corrections: several findings in this series were sharpened by people who knew more about a corner of it than he did.
On the writing: this series took shape over about seven weeks and was restructured, split and rewritten far more often than anyone would manage by hand — what began as one article ended up as six. An AI assistant did the heavy lifting on the prose. It decided nothing: every finding, every number and every conclusion here came off the bench first and was checked back against it afterward. Where the text and the hardware disagreed, the hardware won.
