Who is accountable when critical infrastructure organisations rely on weak authentication controls?

Why This Matters for Security Teams

In critical infrastructure, weak authentication is rarely just a login problem. It is a control failure that can let operators, contractors, service accounts, and now AI agents cross boundaries they were never meant to cross. Accountability therefore sits with the leadership and risk functions that approve control design, funding, and exceptions, not with the attacker who merely exploits the gap. Guidance in NIST SP 800-53 Rev 5 Security and Privacy Controls reinforces that authentication strength is part of a managed security program, not a standalone technical setting.

For organisations running plants, grids, pipelines, transport systems, or other high-consequence environments, weak authentication often persists because it is embedded in operational convenience, legacy integration, and unclear ownership. That is why NHI Management Group treats this as a governance issue, not a tooling issue. The broader NHI problem is visible in research showing Ultimate Guide to NHIs — Standards report that 97% of NHIs carry excessive privileges, while 90% of IT leaders say proper NHI management is essential to zero trust. In practice, many security teams encounter the failure only after an exposed account, stale token, or over-broad service credential has already been used to move into a critical system.

How It Works in Practice

Accountability should be mapped to the people who can accept risk, define policy, and force remediation. That usually means the board or executive sponsor owns risk acceptance, the CISO or security leadership owns the control standard, infrastructure and application owners own implementation, and compliance or audit verifies that authentication requirements are met and sustained. For human users this means phishing-resistant MFA, privileged access management, and strong session controls. For machine identities and agentic systems it means workload identity, short-lived credentials, and explicit authentication boundaries.

Current guidance suggests aligning control selection to the asset class and its blast radius. For example, a remote operator console may require hardware-backed MFA, while a service account should not rely on a shared password at all. Instead, use workload identity primitives such as SPIFFE or short-lived OIDC tokens, then enforce policy at request time rather than trusting static role assumptions. That is especially important for autonomous systems, because the right question is not only “who logged in?” but “what is this identity allowed to do right now, in this context?”

• Define accountable owners for authentication policy, exceptions, and compensating controls.
• Separate human authentication, service authentication, and agent authentication into different control patterns.
• Use JIT access and ephemeral secrets where elevated access is unavoidable.
• Continuously review logs for dormant accounts, shared credentials, and failed step-up authentication.

Research from The 2026 Infrastructure Identity Survey found that 67% of organisations still rely heavily on static credentials despite the risks they pose to agentic deployments, which is a strong signal that weak authentication is usually a management problem before it becomes an incident. These controls tend to break down in OT and hybrid environments because legacy protocols, vendor access, and uptime requirements make credential rotation and MFA harder to enforce consistently.

Common Variations and Edge Cases

Tighter authentication often increases operational overhead, requiring organisations to balance resilience against latency, vendor supportability, and maintenance windows. That tradeoff is real in critical infrastructure, where forcing a universal MFA pattern can disrupt field operations or break older equipment. Best practice is evolving rather than settled for some of these environments, so teams should avoid pretending that one control template fits every system.

Edge cases usually involve shared engineering stations, third-party maintenance access, emergency break-glass accounts, and machine-to-machine traffic that cannot tolerate interactive prompts. In those cases, the control objective is not “more passwords” but stronger assurance and tighter lifecycle control. Use compensating controls such as network segmentation, session recording, time-boxed access, independent approval for break-glass use, and rapid revocation after maintenance completes. Where autonomous workflows are involved, weak authentication also interacts with unpredictable tool chaining, so a single over-privileged identity can become a fast path into multiple systems. NIST and sector guidance such as CISA cyber threat advisories and the ENISA Threat Landscape both support reducing standing access and hardening identity assurance.

In the most mature programs, accountability is explicit: leadership owns the risk decision, technical teams own enforcement, and no exception survives without expiry, review, and a named approver. In practice, weak authentication becomes a breach enabler when exceptions are normalised and no one is clearly responsible for closing them.

Related resources from NHI Mgmt Group

• Who is accountable for wallet trust when organisations rely on certified identity wallets for access decisions?
• How should organisations modernize authentication in critical infrastructure without breaking operations?
• Who is accountable when machine identity controls fail in critical infrastructure?
• Who is accountable when certificate-based authentication is rolled out but lifecycle controls are weak?