Firmware 4.21 Alone Won't Close the M580 Safety Bypass

On 8 September 2026 Schneider Electric published security notification SEVD-2026-251-04 for CVE-2026-3869, an authentication flaw in its Modicon M580 controllers and in the Modicon M580 Safety, the variant of the same rack that's certified to run safety instrumented functions up to SIL3. The company scores it 9.8 under CVSS v3.1 and 9.2 under v4.0. It files the flaw as CWE-303 (an incorrect implementation of an authentication algorithm) and describes the outcome as an unauthenticated connection to the controller, with loss of confidentiality, integrity and availability. Every M580 running an application project below application level 4.00 is affected. So is every M580 Safety below application level 4.20.

The sentence that decides how your next few months go sits in the remediation table. For the standard M580 the fix is firmware 4.10 or later and an application project raised to application level 4.00 or later, which takes EcoStruxure Control Expert V15.2 or newer. For the M580 Safety it's firmware 4.21 or later and application level 4.20 or later, which takes Control Expert V16.0 with hotfix HF001 or newer. The two are joined by an "and". Flashing the CPU satisfies one of them.

That second condition is what separates this notification from the PLC advisories a plant engineer skims on a Tuesday and forwards to the integrator. A safety PAC is the layer that's supposed to hold after the basic process control has already failed: the burner management on a waste-to-energy boiler, the high-pressure and high-level trips on the ammonia plant behind a dairy, the interlocks around a reheat furnace. An unauthenticated engineering session into that layer is a different class of exposure from the same flaw on a conveyor PLC. And the remedy asks you to rebuild the one application on site that a functional safety assessor has signed, with a compiler version the assessor never saw, on a controller you're only allowed to touch when the process is down. That's why this one will stay open on a lot of sites long after the process PLCs are patched, and why the interim controls carry more of the load than usual.

One port commissions the safety logic and can also stop it

Control Expert talks to an M580 over UMAS, Schneider's engineering protocol, carried inside Modbus TCP on port 502 alongside the SCADA polling. Everything an engineer does from the laptop travels that way: uploading and downloading the project, starting and stopping the PAC, reading and writing variables, forcing I/O, online changes. On the Safety CPU the same link carries one more thing, because Control Expert Safety is the only tool that can move the controller between its two operating modes. Safety mode is the default, the state the PAC boots into with a valid application. Maintenance mode is the temporary state you enter to debug and modify the safe part of the application, and the manual is blunt about it: while the PAC sits in maintenance mode, the SIL level isn't guaranteed.

A safety rack is on a network because it has to be. The backplane is Ethernet, the SCADA reads its diagnostics, the historian trends its I/O, and the engineering VLAN reaches it because Control Expert has to reach it. So access was settled at the design stage. What does a session the controller believes is Control Expert get to do once it's there? The notification doesn't enumerate commands. It says the connection is unauthenticated and rates all three impacts high, which for a controller means someone can read it, change it, or stop it. The operating-mode rules fill in the rest.

Seen from an intruder's chair, the table has two soft spots. Safety mode protects the safe variables from a live session, but it doesn't protect the PAC from a STOP, and it doesn't prevent a complete application from being loaded. A STOP on a safety PAC leaves the outputs in their fallback state, which on a boiler is a burner trip and on a refrigeration plant is the compressors tripped. That's the availability column of the CVSS vector, expressed in hours of restart. The confidentiality column is the project itself: the trip setpoints, the voting arrangement, the bypass logic, the tag names that tell a stranger which valve is the fuel valve and how far the process can be pushed before the trips act. Integrity is the one people picture first, a changed interlock, and it's the one the mode switch genuinely makes harder, as long as the switch itself can't be thrown from the network.

Which is where the one piece of hardware in this story comes in. The Safety CPU has a configurable maintenance input: in the CPU configuration you nominate an input bit on a non-interfering digital input module in the local rack, and while that bit reads 0 the PAC is locked in safety mode. Only with the bit at 1 can a transition to maintenance mode happen at all. Wire it to a keyswitch on the cabinet door and the writable path to the safe logic needs a person at the cabinet holding a key, whatever the network has been persuaded to believe. If the input was left unconfigured at commissioning, because that was simpler and the mode switch could be put behind a password anyway, this notification is the reason to go back and configure it.

