PLC Security Handbook: Securing Your Industrial Automation Systems in 2026

Introduction: The Blind Spot in Your Control Panel

Your PLC has been running reliably for years. It executes its control logic flawlessly, handles I/O without complaint, and has never caused a production stoppage. So it is secure. Right?

Wrong.

The assumption that "nobody would target my factory" is dangerously outdated. In 2025, ransomware attacks against manufacturers surged 45%, with 1,156 recorded incidents and an average breach cost of $8.7 million. In Q1 2026 alone, manufacturing accounted for 29% of all global ransomware targets, making it the most attacked sector worldwide. A 2026 ESET survey found that 78% of manufacturers experienced a cyber incident in the past year—among them, 95% reported direct business impact.

The threat is not theoretical. In April 2026, CISA, FBI, NSA, and three other U.S. agencies jointly warned that Iranian-affiliated threat actors were actively exploiting internet-facing PLCs across critical infrastructure, causing operational disruption and financial loss. Attackers used legitimate remote engineering tools and valid credentials to manipulate OT systems. The advisory emphasized that many compromised PLCs were accessible simply because of a lack of robust network segmentation.

This handbook is your practical guide to securing PLC-based automation systems against real-world threats. We will examine how attackers target PLCs, provide step-by-step hardening procedures, review secure programming practices, and establish security monitoring that works in production environments. By the end, you will have a actionable framework to protect your automation assets—without compromising operational uptime.

Part 1: The Threat Landscape — Why PLCs Are Prime Targets

1.1 The Attack Surface Has Exploded

Traditional industrial networks were isolated. The "air gap" was considered sufficient security. Today, the air gap has evaporated. PLCs connect to:

• Engineering workstations running Windows with internet access

• Remote maintenance portals accessible from anywhere

• Cloud platforms for data collection and analytics

• Third-party VPNs used by OEMs and system integrators

• Wireless networks throughout the facility

Every connection is a potential entry point. And because PLCs were designed for reliability, not security, many lack basic defenses: encrypted authentication, access logging, or even password protection on some models.

1.2 How Attackers Get In — Real-World Attack Vectors

1.3 What Attackers Do Once Inside

Modern OT attacks are not just about stealing data. Attackers actively manipulate control logic:

The dwell time for OT ransomware remains alarmingly long. The all-time average dwell time is 42 days—attackers are inside the environment for more than a month before detection. In the fastest cases observed, attackers still had approximately five days inside before detection.

Part 2: Real-World Vulnerability Examples (2025–2026)

2.1 Delta Electronics DVP-12SE11T — Critical Vulnerabilities (January 2026)

Security researchers from OPSWAT's Unit 515 disclosed four significant vulnerabilities in the Delta Electronics DVP-12SE11T PLC, a device widely used in water treatment, food and beverage processing, and other sensitive sectors in Asia.

Vulnerability details:

• One high-severity vulnerability

• Three critical-severity vulnerabilities

• Affected device: Delta DVP-12SE11T

Impact: Attackers could remotely exploit these vulnerabilities to disrupt operations, alter control logic, or potentially cause physical damage. Delta pushed a firmware fix before New Year 2026, but because PLCs are buried deep inside operational networks designed to run 24/7, many organizations were unable or unwilling to patch immediately.

Lesson: Even reputable vendors have vulnerabilities. Secure configuration is not enough—you must have a patching process that works without prolonged downtime.

2.2 Siemens S7-1500 — Multiple Vulnerabilities (2025–2026)

The Siemens S7-1500, one of the most widely deployed PLC families in manufacturing and energy sectors, has been subject to multiple vulnerability disclosures:

Siemens S7-1500 devices also contain a vulnerability that could allow an attacker to inject code by tricking a legitimate user into importing a specially crafted trace file in the web interface.

Lesson: High-end PLCs are not immune. Security must be layered; no single product provides complete protection.

2.3 Delta AS300 Series — Undocumented Functionality (May 2026)

Positive Technologies helped fix vulnerabilities in Delta AS300 series PLCs running firmware versions 1.14 and earlier. The AS320T had a denial-of-service vulnerability via an undocumented subfunction.

Key finding: The product contained functionality that was not documented, not part of the specification, and not accessible through an interface. Attackers who discover such "hidden" functions can exploit them to disrupt operations.

