Subscribe to the Non-Human & AI Identity Journal

Who is accountable when machine identity controls fail in critical infrastructure?

Accountability should sit with the teams that own the device estate, the identity lifecycle, and the operational risk of the connected systems. Compliance frameworks can require stronger authentication, but governance only works when ownership is explicit and audit-ready. If no one owns revocation and trust decisions, the control will drift.

Why Accountability Breaks Down When Machine Identity Controls Fail

Critical infrastructure fails fast when machine identity ownership is vague. Devices, service accounts, API keys, and automation tokens often sit between IT, operations, security, and engineering, so no single team feels responsible for revocation, rotation, or trust decisions. That gap matters because compliance may demand stronger authentication, but accountability is what makes the control actually work.

NHIMG research shows the scale of the problem: only 20% of organisations have formal offboarding and revocation processes for API keys, while 80% of identity breaches involve compromised non-human identities. The Ultimate Guide to NHIs makes clear that weak lifecycle ownership is not a niche issue, it is a structural one. In critical infrastructure, that weakness can translate directly into unsafe operations, service disruption, or uncontrolled access paths. External guidance from CISA cyber threat advisories reinforces a simple principle: threats persist where asset ownership and response responsibilities are unclear.

The practical failure is usually not a missing policy. It is a missing owner who can act before a credential, certificate, or device trust relationship becomes an incident. In practice, many security teams encounter the breach only after the revocation path has already been proven absent.

What Accountability Looks Like in Operational Practice

Accountability needs to be mapped to the people who can actually change the system. That usually means the device estate owner, the identity lifecycle owner, and the operational risk owner each have a defined role, with escalation paths that work during outages, maintenance windows, and emergency changes. For infrastructure environments, ownership should be explicit in asset inventories and in identity registers, not buried in shared ticket queues.

Current guidance suggests three operational controls matter most:

  • Named ownership for every machine identity, including service accounts, certificates, and automation secrets.
  • Documented revocation authority, so a team can disable access without waiting for committee review.
  • Audit-ready lifecycle controls for issuance, rotation, and offboarding, with evidence tied to each control owner.

This is where the NHI lifecycle model becomes practical. The Ultimate Guide to NHIs — Standards is useful because it ties governance to operational action, not just policy language. Where teams are dealing with high-change infrastructure, the right question is not only who approved access, but who can revoke it within minutes if trust is broken. That aligns with broader identity governance expectations in the EU NIS2 Directive, which pushes organisations toward clear responsibility and resilience outcomes.

NHIMG’s 52 NHI Breaches Analysis also shows a recurring pattern: incidents escalate when machine credentials outlive the teams that created them. These controls tend to break down when infrastructure is shared across business units because ownership gets fragmented faster than the identity estate can be inventoried.

Where the Standard Answer Breaks Down

Tighter accountability often increases operational overhead, requiring organisations to balance faster automation against stronger review and emergency access controls. In mature environments, that tradeoff is manageable. In highly distributed or outsourced estates, it becomes harder because the team that runs the workload may not control the identity system that issues trust.

The edge cases are usually the ones that matter most. Legacy OT, third-party managed platforms, and hybrid cloud services may have identities that cannot be rotated on a human-friendly schedule or revoked through a single console. In those environments, best practice is evolving, and there is no universal standard for this yet. Some teams are moving toward policy-backed ownership and exception registers, but that only works if exceptions are time-bound and reviewed.

Another common failure mode is shared responsibility without shared evidence. If platform teams run the infrastructure, security owns the policy, and operations owns uptime, accountability can still collapse unless one named owner can prove who may issue, rotate, and revoke machine trust. The most reliable programmes pair explicit RACI assignments with continuous inventory and short credential lifetimes. The warning signs are consistent: if no one can answer who revoked the last compromised key, the control is already weaker than the policy says.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.

Framework Control / Reference Relevance
OWASP Non-Human Identity Top 10 NHI-03 Revocation and rotation failures are central to machine identity accountability.
NIST CSF 2.0 ID.AM-1 Asset ownership is required before identity controls can be enforced reliably.
NIST AI RMF Accountability for autonomous or automated systems must be defined across the full lifecycle.

Establish governance, traceability, and human accountability for machine actions and trust decisions.