CISA has flagged internet-exposed PLCs as one of the most preventable risks in critical infrastructure—yet the exposure persists. For industrial operators, the challenge is not just identifying the gaps but closing them without halting production or creating new safety risks.
Why Internet-Exposed PLCs Are a Critical Risk
PLCs control everything from assembly lines to power grids, but when they face the internet—due to legacy architecture, misconfigured firewalls, or third-party remote access—they become high-value targets. Protocols like Modbus, DNP3, and OPC UA were designed for reliability, not external exposure. When those protocols are reachable from the internet without proper controls, attackers can manipulate process logic, cause equipment damage, or pivot deeper into the network.
The conditions that create exposure are common: incomplete asset inventories, outdated network diagrams, and unclear ownership between IT and OT teams. Operators often do not know a PLC is internet-reachable until a scan reveals it—or worse, until an incident does. As CISA’s ICS security guidance makes clear, this is not a theoretical threat class; it is an active one. Visibility is not the end state—it is the starting point for risk-informed decisions.
Assessing Exposure Without Disrupting Operations
An effective OT cybersecurity assessment does not begin with scanning—it begins with understanding. Before any active discovery, assessors need to know which systems are fragile, which processes cannot tolerate interruption, and where vendor-managed access creates blind spots. That context shapes every subsequent step.
For example, a legacy PLC running Modbus TCP may be exposed because a firewall rule was opened for a vendor during a maintenance window and never closed. Identifying that vulnerability requires network mapping and protocol analysis, but testing it requires care. Assessments structured around OT-safe testing methods can confirm exposure without sending traffic that risks tripping a safety interlock or disrupting a live process.
Key Assessment Considerations
- Asset inventory: Automated discovery tools should map PLCs, HMIs, SCADA systems, and communication paths—including assets that IT teams may not know exist.
- Network segmentation review: Evaluate whether critical systems are logically isolated from business networks and the internet, using IEC 62443-compliant zone and conduit models.
- Vendor-specific risk: Review configurations for Rockwell, Honeywell, ABB, and Siemens systems. Default credentials, unpatched firmware, and open service ports are common findings across all major platforms.
- Remote access paths: Third-party remote access is one of the most frequent entry points. Every inbound connection to the OT network should be inventoried and validated.
Practical Remediation That Respects OT Realities
Once exposures are identified, remediation must account for operational constraints. Security controls that work in an IT environment can create safety or reliability problems in OT. Patching a vulnerable PLC, for instance, may require a vendor-specific firmware process that cannot be applied during a production run. Forcing that update on an arbitrary schedule is not a reasonable recommendation—scheduling it within a planned maintenance window is.
Virtual patching—placing a compensating control such as a protocol-aware firewall or IDS rule in front of a device that cannot be patched—is a legitimate interim strategy when downtime is not immediately available. Similarly, restricting remote access to PLCs through a properly configured jump server with multi-factor authentication closes a significant portion of internet-exposure risk without requiring changes to the PLC itself.
Remediation plans that are not executable in the operating environment have no value. The right approach converts findings into actions OT teams can actually implement, sequenced by criticality and feasibility. Teams addressing complex OT environments should expect remediation to be phased across multiple maintenance cycles, not completed overnight.
IEC 62443-2-1 Alignment
The IEC 62443-2-1 standard provides a structured framework for establishing and maintaining an OT security management system. Practically, this means:
- Conducting a risk assessment that prioritizes PLCs by exposure level and process criticality.
- Implementing network segmentation to isolate PLCs from external networks and from corporate IT.
- Deploying intrusion detection capabilities tuned to OT protocols—Modbus, DNP3, OPC UA—rather than IT traffic patterns.
- Establishing change management procedures so that firewall rules and remote access configurations do not silently accumulate over time.
Monitoring Internet-Exposed PLCs in Context
OT monitoring is not IT intrusion detection pointed at a plant network. Effective monitoring requires protocol context, behavioral baselines built around normal operational patterns, and alert logic that minimizes false positives. A spike in Modbus traffic might indicate an attack—or it might reflect a scheduled batch process. Without operational context, security teams cannot distinguish between the two, and alarm fatigue sets in quickly.
OT-specific monitoring tools passively observe network traffic without injecting packets that could disturb sensitive devices. They establish baselines for normal communication patterns between engineering workstations, PLCs, and SCADA servers, then alert on deviations—unauthorized commands, new connections, unexpected protocol usage. When a PLC that has never communicated with an external IP address suddenly does, that signal is unambiguous.
Monitoring alone is not sufficient. Alert handling must be tied to response procedures that account for OT constraints. An analyst who isolates a compromised network segment without understanding the process consequences may create a safety event worse than the incident itself.
Incident Response Built for OT Environments
When a PLC is compromised or suspected to be, the response must be prepared in advance. Improvised containment in an OT environment carries real risk—a control system taken offline unexpectedly can cause equipment damage, process upsets, or personnel safety events. Containment actions must be defined before the incident, with clear decision authority and operational constraints documented in the plan.
Proactive preparation includes tabletop exercises that simulate attacks on internet-exposed PLCs, testing whether operations and security teams can coordinate under pressure. Recovery planning must address vendor involvement, known-good firmware versions, configuration backups, and the sequencing required to bring systems back online in a safe order. These are engineering problems, not just IT recovery tasks.
Teams that have not exercised their OT incident response plans before an event are at a significant disadvantage. A structured OT incident response playbook that operations staff can actually execute—not a generic IT document retrofitted for OT—is a foundational requirement for any plant with internet-reachable control systems.
Closing the Gap Is a Continuous Process
Securing internet-exposed PLCs is not a project with a finish line. Networks change, vendors introduce new remote connections, firmware updates open new service ports, and threat actors continuously probe for exposed industrial systems. The operators who manage this risk effectively treat it as an ongoing program—not a one-time audit.
OT cybersecurity has to protect production, not just information. That means assessments must be safe to perform, remediation must be feasible to execute, monitoring must be tuned to the process, and response plans must respect safety and uptime constraints. Every layer of the approach has to be designed around operations—not imposed on top of them.
