Who is accountable when a missing access review affects grid reliability?

Why This Matters for Security Teams

A missing access review is not just an identity hygiene issue when grid reliability is in scope. It can leave privileged service accounts, operator tooling, and remote access paths active long after their business need has changed. In critical infrastructure, that creates a reliability problem as much as a security problem because stale access can alter configuration, delay response, or widen the blast radius of an error. The governance expectation is reinforced by NIST SP 800-53 Rev 5 Security and Privacy Controls, which treats access review and accountability as core control functions.

NHIMG research shows that only 5.7% of organisations have full visibility into their service accounts, which makes review failures especially dangerous because teams often cannot prove what is still active. The issue is larger than one missed certification cycle: once controls span IAM, OT, physical security, and compliance, ownership gaps can persist across multiple systems and shifts. Current guidance suggests that accountability must be explicit, documented, and tied to revocation outcomes, not merely to periodic review completion. In practice, many security teams encounter the failure only after an outage, failed maintenance window, or unexpected privilege use has already exposed the gap.

How It Works in Practice

For grid environments, accountability should be mapped to the control owner who can actually change access, not to the team that merely records the review. That usually means IAM owns the identity workflow, OT operations own operational necessity, physical security owns site and badge dependencies, and compliance tracks evidence and deadlines. The goal is a closed loop: identify the account, validate current need, approve or deny access, revoke when no longer justified, and retain proof of the decision.

Practitioners often use a control matrix that pairs each access path with a named owner, a review cadence, and an escalation path for overdue reviews. A practical model is to distinguish between:

• human access for operators, engineers, and contractors
• non-human identities such as service accounts, schedulers, and integration keys
• emergency or break-glass access that requires post-use review
• physical access dependencies that may indirectly preserve system access

The review itself should test whether the account still has a valid business function, whether privileges match current duties, and whether revocation would affect safety or uptime. That is why NHI governance guidance from Ultimate Guide to NHIs and NHI Lifecycle Management Guide is relevant even in OT-heavy settings: accounts must be visible, owned, and retired on a defined lifecycle. The same logic applies to access review evidence, which should be traceable to a named approver and an execution record. These controls tend to break down when organisations split responsibility across IT and OT silos because no single team can verify end-to-end revocation.

Common Variations and Edge Cases

Tighter review governance often increases operational overhead, requiring organisations to balance assurance against maintenance windows, staffing constraints, and safety rules. In a grid context, the edge cases are usually the ones that matter most: shared vendor accounts, emergency access, inherited permissions from legacy plants, and accounts tied to third-party maintenance. Best practice is evolving, but there is no universal standard for this yet on how to assign a single accountable party when access spans multiple domains.

Where teams disagree, the safer pattern is to separate decision authority from execution authority. The operations owner may decide whether access is still required, while IAM or platform security executes the change and compliance validates the evidence. That prevents the common failure mode where everyone signs the review and nobody removes the access. The OWASP Non-Human Identity Top 10 is useful here because many “missing review” findings are actually non-human identity lifecycle failures, not just recertification misses. NHIMG’s broader research also shows why this matters: 97% of NHIs carry excessive privileges, so an unreviewed account can become a reliability issue quickly. The key exception is break-glass access, which may need to stay enabled by design but must still be time-bound and post-incident reviewed.

Related resources from NHI Mgmt Group

• When should organizations review access controls?
• How should security teams run access reviews for non-human identities?
• How should security teams govern non-human identities that have persistent access?
• When do NHI access reviews create more value than a one-time cleanup?