On April 14, 2026, Schneider Electric published SEVD-2026-104-02, confirming that BlastRADIUS (CVE-2024-3596), a vulnerability published in July 2024 and later assessed as Critical (CVSS 9.0), affects all versions of Connexium Managed Switches (TCSESM), Modicon Managed Switches (MCSESM, MCSESP), and Modicon Redundancy Switches (MCSESR). The advisory will get filed under “patch this firmware,” and for a lot of teams that will be the beginning and end of it. That framing misses the actual problem.
Schneider’s 2026 advisory does not mark the moment BlastRADIUS became severe; it marks the point at which Schneider confirmed these specific switch families are affected—nearly two years after the vulnerability was public.
In the majority of environments where these switches are running, the exposure persists not because of an exotic attack or a complex architectural failure, but because RADIUS was configured once, the wrong authentication methods were left enabled, and the configuration has remained unexamined ever since.
Applying the firmware update is the simple part. Explaining how a known 9.0 went unaddressed in operational environments for that long is less comfortable.
How BlastRADIUS Works
The answer lies in the age and design of the protocol itself. RADIUS handles authentication for network access by brokering communication between your managed switch and a central server. Because the protocol has been around since the mid-1990s, it still relies on MD5 for message integrity in the response path.
BlastRADIUS exploits that. An attacker already positioned on the network path between the switch and the RADIUS server, able to read, intercept, block, and modify traffic, can use an MD5 chosen-prefix collision attack to forge a valid Access-Accept response, telling the switch that authentication succeeded when it did not. Any MFA that relies on the RADIUS exchange for final authorization can be bypassed. The research team behind the BlastRADIUS disclosure demonstrated the attack can be executed in under five minutes with modern hardware.
The attack works against PAP, CHAP, and MS-CHAP. EAP is not practically affected by the demonstrated attack. Those non-EAP methods are still commonly configured across legacy OT networks, not because engineers chose them knowingly, but because they were set up years ago and the configuration was never revisited.
The Fix Was Already Available
This is the part that the advisory does not say loudly enough. BlastRADIUS exposure can be significantly reduced with correct configuration. At a protocol level, enforcing the RADIUS Message-Authenticator attribute prevents forged responses and is the primary mitigation recommended by both the research team and vendors. For organizations planning longer-term remediation, migration toward RADIUS over TLS removes the underlying protocol weakness entirely. Restrict RADIUS traffic to a trusted management VLAN to significantly reduce interception risk. Disabling PAP, CHAP, and MS-CHAP removes the primary attack path. Several of the most important mitigation steps are configuration decisions rather than firmware changes and should already have been in place in most environments.
The broader pattern here is one the OT industry has been slow to address. Configuration weaknesses and exposures are the most consistently overlooked area of risk management in industrial environments. Whether it is a deviation from default settings, a capability that was never enabled, or infrastructure that was designed without a full understanding of the security implications, the majority of preventable incidents trace back to how devices were configured and whether anyone is actively managing configuration drift over time. SEVD-2026-104-02 lands squarely in that pattern.
CISA’s ICS advisory data for 2025 recorded 2,155 CVEs across 508 advisories, the highest volume since the program began in 2010, as analyzed by Forescout’s Vedere Labs. The industry tends to respond to that number by talking about patching velocity. The harder conversation is about how many of those vulnerabilities are exploitable specifically because of configuration choices that were made once and never reviewed.
Why OT Networks are Still Exposed
RADIUS authentication infrastructure in OT is notorious for being configured during commissioning and left untouched. It isn’t negligence, but rather the reality of running systems where uptime matters and change control is strict. But the consequence is that authentication infrastructure nobody has reviewed in five or ten years becomes the primary attack surface.
The SANS State of ICS/OT Security 2025 survey found that only 12.6% of organizations have full visibility across the ICS Cyber Kill Chain. If you cannot see down to managed switch firmware versions and active authentication configurations, you cannot know your exposure to this advisory.
IBM X-Force’s 2026 Threat Intelligence Index found that 56% of disclosed vulnerabilities did not require authentication to exploit, and that exploitation of public-facing applications rose 44% in 2025. Manufacturing was the most attacked industry for the fifth consecutive year, accounting for 27.7% of all observed incidents. The environments running these Schneider switches are exactly the environments threat actors are prioritizing.
There is also the dual-update problem. Both the RADIUS server and the affected switches should be reviewed for updates and Message-Authenticator enforcement. Updating servers is the immediate priority, but leaving older client devices unchanged can preserve exposure. For teams without a clear picture of what RADIUS infrastructure they are running across sites, that is a difficult problem to even scope, let alone execute against.
What To Do About It
Schneider Electric provides mitigation guidance and affected product details in SEVD-2026-104-02. Review it against your specific device types and firmware versions. But the firmware update is not the complete answer.
The configuration steps that should accompany it:
- Restrict RADIUS traffic to trusted management VLANs and ensure it does not traverse untrusted network segments
- Disable PAP, CHAP, and MS-CHAP where operationally feasible and move to EAP-based authentication
- Audit both the RADIUS server and client devices: updating one side without the other is not a complete fix
- Enforce the Message-Authenticator attribute on both RADIUS servers and clients where supported
- Review when RADIUS was last configured on these devices and whether the current configuration reflects current security standards
- Plan longer-term migration toward RADIUS over TLS to address the underlying protocol weakness
That last point is the one most teams will skip. It should not be skipped.
From Advisory to Execution
The first practical question for most teams is whether they actually know which of these switches are deployed, what firmware each one is running, and what authentication methods are configured. In a large OT environment across multiple sites, answering that question is not a quick manual exercise.
Foxguard Discover builds a complete OT asset inventory using a hybrid of passive discovery, air gapped collection for isolated network segments, and safe queries over native OT protocols including Modbus, SNMP, EthernetIP, SSH, and S7, without disrupting operations. If Connexium or Modicon managed switches are on your network, Discover surfaces them with firmware version detail, establishing the real scope of this advisory in your environment before remediation planning begins.
From there, Patchintel removes the manual work of tracking down the right patches. Rather than checking Schneider’s portal individually for each device type, Patchintel aggregates patch data directly from vendor sources with release notes and security bulletin links, giving teams the context needed to make decisions quickly. It documents patch authenticity checks and integrity verification for every update supplied, which matters in NERC CIP environments that require audit evidence. It also covers OT device patches that do not appear in the NVD, a genuine gap for teams relying solely on CVE feeds.
For organizations without the internal bandwidth to run a full assessment and deployment cycle against this advisory, Foxguard’s PMaaS team handles prioritization, playbook development, and remediation coordination, built for OT operational constraints. The service was developed in collaboration with the US Department of Energy and is built around NERC CIP compliance requirements.
The firmware update matters. But if your RADIUS configuration has not been reviewed since commissioning, that is where to start.