How can security teams detect INCONTROLLER?

What INCONTROLLER monitoring should look for

Detection starts with the control-path, not just the endpoint. INCONTROLLER activity is most visible when security teams baseline normal PLC, engineering workstation, and OT jump point behaviour, then look for commands, sessions, or configuration changes that do not match expected maintenance workflows. Unexpected remote administration, direct controller access, and changes to logic or process settings are the key signals.

Because OT environments are operationally constrained, the useful question is whether the command or session is plausible for that asset at that time. Abnormal source systems, new remote paths into engineering interfaces, and activity that skips established change-control routes are all stronger indicators than a single packet or isolated login event. This is why segmentation and logging matter: they give the detector a reference point for what should not happen.

For teams mapping these behaviours to a broader detection model, MITRE ATT&CK Enterprise Matrix remains a useful reference for turning suspicious access and lateral movement into huntable patterns, and NIST Cybersecurity Framework 2.0 helps structure the detect-and-respond workflow around monitored events and recovery steps.

Which logs and sensors are most useful in OT environments?

The highest-value telemetry is usually the data that shows who touched the controller, from where, and through which trusted path. OT jump hosts, remote access gateways, engineering workstations, historian-to-controller pathways, and firewall logs between business and control networks are the first places to inspect. If the environment supports it, PLC command auditing and engineering tool logs provide the clearest evidence of unauthorised changes.

Teams should also retain protocol-aware visibility where possible, because many industrial protocols expose actions that generic IT logging misses. That includes new sessions to PLCs, write operations, program downloads, mode changes, and repeated command attempts outside a maintenance window. A narrow view of “successful login” is often not enough, because the more important indicator is whether the access path was expected and whether the resulting command was operationally normal.

Use the OT network architecture itself as a detection aid. When a controller is reachable only through a specific jump point or zone boundary, any deviation from that path is easier to spot and triage. This is why segmented environments detect controller abuse better than flat networks: the architecture gives defenders a smaller set of legitimate pathways to compare against.

How should teams separate suspicious activity from routine maintenance?

The best discriminator is change context. Legitimate engineering work tends to be planned, time-bounded, and tied to approved maintenance windows, while malicious or rogue activity often appears as out-of-band access with no matching work order, no prior notice, or no operational reason. Security teams should compare command timing, originating host, operator identity, and target asset against the approved maintenance record before treating the event as benign.

Unexpected program changes are especially important because they can be both a compromise signal and a process-impact signal. Even if the change does not immediately disrupt production, it may indicate that the attacker has reached the stage where controller logic can be altered. Teams should therefore treat unauthorised writes, firmware or logic updates, and unusual engineering-tool use as high-priority investigation triggers, not as low-level noise.

For incident handling discipline, SANS Security Resources is a practical place to align hunt and response playbooks, while FIRST is useful when a confirmed controller compromise needs coordinated incident response and escalation.

Practitioner Guidance

What to prioritise: Start with direct controller access paths, especially any OT jump point, remote access service, or engineering workstation that can write to PLCs. If you can only instrument one area first, instrument the path that can change controller logic, not the path that merely observes it.

What to verify: Confirm that every controller-write event can be tied to an approved operator, an approved window, and an approved source host. If any one of those three is missing, treat the event as suspicious until proven otherwise.

Decision rule: If activity reaches PLCs or engineering interfaces from an untrusted source, prioritise containment and log preservation before you spend time proving intent. In OT, the business impact of a delayed response is often higher than the cost of a false positive.

Practitioner takeaway: The strongest INCONTROLLER detections come from correlating control-path access, not from chasing generic malware indicators; if the command path is abnormal, the activity deserves immediate scrutiny even when the endpoint looks ordinary.

Related resources from NHI Mgmt Group

• Guide: OT Security Guide
• Why are NHIs a critical concern for security teams?
• What steps should security teams take to prevent Shadow AI risks?
• Why is the abuse of NHIs a priority for security teams?
• What is the difference between SAST and DAST for security teams?