Jherrod ThomasThe Lion of Functional Safety™

September 25, 2026 · 13 min read

IEC 62443-3-2 ZCR 3 / ZCR 5 / ZCR 6IEC 61511-1 §8.2.4 / §11.2.12 / §17IEC 62443-3-3 SR 2.1 / 5.1 / 7.7CISA AA26-231A / SSB-104599

When There Was No Bug to Patch: AA26-231A, the Siemens S7 Write Path, and the Conduit Nobody Specified

Most advisories I write about come with a CVE, a CVSS vector, and a firmware version that makes the problem go away. AA26-231A has none of those. Five agencies told every owner of a Siemens S7 controller - F-series safety CPUs included - that someone is reading and writing their PLC memory with scripts a language model helped write. Siemens answered, correctly, that nothing in its product is newly broken. Both statements are true. That is exactly the problem.

When there is no bug to patch, the finding moves from the vendor's backlog to the asset owner's documentation. And the document it lands on is one most plants never wrote: a specification of who is allowed to write what, over which path, to the controller that stands between a process and a hazard.

1. The public record

On August 19, 2026, the NSA, CISA, FBI, Department of Energy and Environmental Protection Agency released joint Cybersecurity Advisory AA26-231A, "Defending Against an Active Threat to Siemens S7 Series PLCs." (CISA AA26-231A)

The core of the advisory, as summarized by Tenable's Research Special Operations team the next day:

(Tenable, August 20, 2026)

The Cloud Security Alliance's research note two days later put the safety point more bluntly than the advisory did: an actor with read/write access to an F-series controller's logic "could be positioned to interfere with the safety instrumented functions," though no safety-function tampering has been reported. The agencies characterize the activity as reconnaissance and pre-positioning, not a confirmed disruption. (CSA Labs, August 22, 2026)

Siemens' response, on August 20, was that the advisory "does not describe any new vulnerabilities in the S7 series," that it points instead to new methods for exploiting potential misconfigurations, and that the company had not detected an increased level of attacks. (Investing.com, August 20, 2026) Its ProductCERT bulletin SSB-104599 directs customers to current software, protected networks, strong passwords and model-specific hardening documentation.

Then, on September 8, Sabine Frömling wrote the piece in CSO Online that every OT engineer should read before touching a firewall rule. Her point: the advisory's recommendations are all reasonable, and several of them can take down production if implemented without knowing the plant. Blocking port 102 inside a cell can cut an HMI. Disabling "unused" PROFINET can drop remote I/O. PLC-side MAC/IP allowlisting can silently exclude a redundant HMI's failover path. Her test for "unused" is three-way agreement: engineering configuration, representative traffic, and the automation and maintenance owners. And on safety programs specifically, she notes that a routine online/offline comparison is not sufficient to accept changes to an F-program; the formal safety comparison and acceptance process applies. (CSO Online, September 8, 2026)

Read those four sources together and a single engineering fact falls out. The recommended fix is "permit only legitimate communication partners." The prerequisite for that fix is a list of the legitimate communication partners. Most plants do not have that list. They have a network drawing, a TIA Portal project, and a maintenance lead who remembers which laptop the integrator uses.

2. The standards lens

2.1 Why the F-CPU label does not end the conversation

The instinctive reply from a safety engineer is: the safety program on an S7-1500F is protected. And it is - the F-CPU has its own safety password, the safety program lives in a partition that requires authorization and a compile/accept cycle to change, and Siemens' own safety programming guideline is explicit that write access to F-data is only allowed from the safety program; the standard user program must not modify fail-safe tags. (Siemens, Safety Programming Guideline for SIMATIC S7-1200/1500)

That protects the safety logic. It does not protect the safety function's inputs from the non-safety world. In real projects the F-program routinely reads standard data: an operator acknowledge or reset request, a maintenance override request, a mode selection, sometimes a trip setpoint entered on an HMI. The data flow is standard DB to F-program, and the standard DB sits in ordinary memory that an S7comm client with sufficient access can write. T0821 - write operations on data blocks - is precisely that path.

So the relevant hazard is not "attacker rewrites the SIL 2 logic." It is "attacker writes a value the SIL 2 logic was designed to trust." That hazard does not show up in a SIL verification calculation, because PFDavg has no term for a legitimate input carrying an illegitimate value.

2.2 The clauses that should have produced the artifact

