CISA Flags RADIUS Risk in Schneider Electric Modicon Managed Switches

What happened

CISA has highlighted a Schneider Electric advisory for Modicon Network Managed Switches involving CVE-2024-3596, a critical third-party RADIUS protocol vulnerability. Schneider’s own security notification SEVD-2026-104-02 identifies affected Connexium Managed Switches TCSESM*, Modicon Managed Switches MCSESM* and MCSESP*, and Modicon Redundancy Switches MCSESR*. The affected scope is broad because Schneider lists all versions of those product families.

The issue is not a conventional buffer overflow or a Schneider-specific backdoor. It sits in the way RADIUS authentication responses can be protected when the Message Authenticator control is disabled. Schneider rates the vulnerability as CVSS 9.0 critical, with network attack vector, no privileges required, no user interaction, and potential impact to confidentiality, integrity, and availability.

The practical risk is that an attacker positioned on the path between a switch and its RADIUS server may be able to tamper with valid RADIUS responses, including Access-Accept, Access-Reject, or Access-Challenge messages. In an industrial network, that matters because managed switches often guard the management plane for production cells, remote I/O segments, PLC networks, and engineering workstations. A forged authentication decision can become an entry point for configuration changes, denial of management access, traffic observation, or movement toward more sensitive operational technology assets.

Schneider states that the default RADIUS configuration is not vulnerable. The exposed condition appears when the RADIUS Server Message Authenticator option has been disabled. That distinction is operationally important. Asset owners should not treat this as a simple patch-and-close ticket. They need to verify configuration state, because two identical switch models may have different exposure depending on how RADIUS was deployed, migrated, or tuned over years of plant operation.

Who's responsible

No named threat actor has been publicly associated with exploitation of this Schneider advisory. The vulnerability is best understood as a protocol weakness affecting products that implement RADIUS in a vulnerable configuration, rather than as evidence of an intrusion campaign against Schneider Electric customers.

The attack model still deserves attention. RADIUS is commonly used to centralize authentication for network devices, including switches, routers, VPN concentrators, wireless controllers, and industrial network equipment. In a Modicon deployment, a switch may use RADIUS to decide whether an engineer, contractor, or administrator can access its management interface. If an attacker can intercept or alter traffic between the switch and the RADIUS server, and if message authentication is disabled, the trust boundary between identity infrastructure and the network device weakens.

That attacker does not need to be a highly visible malware operator. A plausible adversary could be a remote intruder who has already reached a poorly segmented business network, a contractor system connected to an engineering VLAN, a compromised jump host, or a malicious insider with access to the routing path. The high attack complexity in the CVSS vector reflects that the attacker needs the right network position and timing, but industrial networks often retain flat segments, legacy routing, and long-lived authentication designs that can make those positions easier to obtain than diagrams suggest.

There are no unique indicators of compromise such as malware hashes or command-and-control domains for this issue. Useful indicators are behavioral and configuration-based: unexpected RADIUS Access-Accept events, failed and successful login patterns that do not align with operator activity, switch configuration changes after unusual authentication sequences, unexplained changes to RADIUS settings, and discrepancies between RADIUS server logs, switch logs, and change-management records.

What it means

This advisory is a reminder that identity infrastructure in operational technology is only as strong as the protocol protections between the device and the identity source. RADIUS was designed decades ago for centralized network access control. It is still widely used because it is simple, well-supported, and operationally familiar. Those strengths also mean it is embedded in places where replacement is slow, including industrial Ethernet switches that may sit in production for many years.

The exposed Schneider configuration weakens message integrity during transmission. In plain terms, the device may rely on a RADIUS response without the stronger assurance that the message arrived unchanged from the legitimate server. In enterprise IT, that could lead to unauthorized access to network infrastructure. In OT, the blast radius can include loss of visibility, unauthorized management-plane access, or disruption of traffic paths that connect controllers, HMIs, historians, safety-adjacent systems, and remote access gateways.

The most serious scenario is not a single unauthorized switch login. It is the chaining opportunity. A forged authentication decision could let an attacker alter switch configuration, weaken segmentation, mirror traffic, change management settings, interfere with redundancy paths, or create conditions for later access. Managed switches are often treated as passive infrastructure, but in an industrial network they are active security controls. They enforce reachability, separate zones, and provide telemetry that defenders rely on during an incident.

The advisory also shows why secure defaults are necessary but insufficient. Schneider says the default RADIUS setting is safe, but production networks rarely remain in default state. Settings may be changed during commissioning, troubleshooting, RADIUS server replacement, disaster recovery, or vendor maintenance. A security option that was enabled on day one can be disabled later to make an authentication problem disappear. That kind of operational workaround is common in environments where uptime pressure is high and maintenance windows are scarce.

What to do

Asset owners should first identify whether affected product families are present: Connexium TCSESM*, Modicon MCSESM* and MCSESP*, and Modicon Redundancy MCSESR*. Schneider’s cybersecurity support portal should be monitored for updates, and CISA’s ICS advisories page should be used to track related federal guidance.

The primary mitigation is configuration verification. For TCSESM* devices, confirm the RADIUS Message Authenticator setting through CLI command radius server msgauth or MIB hmAgentRadiusServerMsgAuth. For MCSESM*, MCSESP*, and MCSESR* devices, Schneider identifies radius server auth modify <index> msgauth and MIB hm2AgentRadiusServerMsgAuth. The setting should remain enabled unless Schneider provides different product-specific guidance.

Defenders should also reduce the conditions required for exploitation. Restrict RADIUS traffic to known switch and server IP addresses, filter UDP 1812 and 1813 as well as legacy RADIUS ports where still used, and prevent general business network hosts from reaching OT authentication paths. Where architecture permits, protect RADIUS transport with stronger channel security such as IPsec or a modern protected RADIUS deployment. Disable RADIUS on switches that do not require centralized authentication.

Monitoring should focus on the management plane. Correlate switch login events with RADIUS server logs, administrator work orders, VPN sessions, and jump-host activity. Alert on successful administrative logins from unusual source addresses, authentication successes following repeated failures, changes to RADIUS configuration, new accounts, altered SNMP settings, firmware changes, port mirroring changes, and unexpected spanning tree or redundancy behavior.

For industrial environments, treat this as a zone and conduit review. Keep control and safety networks isolated from business networks, place remote access behind controlled gateways, restrict engineering workstation paths, and verify that switches are not internet-accessible. CISA’s broader Shields Up guidance remains relevant for organizations operating critical infrastructure, especially when a vulnerability affects foundational network controls rather than a single application endpoint.

The defensive priority is clear: confirm the Message Authenticator setting, constrain who can talk to RADIUS, monitor authentication decisions, and document any deviation from Schneider’s default secure configuration. This is a protocol-level trust issue, so the strongest response is not only to harden the affected switch models, but to examine every place where RADIUS still carries administrative authority across an industrial network.