Jherrod ThomasThe Lion of Functional Safety™

September 15, 2026 · 14 min read

IEC 61511-1 §8.2.4 / §11.2.10IEC 62443-4-2 CR 1.1 / 1.2 / 1.5CVE-2026-3869 / CWE-303 / SEVD-2026-251-04

When the Authentication Depended on the Project File: CVE-2026-3869 in the Modicon M580 Safety Through an IEC 61511 and IEC 62443 Lens

Schneider Electric's September 2026 Patch Tuesday bundle contains one item that should stop a process safety engineer mid-coffee. CVE-2026-3869 is an authentication flaw in the Modicon M580 and — this is the part that matters — the Modicon M580 Safety, a controller TÜV Rheinland certified for SIL3 safety instrumented functions. CVSS v4.0 9.2. Network vector. No privileges required. And it only bites under a condition that reads like a configuration note rather than a vulnerability.

Most ICS advisories are a parser bug, a hardcoded key, or a web interface that forgot to check a session cookie. This one is different, and the difference is architectural: the enforcement state of the authentication control is a property of the application project loaded onto the controller, not a property of the controller. That is a safety-relevant statement, and nothing in the plant's proof test regime will ever surface it.

1. The public record

On September 9, 2026, Schneider Electric published four new security advisories and updated four others as part of the month's coordinated ICS release. The most severe of the new items is CVE-2026-3869, covered by advisory SEVD-2026-251-04. (SecurityWeek / ICS Cyber Security Conference, September 9, 2026)

The CVE record was published to the CVE Program on September 11, 2026, assigned by Schneider Electric, with a reservation date of March 10, 2026 — a six-month coordination window. The description is one sentence, and every clause in it is load-bearing:

"CWE-303: Incorrect Implementation of Authentication Algorithm vulnerability exists that could cause loss of confidentiality, integrity and availability of the PLC provided an application project with a lower application level is running on the PLC."

The scoring:

| Field | Value | |---|---| | CVSS v4.0 base | 9.2 (Critical) | | Vector | CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N | | Weakness | CWE-303, Incorrect Implementation of Authentication Algorithm | | EPSS (at publication) | 0.5% | | Affected | Modicon M580, application level below 4.00 | | Affected | Modicon M580 Safety, application level below 4.20 |

(CVE Program record via OffSeq Threat Radar, September 11, 2026; NVD entry for CVE-2026-3869)

Two things in that vector deserve a second look. PR:N means an attacker needs no credentials at all. AT:P — "Attack Requirements: Present" — is CVSS v4.0's way of encoding the precondition in the description: the controller has to be running a project at a lower application level. That is not a rare corner case. In a process plant, the application project is the thing you change least. It was validated against the safety requirements specification, it carries the SIL verification calculations, and re-validating it costs a shutdown. Firmware might get bumped during a turnaround; the project stays.

The practical consequence was stated plainly by a vendor-side commentator the same week: "Nobody with a live process is patching a safety controller this week — vendor validation and change control put that window months out." (BlastWave, September 9, 2026)

And one date coincidence worth naming, because it is not a coincidence for long: the CVE record went public on September 11, 2026 — the same day the EU Cyber Resilience Act's Article 14 reporting obligations became mandatory and ENISA's Single Reporting Platform went live. From that date, manufacturers must file an early warning within 24 hours of becoming aware of an actively exploited vulnerability, a technical notification within 72 hours, and a final report within 14 days. (European Commission — CRA reporting; Crowell & Moring, September 11, 2026)

2. The standards lens

2.1 What the M580 Safety is certified to do

The Modicon M580 Safety platform is certified by TÜV Rheinland for use in safety functions up to SIL3 per IEC 61508 and IEC 61511, SILCL3 per IEC 62061, and Category 4 / PL e per ISO 13849-1. In a process plant it is the logic solver of a Safety Instrumented System — the thing that closes the trip valve when the pressure transmitters agree that the vessel is going somewhere bad. (Schneider Electric — Modicon M580 Safety Manual, QGH46982)

A SIL3 claim is a claim about a probability of failure on demand — for a low-demand SIF, PFDavg between 1×10⁻⁴ and 1×10⁻³. That number is computed from random hardware failure rates, diagnostic coverage, proof test interval and proof test coverage. It contains no term whatsoever for "an unauthenticated party on the network rewrote the logic."

That is not an oversight in IEC 61508. It is the boundary of what a PFD calculation can express. Which is precisely why IEC 61511 added a separate clause.

2.2 The clause that should have caught this — on the asset owner's side