IEC 61511-1:2016 §8.2.4 requires a security risk assessment of the SIS and its associated elements, covering the attack vectors through which the SIS could be made to fail. The operative words are "associated elements" - the HMI, the engineering station, and the standard-program data the F-program consumes are all in scope. §11.2.12 then requires the SIS design to provide resilience against the risks identified. If §8.2.4 never enumerated the standard-to-safety data path, §11.2.12 has nothing to design against.

IEC 61511-1 §17 (modification) and §16 (operation and maintenance, including bypass and override management) matter because every override bit in a standard DB is, functionally, a bypass. §16 expects bypasses to be authorized, time-limited and logged. A PUT/GET write from an unknown host is none of those.

IEC 62443-3-2 is where the missing artifact actually lives:

IEC 62443-3-3 supplies the system requirements the CRS should call up: SR 2.1 authorization enforcement (not everyone who can connect may write), SR 3.1 communication integrity, SR 5.1 network segmentation, SR 5.2 zone boundary protection, and SR 7.7 least functionality - which is where "disable PUT/GET, the web server and unused protocols" belongs, with the evidence that they are in fact unused.

IEC 61508-1 §7.4.2.3 closes the loop from the other side: if the hazard analysis identifies that malevolent action is reasonably foreseeable, a security threat analysis shall be carried out. After AA26-231A, "foreseeable" is not a debate.

The through-line: every one of these clauses assumes the existence of an authoritative list of permitted writers per controller. None of them is satisfiable without it, and none of the AA26-231A mitigations can be implemented safely without it either. That is Frömling's "prove unused" argument restated as a work product.

3. A worked snippet

3.1 Fault tree - SIF fails to act on demand via a network write

Take a representative case: a SIL 2 high-pressure trip on a reactor feed, implemented on an S7-1500F. The F-program trips on transmitter PT-101 exceeding a fixed limit, but it also honors a maintenance override request bit (DB_Maint.OVR_PT101) set from the HMI during transmitter calibration, and it takes its trip setpoint from an HMI-entered value clamped to a range.

TOP: SIF-07 (reactor feed HP trip) fails to act on demand
 └─ OR
    ├─ G1  Random HW failure of sensor / logic / final element   [PFDavg, covered]
    ├─ G2  Systematic fault in F-program                         [F-program acceptance, covered]
    └─ G3  F-program acts correctly on a malicious input          [NOT COVERED]
         └─ OR
            ├─ G3.1  Override bit written TRUE outside a work permit
            │     └─ AND
            │        ├─ E1  S7comm reachable from non-engineering host (port 102 open across zone)
            │        ├─ E2  PUT/GET enabled or CPU protection level permits write
            │        └─ E3  F-program has no independent confirmation of override (key switch, timer)
            └─ G3.2  Setpoint written to top of permitted range
                  └─ AND
                     ├─ E1  (as above)
                     ├─ E2  (as above)
                     └─ E4  Permitted setpoint range exceeds process safety margin

G1 and G2 have numbers and certificates. G3 has an assumption. Every basic event under G3 is a configuration fact, not a component failure - which is why no vendor patch closes it and why the evidence for it has to come from the asset owner.

3.2 Zone-and-conduit risk row (IEC 62443-3-2 ZCR 5)

| Field | Value | |---|---| | Conduit ID | C-SIS-03 (Control LAN to SIS zone, S7comm) | | Asset | F-CPU running SIF-07, standard DB DB_Maint, DB_HMI_SP | | Threat scenario | Masqueraded snap7 client on a compromised control-LAN host issues PUT to DB_Maint.OVR_PT101 (T0849 + T0821) | | Consequence | SIF-07 inhibited; overpressure demand unmitigated; consequence category matches the SIF's original hazard (LOPA scenario HAZ-12) | | Likelihood (unmitigated) | High - public tooling, active scanning, no zero-day required per AA26-231A | | SL-T | SL 3 (sophisticated means, IACS-specific skills - now cheaper per the advisory's AI finding) | | SL-C (as found) | SL 1 - PUT/GET enabled for legacy historian; no conduit allowlist; override bit unconfirmed | | Gap | SR 2.1, SR 5.2, SR 7.7 unmet; IEC 61511 §16 bypass control unmet for network-originated overrides | | Treatment | Conduit allowlist; PUT/GET disabled or restricted to named partner; hardwired key switch AND-ed with override bit in F-program; override auto-expiry |

3.3 Conduit specification excerpt - the artifact that was missing

This is the document the advisory's mitigations silently depend on. One row per legitimate writer, per controller.

