How do security teams know whether PLC controls are actually working?

Why This Matters for Security Teams

PLC controls can look healthy from the outside while the logic, messaging, or operator view has already drifted from what the process should be doing. Perimeter tools may confirm that traffic is moving, but they do not prove that a remote session is traversing the right gateway, that a project file matches a known-good baseline, or that an HMI display reflects the real process state. That gap is why validation has to move from “is it connected?” to “is it trustworthy?”

This is especially important in OT environments where safety, uptime, and change control are tightly coupled. NIST’s NIST SP 800-53 Rev 5 Security and Privacy Controls emphasizes continuous monitoring and integrity checks because point-in-time access decisions do not prove ongoing control health. NHIMG’s Ultimate Guide to NHIs - Standards makes a similar point for non-human access: possession of credentials does not equal secure operation. In practice, many security teams discover PLC tampering only after operators notice a process anomaly, rather than through intentional validation of control integrity.

How It Works in Practice

Effective validation uses independent evidence, not a single trust signal. Teams typically confirm that remote engineering access is brokered through a controlled gateway, compare PLC project files and logic against an approved baseline, and verify that HMI readings match separate process measurements from historians, sensors, or independent instrumentation. If those sources disagree, the issue may be a display compromise, a logic change, or a sensor problem, and each requires a different response.

The strongest programs treat PLC control validation as a layered integrity check. Common techniques include:

• Session path validation, to prove the connection is traversing the intended jump host or OT gateway.
• Configuration drift detection, to identify unauthorized changes in ladder logic, firmware, recipes, or project files.
• Cross-checking, to compare HMI values with historian records, process sensors, or independent telemetry.
• Service and port review, to detect unexpected services on modems, engineering workstations, or OT endpoints.
• Audit logging, so changes can be attributed to a person, tool, or maintenance event.

These checks align with current guidance in IEC 62443-style OT practice and with NIST’s emphasis on integrity, but there is no universal standard for proving “working” PLC control in every plant. NHIMG’s The State of Non-Human Identity Security highlights why this matters operationally: lack of monitoring and logging is a major contributor to identity-related incidents, and similar blind spots exist in OT when change evidence is not independently verified. These controls tend to break down when legacy PLCs, shared engineering accounts, and flat OT networks prevent reliable baselines or trustworthy telemetry.

Common Variations and Edge Cases

Tighter validation often increases operational overhead, requiring organisations to balance confidence against downtime, vendor access friction, and engineering effort. That tradeoff is real in plants with old controllers, proprietary protocols, or maintenance windows measured in minutes rather than hours.

Best practice is evolving for these environments. Some facilities can take cryptographic baselines of project files and enforce signed change workflows; others can only compare hashes, file timestamps, and operator logs. In remote or highly distributed OT sites, a gateway may prove that traffic was proxied, but not that every command was safe or intended. Likewise, a matching HMI value is reassuring, but it is not definitive if the underlying sensor has failed or been spoofed.

Security teams should treat exceptions explicitly. If a vendor modem must remain in place, validate service inventory more often. If a plant uses shared credentials, add stronger change attribution and compensating monitoring. If direct instrumentation is unavailable, document that the assurance level is lower and avoid overstating control effectiveness. NHIMG’s research shows many organisations still lack full visibility into connected third parties, which makes “working” controls hard to prove when external access is part of the OT model.

Related resources from NHI Mgmt Group

• How do security teams know whether privacy controls are actually working?
• How do security teams know whether chatbot controls are actually working?
• How do security teams know whether password reset controls are actually working?
• How do security teams know whether their ISO 27001 controls are actually working?