"Application level" is the phrase doing the damage

A Control Expert project is built for a declared controller version. When you configure the CPU you pick which M580 the application targets, and that choice is the application level. The firmware on the CPU can be newer than the level of the application it runs, and that's by design, because the alternative would turn every firmware update into a project rebuild. A controller on current firmware carries an application built years ago at an older level without complaint, which is exactly the situation a long-serving rack is likely to be in.

The whole reach of this vulnerability rides on that convenience. Schneider's own description conditions the flaw on "an application project with a lower application level" running on the PLC, and the CVSS v4.0 vector records the same fact as AT:P, attack requirements present: the precondition is the old-level project. The CPU does with an old-level application what it always did with old-level applications, and that includes the authentication behaviour this CVE is about. Firmware 4.21 on a Safety CPU running a project built at an older level changes nothing about the finding.

So the inventory question changes shape. Firmware lives on the CPU, and any asset register worth keeping records it; EADM and Control Expert both show it in connected mode. Application level lives in the project file, in the CPU configuration. Does your asset register have a column for it? A site that flashed its Safety CPUs at last year's turnaround, kept the validated project untouched, and filed the work as done has done exactly what good SIS practice told it to do. It's also still on the affected list. The same goes for the standard M580s: a rack on fixed firmware with a project last built for a 3.x controller is affected until someone opens that project in a current Control Expert, raises the level, rebuilds, and downloads.

Why the safety half waits for the turnaround

Start with what a rebuild does to the safety record. An M580 Safety computes a safe application identifier, the SAId, at runtime from the binary of the safe part of the application; you can read it in system word %SW169 or from the S_SYST_STAT_MX function block, and Schneider's support note on the identifier spells out the rules. A modification to the safe part changes the value. A build change confined to the non-safe part doesn't. And a full rebuild after a partial build may change it even with the source untouched, because the identifier follows the executable, and the same source can compile to different binaries depending on how it was built. Rebuilding a project at a new application level, in a newer Control Expert, is a build change of the largest kind. Expect a new SAId.

That matters because the SAId is the number the validation record hangs on. It's the runtime evidence that the PAC is executing the safe application that was tested, and the manual recommends checking it regularly for exactly that reason. The security patch, by construction, produces a safe application whose identifier no longer matches the one your own records say was validated. Under IEC 61511 that's a modification to the SIS, and a modification means impact analysis, re-verification, and a functional test of the safety functions before anyone trusts the trips again. The safe logic source may be byte-for-byte identical, and the source-based safe code signature will tell you so. But the compiled artefact is new, and functional safety is assessed on what runs.

Then there's the window. Loading a new application means stopping the PAC, and the manual's warning about maintenance mode is a warning about the process rather than the controller: while you're in there, the SIL claim is off, so the process has to be in a safe state or covered by other measures. For a waste-to-energy line that means the boiler outage, for a caster or a reheat furnace the planned stop, and for a dairy the seasonal low, if the site has one. The work takes a day. The date comes from an outage calendar that runs in years.

The tool chain adds its own friction. Application level 4.20 for the Safety CPU means the hotfixed Control Expert V16.0 or later on the engineering station, and the safety engineering station is often the most deliberately frozen computer in the plant: a validated version, sometimes a validated laptop, opened for the SIS and nothing else. Upgrading it is a change with its own paperwork, and if that same station also builds the standard M580 and M340 projects, every one of them gets a new compiler at once. The firmware side has a matching check. The Safety CPU's certification applies to specific firmware versions, and the list of certified versions is TÜV's, so the version you flash to has to be on it, which is a different page from the download page. Redundant Hot Standby safety pairs add their own sequencing on top. All of it is the ordinary weight of touching a certified system, which is why "we'll do it at the turnaround" is the correct answer and also the reason the flaw stays live for months.

Meanwhile the notification offers no workaround specific to this CVE. What it gives is the standard best-practice list that closes every Schneider notification: segment control and safety networks away from the business network, lock the cabinets, keep the programming station off every network but the one it serves, sanitize removable media, tunnel remote access. The absence is information in itself. There's no setting that switches this flaw off on an old-level application, so the time between now and the outage belongs to architecture and monitoring.

