How is security ensured in PLC systems?
Hello everyone,
PLC system security means restricting access to controllers, programs, and communications; detecting unexpected changes; and being able to restore a verified operating state. A password or firewall alone is not enough. Hardware, software, networks, and working procedures must be considered together.
First, distinguish two requirements. Industrial cybersecurity addresses unauthorized access and digital interference. Machinery safety addresses the risk of injury from hazardous movements and process conditions. Adding a password does not turn a standard PLC into a safety PLC. Emergency stop and other safety functions need an appropriate risk assessment and safety design.
1. Know which devices you need to protect
Record the PLC manufacturer and model, firmware version, network address, and connected equipment. The inventory should include input and output modules, remote I/O, HMI panels, and industrial PCs. You need to understand which devices communicate with each other before defining appropriate access rules.
Identify equipment that no longer receives manufacturer security support. You cannot base protection on features a legacy PLC does not have. Suitable network restrictions and a planned replacement strategy become especially important in this situation.
2. Restrict permissions according to the user's role
Where supported, use individual accounts, strong passwords, and permissions limited to the task. Viewing an operator screen, changing a maintenance parameter, and downloading an engineering project are different privileges. Access to PLC programming software should be considered alongside the controller's own access settings.
Protections available in environments such as CODESYS depend on the target device. Review default accounts and manufacturer passwords. If multifactor authentication (MFA) is unavailable on the PLC itself, it can be applied at a suitable VPN or access gateway. Remove access when employees leave or a service contractor's work is complete.
3. Segment the control network
Arrange connections between SCADA, engineering workstations, and PLCs according to their actual needs. Allow only necessary traffic between business and control networks. Industrial firewall rules should restrict sources, destinations, and required services. Creating a VLAN does not, by itself, enforce access control. Rules must be enforced wherever traffic crosses network boundaries.
Reassess data flows when adding IIoT devices or cloud connections. Production PLCs should not be directly exposed to the internet. Segmentation supports controlled communication within the PLC–SCADA architecture.
4. Provide controlled remote maintenance access
When remote access is needed, use a managed VPN or secure access gateway, appropriate authentication, and access limited to the required equipment. Record the user, session time, and changes made. A VPN does not, by itself, establish that the connecting computer is trustworthy. Service computers and the remote access infrastructure also require protection.
5. Apply encryption according to device and protocol support
For supported communications, consider encryption, peer authentication, and certificate management together. Classic Modbus RTU does not provide built-in encryption. Modbus Security is a different solution that uses TLS and certificates; compatible support is needed at both ends.
Using TCP or UDP does not automatically provide encryption either. A tunnel does not automatically encrypt local connections outside that tunnel. Access restrictions and suitable gateways can help reduce the risks associated with legacy equipment.
6. Protect the cabinet and engineering workstation together
Control access to cabinet keys, programming ports, and removable media. An unauthorized person connecting a programming cable is also a security concern. Maintenance laptops, USB drives, and externally supplied project files should pass through a defined checking process.
Protecting the computer used to develop the PLC program matters as much as protecting the controller. Maintenance equipment can introduce risks into a control network even when that network has no internet connection. Our Stuxnet and Iran incident article provides a useful starting point for considering field access and the engineering environment together.
7. Manage updates with testing and rollback preparation
Monitor manufacturer security notices. Plan firmware and software updates with compatibility checks, testing in a separate environment where possible, and a suitable maintenance window. Prepare backups and rollback procedures beforehand. Equipment that cannot be patched needs additional access restrictions and consideration of planned replacement.
8. Verify that backups can actually be restored
Retain source projects, hardware configurations, parameters, and HMI/SCADA files with their version information. Document the software version, libraries, and programming language needed for restoration. An uploaded program copy is not necessarily the complete editable source project on every PLC model.
Protect at least one backup copy from incidents affecting the production network. Creating a backup and successfully testing restoration are different tasks. Perform restoration tests in an appropriate test setup.
9. Validate commands and program changes
Check commands received from an operator screen against operating mode, permissive conditions, and accepted value limits. Bound operator-adjustable settings and use supported controller protections to prevent unauthorized program downloads. Apply these measures alongside proper PLC debugging and testing.
Process interlocks in ordinary application code do not replace cybersecurity access controls or required safety functions. Record forcing operations and temporary test changes, and verify their removal when the work is finished.
10. Prepare monitoring and incident response in advance
Monitor failed logins, program changes, and unusual connections wherever the system provides visibility. Passive network monitoring can inspect existing traffic. Active scans can disrupt PLCs, so their method and timing should be tested and approved beforehand. Assign responsibility for investigating IDS alerts.
Maintain an incident response and controlled recovery plan for maintenance, production, and security teams. Plan evidence preservation, safe process management, and restoration from verified backups together. Train staff to recognize fraudulent service requests, suspicious files, and inappropriate account sharing.