PLC Security. Protect the controllers that can't protect themselves.
PLC security means protecting the controllers that run physical processes, by enforcing identity, segmentation, and audit in front of devices that cannot defend themselves.
Last updated:
PLC security is about protecting the programmable logic controllers that run physical processes. Most controllers in the field, like Siemens S7, Rockwell ControlLogix, and Schneider Modicon, cannot authenticate a user, encrypt their traffic, be patched, or run an agent. So you do not secure a PLC on the device. You secure it in front of the device: an on-premise industrial proxy brokers every connection, checks who is asking, allows only the commands each user needs, keeps the PLC off the flat network, and records the session. This is a compensating control, and it maps to IEC 62443 and NIST 800-82. The stakes are physical: a manipulated controller changes a process, so a bad command means a stopped line, damaged equipment, or an unsafe setpoint.
Why PLCs are hard to secure
A PLC is a rugged controller built to run a process for twenty years, not to defend itself on a network. The families in most plants, Siemens S7-1200 and S7-1500, Rockwell ControlLogix and CompactLogix, and Schneider Modicon, share four weak spots.
They can't be patched
Vendors rarely ship firmware updates, and you cannot take a running controller offline to apply them. Known bugs stay open for years, many of them listed in CISA's ICS advisories. So "we cannot patch it" no longer satisfies an auditor or a cyber-insurer. They expect a documented compensating control, not an accepted risk.
They trust by default
Most PLC protocols have no authentication or encryption out of the box. Modbus/TCP (port 502), Siemens S7comm (port 102), EtherNet/IP CIP (44818), DNP3 (port 20000), and Profinet let any device on the network read or write registers and send commands. Secure versions exist, S7comm-plus, CIP Security, and DNP3 Secure Authentication, but they are optional and rarely switched on.
They ship with default credentials
Default and hardcoded passwords are common and well documented. Most are never changed, because changing one risks breaking a working integration.
A VLAN is no longer enough
PLCs, HMIs, and engineering workstations often share one flat network, and putting them on a VLAN is not enough anymore. A VLAN separates traffic, but it does not control who may reach a specific controller, or record what they did. Port-based access control like 802.1X helps, but it is complex to run and maintain at plant scale, and its logs are hard to tie back to what a user actually did at the controller. The engineering workstation is the weak point, since it runs the software that programs the PLC (TIA Portal, Studio 5000). The goal is granular, traceable access to the machine itself, per user and per command, not just a network zone.
How PLCs get attacked
Most PLCs run any valid command they receive on an unauthenticated protocol, so the attack path is short. This is not theory: from the 2023 Unitronics intrusions at US water utilities that still used default credentials, to the incidents tracked through 2026, CISA and OT threat researchers keep finding internet-exposed and default-credentialed controllers. The techniques below are the same ones, mapped to MITRE ATT&CK for ICS.
| Tactic | Technique (ID) | What happens on a PLC |
|---|---|---|
| Initial Access | External Remote Services (T0822) | A vendor VPN or jump host gives a compromised third party broad reach into the OT network. |
| Initial Access | Internet Accessible Device (T0883) | A PLC exposed to the internet is found by Shodan or Censys and reached directly. |
| Lateral Movement | Default Credentials (T0812) | Documented default passwords let an attacker log in to the controller. |
| Execution | Unauthorized Command Message (T0855) | With no authentication, a crafted Modbus (port 502) or S7comm (port 102) message writes registers or changes logic. |
| Execution | Program Download (T0843) | A compromised engineering workstation uses TIA Portal or Studio 5000 to push altered logic to the controller, over the same path a real engineer uses. |
| Impair Process Control | Manipulation of Control (T0831) | Altered setpoints or logic drive the process to an unsafe state: overfeeding a chemical dose, over-pressurizing a line, or forcing equipment past a limit. |
Secure a PLC without touching it
You cannot harden most PLCs directly, so you add the missing controls in front of them: identity, least privilege, and a record the device never had. This is what Trout Access Gate does. It is a resilient industrial proxy that runs on-premise in front of your controllers and enforces identity-bound access, per-command allowlisting, microsegmentation, and full audit, with no agent on the PLC and no downtime to deploy. Auditors call this a compensating control. None of the six steps below touch the controller.
01Put an enforcement point in front of the controller
Trout Access Gate sits in the path to the PLC and brokers every connection. The controller is never touched or patched, and the proxy stays transparent to the process, so it does not affect control-loop timing or a connected safety system (SIS).
02Authenticate every connection by identity
Tie access to a named user or device through your directory (Active Directory, Microsoft Entra ID), with MFA at the network layer, not a shared IP or password.
03Allow only what each user needs
Scope access per asset, protocol, and command. An engineer reaches the PLCs they own; a vendor reaches one machine for one task, time-boxed.
04Segment the PLC off the flat network
Use microsegmentation so a compromised workstation cannot reach the controller, with no VLAN redesign and no re-IPing.
05Record every session
Keep a tamper-evident record of who connected, to which controller, over which protocol, and what commands ran, ready for an audit or an incident.
06Keep the process running if enforcement degrades
The proxy now sits in the path, so build it for uptime: run it with failover so one fault never stops the process, and give operators a documented break-glass path that is itself logged.
What a compensating control has to produce
A control that cannot produce evidence is not a control. Auditors and cyber-insurers accept records, not claims. For every controller behind the proxy, you should be able to export:
- Identity attribution: the named user or device behind every session, not an IP or a shared account.
- Least-privilege proof: the per-asset, per-command scope each identity was allowed.
- Command-level records: which protocol commands and register writes reached the controller, and which were blocked.
- Tamper-evident, time-synced logs with a stated retention period, so a timeline survives an investigation.
- Coverage: which controllers sit behind enforcement and which do not, tied to the asset inventory.
- Proof it cannot be bypassed: in-path enforcement, not out-of-band detection, with the break-glass path itself logged.
- The mapping: each item tied to the specific IEC 62443, NIST 800-82, CMMC, or NERC CIP requirement your assessor tests. Evidence stays on-premise, not in a vendor cloud.
PLC security checklist
A practical sequence to secure a fleet of controllers, from inventory to framework mapping.
| # | Action | Detail |
|---|---|---|
| 01 | Inventory every PLC | Build a live inventory of controllers, HMIs, and RTUs, including legacy devices that cannot run an agent. Use passive discovery: older CPUs can fault or drop I/O under an active scan, so never active-scan a running controller. |
| 02 | Remove internet exposure | Take PLCs off any internet-reachable path, and confirm none are exposed via Shodan or Censys. |
| 03 | Change or front default credentials | Replace default passwords where you can; where you cannot, enforce authentication in front of the device. |
| 04 | Enforce identity and MFA at the network layer | Require named, MFA-backed authentication before any session reaches a controller. |
| 05 | Segment IT from OT, and PLC from PLC | Microsegment so lateral movement to controllers is blocked, without rewiring. |
| 06 | Control vendor and remote access | Broker third-party access per asset, time-boxed and recorded, and retire standing VPN accounts. |
| 07 | Record and retain sessions | Keep tamper-evident, time-synced session logs mapped to identity, with a retention period that meets your auditor, regulator, or insurer. |
| 08 | Stage changes around the process, not against it | Cut enforcement over in a planned maintenance window, keep safety systems (SIS) out of scope, and confirm the line runs unchanged before and after. |
| 09 | Map controls to the frameworks you answer to | Document each control against IEC 62443, NIST 800-82 Rev 3, and CISA CPGs, plus TSA directives, NERC CIP, or CMMC where they apply. |
PLC security and IEC 62443
Legacy PLCs meet almost none of the IEC 62443 foundational requirements on their own. A compensating control in front of the controller closes the gap and produces the evidence, and the same control covers the other frameworks a US operator answers to: NIST 800-82 Rev 3, CISA CPGs, and where they apply, TSA directives, NERC CIP, and CMMC.
| IEC 62443 requirement | The PLC gap | How to cover it |
|---|---|---|
| FR 1 Identification & Authentication Control | PLCs have no native authentication | Identity-bound access enforced at the proxy |
| FR 2 Use Control | No per-command control on the device | Allowlist per asset, protocol, and command |
| FR 3 System Integrity | Unauthenticated commands can alter logic | Only authorized commands reach the controller |
| FR 4 Data Confidentiality | Legacy protocols send commands in clear text | Encrypt the client-side session; confine cleartext to the segment in front of the controller |
| FR 5 Restricted Data Flow | Flat networks, no zones or conduits | Microsegmentation into zones and conduits |
| FR 6 Timely Response to Events | No native logging on the device | Tamper-evident session records for detection and audit |
| FR 7 Resource Availability | No protection against overload or a broken integration | In-path enforcement with failover and a logged break-glass path |
What to do this week
- List every PLC and where it sits on the network.
- Check whether any controller is reachable from the internet.
- Find which PLCs still use default or shared credentials.
- Check whether vendor remote access relies on standing accounts or open VPNs.
- Try to name, for one critical controller, who reached it and what commands they sent in the last 30 days. If you cannot, that is the gap.
- Pull the OT section of your cyber-insurance application and read how it asks you to handle unpatchable assets.
PLC security questions, answered
agents on the PLC, no downtime to deploy
PLC security is protecting programmable logic controllers, the devices that run physical processes, from unauthorized access and manipulation. Because most PLCs cannot authenticate, encrypt, or be patched, you enforce PLC security in front of the controller: identity-bound access, segmentation, and audit at the network layer.
Put a compensating control in front of it. An on-premise industrial proxy brokers every connection to the controller: it authenticates the user, allows only the commands they need, segments the PLC off the flat network, and records the session. The PLC is never modified, and it stays online.
Not on the PLC itself, since most controllers do not support it. You enforce MFA at the network layer instead: a user authenticates with MFA against your directory before any session reaches the controller. The effect is MFA-protected PLC access without changing the device.
Scan carefully. Older controllers can fault, drop I/O, or stop responding under an active port scan, so discovery on a running plant should be passive: read the traffic already on the wire instead of probing the device. Keep active testing to a maintenance window against a spare or offline unit.
Default credentials, internet exposure, unauthenticated protocols, unpatched firmware, flat networks, compromised engineering workstations and vendor laptops, and uncontrolled vendor remote access. Each one lets an attacker reach a controller and issue commands, or push new logic, that it runs without question.
Underwriters increasingly expect one. Cyber-insurance applications ask how you handle unpatchable OT assets, MFA, and segmentation, and "we cannot patch it" without a control is a red flag at renewal and a dispute at claim time. A compensating control that enforces identity, least privilege, and segmentation in front of the controller, and produces session evidence, answers the questionnaire and the claim.
For each controller: the named identity behind every session, the per-asset and per-command scope they were allowed, the commands that reached the device, tamper-evident time-synced logs with a retention period, coverage of which controllers are protected, and a mapping of each item to the IEC 62443, NIST 800-82, CMMC, or NERC CIP requirement your assessor tests. Evidence is exported on-premise, not from a vendor cloud.
IEC 62443 expects identification and authentication, use control, system integrity, zoning, and event logging. Legacy PLCs meet none of these natively, so operators satisfy the requirements with a compensating control that enforces them in front of the controller and documents the mapping.
Yes, because they ask for the same things in different words: identity-bound access, least privilege, segmentation, and logging in front of assets that cannot do it themselves. One enforcement point in front of the controller produces the evidence for IEC 62443, NIST 800-82 Rev 3, CISA CPGs, TSA directives, NERC CIP, and CMMC.
Inventory every controller, check for internet exposure and default credentials, verify segmentation and identity-based access, confirm vendor access is brokered and recorded, and map each control to IEC 62443 or NIST 800-82. The checklist on this page walks through it.