What should critical infrastructure teams prioritise over perimeter monitoring?

Why Device-State Integrity Beats Perimeter Monitoring in Critical Infrastructure

Perimeter monitoring is useful for seeing traffic patterns, but it cannot reliably tell you whether the control environment itself has been altered. Device-state integrity shifts the question from “what is entering or leaving?” to “is the controller, host, or field device still running the trusted state we expect?” That is the more important signal when change inside the environment can affect safety, availability, or process control.

For critical infrastructure, the trusted state includes firmware, PLC logic, host binaries, service status, configuration, and approved communications paths. If those elements drift, the environment can remain network-visible while the actual control function is already compromised. Integrity-focused monitoring therefore helps detect conditions that perimeter tools often miss, especially when changes are local, low-noise, or made through legitimate administrative channels.

What Integrity Monitoring Looks For on OT and Control Assets

Effective device-state integrity monitoring compares the live asset state against a known-good baseline. On controllers and field devices, that means watching for unauthorised logic changes, altered ladder code, unexpected firmware revisions, disabled protections, and configuration drift. On hosts, it includes unexpected binaries, modified services, new persistence mechanisms, and changes to security settings that weaken trust in the endpoint.

The practical value is that these checks can surface compromise even when the attacker does not create obvious perimeter anomalies. A remote-access session may appear normal, yet the change on the device can still be harmful. The same is true for vendor maintenance activity, where legitimate access can be abused or simply misused, and the most meaningful signal becomes the change itself rather than the network session that caused it.

For essential services, that distinction matters because a control system can continue to communicate while operating on false assumptions. Integrity monitoring gives operators a way to verify whether the asset is still aligned to approved state, which is often the earliest reliable warning that the process environment has been tampered with.

How to Use Integrity Signals Without Losing Operational Context

Device-state integrity works best when it is tied to an asset inventory, a golden configuration, and a clear approval process for maintenance and emergency change. Teams need to know which device states are expected, which changes are sanctioned, and which exceptions are time-bound. Without that baseline, the control produces noise and the team cannot distinguish a legitimate patch, a troubleshooting action, or an intrusion.

Integrity checks should also be interpreted alongside the device’s role in the process. A change on a historian server is not the same as a change on a PLC controlling an upstream safety function, and the response should reflect that difference. The point is not to treat every deviation as an incident, but to ensure that the most critical devices are never left in an unverified state.

If a team can only monitor one class of signal deeply, device-state integrity is usually the better investment for OT and critical infrastructure than perimeter-centric visibility alone. It gives direct evidence about whether the system still behaves as intended, which is the outcome operators actually need to protect.

Risk and Threat Considerations

Perimeter monitoring can miss the most consequential OT failures because many dangerous changes happen after access has already been obtained. An attacker, contractor error, or maintenance misuse can alter logic, disable services, or change firmware without generating a meaningful boundary alert. Once the trusted state is changed, the environment may keep operating, but it is operating on compromised assumptions.

Failure mechanism: The defender watches traffic at the edge, while the real failure occurs inside the asset, where altered code or configuration changes control behaviour without a corresponding perimeter signature.

Impact: The organisation can lose process integrity, safety assurance, and recovery confidence at the same time, because the device may still appear reachable and healthy while its internal state is no longer trusted.

Practitioner Guidance

What to prioritise: Start with the assets whose logic or configuration can directly affect safety, uptime, or physical process behaviour. That usually means PLCs, controllers, engineering workstations, jump hosts, and the most sensitive supporting servers rather than generic network sensors.

What to verify: Maintain a baseline for firmware, logic, startup services, configuration files, and approved administrative paths, then verify that your monitoring can detect drift quickly enough to matter operationally. If you cannot explain what “good” looks like for a device, you cannot trust the alerting.

Practitioner takeaway: In critical infrastructure, perimeter telemetry is secondary to proving that the device itself still matches the trusted operating state, because that is what determines whether the process remains safe and under control.

Related resources from NHI Mgmt Group

• Guide: Critical Infrastructure Identity Security Guide
• Should organisations prioritise trust-channel monitoring over perimeter-only controls?
• When should organisations prioritise ML monitoring over general infrastructure monitoring?
• When should critical infrastructure teams prioritise credential control over more network tooling?
• Should organisations prioritise insider-risk monitoring over more perimeter controls?