PLC Security Checklist

Programmable logic controllers should not be directly exposed to the public internet. Organizations that require remote access to PLCs should place that access behind a controlled gateway, restrict communications to approved systems, monitor every connection, and maintain a tested method for restoring trusted control logic.

This is not only a theoretical best practice. A joint advisory from the FBI, CISA, NSA, EPA, Department of Energy, U.S. Cyber Command, and Department of the Treasury warned that Iranian-affiliated actors have been exploiting programmable logic controllers across U.S. critical infrastructure. The advisory was first published on April 7, 2026, and updated on July 22, 2026 with additional guidance for detecting malicious changes and securing remote connectivity.

The incidents provide a practical lesson for manufacturers, utilities, logistics companies, building operators, local governments, and MSPs: operational technology must be protected as part of the organization’s wider network, but it cannot be managed exactly like an ordinary office computer.

What Is a Programmable Logic Controller?

A programmable logic controller, or PLC, is a specialized industrial computer used to control physical equipment and processes. PLCs can operate pumps, valves, motors, conveyors, production lines, environmental systems, traffic equipment, and other machinery.

A PLC repeatedly reads input signals, applies programmed logic, and changes outputs. For example, it might:

• Start a pump when a water level falls below a threshold
• Stop a conveyor when a safety sensor is triggered
• Open or close a valve according to pressure readings
• Maintain temperature within an approved range
• Coordinate machinery across a manufacturing process

Because these systems affect physical operations, a cybersecurity incident can cause more than lost data. It can interrupt production, degrade a public service, damage equipment, create unsafe conditions, or force operators to switch to manual processes.

Why Are Internet-Facing PLCs So Risky?

Many PLCs were designed for trusted industrial environments rather than direct exposure to hostile internet traffic. Some use specialized protocols, limited authentication, long equipment lifecycles, or configurations that prioritize operational availability over modern security controls.

Direct internet exposure creates several problems:

• Attackers can discover the device through routine scanning.
• Administrative or programming services may be reachable from anywhere.
• Weak or reused credentials may provide immediate access.
• Older protocols may lack strong encryption or authentication.
• Known vulnerabilities may remain unpatched because downtime is difficult to schedule.
• Operators may have limited logs showing what changed.
• An unauthorized logic change may directly affect a physical process.

A firewall located elsewhere in the organization does not help when a cellular modem, vendor-installed router, temporary maintenance connection, or port-forwarding rule exposes the controller through another path.

What the 2026 Government Advisory Recommends

The joint cybersecurity advisory AA26-097A describes activity targeting PLCs in U.S. critical-infrastructure environments. The agencies recommend immediate action to remove direct internet exposure and tightly control access to affected devices.

The central recommendation is straightforward:

Disconnect PLCs from the public-facing internet and broker necessary remote access through a secure, monitored gateway or jump host.

The July 22 update also recommends:

• Strict firewall or access-control rules allowing only expected communications
• Strong protection for cellular modems used for remote access
• Logging and review of modem and remote-access activity
• Private cellular connectivity, site-to-site VPNs, zero-trust access, or other isolated architectures
• Use of physical or software controls that restrict remote programming
• Review and validation of PLC project files before returning devices to normal operation
• Continuous testing of defensive controls against the behaviors described in the advisory

These recommendations are relevant even when an organization does not operate the specific PLC models discussed in the advisory. The broader security weaknesses—direct exposure, poorly controlled remote access, weak authentication, unrestricted programming, and limited monitoring—apply across many industrial environments.

PLC Security Checklist

1. Build an Accurate OT Asset Inventory

Start by identifying every PLC and the systems that can communicate with it. This includes equipment managed by operations teams, engineering contractors, equipment vendors, building-management providers, and telecommunications carriers.

For each device, record:

• Manufacturer and model
• Firmware version
• Physical location
• Process or equipment controlled
• IP address and network segment
• Internet exposure
• Connected human-machine interface or SCADA system
• Engineering workstation used for programming
• Remote-access method
• Vendor and internal support owner
• Current project-file backup
• Safety and operational criticality

Do not limit the inventory to equipment in a main plant. Remote pumping stations, warehouses, branch facilities, utility buildings, cellular-connected controllers, and temporary field systems are often harder to see and easier to overlook.

2. Find Every Path From the Internet to OT

Review more than the primary corporate firewall. PLC exposure may exist through:

• Port forwarding on an industrial router
• Cellular modems
• Vendor remote-support appliances
• Remote desktop systems
• Cloud-connected gateways
• Temporary maintenance VPNs
• Dual-homed engineering workstations
• Wireless bridges
• Unmanaged internet connections installed at remote sites

Conduct an authorized external assessment of public IP addresses and compare the findings with network diagrams and firewall rules. An internal document stating that a PLC is isolated is not proof that no alternate path exists.

3. Remove Direct Public Exposure

A PLC should not accept inbound connections directly from arbitrary internet addresses.

Where remote access is necessary, route it through an architecture that can authenticate the user, restrict the destination, record the session, and terminate access when the work is complete.

Possible controls include:

