How should teams detect compromise in constrained OT devices?

How compromise shows up on constrained OT devices

Constrained OT devices often fail quietly, so compromise detection has to focus on state drift rather than rich host telemetry. The useful question is not whether the device can run an EDR agent, but whether its firmware, configuration, boot sequence and expected behaviour still match a trusted baseline.

That means you look for unauthorised changes to images, startup state, configuration files and signed components, plus operational anomalies such as unexpected reboots, missing logs or an attestation failure. These signals are especially important in environments where the device itself cannot produce much evidence.

For device visibility, an OT inventory that knows the expected firmware, role and maintenance pattern is the reference point for deciding what counts as abnormal. OT asset visibility is what makes a drift check meaningful instead of guesswork.

What to compare when telemetry is thin

The strongest detection method is a structured comparison against known-good state. Firmware hashes, signed baselines, configuration snapshots, bootloader or secure boot status, and protocol-aware asset attributes all give you something to compare against when the device itself is not chatty.

Where possible, use passive network monitoring and asset profiling to corroborate device state from the outside. A well-maintained reference set lets you spot changes that matter, such as a management interface coming up unexpectedly, a service mode being enabled, or a version and configuration combination that no longer matches the approved build.

NIST’s OT guidance treats visibility, segmentation and baselining as core controls for industrial environments, which is why OT compromise detection works best when it is tied to an asset model rather than a one-off scan. NIST SP 800-82 Rev 3 is a useful reference for that baseline-first approach.

For industrial environments specifically, CISA Industrial Control Systems is the right place to anchor advisory-driven monitoring and response expectations.

How to separate normal maintenance from compromise

Constrained OT devices are often changed during scheduled work, so detection fails when teams cannot distinguish sanctioned change from attacker activity. The practical control is change control plus maintenance-window validation, with explicit approval for firmware updates, configuration edits and reboot events.

That also means you need a simple rule for exceptions: if a device changes outside the maintenance window, or if the expected change does not match the change record, treat it as suspicious until proved otherwise. The same applies when attestation fails, logs disappear, or the device reboots without a corresponding service ticket or engineering record.

Where compromise assessment is required, focus first on whether the device has drifted from the approved state and whether the drift could have enabled persistence. Compromise assessment guidance helps teams formalise that evidence-led process before they decide whether to rebuild or contain.

Risk and Threat Considerations

Constrained OT devices are attractive to attackers because weak telemetry makes stealthy persistence harder to notice. A successful compromise can survive for a long time if defenders rely on monitoring that the device cannot actually produce, or if maintenance activity is accepted without corroborating state checks.

Failure mechanism: An attacker changes firmware, configuration or boot state, then hides behind the device’s limited logging and infrequent servicing, so defenders see normal operations while the compromised state persists.

Impact: The device can become a durable foothold for operational disruption, unsafe behaviour, lateral movement or repeated re-entry, especially when compromise also exposes credentials or management access paths.

Practitioner Guidance

What to prioritise: Build the detection model around trusted baselines for firmware, configuration and boot state before you invest in more scanning. On constrained devices, the quality of the baseline usually matters more than the volume of telemetry.

What to verify: Confirm that each device has an approved reference image, an expected reboot pattern, a change record source and a way to validate signing or attestation results. If any of those are missing, treat detection as incomplete rather than “good enough.”

Decision rule: If a device diverges from baseline outside an approved maintenance window, assume compromise or uncontrolled change until engineering can explain it. If you cannot prove integrity, the safer assumption is that the state is untrusted.

Practitioner takeaway: On constrained OT devices, compromise detection is really integrity management, teams that cannot prove trusted state should not assume the device is clean just because it is still running.

Related resources from NHI Mgmt Group

• Detect
• How should teams detect unauthorized change in OT devices?
• Why do static API inventories fail to detect compromise?
• What should IAM teams monitor to detect OAuth token compromise?