2.4 COMMGR Stack-Based Buffer Overflow (April 2026)

Delta Electronics COMMGR, a communications management utility, contained a stack-based buffer overflow vulnerability (CVE-2026-3630) affecting versions 1.12 and prior. An unauthenticated attacker could execute remote code.

Lesson: Security vulnerabilities are not limited to the PLC itself. Associated software—configuration tools, communication utilities, engineering environments—poses equal risk.

Part 3: Step-by-Step PLC Security Hardening Guide

3.1 Phase 1: Discovery and Assessment — Know What You Have

You cannot secure what you do not know exists.

Step 1: Inventory all PLCs and OT devices

Step 2: Identify exposure to external networks

• Are any PLCs assigned public IP addresses? (If yes, this is a critical finding—remediate immediately)

• Are any PLCs reachable through NAT or port forwarding from the internet?

• Are remote access credentials shared among multiple users?

• Are default passwords still enabled?

Step 3: Review vulnerability status

• Cross-reference PLC models and firmware versions against:

  • Vendor security advisories

  • CISA ICS advisories (published regularly)

  • CVE databases

• Prioritize remediation based on:

  • Exploit availability (public exploit code exists)

  • Criticality of affected system

  • Ease of exploitation

Step 4: Document current network connections

Create a data flow diagram showing all communications between PLCs and other systems. Include:

• Which HMI connects to which PLC

• Which SCADA or MES systems poll data

• Which engineering workstations have programming access

• Which remote access tools are used

3.2 Phase 2: Network Defense — Segmentation and Isolation

Principle: If an attacker cannot reach the PLC, they cannot attack it.

Action 1: Remove internet-exposed PLCs immediately

If any PLC has a public IP address or is reachable from the internet via port forwarding:

• Immediate: Disable external access. Use a jump host or VPN if remote access is required.

• Root cause: Investigate why the exposure existed (commissioning oversight? IT change? vendor requirement?)

• Prevention: Implement policy that no OT device receives a public IP address.

Action 2: Implement network segmentation

The CISA advisory emphasized that many compromised PLCs were accessible because of a lack of robust network segmentation.

Minimum segmentation architecture:

[INTERNET] --- [CORPORATE IT NETWORK]
                      |
                      | (Firewall)
                      |
[DMZ] --- [SCADA / HISTORIAN / REMOTE ACCESS GATEWAY]
                      |
                      | (Industrial Firewall)
                      |
[OT CONTROL NETWORK] --- PLCs, HMIs, Drives
                      |
                      | (Optional further segmentation)
                      |
[SAFETY NETWORK] --- Safety PLCs (isolated)

Key rules:

• No direct communication from IT to OT. All traffic must pass through a firewall with restrictive rules.

• Use VLANs to separate different OT zones (e.g., control network, maintenance network, safety network).

• Disable all unused ports and protocols on managed switches.

Action 3: Implement jump hosts for programming access

• Never connect engineering laptops directly to the OT network.

• Require all programming access to go through a dedicated jump host (a locked-down computer in the DMZ).

• Log all programming sessions.

3.3 Phase 3: Access Control — Who Can Touch the PLC?

Principle: Restrict access to the absolute minimum necessary for each role.

Action 1: Change all default passwords

This should be non-negotiable, yet it remains one of the most common findings in security assessments. For each PLC:

• Change the default password before connecting to any network.

• Document the new password in a secure password manager (not on a sticky note attached to the panel).

• For platforms that support it, implement password complexity requirements and expiration.

Action 2: Implement role-based access control

Action 3: Disable unused communication protocols

Many PLCs have multiple protocols enabled by default. Disable:

• Any protocol not actively used (e.g., FTP, HTTP, Telnet)

• Unused physical ports (switch ports, serial ports)

• Unused network services (SNMP if not needed)

Action 4: Secure remote access

Traditional VPNs extend network access, allowing lateral movement within the OT network once a user connects. This violates the principle of least privilege.

Best practices for remote access:

• Never expose PLCs directly to the internet.

• Use a secure access gateway that brokers sessions, not network tunnels.

• Require multi-factor authentication (MFA) for all remote access, including vendor connections.

• Implement session recording and logging.

