Who is accountable when a leaked non-human identity is used to access production systems?

Why This Matters for Security Teams

When a leaked non-human identity is used in production, the issue is rarely just theft of a secret. It usually exposes a gap in ownership, rotation, approval, and monitoring across the workload that used the credential. That makes accountability operational, not theoretical: the team running the service, the security function governing identity controls, and any platform team that issued or stored the secret all have a role. The OWASP Non-Human Identity Top 10 treats weak lifecycle control and overprivileged machine identities as core risks, not edge cases.

NHIMG’s Ultimate Guide to NHIs shows why this becomes a production problem fast: NHIs outnumber human identities by 25x to 50x in modern enterprises, and only 20% of organisations have formal offboarding and revocation processes for API keys. In practice, many security teams encounter accountable ownership only after a leaked secret has already been used to reach production, rather than through intentional control design.

How It Works in Practice

Accountability should be mapped to the asset and the control plane that manages the identity, then validated before an incident. That means the workload owner is responsible for how the NHI is used, the security team is responsible for policy, detection, and response standards, and the platform owner is responsible for how secrets are issued, stored, or rotated. If the secret is embedded in CI/CD, the pipeline owner also inherits part of the control burden because that system becomes part of the trust boundary.

Practically, that accountability chain should be backed by named owners, a defined approval path for access, and an incident playbook that answers four questions: who rotates the credential, who revokes it, who checks for abuse, and who signs off that the workload is safe to restore. The current guidance in NHI governance is to pair ownership with short-lived credentials, because static secrets create long exposure windows that are hard to defend once leaked. NHIMG’s research also shows why this matters operationally: 52 NHI Breaches Analysis and the The 52 NHI breaches Report both reinforce that machine identities are frequently involved in real incidents.

For control design, teams should align production access with NIST security expectations for identification, access enforcement, logging, and incident response, using NIST SP 800-53 Rev 5 Security and Privacy Controls as the baseline. Where secrets are shared across systems, the ownership model must explicitly identify which team can revoke without waiting for another team’s approval. These controls tend to break down when secrets are duplicated across CI/CD, infrastructure-as-code, and runtime configs because no single team can see or revoke the full exposure path.

Common Variations and Edge Cases

Tighter ownership often increases operational overhead, requiring organisations to balance rapid incident response against the friction of cross-team approvals. That tradeoff becomes more visible when a single NHI is reused across multiple services, cloud accounts, or environments. In those cases, accountability is shared but not diluted: the workload owner still owns the business risk, while platform and security teams own the guardrails that make revocation and monitoring possible.

One common edge case is contractor-managed or vendor-issued credentials. Current guidance suggests that the enterprise consuming the service cannot outsource accountability simply because a vendor generated the secret. Another is emergency access during an outage: if a leaked NHI is used under break-glass conditions, the incident still needs a named approver and a post-event review. This is where the difference between policy and practice matters, especially after incidents like the Cisco DevHub NHI breach, which illustrates how machine identity exposure can become an enterprise-wide issue. Best practice is evolving, but the consistent rule is that no workload should depend on an unowned secret, even temporarily.

For higher-risk systems, teams should treat leaked NHIs as a governance failure, not just an access event, and use the Top 10 NHI Issues to pressure-test whether ownership, rotation, and monitoring are actually enforceable.

Related resources from NHI Mgmt Group

• How should security teams run access reviews for non-human identities?
• How should security teams govern non-human identities that have persistent access?
• How should teams certify non-human identity access without breaking production?
• Who is accountable when a non-human identity deletes production data through a valid token?