If you're responsible for auditing operational technology controls, you're facing a serious threat: programmable logic controllers (PLCs) exposed on the public internet. Iran-linked actors are actively targeting these devices across water, energy, and local government facilities, leading to operational disruption and financial loss. Your task is to ensure these devices aren't exposed in your environment and that your organization has controls to prevent future exposure.
This checklist guides you on what to verify, what evidence to collect, and what success looks like for each control.
Prerequisites
Before starting this audit, confirm:
- You have an inventory of all PLCs in your environment (Rockwell Automation, Schneider Electric, Siemens, and others).
- You can access network diagrams showing how these devices connect.
- You have contact information for the teams responsible for OT network architecture.
- You understand which PLCs support critical processes (valves, pumps, sensors).
If you don't have a complete PLC inventory, that's your first finding. You can't audit what you can't see.
Checklist Items
1. Verify no PLCs are directly accessible from the internet
Scan your external IP ranges or request results from your network team. Cross-reference against your PLC inventory. Check for devices listening on common industrial protocols (Modbus TCP port 502, EtherNet/IP port 44818, S7 port 102).
What good looks like: Zero PLCs respond to external scans. All devices sit behind firewalls or security gateways on segmented networks.
2. Confirm PLCs require authentication before accepting configuration changes
Review device configurations. Many PLCs ship without authentication enabled because they were designed for closed networks. Check manufacturer security hardening guides for your specific models.
What good looks like: All PLCs require credentials to modify logic or settings. Default passwords have been changed. A documented exception process exists for any device that physically cannot support authentication.
3. Document how third-party vendors connect to PLCs
Interview the teams that manage vendor access. Many exposures happen when service providers install cellular modems for remote monitoring. Trace these connections to understand if they create internet-facing paths.
What good looks like: All vendor remote access goes through VPN or jump hosts, not direct PLC connections. Cellular modems, if used, connect to private APNs or are protected by firewalls. You have contracts specifying vendor security requirements.
4. Test network segmentation between IT and OT environments
Attempt to reach PLCs from standard corporate workstations. Verify that firewalls block traffic between business networks and control system networks except through documented, monitored pathways.
What good looks like: PLCs are unreachable from IT networks without going through a security gateway. Firewall rules follow the Principle of Least Privilege. You have logs showing denied connection attempts.
5. Verify someone monitors CISA advisories for your PLC manufacturers
Check email distribution lists, ticketing systems, or SIEM rules. CISA updated its PLC advisory in July 2026 to add Schneider Electric and Siemens after initially covering only Rockwell. Who in your organization saw that update?
What good looks like: A specific role or team receives CISA ICS advisories. They have a documented process to review advisories against your asset inventory within 48 hours. You can show evidence of past advisory reviews.
6. Confirm IP address ownership is documented for all PLC connections
For any PLC with external connectivity, document who owns the IP address. If it's a carrier like Verizon, document the customer account details and the actual asset owner. This matters for incident response.
What good looks like: You can trace every PLC connection to the responsible party. If a carrier owns the IP, you have the account number and service contract. You know how to reach the asset owner within one hour.
7. Review incident response procedures for PLC compromise
Ask the Computer Security Incident Response Team how they would handle a compromised PLC. Do they know that rebooting a PLC creates a 30-second window when the controlled process stops responding?
What good looks like: IR procedures include OT-specific steps. The team knows not to reboot PLCs without coordinating with operations. Recovery procedures account for the physical processes these devices control.
8. Validate that PLC firmware is current and patched
Check installed firmware versions against manufacturer security bulletins. Unlike IT systems, you can't always patch PLCs immediately due to uptime requirements, but you should know your patch status.
What good looks like: You have a current firmware inventory. Critical security patches are applied during planned maintenance windows. Unpatched devices have documented compensating controls and scheduled patch dates.
9. Confirm PLCs aren't discoverable via Shodan or similar search engines
Search for your organization's name, IP ranges, and facility locations in Shodan. Check if any PLCs appear. This is what attackers do.
What good looks like: Zero results. Your devices don't respond to internet scans and don't broadcast identifying information.
10. Verify someone owns the risk for each exposed or unpatched PLC
For any PLC that doesn't meet security baselines, confirm a risk owner has accepted the exposure in writing with a remediation timeline.
What good looks like: Every exception has a named risk owner, business justification, compensating controls, and review date. No "temporary" exceptions older than 90 days.
Common Mistakes
Assuming cellular connections are safe. Just because a PLC uses a cellular modem doesn't mean it's protected. Many cellular connections put devices directly on the public internet. Verify the network architecture.
Relying on IP address lookups to find asset owners. As of July 2026, approximately half of exposed Rockwell devices in the U.S. showed Verizon IP addresses. That tells you the carrier, not the customer. You need account-level details to trace ownership.
Treating all PLCs the same. A PLC controlling a backup pump has different risk than one controlling a water treatment chemical dosing system. Prioritize your audit based on process criticality.
Waiting for CISA to notify you. CISA works to identify and notify owners of vulnerable devices when possible, but with thousands of exposed devices, you can't count on direct notification. You need to find your own exposures.
Ignoring third-party installers. The organization running the water facility may not know their PLCs are internet-connected if a vendor installed them. Audit vendor installation practices.
Next Steps
After completing this checklist:
- Escalate any internet-exposed PLCs immediately. This is a critical finding.
- For PLCs requiring authentication, work with OT teams to enable it during the next maintenance window.
- If you found gaps in CISA advisory monitoring, establish a process before the next advisory drops.
- Review your findings against ANSI/ISA-62443 requirements for industrial automation security. Map gaps to specific control requirements.
- Schedule a follow-up audit in 90 days to verify remediation of any exposures.
The threat isn't theoretical. Organizations across water, energy, and government sectors have already experienced operational disruption and financial loss from PLC compromises. Your audit creates the evidence trail showing whether your organization is protected or exposed.