• A secure gateway or jump host
• A site-to-site VPN
• A dedicated remote-access VPN with multifactor authentication
• Zero-trust network access limited to specific systems
• Private cellular access-point networks
• A software-defined private WAN
• An isolated out-of-band management network

The correct design depends on the equipment, safety requirements, operational process, and available vendor support. The key requirement is that remote users do not connect directly from the public internet to the controller.

4. Use Deny-by-Default Firewall Rules

OT firewall policy should allow only the communications required for the industrial process.

A useful rule should identify:

• The approved source system
• The approved destination
• The required protocol and port
• The business or operational purpose
• The rule owner
• The date the rule was last reviewed

Broad rules such as “allow any from the engineering network to the OT network” make it difficult to contain a compromised workstation or vendor account.

Where supported, separate routine monitoring traffic from programming access. A system that only needs to read process data should not automatically have permission to upload new control logic.

5. Segment IT and OT Networks

PLCs should not share a flat network with employee laptops, guest Wi-Fi, ordinary servers, or unmanaged devices.

A common design separates:

• Corporate IT systems
• OT supervisory systems
• Engineering workstations
• PLCs and industrial devices
• Vendor remote access
• Safety systems
• Industrial demilitarized zones

Segmentation reduces the chance that malware entering through email, a browser, a stolen account, or an ordinary endpoint can move directly into the control network.

Segmentation must be enforced by routing and security policy, not merely by assigning different VLAN names.

6. Secure Remote Vendor Access

Third-party support is often necessary for industrial equipment, but permanent and unmonitored access creates a significant risk.

Vendor access should be:

• Disabled by default
• Enabled only for approved work
• Limited to named users
• Protected by multifactor authentication where possible
• Restricted to specific devices and protocols
• Time-limited
• Logged and reviewed
• Revoked when the engagement ends

Shared vendor accounts should be replaced with individual identities whenever the platform supports them. The organization should also know whether the vendor uses subcontractors and whether credentials are shared across multiple customers.

7. Protect Engineering Workstations

An engineering workstation can change PLC logic and should be treated as a privileged administrative system.

Recommended controls include:

• Dedicated use rather than ordinary email and web browsing
• Application allowlisting where operationally appropriate
• Endpoint monitoring compatible with the engineering software
• Restricted administrator rights
• Controlled removable-media use
• Strong authentication
• Limited network reachability
• Secure backups
• Logging of programming activity

A workstation with access to both the corporate network and PLC programming interfaces can become a bridge between IT and OT. That architecture should be reviewed carefully and avoided where safer alternatives are available.

8. Restrict Who Can Change PLC Logic

Not every user who can view process data should be able to upload a project file or modify control logic.

Use the strongest access controls supported by the equipment, including:

• Named user accounts
• Role-based permissions
• Programming protection
• Physical mode switches
• Software key switching
• Change approval
• Session logging

The joint advisory recommends placing physical mode switches in the run position when remote programming is not required. Devices should be placed into a programming mode only for controlled maintenance and returned to the more restrictive operating mode immediately afterward.

9. Back Up and Validate PLC Project Files

A PLC backup is not merely a copy of a file stored somewhere on an engineer’s laptop. The organization should maintain a known-good, versioned, and recoverable copy of the logic required to operate the process safely.

A mature backup process records:

• The approved project file
• Firmware and programming-software versions
• Hardware configuration
• Checksums or other integrity information
• The approver and change record
• The date the file was deployed
• Instructions for restoring the controller

Backups should be protected from unauthorized changes and stored separately from the engineering workstation.

After suspected compromise, compare the running logic with the approved baseline. Do not assume that a project file is trustworthy merely because it has the expected filename.

10. Monitor for Unauthorized Changes

Traditional IT monitoring may detect a suspicious login or malware process. OT monitoring must also consider changes to the physical process and control logic.

High-value alerts include:

• A PLC entering programming mode unexpectedly
• A new project-file upload
• Changes outside an approved maintenance window
• Communication from an unfamiliar engineering workstation
• Remote access from a new address or country
• New firewall rules allowing OT traffic
• Repeated authentication failures
• Unexpected cellular-modem connections
• Changes to HMI or SCADA data
• Loss of logging or monitoring
• Process behavior inconsistent with operator commands

Alerts should be evaluated with operational personnel who understand the process. A change that looks suspicious to a security analyst may be planned maintenance, while a subtle shift in timing or output may be obvious to an experienced operator.

11. Centralize the Logs That Exist

Some industrial devices provide limited logs, but that makes surrounding telemetry more important.

Collect relevant events from:

• Firewalls and industrial gateways
• VPN and zero-trust access systems
• Cellular modems
• Engineering workstations
• Windows and Linux servers supporting the OT environment
• Identity systems
• DNS services
• Remote-support platforms
• HMI and SCADA applications
• PLC management software

Centralized monitoring helps investigators connect an approved remote login, an unexpected programming session, a firewall-policy change, and unusual process behavior into one timeline.

12. Manage Vulnerabilities Without Ignoring Availability

Industrial patching can be difficult. Equipment may run continuously, replacement parts may be scarce, and a poorly tested update may interrupt a critical process.