Between now and the outage

1. Inventory by application level, Safety racks first. For every M580 and M580 Safety, record four things: the firmware (from EADM or from Control Expert in connected mode), the application level (open the project offline and read the CPU version in the configuration), the Control Expert version that last built it, and the next outage on the calendar. The second column is the one your register doesn't have, and it's the only one this notification cares about.

1. Shrink who can open an engineering session. You can't simply block port 502 at the safety rack, because the HMI and historian polling share it. Restrict by source instead: enable the CPU's access control list and enumerate the addresses allowed to connect, then mirror the rule at the cell firewall so only the engineering station's address reaches the rack. On standard M580s at recent firmware the engineering link can also be moved to HTTPS with the plain Modbus engineering driver refused. An allow-list doesn't authenticate anyone; a foothold on the engineering laptop, or a spoofed address on a flat cell network, walks straight through. What it buys for the interim is a smaller set of places an attack can start from.

1. Configure the maintenance input and put a key on it. One spare channel on a local-rack digital input module, a keyswitch, an afternoon. With the bit at 0 the PAC can't leave safety mode, so the writable path to safe variables and safe I/O needs a physical key, no matter what the session claims to be. It doesn't stop a STOP or a full download; nothing short of the fix does. It removes the most surgical form of tampering, the changed interlock that leaves the screen green.

1. Trend three registers and alarm on them. The CPU already logs entries to and exits from safety mode to its own syslog server, along with the connections, logins and communication-parameter changes that precede them; point that at a collector someone reads. Then put the two system words that report the operating mode, %SW12 and %SW13, and the SAId in %SW169 into the historian or onto the edge gateway that already polls the rack for process trends. A mode word that isn't the safety-mode value, an identifier that changes outside a permit, a STOP with no work order behind it: each is an alarm for the shift supervisor rather than a line in a security inbox. This is the cheapest detection a plant can build, because it uses registers the controller already exposes for exactly this purpose.

1. Set the passwords you were going to set anyway. Plenty of long-serving safety projects carry no application password at all, and the safe-area protection that locks the safe part of the program is a separate setting again, reached from the project's properties. They're no substitute for the fix, and they still stop the ordinary mistakes: the integrator's laptop with the wrong project open, the download meant for the rack next door.

At the outage

Do the standard M580s first. They need a stop, but they don't need a SIS window, and the process side of the plant is where most of the racks are. For the Safety racks, stage everything on a test rack before the outage: a spare Safety CPU on the fixed firmware, the hotfixed Control Expert on a station you've upgraded under change control, a copy of the project raised to application level 4.20 and rebuilt with Rebuild All, downloaded, and its new SAId recorded. Run whatever safety function tests the test rack can support against simulated I/O. Write the modification up as what it is: compiler, level and firmware changed, safe logic source unchanged (attach the safe code signature comparison), functional test to follow on the live rack. At the outage the download itself is the short part. The functional test of every safety instrumented function, and the sign-off that writes the new SAId into the validation record as the reference, is the day. If the CPUs are still on a 3.x firmware, read the update guide before that day, because the move to the 4.x line has its own staged procedure.

All of this assumes a plant where the safety rack is on the network the way most are, reachable from the engineering VLAN around the clock. If yours keeps the engineering port unplugged between jobs and already has a key on the maintenance input, the notification is an outage-list item and most of the list above is done. The assumption breaks in the other direction too. The M580 Safety runs process tasks beside its SAFE task, and the platform is built for exactly that, one rack carrying both the basic control and the safety functions. On that architecture the maintenance input guards the safe half only. The process half is as exposed as any standard M580 with an old-level application, the calm of the turnaround schedule doesn't apply to it, and that project needs its rebuild on the first stop you can take, whether or not a functional safety assessor is anywhere near it.

Notes

The operating-mode and identifier behaviour described here is the Modicon M580 Safety's, as its safety manual documents it; other safety PLC families lock and version their applications differently, and the application-level mechanism belongs to Control Expert projects specifically. Notification SEVD-2026-251-04 was at version 1.0.0 on 8 September, and Schneider revises these documents, so check the current revision before scheduling the work. Where the safety function is a hardwired relay logic solver with no PLC in the loop, only the process-side steps apply.