Change-based detection compares the current device instruction set with a trusted baseline and alerts on unauthorised edits, new logic blocks, or altered control parameters. On industrial controllers, it works by monitoring program uploads, configuration writes, and command sequences so operators can spot tampering, logic drift, or unsafe maintenance changes.
How change-based detection is anchored on a trusted baseline
Change-based detection only works if the baseline is stable, complete, and tied to the exact controller image you expect to see. The baseline is usually captured from a known-good program, then compared against live controller state so even small logic edits, added blocks, or parameter shifts stand out.
On industrial controllers, that comparison has to account for engineering workflows such as controlled uploads, maintenance windows, and legitimate program revisions. Without that operational context, a detector can confuse expected change with tampering or miss a malicious edit hidden inside an approved update.
What matters most is that the detector is watching the controller's executable logic and configuration state, not just file hashes or generic host drift. That is why OT-focused guidance such as NIST SP 800-82 Rev 3 is useful here, because it frames controller integrity around OT architectures and the realities of industrial operations.
What the detector watches on PLCs and similar controllers
In practice, change-based detection looks for specific events that imply the controller has been altered: program uploads, configuration writes, block additions or removals, and changes to control parameters. It may also compare the running logic against the approved engineering project or golden image stored offline.
That event-based view matters because many unsafe changes do not look dramatic from a business perspective. A single altered setpoint, a modified permissive, or a removed interlock can create physical risk even when the controller still appears healthy and responsive.
Industrial defenders often pair this with authoritative asset and advisory sources such as CISA Industrial Control Systems, since the practical question is not only whether a change happened, but whether it was expected, approved, and safe for the process.
Why change detection catches tampering, drift, and unsafe maintenance
The main value of change-based detection is that it highlights deviations that operators may not notice during normal production. Unauthorised edits can indicate tampering, while repeated small modifications can reveal logic drift, weak change control, or maintenance work that never went through proper review.
It is also useful after incident response or recovery. If a controller was touched during troubleshooting, restoration, or vendor support, the detector helps confirm whether the live logic still matches the approved baseline before the process is returned to full operation.
Defenders can extend this with control validation and adversary emulation using MITRE D3FEND, because the core defensive task is to verify that the monitoring logic would actually catch the kinds of unauthorized edits and configuration abuse that matter in OT environments.
Risk and Threat Considerations
Industrial controllers are high-value targets because small changes can create large downstream effects in safety, availability, and process integrity. An attacker or careless maintainer may use a legitimate programming path to alter logic, so the control problem is often not simple malware detection, but distinguishing authorised engineering from unsafe or malicious change.
Failure mechanism: The detector misses the change because the baseline is stale, the upload path is not monitored, or the alerting rules ignore routine-looking parameter edits and maintenance activity.
Impact: Operators can continue running with altered interlocks, unsafe setpoints, or hidden logic changes, which can lead to process upset, downtime, or unsafe physical conditions before anyone realises the controller has diverged.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | DE.CM-09 — Continuous Monitoring for Security Events | Change detection depends on continuous monitoring of controller state and edits. |
| PR.DS-10 — Confidentiality, Integrity and Availability of Data | Baseline comparison is an integrity control over controller logic and parameters. | |
| Recommendation — Monitor controller changes continuously and alert on unauthorised logic or configuration drift. Protect controller logic integrity by comparing live state against an approved baseline. | ||
| NIST SP 800-53 Rev 5 | CM-3 — Configuration Change Control | Industrial controller edits must be approved, tracked and reviewed as controlled configuration changes. |
| SI-7 — Software, Firmware, and Information Integrity | The subject is detecting unauthorized alteration of controller logic and parameters. | |
| AU-6 — Audit Record Review, Analysis, and Reporting | Change-based detection relies on reviewing program uploads and command sequences as evidence. | |
| Recommendation — Enforce formal approval and review for controller logic and configuration changes. Validate controller integrity and alert when logic or firmware deviates from the trusted baseline. Review controller audit events for uploads, writes and other change indicators. | ||
Practitioner Guidance
What to verify: Confirm that your baseline is an approved golden image, not just a recent backup. The most useful validation is whether the detector can identify both full program replacement and subtle logic drift in the same controller family.
Decision rule: If a controller change comes from a maintenance workflow, treat it as trusted only after the source, timestamp, and approver are reconciled with the engineering record. If you cannot tie the change to an authorised event, treat it as an integrity alert first and a change ticket second.
Practitioner takeaway: Change-based detection is most effective when it is treated as integrity monitoring for the control logic itself, with strong baselines, monitored upload paths, and a clear approval trail for every legitimate edit.
Related resources from NHI Mgmt Group
- Why do certificate-based logins change identity governance work?
- Why does browser-based work change IAM and PAM governance?
- Why do browser-based work models change identity and session risk?
- How should enterprises enforce security and governance controls in browser-based work without forcing users to change browsers?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on November 9, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org