How should teams detect unauthorized change in OT devices?

What counts as unauthorised change in an OT device?

Unauthorised change is any deviation in the device’s own trusted state, not just a suspicious packet pattern. That includes firmware replacement, configuration drift, logic edits, mode changes, altered setpoints, and unexpected changes to security-relevant parameters. The key question is whether the device is still in the state that engineering and operations approved.

That distinction matters because OT devices often keep running even after local tampering. A controller can accept a new program, a switch can silently change configuration, and a field device can drift away from the documented baseline without a network alert ever firing.

In practice, detection works best when you compare the current device state to a known-good baseline captured from trusted sources. That baseline should include the exact firmware image or hash, configuration export, approved logic or program version, operating mode, and any process setpoints that affect safety or availability.

How should teams compare device state to a trusted baseline?

The most reliable approach is to combine authenticated polling with configuration and firmware attestation, then correlate the results with asset inventory and change records. Authenticated access lets you query the device directly rather than inferring state from traffic, while signed configuration records and inventory data help you tell legitimate maintenance from unauthorised alteration.

Where possible, use read-only checks that are safe for the control environment. The goal is to verify state without introducing instability, especially on older controllers or fragile field equipment. If the device cannot support strong attestation, then a mix of scheduled polling, secure backups, and disciplined change review becomes the next best control.

Baseline quality matters as much as the comparison method. If the approved state is stale, incomplete, or not tied to actual operational changes, teams will either miss real tampering or generate constant false alarms. Baselines should be refreshed after planned engineering work, vendor service actions, and emergency interventions.

Why packet inspection is not enough for OT integrity monitoring

Packet inspection is useful for spotting some command and protocol anomalies, but it cannot fully prove that the device itself has not been altered. Local changes may happen through direct console access, removable media, engineering workstations, or embedded management functions that never produce a clear network signature.

That is why integrity monitoring in OT has to focus on device state, not just network behaviour. If you only watch the wire, you may miss unauthorised downloads, hidden logic changes, or a firmware swap that preserves normal-looking traffic while changing how the device actually behaves.

A stronger model is to treat the network as one evidence source among several, then confirm the device’s present state against inventory, engineering approvals, and version control. When those sources disagree, the discrepancy itself is the alert, even if the traffic looks normal.

Risk and Threat Considerations

Unauthorised change in OT devices can create both safety and availability exposure because the device may continue operating with altered logic, configuration, or setpoints. That makes compromise harder to notice and increases the chance that a malicious or accidental change persists long enough to affect process behaviour.

Failure mechanism: Attackers or insiders can alter the controller locally, reuse valid access paths, or push a new image that bypasses network-based detection, leaving the device functional but untrusted.

Impact: The result can be hidden process manipulation, unsafe operating conditions, unexpected downtime, or delayed recovery because responders are looking at traffic instead of device state.

Practitioner Guidance

What to verify: Verify the exact firmware, logic, configuration and mode that are actually running, not just the last approved change ticket. If the device cannot provide strong attestation, treat periodic authenticated reads plus signed backups as a minimum evidentiary standard.

What to prioritise: Prioritise the highest-consequence devices first, especially controllers or safety-adjacent assets where a silent change would have the largest operational impact. Also prioritise any device whose inventory entry, change record, or observed state does not line up cleanly.

Practitioner takeaway: The best OT change detection strategy is evidence triangulation, compare the device, the baseline and the change record, and treat any mismatch as a security event until proven otherwise.

Related resources from NHI Mgmt Group

• Detect
• How do security teams detect unauthorized change when the baseline is moving?
• Why do BYOD devices change the risk profile of passwordless authentication?
• Why do OT devices complicate certificate governance more than standard IT assets?