Industrial control systems fail because people make decisions based on bad information or because core control devices – PLCs – are altered, corrupted, or manipulated. A tampered PLC can change setpoints, silence alarms, disable safety interlocks, or simply stop the plant. That’s why protecting PLCs is not a checkbox for IT – it’s a safety imperative for operations.
This article is written in the voice of a senior OT/ICS security architect. It explains why PLC security matters, how real attackers operate in industrial environments, and – most importantly – gives seven practical, prioritized PLC security checks you can run during the next maintenance window. Each check contains what to verify, how to test it safely, rollback considerations, and measurable KPIs you can track.
Read this if you want steps that operators will accept, that preserve determinism and safety, and that materially reduce the risk of silent tampering.
Background – why PLCs are both targets and single-point risks
PLCs sit at the heart of process control. They read sensors, run control logic, command actuators and talk to HMIs, historians, and safety systems. Historically they were relatively isolated, proprietary, and slow to change – which provided a degree of protection. Today they are more connected:
- Engineering workstations run vendor tools and connect to PLC networks.
- Edge gateways mirror telemetry to historians and cloud analytics.
- Remote vendor access and contractor workstations are common.
- Many PLCs run commodity operating systems or expose Ethernet services.
Adversaries follow easy, high-impact paths: compromise a vendor laptop or IT credential → pivot via jump host or exposed management port → alter logic or manipulate telemetry. In some attacks the PLC is never “hacked” in the classical sense; instead analytics and HMIs are poisoned so humans make unsafe choices. In others the PLC firmware or ladder logic are directly modified.
PLC security checks must therefore defend three properties: integrity (logic and firmware are unchanged), availability (controls remain responsive), and safety (no unauthorized actuator control). The seven checks below are ordered to give you the best risk reduction early, while minimizing operational risk.
Quick operational rule: safety first, revert fast
Always validate actions in a staging cell or a single non-critical PLC first. Never perform active checks that could change control logic or disrupt timing without written OT approval and a rollback plan. For every check you plan, document abort criteria, who to notify, and how to return the PLC to the known-good state.
The 7 PLC Security Checks (engineer-grade)
1) Inventory, Firmware Provenance & SBOM – verify what you have and where it came from
Why: You can’t secure what you don’t know. Unknown or unmanaged PLCs, or unsigned firmware, are the most common root causes of compromise and supply-chain attacks.
What to verify
- A complete inventory: make/model, IP/MAC, serial, firmware version, tag mappings, physical location, and owner.
- Existence of an SBOM or firmware manifest for each PLC family.
- Whether installed firmware and boot loaders are cryptographically signed.
- Whether firmware upgrades came from vendor repositories (avoid ad-hoc USB images).
How to test (safe)
- Use passive discovery tools (industrial network sensors, ARP tables, MAC lookups) to enumerate devices. Do not run active scans across PLC networks.
- On a pilot PLC (or maintenance testbed), verify firmware hashes match vendor-supplied hashes. If devices support signed firmware, validate the signature using vendor tooling.
- Request firmware provenance documentation from OEMs for your production versions.
Rollback & safety
- Never flash firmware in production without a tested rollback image and spare controller. If an integrity check fails, isolate the device and revert to earlier known-good firmware only under OT change control.
KPIs
- % of PLCs inventoried vs. floor count (target: 100% for control VLANs)
- % of PLCs with signed firmware (target: 90–100%)
- % of PLCs with an SBOM/manifest on file
2) Network Exposure & Segmentation – ensure PLCs are reachable only by intended systems
Why: Network-level exposure is the fastest attack path. Lateral movement from IT to OT is usually network enabled.
What to verify
- PLCs should only accept traffic from engineering jump hosts, HMIs, and required historians – nothing else.
- Management interfaces must be behind Industrial DMZ (IDMZ) or jump hosts. No direct RDP/SSH/VPN to PLC subnets.
- Protocol-level proxies or gateways (OPC/OPC UA, Modbus proxies) should be used for cross-domain traffic; direct cross-zone writes should be minimized.
How to test (safe)
- Review switch ACLs and firewall rules. Use passive flow captures (SPAN/tap) to validate actual communication pairs and to spot unexpected talkers.
- Produce a zones & conduits matrix (IEC 62443 style) and confirm observed flows match the matrix for at least 2–4 weeks of baseline.
- Test a sample block rule in a monitoring (shadow) mode first – many microsegmentation platforms offer “observe-only” mode.
Rollback & safety
- Changes to enforcement must have an emergency bypass (e.g., pre-approved ACL rollback script) and local operator authority for rapid reversal.
KPIs
- Reduction in unique source subnets reaching PLCs
- % of cross-zone writes brokered via IDMZ proxies
- Number of detected unauthorized flows per month
3) Authentication & Account Hygiene – remove defaults and enforce least privilege
Why: Default or shared accounts are an open door. PLC toolchains and vendor accounts frequently use weak or long-lived credentials.
What to verify
- No default credentials remain (check both PLC and vendor HMI accounts).
- Admin accounts only exist in a PAM or JIT system. No permanent vendor accounts.
- Engineer and operator accounts follow RBAC; no operator has unintended admin rights.
- Passwords and service accounts rotate; where possible use certificate-based authentication.
How to test (safe)
- Review account lists from PLCs and HMIs using vendor read-only query tools. Do this passively.
- Audit jump host and PAM logs for standing sessions and long-lived tokens.
- Confirm MFA is enforced for sessions that can reach engineering tools (via PAM/jump host).
Rollback & safety
- Removing or changing accounts must be tracked and reversible. Keep an out-of-band admin emergency account under strict control and multiple eyes.
KPIs
- % of default/shared accounts remaining (target: 0)
- % of privileged sessions brokered via PAM (target: 100%)
- Average credential lifetime (target: short, e.g., <30 days for vendors)
4) Firmware & Runtime Integrity – enable secure/verified boot and tamper evidence
Why: Unsigned or tampered firmware is a stealth persistence mechanism. Secure boot and measured boot create a chain of trust.
What to verify
- If hardware supports it, enable Secure Boot / Measured Boot and a TPM or hardware root of trust.
- Ensure PLC runtime images (and any local edge/container images) are signed and verified at boot.
- File integrity monitoring on engineering stations and PLC-supporting servers (where agents are feasible).
How to test (safe)
- On a test PLC, confirm secure boot boots only a signed image; confirm a tampered image fails verification.
- Collect and archive measured boot logs and verify attestation records.
- For vendors who do not support secure boot, require vendor attestations and monitor firmware version drift tightly.
Rollback & safety
- Do not enable secure boot on heterogeneous fleets without vendor validation – improper enablement can brick devices. Use a staging cell.
KPIs
- % of PLC models supporting secure/verified boot
- % of deployed PLCs with attestation logs being collected
- Frequency of firmware-version drift alerts
5) PLC Logic & Configuration Protection – control who can change logic and how
Why: Changes to ladder logic or function blocks are the simplest way to alter behavior.
What to verify
- Engineering tool uploads are logged and require ticketed approvals.
- Logic downloads are performed only from authorized jump hosts with session recording.
- Version control is in place for PLC logic (SVN/Git/dedicated vendor system) with signed commits.
- Watch for logic differences versus baseline (automated diffing).
How to test (safe)
- Validate a sample logic upload workflow: create a test ticket, perform upload via jump host, confirm session recording exists and the new logic version is in SCM.
- Use read-only compare tools to detect unexpected changes (diff production vs. archived baseline).
Rollback & safety
- Always have last-known-good logic available and tested in staging. Ensure rollback procedures are practiced.
KPIs
- % of logic changes accompanied by ticket & recorded session
- Time to detect unauthorized logic change
- % of PLCs with versioned logic backups
6) Protocol & Command Controls – limit dangerous function codes and rate limits
Why: Journaled incidents show attackers issue legitimate protocol commands (e.g., Modbus write coils) to cause harm. Limiting function codes and enforcing limits prevents abuse even if an attacker obtains connectivity.
What to verify
- Configure protocol proxies/gateways to allow only necessary function codes (e.g., read-only where appropriate).
- Enable rate limiting and locking for write operations.
- Validate write access is limited to specific source identities and times.
How to test (safe)
- In a controlled maintenance window, test gating policies using a replica or test PLC. Confirm that disallowed function codes are blocked and logged.
- Deploy DPI/IDS sensors that understand the protocol and raise alerts on unusual function code use or replayed commands.
Rollback & safety
- Rollbacks may be needed if proxies or filters mistakenly block required operational writes. Keep operator-approved emergency overrides.
KPIs
- Number of blocked unsafe function code attempts
- % of write operations passing through protocol proxy
- False positive rate for protocol policy enforcement
7) Monitoring, Forensics & Response – detect tampering and be ready to act
Why: Prevention will fail occasionally. Detection and response decisively reduce impact.
What to verify
- Passive network sensors and DPI that understand OT protocols are in place at conduits and zone boundaries.
- PLC-level telemetry (critical tags, heartbeat, logic checksum) is collected and forwarded to a hardened collector.
- Forensic collection policies are defined (immutable logs, PCAP retention for DMZ, secure time sync).
- Incident response runbooks include PLC-specific containment and rollback instructions and a human-in-the-loop for safety checks.
How to test (safe)
- Run tabletop and red-team exercises focused on PLC compromise scenarios. Validate whether SOC can detect an anomalous command and whether OT can isolate the segment safely.
- Verify time synchronization and integrity of logs for at least 90 days.
Rollback & safety
- Containment should prefer isolation of segments and retention of evidence over disruptive actions. Always verify safety before killing network paths that could affect interlocks.
KPIs
- MTTD for PLC-affecting anomalies
- MTTR for PLC incidents (target: decreasing)
- % of incidents where forensic evidence preserved
Converged monitoring: why IT+OT telemetry matters (and quick vendor list)
PLC security is stronger when PLC telemetry is correlated with IT telemetry. Converged monitoring reveals the typical attack chain: identity abuse → lateral movement → PLC access. If you’re evaluating converged monitoring vendors, here’s a concise list (placed per your request) – Shieldworkz is listed 4th because of its engineering-led service offerings:
- Nozomi Networks – deep OT protocol visibility and anomaly detection
- Dragos – ICS threat intelligence + detection
- Claroty – asset discovery, vulnerability context, and secure remote access controls
- Shieldworkz – engineering-led converged monitoring and managed OT SOC services
- Microsoft Defender for IoT / Sentinel integrations – cloud-scale XDR with OT connectors
Note: choose a provider that supports passive OT telemetry, integrates with your SIEM/SOAR, and offers human OT analysts, not just alerts.
Practical PLC security checklist to use in a maintenance window
Copy-paste this to your change ticket; run it on one PLC or a test cell first.
- Confirm PLC inventoried and firmware hash recorded.
- Verify engineering access uses jump host + PAM; ensure session recording active.
- Check for any default/shared accounts; disable or rotate.
- Confirm protocol proxy or firewall allows only required function codes.
- Verify device time sync and that logs are forwarded to collector.
- Validate presence of signed firmware (or documented vendor attestation).
- Snapshot PLC logic and commit to version control.
- Run passive flow capture for 24–72 hours to detect anomalies.
- Confirm rollback plan and emergency admin account availability.
- Notify control room and safety owner before any enforcement action.
Procurement & RFP tips (short)
- Require passive discovery capability and a signed safety methodology.
- Ask vendors to show prior OT field references with your PLC models.
- Demand human OT analysts for the SOC – not just IT analysts.
- Require vendor support for staged firmware validation and rollback testing.
- Ensure contractual SLAs cover evidence preservation and support during incidents.
Measurable KPIs to demonstrate progress
- % PLCs with a current firmware manifest and hash (target: 95–100%).
- % PLCs with access only via PAM + jump host (target: 100%).
- Time to detect a PLC-affecting anomaly (MTTD) – aim to cut this in half year over year.
- % of logic uploads with recorded session and ticket (target: 100%).
- Number of blocked unsafe protocol actions per quarter (trend should decrease as policies mature).
Final words – prioritize engineering discipline over security theater
PLC security isn’t about buying the newest gadget. It’s about discipline: inventory, identity, integrity, and monitoring – all delivered in a way that respects process