IEC 61511-1 §8.2.4 requires a security risk assessment of the SIS, covering the devices, the connected systems, the engineering tooling and the human interfaces. §11.2.10 then requires the SIS design to provide the resilience identified by that assessment.

Most plants run §8.2.4 once, at design, and the output is an architectural statement: the SIS sits in a separate zone, the conduit to the BPCS is one-way, engineering access requires a physical keyswitch. Those are all true statements about the network. None of them is a statement about whether the controller's own authentication is currently being enforced.

Here is the gap, stated as plainly as I can. The security risk assessment asked "who can reach the logic solver?" It did not ask "under what loaded configurations does the logic solver stop checking who is asking?" The second question is the one CVE-2026-3869 answers.

2.3 The clause that should have caught this — on the product supplier's side

IEC 62443-4-2 is the component requirements standard, and the relevant requirements are unglamorous:

CR 7.6 is the one I would put a finding against. A component that can silently operate in a mode where CR 1.2 is not enforced, and that does not report that it is in that mode, has satisfied the letter of the authentication requirement in its certified configuration and nothing at all in its degraded one.

On the development-process side, IEC 62443-4-1 SD-4 (secure design best practices) and SVV-3 (vulnerability testing) both cover this. Backward-compatibility paths are a classic SVV-3 blind spot: the test matrix runs the current project against the current firmware, because that is what the release is. The dangerous cell in that matrix is old project on new firmware, and it is the cell every real plant lives in.

And since September 11, 2026, CRA Annex I, Part I is no longer aspirational for products placed on the EU market: it requires products with digital elements to be delivered with a secure-by-default configuration and to protect the integrity of stored and transmitted data. A compatibility mode that weakens authentication without announcing itself is hard to square with "secure by default."

2.4 The artifact that does not exist

IEC 61511-1 §16 governs proof testing. A proof test on a SIF exercises the full loop: transmitter, logic solver, final element. It verifies that the trip happens, at the right setpoint, in the right time. It is documented, scheduled, and the interval feeds directly into the PFDavg.

There is no line item in any proof test procedure I have ever reviewed that reads: verify that the logic solver is enforcing authentication on the engineering conduit. The security control has no proof test, no proof test interval, and no coverage figure. It is assumed to be in the state it was in at commissioning, permanently, with no diagnostic to say otherwise.

That is the missing artifact. Everything else in this post follows from it.

3. A worked snippet

3.1 The fault tree the SIS security risk assessment should have drawn

TOP: Unauthorized modification of SIF logic
     in Modicon M580 Safety logic solver
                 |
                AND
                 |
    +------------+------------+
    |                         |
 [G1] Attacker can           [G2] Controller does not
 reach engineering                reject the unauthenticated
 conduit (Modbus/TCP,             engineering request
 EtherNet/IP, FTP, HTTP)
    |                             |
   OR                            OR
    |                             |
+---+----+----------+       +-----+--------------------+
|        |          |       |                          |
B1       B2         B3     [G2.1] Auth algorithm     B6 Keyswitch
Flat     Vendor     Eng.    incorrectly implemented     left in
IT/OT    remote     WS on   (CWE-303)                   PROGRAM
subnet   access     both        |
                   networks    AND
                                |
                    +-----------+-----------+
                    |                       |
                   B4                      B5
              Firmware exposes        Loaded application
              legacy auth path        project is at
              for compatibility       application level
                                      below 4.20

Read the bottom of that tree carefully. B5 is not a fault. It is a perfectly legitimate, change-controlled, SIL-verified engineering decision: keep the validated project. It becomes a basic event only because B4 exists, and B4 was invisible to the plant until September 9.

3.2 SIS security risk assessment row (IEC 61511-1 §8.2.4 format)

| Ref | Asset | Threat / vector | Existing countermeasure | Residual likelihood | Consequence if realized | Adequate per §11.2.10? | |---|---|---|---|---|---|---| | SRA-07 | M580 Safety logic solver, SIF-201 high-pressure trip | Unauthenticated write to application logic over engineering conduit (AV:N, PR:N) | Zone separation; keyswitch; vendor-supplied device authentication assumed always-on | Was rated Low on the assumption the device authenticates. Re-rate Medium/High: authentication is conditional on loaded project application level. | Defeat or silent alteration of SIL3 SIF. Loss of the entire protection layer, not a degraded one. | No. No detection, no proof test, no configuration attestation. | | SRA-07a | Same | Same, during vendor remote-access session for firmware remediation | Session recording (if present) | Elevated during remediation window | Same | No. Remediation window is the highest-exposure period and is not separately assessed. |

