Why is internal monitoring not enough for critical infrastructure access risk?

Internal monitoring tells you that something happened, but it does not prevent overbroad access from existing in the first place. In OT environments, a user who can reach too many systems creates more operational risk than a monitoring dashboard can offset. Access control has to shrink the reachable surface before detection becomes meaningful.

Why This Matters for Security Teams

Internal monitoring is necessary, but it is not a substitute for access minimisation. In critical infrastructure, the larger risk is often not whether activity is visible after the fact, but whether a user, service, or agent can already reach too many systems and too many privileged functions. Once broad access exists, detection only shortens the time to response. It does not reduce blast radius, restore segregation, or prevent unsafe commands from being issued.

That distinction shows up clearly in Ultimate Guide to NHIs and in the broader control framing of NIST Cybersecurity Framework 2.0: detect and respond matters, but it does not replace least privilege, segmentation, and policy enforcement at the point of access. NHI Management Group research also shows why this matters operationally. In The State of Non-Human Identity Security, 37% of organisations cited inadequate monitoring and logging as a cause of NHI-related attacks, alongside 37% for over-privileged accounts.

In practice, many security teams discover the access problem only after a routine operator account, integration, or machine credential has already touched systems it should never have been able to reach.

How It Works in Practice

For critical infrastructure, the right question is not only “can we see it?” but “should this identity be able to do it at all?” Monitoring is valuable for investigations, but access risk is reduced by controlling the reachable surface before an action is attempted. That means pairing network segmentation, role design, and just-in-time access with continuous policy enforcement rather than relying on alerting alone.

A practical approach usually includes three layers. First, define the minimum reachable systems for each user, service account, or non-human identity. Second, constrain privileged actions with explicit approval paths, time-bound access, and separation of duties. Third, monitor for drift so that standing permissions do not quietly expand over time. NHI Management Group’s NHI Lifecycle Management Guide is useful here because lifecycle controls make revocation, rotation, and ownership part of the operating model rather than an afterthought.

• Use least privilege to limit which substations, controllers, or OT application layers an identity can reach.
• Apply just-in-time elevation for maintenance windows instead of permanent admin access.
• Separate human operator access from service or integration access wherever possible.
• Log and alert on privilege changes, but treat alerts as secondary to prevention.

This aligns with incident patterns described in 52 NHI Breaches Analysis, where overreach and weak credential discipline turn routine access into enterprise-wide exposure. These controls tend to break down in legacy OT environments with flat networks and shared accounts because access cannot be cleanly scoped without disrupting operations.

Common Variations and Edge Cases

Tighter access control often increases operational overhead, requiring organisations to balance uptime and maintenance speed against the reduction in blast radius. That tradeoff is real in plants, utilities, and transport environments where vendor support, emergency response, and 24/7 operations make strict preapproval impractical. Current guidance suggests using exception handling, not blanket exceptions, so that urgent access still expires and remains attributable.

There is no universal standard for this yet, especially for hybrid environments that mix OT, cloud, and identity federation. In some cases, monitoring remains the best available compensating control for a short period, but it should be treated as temporary debt, not the target state. The stronger pattern is to combine CISA cyber threat advisories with internal policy so that known attack paths inform which identities need tighter reach constraints.

For organisations with many machine identities, broad access often creeps in through service accounts, integrations, and vendor pathways rather than named users. That is why the operational focus should be on reachability, not only logging. In mature programmes, monitoring answers “what happened,” while access design answers “what could happen.” When those are treated as the same control, critical infrastructure ends up observable but still unnecessarily exposed.

Related resources from NHI Mgmt Group

• When does JIT access create more risk than it reduces?
• Why do manual access processes create risk in critical infrastructure environments?
• How should organisations control access to frontier AI systems without creating surveillance risk?
• Why do VPN-style access models create risk in healthcare?