• Use time-bound access (credentials expire after the maintenance window).

• Audit all remote sessions.

3.4 Phase 4: Secure PLC Programming Practices

Even with perfect network security, a compromised engineering workstation or malicious insider can modify PLC logic. Secure programming practices reduce this risk.

Principle 1: Modularize PLC code

Structure code into functional modules with clear interfaces. This simplifies validation and limits the impact of unauthorized modifications.

Principle 2: Implement operating mode awareness

• Detect whether the system is in production, maintenance, or simulation mode.

• Restrict certain operations (e.g., parameter changes) to specific modes.

• Use different passwords or security levels for different modes.

Principle 3: Use PLC flags as integrity checks

• Implement checksums or hashes of critical code and data blocks.

• Store the expected value in a protected location.

• Periodically verify that actual values match expected values.

• Alert and take safe action if mismatch detected.

Principle 4: Validate inputs based on physical plausibility

• Set expected ranges for all analog inputs.

• Check rate-of-change limits (e.g., a pressure reading cannot change by 50% in 10 ms).

• Reject anomalous values and take appropriate action.

Principle 5: Avoid dangerous branching instructions

Use structured instructions (IF THEN ELSE, CASE, WHILE) rather than CONTINUE and EXIT instructions that can bypass expected execution paths.

Principle 6: Separate safety and non-safety functions

• Never mix safety logic and standard control logic in the same program block.

• Use certified safety PLCs for safety functions.

• Follow ISO 13849 and IEC 62061 requirements for programmed safety functions.

3.5 Phase 5: Monitoring and Anomaly Detection

Principle: If you cannot see an attack, you cannot respond to it.

Action 1: Log PLC uptime and trend it on the HMI

Unexpected PLC resets may indicate a cyberattack causing the controller to reboot. Trend PLC uptime over time; investigate any unexplained interruptions.

Action 2: Log PLC hard stops and trend them on the HMI

Hard stops (watchdog timeouts, fatal errors) should trigger immediate investigation.

Action 3: Monitor PLC memory usage

Sudden changes in memory usage may indicate malicious code injection or resource exhaustion attacks.

Action 4: Monitor network traffic for anomalies

• Establish baseline traffic patterns during normal production.

• Alert on:

  • Communications between PLCs that do not normally talk to each other

  • Traffic from PLCs to unexpected IP addresses

  • High rates of failed authentication attempts

  • Protocol anomalies (unexpected function codes)

Action 5: Implement intrusion detection for OT networks

Consider dedicated OT intrusion detection systems that monitor for malicious patterns, such as:

• Attempts to change PLC operating mode (Run → Stop)

• Unauthorized program downloads

• Excessive read/write operations to critical registers

3.6 Phase 6: Patch Management — Fixing Vulnerabilities Without Stopping Production

The challenge: Many PLC vulnerabilities require firmware updates. Firmware updates typically require:

• A scheduled production stop

• Validation testing after update

• Downtime that may not be available for months

The solution: A risk-based approach to patching.

Compensating controls while waiting to patch:

• Increase network segmentation to limit exposure

• Restrict access to vulnerable functions

• Implement enhanced monitoring for attack patterns

• Document the vulnerability and decision

Patch testing:

• Maintain a non-production PLC for patch testing

• Verify that critical functions still operate after patching

• Document patch rollback procedures

Part 4: The Security-Safety Convergence

A critical insight often missed: cyberattacks can undermine system safety. Security vulnerabilities can be exploited to violate safety constraints, causing physical harm.

The relationship:

• Safety systems protect against random hardware failures and random errors.

• Security protects against intentional, intelligent adversaries.

• A security breach can force the safety system to operate outside its design assumptions.

Practical implications:

1. Safety logic must be protected at least as well as control logic — an attacker who disables safety interlocks creates immediate physical risk.

2. Safety PLCs should be isolated on their own network segment — separate from standard control networks.

3. Safety and standard control credentials should be completely separate — a compromised engineer password should not affect safety systems.

4. Safety function testing should include security considerations — verify that safety cannot be disabled through network access.

Part 5: Building a Security Culture

5.1 Training and Awareness

For operators:

• Recognize phishing attempts (attackers target OT personnel through social engineering)

