Article: A fresh CISA advisory warns that state-backed groups are increasingly targeting PLCs from the two biggest industrial vendors, using unauthenticated protocols and exposed network interfaces to rewrite control logic. The advisory says the trend is moving from isolated, niche systems to the global supply chains that power factories, power plants and water treatment facilities, and it urges operators to treat logic-tampering as a physical-security breach.

Why PLCs are now a front-line target

Programmable Logic Controllers sit at the heart of modern industry: they open valves, spin turbines, regulate chemicals and keep production lines running. A malicious change to a PLC’s code can turn a routine process into a safety hazard, cause costly downtime or even trigger environmental damage. The advisory points to three recurring weaknesses that make these devices attractive:

  • Unauthenticated industrial protocols such as Modbus TCP and S7comm were designed for speed, not security, and they transmit commands in clear text.
  • Weak access controls let anyone with network reach issue write commands or download new programs.
  • Internet-facing interfaces expose the control plane to the wider corporate or public network, inviting remote exploitation.

When attackers exploit these gaps they rewrite registers to change setpoints, bypass safety interlocks, or spoof sensor data to hide dangerous conditions. The impact is no longer limited to data loss; it becomes a matter of physical safety.

From reactive fixes to defense-in-depth

CISA’s guidance pushes operators away from “detect-and-react” postures toward layered protection. The following steps translate the advisory’s recommendations into a concrete hardening roadmap for development and operations teams.

1. Eliminate direct Internet exposure

Never place a PLC on a public-facing subnet. Funnel all remote access through a dedicated Industrial DMZ (IDMZ). The IDMZ acts as a buffer zone where traffic can be inspected, logged and limited to approved services.

2. Route remote sessions through secure gateways

Deploy a jump host inside the IDMZ and require multi-factor authentication (MFA) for every connection. MFA adds a second verification step—something the user has or knows—making credential theft far less useful.

3. Install unidirectional gateways (data diodes)

A data diode physically enforces one-way traffic from the OT (operational technology) network to the IT network. This hardware barrier prevents inbound commands while still allowing telemetry and logs to flow outward for analysis.

4. Use physical write-protect keys

Most PLCs offer a RUN/PROGRAM mode toggle. In RUN mode the controller executes its current logic but refuses remote program uploads. Switching to PROGRAM mode requires a physical key turn, ensuring any logic change is a deliberate, onsite action.

5. Deploy passive network monitoring

Active scanners can overload legacy PLC firmware and cause crashes. Passive monitors listen to traffic without injecting packets, alerting on:

  • New devices appearing on the OT segment
  • Unusual command patterns or malformed protocol frames
  • Unauthorized attempts to download or upload PLC programs

6. Baseline and continuously compare configurations

Maintain a version-controlled repository of approved PLC logic. Periodically compute a checksum or hash of the running program and compare it against the baseline. Any mismatch should trigger an immediate security incident response.

What to watch next

Takeaway: Treat PLC logic as a critical code base, not just a device firmware. By removing Internet exposure, enforcing physical write protection, and continuously monitoring for unauthorized changes, you turn a vulnerable control surface into a hardened, auditable component of your overall security posture.