Who is accountable for identity security in critical infrastructure resilience programs?

Accountability sits with the organisation that operates the infrastructure, not with the regulator or technology supplier. Security, infrastructure, IAM, risk, and compliance leaders should share responsibility for defining access policy, reviewing privileged exposure, and validating that controls support regulatory obligations. The governance model must be explicit, because resilience depends on clear ownership of identity decisions.

Why This Matters for Security Teams

In critical infrastructure, identity security is not a back-office IAM issue. It is part of operational resilience, because compromised service accounts, API keys, and operator credentials can interrupt availability, distort telemetry, and create unsafe privilege paths across OT, IT, and cloud control planes. The organisation that runs the infrastructure owns that risk, even when regulators set the expectations and suppliers provide the tooling.

That distinction matters because accountability without execution becomes a gap. NHI Management Group’s Ultimate Guide to NHIs shows how widespread the exposure is: only 5.7% of organisations have full visibility into their service accounts, and 97% of NHIs carry excessive privileges. Those numbers explain why resilience programs need named owners for identity decisions, not just policy statements. External guidance such as NIST SP 800-53 Rev 5 Security and Privacy Controls reinforces that access control, monitoring, and accountability must be implemented and reviewed inside the operating organisation.

In practice, many security teams discover identity accountability gaps only after a privileged credential is abused or a supplier integration has already widened the attack surface.

How It Works in Practice

Accountability should be assigned across four operational layers: business owner, security owner, platform owner, and control approver. The infrastructure operator defines the access policy, the security team validates privilege and logging, the IAM team enforces lifecycle controls, and the risk or compliance function verifies that the control set supports regulatory obligations. This is especially important for NHI and agentic workloads, where access is often machine-to-machine, time-bound, and difficult to review after the fact.

For critical infrastructure resilience, the practical model is to treat identity as part of the control plane. That means every privileged human account, service account, OAuth grant, API key, certificate, and autonomous agent identity should have a named owner, a purpose, a renewal path, and a revocation trigger. Standards-based controls from CISA cyber threat advisories and sector-specific requirements like the EU NIS2 Directive point in the same direction: resilience depends on demonstrable control ownership, incident readiness, and timely remediation.

• Map each identity type to a control owner, not just a technical administrator.
• Separate policy approval from policy enforcement so the same team is not self-authorising access.
• Require periodic review of privileged exposure, especially for third-party integrations and dormant credentials.
• Use logging and attestation to prove who approved access, when it was granted, and when it was revoked.

NHI Management Group’s 52 NHI Breaches Analysis is a useful reminder that identity failures often spread through stale credentials and over-privileged accounts, not through a single broken firewall. These controls tend to break down when OT operations, cloud platforms, and third-party managed services all share the same privileged identity paths because no single team owns the full lifecycle.

Common Variations and Edge Cases

Tighter identity control often increases operational overhead, requiring organisations to balance resilience gains against uptime, vendor dependency, and emergency-access needs. Best practice is evolving, and there is no universal standard for exactly where accountability should sit in every hybrid OT environment.

In highly regulated plants, accountability may be split by domain, with one team owning operator access, another owning machine identities, and a third owning supplier access. In outsourced service models, the supplier may administer tooling, but the infrastructure operator still remains accountable for the risk decision and the residual exposure. For autonomous systems and AI-driven operations, this becomes even more important because the identity may act outside normal human workflows, which is why guidance from ENISA Threat Landscape and NIST-style control families should be interpreted through an operational resilience lens rather than a pure IT audit lens.

Where organisations get into trouble is assuming that a supplier’s contract or a regulator’s rule set transfers accountability away from the operator. It does not. The operator still needs evidence that access was approved, monitored, rotated, and revoked in line with resilience objectives, especially when third-party integrations and shared credentials are involved.

Related resources from NHI Mgmt Group

• How should security teams apply identity security to critical infrastructure resilience and compliance?
• Who should be accountable for moving identity security from tactical projects to a business programme?
• What do security teams get wrong about cyber resilience in identity-heavy environments?
• Who should be accountable when platform claims do not match the actual identity security architecture?