• Report unusual HMI behavior (unexpected screens, missing alarms, changed setpoints)

• Never share passwords

For maintenance technicians:

• Use dedicated, hardened laptops for PLC connections

• Never connect personal devices to the control network

• Report and log all remote access sessions

For control engineers:

• Follow secure coding practices

• Validate all code before download

• Maintain version control of PLC programs

• Document all online edits

5.2 Incident Response for OT Environments

Preparation (before an incident) :

• Maintain offline backups of all PLC programs (not just on the network)

• Document emergency procedures for disconnecting compromised PLCs

• Establish contact information for vendor security support

• Conduct tabletop exercises for OT cyber incidents

Detection:

• Monitor for indicators: unexpected PLC stops, changed programs, unusual I/O behavior

• Use HMI trends for baseline comparison

Containment:

• If a PLC is compromised: disconnect from the network (pull the Ethernet cable) and operate in local mode

• Isolate affected network segments

• Preserve logs and forensic evidence

Recovery:

• Restore from known-clean backups

• Change all passwords

• Update firmware if vulnerability was exploited

• Investigate root cause before reconnecting to network

5.3 Procurement and Vendor Management

When purchasing new PLCs:

• Require vendors to disclose known vulnerabilities and provide security documentation

• Specify secure configuration defaults (no default passwords, no unnecessary services)

• Require support for secure protocols (encrypted communications, authentication)

• Include security testing in acceptance criteria

Managing third-party access:

• Require MFA for all vendor remote access

• Use time-limited credentials

• Log and audit all vendor sessions

• Revoke access immediately after project completion

• Require vendors to follow your security policies

Part 6: Emergency Actions — What To Do Right Now

If you take nothing else from this handbook, implement these three actions immediately:

Action 1: Identify and remove internet-exposed PLCs

Search your network for any PLC with a public IP address or reachable from the internet. Remove external access immediately. Use a jump host or secure gateway if remote access is required.

Action 2: Change all default passwords

Every PLC, HMI, switch, and engineering workstation. Document the new passwords securely. Remove any shared or generic accounts.

Action 3: Implement network segmentation

Ensure a firewall exists between your OT network and any other network (IT, guest, corporate). Create at least two OT zones: control and safety. Block all traffic between OT and IT except what is specifically required.

Conclusion: Security Is a Process, Not a Product

There is no single "security PLC" or "secure by default" configuration that will protect you from all threats. Security is a continuous process of assessment, hardening, monitoring, and improvement.

The good news is that most successful attacks exploit basic weaknesses: default passwords, missing segmentation, unpatched vulnerabilities, and unmonitored remote access. Fixing these does not require expensive new hardware or specialized security expertise—just disciplined application of the practices in this handbook.

At PLC ERA, we believe that security should be a priority for every automation system, not an afterthought. When you source PLCs, HMIs, servo drives, and industrial switches from us, we can provide guidance on secure configuration, vulnerability management, and lifecycle security. Visit plcera.com for product specifications, security documentation, and application support.

References and Further Reading

1. CISA. (2026). *AA26-097A: Iranian Cyber Actors Targeting U.S. Critical Infrastructure*

2. Dragos. (2026). OT/ICS Cybersecurity Report — Dwell Time Analysis

3. ESET. (2026). Manufacturing Cybersecurity Survey — 78% of manufacturers experienced incidents

4. GuidePoint Security. (2026). GRIT Ransomware and Cyber Threat Report

5. OPSWAT Unit 515. (2026). *Delta Electronics DVP-12SE11T Vulnerability Disclosure*

6. Positive Technologies. (2026). Delta AS300 Series Vulnerabilities

7. Siemens. (2025–2026). *S7-1500 Security Advisories*

8. Tenable. (2026). *Delta COMMGR Vulnerability (CVE-2026-3630)*

9. PLCopen. (2026). Secure PLC Programming Guidelines

10. OPSWAT. (2026). Secure Remote Access Best Practices

Article Tags

#PLCSecurity #OTCybersecurity #IndustrialCybersecurity #CyberThreats #Ransomware #CriticalInfrastructure #SecurePLCProgramming #NetworkSegmentation #RemoteAccessSecurity #DeltaPLC #SiemensPLC #RockwellPLC #CISA #IEC62443