| Controller | Partner (host / role) | Protocol / port | Direction | Data objects | Mode / window | Evidence | |---|---|---|---|---|---|---| | F-CPU SIF-07 | EWS-02 (TIA Portal, engineering) | S7comm+ / 102 | R/W program | Full project | Change window only, per MOC | Project config + MOC log | | F-CPU SIF-07 | HMI-A / HMI-B (redundant pair) | S7comm+ / 102 | R/W | DB_HMI_SP, DB_Maint | Continuous | Config + 30-day capture incl. failover test | | F-CPU SIF-07 | HIST-01 (historian) | S7comm (PUT/GET) / 102 | Read only | DB_Status | Continuous | Config + capture | | F-CPU SIF-07 | Any other host | - | Deny, alert | - | - | Firewall rule + monitoring rule |

Note the redundant HMI row explicitly carries a failover test in its evidence column. That is Frömling's point about allowlists excluding a secondary path, turned into a verification requirement.

4. Derived requirements (excerpt)

SEC-SIS-011 (conduit allowlist). Every S7 controller hosting a SIF shall have a conduit specification listing each permitted communication partner, protocol, direction and data object. Traffic to TCP 102 on the SIS zone from any host not in the specification shall be denied at the zone boundary and shall raise an alarm to the monitoring system within 60 s. Trace: IEC 62443-3-2 ZCR 3 / ZCR 6; IEC 62443-3-3 SR 5.1, SR 5.2. Verification: Attempted S7comm connection from a non-listed host on each adjacent zone; confirm deny and alarm timestamp.

SEC-SIS-014 (write authority on safety-consumed standard data). Any standard-program data object read by an F-program shall be writable only by partners named in the conduit specification. PUT/GET access shall be disabled on F-CPUs unless a named partner requires it, in which case that partner shall be restricted to read-only objects. Trace: IEC 62443-3-3 SR 2.1, SR 7.7; IEC 61511-1 §11.2.12. Verification: Configuration audit of CPU protection level and PUT/GET setting; write attempt to DB_Maint from the historian host must fail.

SAF-SIF07-022 (override confirmation independent of the network). The F-program shall honor a maintenance override of SIF-07 only when the network override request AND a hardwired key-switch input (read via F-DI) are both TRUE. The override shall expire automatically after 4 h and shall be annunciated at the operator console for its full duration. Trace: IEC 61511-1 §11.2.12, §16 (bypass management); LOPA HAZ-12. Verification: F-program test with network bit TRUE and key switch FALSE - SIF must remain armed; expiry timer test.

SAF-SIF07-023 (setpoint bound tied to safety margin). Any HMI-supplied trip setpoint shall be clamped inside the F-program to a range whose upper bound is at or below the value used in the SIF's process safety time calculation; out-of-range values shall be rejected and the last valid value retained. Trace: IEC 61511-1 §10.3 (SRS content), §11.2.12. Verification: Inject setpoint above bound via engineering test harness; confirm rejection and diagnostic event.

SEC-SIS-019 (baseline and comparison). A signed reference copy of each F-CPU project, including hardware configuration and standard DBs consumed by the F-program, shall be held outside the control network. The online project shall be compared against it at least monthly and after every MOC; any F-program difference shall be treated as an unaccepted change under IEC 61511-1 §17 until resolved through the safety acceptance process. Trace: IEC 61511-1 §17; IEC 62443-3-3 SR 3.4 (software and information integrity). Verification: Comparison report archived per period; deliberate non-safety change in a test system is detected.

5. What the headline really tells us

The headline says AI is writing ICS exploits now. That is a real shift in attacker economics, and I would not wave it away. But the AI finding changes the likelihood column, not the design. The actors in AA26-231A did not need a zero-day. They needed port 102 to answer and the controller to accept a write. Both of those are configuration facts owned by the plant.

The engineering event is quieter. The agencies' mitigation list and Siemens' hardening guide both reduce to one instruction: permit only legitimate partners. And across most of the installed base, the only authoritative record of who the legitimate partners are is the running traffic itself - the same traffic the attacker is designed to blend into. You cannot allowlist from a memory. You cannot prove "unused" without a baseline. You cannot run the IEC 61511 §8.2.4 assessment on an S7-1500F without knowing which standard data blocks its safety program trusts.

Siemens is right that nothing in its product is newly broken. The finding is not in the product. It is the conduit specification that IEC 62443-3-2 has asked for since 2020 and that most sites never produced - and, for anyone running an F-CPU, the §8.2.4 assessment that stopped at "the safety program is password-protected" without asking what the safety program reads.

No patch is coming for that. It is a document, and the plant has to write it.

6. Sources

— Jherrod Thomas, The Lion of Functional Safety™