The honest entry in the right-hand column is the one most plants will not want to write: the countermeasure was a vendor assumption, and the assumption was never restated as a verifiable requirement with an owner.

3.3 The one number that changes

If SIF-201 claims SIL3 with PFDavg ≈ 3×10⁻⁴, that figure is the probability the loop fails to act on a random demand. Systematic defeat of the logic solver is not in the model, and there is no honest way to add it as a probability. IEC 61508-2 handles systematic capability qualitatively, through SC 3 — and SC 3 rests on the safety manual's assumptions of use being true in the installed configuration. When the safety manual's implicit assumption is "the controller authenticates engineering requests," and the installed configuration quietly falsifies that assumption, the SC 3 argument has a hole in it that no recalculation will close.

4. Derived requirements (excerpt)

These are written as I would write them into a plant's SIS security requirements specification, after the September 9 advisory forced a re-run of §8.2.4.

SIS-SEC-014 — Security configuration attestation. The safety logic solver shall expose, on an interface readable without modifying controller state, a machine-readable attestation of its currently enforced authentication mode, including the application level of the loaded project. The attestation shall be readable within 5 s and shall be collected by the historian at an interval not exceeding 24 h. Rationale: IEC 62443-4-2 CR 7.6. Closes G2.1 by making the degraded mode observable. Verification: Inspection of vendor interface specification plus functional test on a bench controller deliberately loaded with a project below application level 4.20.

SIS-SEC-015 — Alarm on degraded authentication mode. Entry of the safety logic solver into any authentication mode weaker than the mode assumed by the SIS security risk assessment shall raise an operator alarm classified as process safety critical within 60 s of entry, and shall be recorded in the sequence-of-events log with a timestamp accurate to ±1 s. Rationale: IEC 61511-1 §11.2.10 resilience; IEC 61511-1 §16 cannot detect this on a proof-test interval measured in years. Verification: Test on bench controller; witness alarm and SOE entry.

SIS-SEC-016 — Proof test scope extension. The proof test procedure for every SIF implemented in a Modicon M580 Safety logic solver shall include verification that (a) the loaded project application level is at or above 4.20, and (b) an unauthenticated write attempt from the engineering conduit is rejected and logged. Rationale: Makes the security control a tested element of the SIF rather than an assumption. Interval inherits the existing proof test interval for the SIF. Verification: Procedure review and first-execution witness.

SIS-SEC-017 — Compatibility-mode change control. Any engineering change that results in an application project of lower application level being loaded onto a safety logic solver shall be treated as a modification to the SIS under IEC 61511-1 §17 and shall require re-execution of the affected §8.2.4 security risk assessment rows prior to download. Rationale: B5 in the fault tree is a change-control decision, not a fault. Put it under change control. Verification: MOC procedure audit.

SIS-SEC-018 — Remediation-window compensating control. For the interval between advisory publication and firmware remediation under the scheduled turnaround, the affected safety zone shall be placed behind an access control that grants per-system, per-identity, time-boxed authorization, with all third-party sessions recorded. Subnet-level authorization to the safety zone shall be withdrawn within 72 h of advisory publication. Rationale: The vulnerability cannot be removed on the plant's timescale; reachability can be. Addresses G1 while G2 remains open. Verification: Re-scan of the safety zone from an untrusted vantage point; confirm no response to unauthenticated probes.

5. What the headline really tells us

The headline says a critical vulnerability was patched. That framing puts the story on a firmware version number, and firmware version numbers get argued about in change-control meetings until the next turnaround.

The engineering event is smaller and worse. On a controller certified to stand between a process and a hazardous event, the enforcement state of an authentication control turned out to be a property of the file the plant deliberately refuses to change, and there was no artifact anywhere in the SIS lifecycle that would tell the asset owner which state the controller was actually in. Not the safety requirements specification, which assumed authentication existed. Not the PFDavg calculation, which has no term for it. Not the proof test, which does not look. Not the §8.2.4 security risk assessment, which asked about reachability and stopped.

CWE-303 is the vendor's finding, and Schneider will close it with firmware. The asset owner's finding is different and is not closed by anything Schneider ships: the SIS had a protection layer whose health was unobservable. Every other element of that loop — transmitter, solver, valve — has a diagnostic, a proof test, and a number. The security control had an assumption.

Assumptions are fine. IEC 61508 is built on them. But an assumption that nobody wrote down, nobody assigned an owner, and nobody scheduled a test for is not an assumption. It is a gap with better manners.

6. Sources

— Jherrod Thomas, The Lion of Functional Safety™