Who is accountable for securing privileged access and cryptography in critical infrastructure programmes?

Why This Matters for Security Teams

Privileged access and cryptography in critical infrastructure are not administrative chores. They are operational risk controls that protect availability, safety, and regulatory standing. When accountability is vague, teams over-rely on tool owners, while no one owns policy, review, or exception handling. That creates gaps in access recertification, key rotation, and emergency access governance, especially where legacy systems and mixed trust zones remain in place.

This is why current guidance from the OWASP Non-Human Identity Top 10 and ISO/IEC 27001:2022 Information Security Management treats identity, secrets, and governance as board-relevant concerns, not just technical tasks. NHIMG research shows the problem is already operational: in The 2026 Infrastructure Identity Survey, 67% of organisations still rely heavily on static credentials despite the risks they pose to agentic AI deployments. In practice, many security teams encounter accountability only after a privilege abuse event or key leak has already forced an incident review.

How It Works in Practice

Accountability should be assigned by control domain, not by tool ownership. The CISO or security leadership typically owns the policy framework, the IAM lead owns identity lifecycle and access enforcement, infrastructure owners approve operational exceptions, and compliance or risk teams validate that the control model meets regulatory obligations. That structure matches how privileged access management, key management, and NHI governance actually operate across hybrid environments.

For privileged access, the practical question is who authorises standing access, who approves just-in-time elevation, and who reviews use after the fact. For cryptography, the question is who owns key generation, storage, rotation, backup, revocation, and recovery. These responsibilities should be explicit in policy and mapped to control evidence. The Ultimate Guide to NHIs shows why this matters: NHIs outnumber human identities by 25x to 50x in modern enterprises, and 97% carry excessive privileges. That scale means cryptographic control and privilege governance cannot be handled informally.

Most mature programmes define a shared operating model with named owners for access reviews, break-glass use, secrets rotation, certificate renewal, and incident response. They also align with CISA cyber threat advisories and NIST SP 800-53 Rev 5 Security and Privacy Controls so that accountability is measurable through audit evidence, not just organisation charts. These controls tend to break down when legacy operational technology requires shared service accounts because no single team can safely change access without risking service interruption.

Common Variations and Edge Cases

Tighter accountability often increases coordination overhead, requiring organisations to balance faster recovery against stronger approval and evidence requirements. That tradeoff becomes more visible in critical infrastructure, where uptime pressure can tempt teams to leave privileged access and cryptographic keys in place longer than intended.

There is no universal standard for this yet, but current guidance suggests that especially sensitive environments should separate policy ownership from implementation ownership. For example, a platform team may administer a vault, but it should not be the sole authority deciding who may use emergency credentials or how long a signing key remains valid. The same logic applies to outsourced operations: vendors may run the tooling, but the asset owner and risk owner still remain accountable for the control outcome.

Programme leaders should also treat cryptographic modernization as a resilience issue, not just a compliance project. That means deciding who owns certificate lifecycle, hardware security module governance, escrow, and recovery testing before a failover is needed. The Ultimate Guide to NHIs — Key Challenges and Risks reinforces that weak visibility and poor rotation remain common failure points, while the ENISA Threat Landscape shows how identity abuse increasingly intersects with infrastructure disruption. In edge cases such as multi-jurisdiction utilities or safety-critical transport, accountability must be documented in the risk register because regulatory duty, not tool configuration, is what ultimately survives an incident review.

Related resources from NHI Mgmt Group

• Who should be accountable for approving sensitive infrastructure access requests?
• Who should be accountable for coordinating response when a critical infrastructure attack affects public services?
• Who should be accountable when an identity failure affects critical infrastructure or delegated AI access?
• Who is accountable when privileged access compromises AI infrastructure?