That does not make vulnerability management optional. It means the process must include engineering and operational planning.

1. Track vendor advisories and supported versions.
2. Identify affected assets in the inventory.
3. Determine whether exploitation is active.
4. Test patches or configuration changes where possible.
5. Schedule an approved maintenance window.
6. Back up logic and configuration first.
7. Document temporary compensating controls.
8. Verify the update after installation.
9. Retest communications and safety functions.

When a device cannot be patched, reduce its exposure through segmentation, strict access rules, monitored gateways, programming restrictions, and a documented replacement plan.

Why Traditional IT Security Is Not Enough for OT

Many security principles apply to both IT and OT, but the priorities can differ.

Area	Typical IT Concern	Additional OT Concern
Availability	Application or service downtime	Interruption of a physical process or public service
Change management	Software and configuration stability	Impact on equipment, product quality, and safety
Endpoint security	User devices and servers	Engineering systems that can alter control logic
Network segmentation	Limit lateral movement	Separate business systems from physical control functions
Incident response	Contain systems and preserve evidence	Maintain safe operations while investigating
Patching	Apply updates quickly	Test against process, safety, and equipment dependencies

An OT security program should combine cybersecurity personnel with plant operators, engineers, safety personnel, equipment vendors, and business-continuity leadership.

What Should an MSP Do for Clients With PLCs?

An MSP may not program or maintain the client’s industrial equipment directly, but it can still play an important role in securing the surrounding environment.

During onboarding and recurring reviews, the MSP should determine:

• Whether the client operates PLCs, SCADA, building controls, or industrial gateways
• Who owns and supports those devices
• Whether any are reachable from the internet
• How vendors connect remotely
• Whether IT and OT are segmented
• Which logs are available
• Who monitors after-hours alerts
• Whether project files are backed up
• Who has authority to isolate a connection during an incident
• Whether the client has an OT-specific response plan

The MSP should avoid assuming that “the plant vendor handles it.” Responsibility should be documented. Otherwise, each provider may believe that someone else is monitoring the remote-access path, firewall, engineering workstation, or security logs.

How to Respond to Suspected PLC Compromise

Do not treat a suspected PLC compromise exactly like malware on an ordinary laptop. Abruptly shutting down a controller or severing communications may affect equipment or safety.

Response should be coordinated with qualified operations and engineering personnel.

1. Stabilize the physical process. Confirm that equipment is operating safely and determine whether manual control is required.
2. Restrict unauthorized remote access. Disable exposed paths or suspicious sessions without creating an unsafe condition.
3. Preserve evidence. Collect firewall, remote-access, workstation, modem, HMI, SCADA, identity, and programming records.
4. Record the current state. Document operating mode, project-file version, firmware, network connections, and observed process behavior.
5. Compare logic with a known-good baseline. Involve personnel who understand the approved control program.
6. Review adjacent systems. Investigate engineering workstations, jump hosts, VPN accounts, vendor systems, and other PLCs.
7. Rotate exposed credentials. Include remote-access accounts, local device passwords, VPN credentials, and vendor access.
8. Restore through an approved process. Use trusted software, validated project files, and manufacturer guidance.
9. Report when appropriate. The advisory provides contact information for CISA, the FBI, and other government organizations.

The organization should also determine whether manipulated equipment affected water quality, production output, environmental controls, customer service, safety, financial reporting, or regulatory obligations.

Questions to Ask a Network-Security Provider

A provider supporting an industrial environment should be able to explain its role clearly.

• Can you identify and block unauthorized inbound access to OT networks?
• Can you restrict communications to approved sources, destinations, and protocols?
• How are remote-access sessions authenticated and logged?
• Can your service separate IT, OT, vendor, and management traffic?
• Which industrial protocols can you identify or inspect?
• Which firewall, VPN, server, identity, and endpoint logs can you centralize?
• Who reviews alerts outside business hours?
• What actions may your SOC take without prior approval?
• How are emergency rule changes documented and reversed?
• Does your incident-response process account for physical safety and operational continuity?

Buyers should not assume that a generic “managed firewall” service automatically includes PLC discovery, industrial-protocol inspection, OT engineering support, or project-file validation. Those responsibilities should be confirmed explicitly.

Protect the Path to the PLC

The most urgent improvement for many organizations is not a specialized industrial-security product. It is removing direct public exposure, restricting remote access, segmenting the control environment, monitoring the systems around the PLC, and documenting who can change the process.

Network Box USA provides managed Unified Threat Management with firewall, intrusion-prevention, VPN, traffic-inspection, centralized logging, and continuous monitoring capabilities. Our Secure SD-WAN service supports centrally managed connectivity for distributed locations, while NBX MDR, SIEM, and SOC services support broader event collection, investigation, and managed response.

These services can help protect and monitor the network paths surrounding operational technology, but PLC programming, process safety, project-file validation, and equipment-specific remediation should remain coordinated with qualified OT engineers and the device manufacturer.

Organizations and MSPs reviewing industrial connectivity can contact Network Box USA to evaluate internet exposure, remote-access paths, segmentation, firewall policy, centralized visibility, and after-hours monitoring around their operational environments.