Who is accountable when unmanaged non-human identities create access risk in an organisation?

Why This Matters for Security Teams

When unmanaged non-human identities create access risk, accountability is not a paperwork issue. It is the difference between a controllable exposure and a persistent one. Service accounts, API keys, and automation tokens often outlive the workload they support, especially when no owner is named to approve creation, review privileges, or retire access. That is why current guidance from the OWASP Non-Human Identity Top 10 and NHIMG’s Ultimate Guide to NHIs treats lifecycle ownership as a core control, not an optional process step.

The practical problem is that unmanaged NHI access tends to spread across teams. Engineering creates it, platform teams store it, application owners depend on it, and security is left to discover it later. That split often means nobody can answer simple questions such as who approved the secret, who last rotated it, or who is allowed to revoke it during an incident. In NHI governance, accountability has to be explicit because identity sprawl is rarely visible until access drift has already widened the blast radius.

In practice, many security teams encounter unmanaged NHI exposure only after a forgotten credential has already been used for lateral movement, rather than through intentional review.

How It Works in Practice

Effective accountability starts by assigning each NHI to a named workload owner and a control owner. The workload owner is accountable for business need and operational use. The identity platform owner is accountable for technical enforcement, including secret storage, rotation, and deprovisioning. The security governance function is accountable for policy, evidence, and exception handling. This division aligns with the governance emphasis in Lifecycle Processes for Managing NHIs and with the identity lifecycle expectations in NIST Cybersecurity Framework 2.0.

In practice, that means every NHI should have a recorded owner, purpose, privilege scope, expiry, and review cadence. Teams should use a joiner-mover-leaver style process for machine identities, even though the “leaver” event may be a pipeline shutdown, deployment replacement, or application retirement rather than a human departure. Where possible, controls should include:

• approval before creation, so the workload and risk are understood up front
• time-bound secrets and certificates, so credentials do not remain valid indefinitely
• continuous inventory, so orphaned identities are found before attackers do
• telemetry on usage, so dormant or abnormal access can be investigated quickly
• formal retirement, so access is revoked when the workload changes or ends

That operational model is consistent with the OWASP Non-Human Identity Top 10 and the control expectations in NIST SP 800-53 Rev 5 Security and Privacy Controls, especially where least privilege, account management, and auditability are concerned. NHIMG research shows the risk is not theoretical: in the Ultimate Guide to NHIs, 97% of NHIs carry excessive privileges, which makes ownership and review the only sustainable way to contain drift.

These controls tend to break down when identities are embedded in legacy applications or CI/CD systems that cannot tolerate rotation, because technical debt turns revocation into a manual exception process.

Common Variations and Edge Cases

Tighter ownership often increases operational overhead, requiring organisations to balance control quality against deployment speed and system complexity. That tradeoff is especially sharp in microservices, multi-cloud estates, and third-party integrations, where a single business function may depend on dozens of machine identities. Best practice is evolving, but there is no universal standard for how granular ownership must be. Some organisations assign ownership at the application level, while others require it at the secret or workload level when the risk is high.

Edge cases also matter. Shared service accounts can be unavoidable in older systems, but they should be treated as temporary exceptions with compensating controls, not as a permanent governance model. Vendor-managed integrations often complicate accountability further, because the external party may create or rotate credentials while the internal organisation still owns the risk. In those cases, contract terms, audit rights, and revocation procedures should be documented clearly. NHIMG’s broader lifecycle guidance in NHI Lifecycle Management Guide and the incident patterns in 52 NHI Breaches Analysis both reinforce the same lesson: if ownership is vague, remediation is usually delayed.

For regulated environments, accountability should also be mapped to audit evidence. That means showing who approved access, who reviewed it, and who can revoke it during an incident. In practice, the strongest programs do not rely on a single team to “own” NHI risk. They define a chain of responsibility so that the workload owner, platform owner, and security function each have a specific action when access becomes unsafe.

Related resources from NHI Mgmt Group

• Why do non-human identities create more audit risk than human accounts?
• Why do non-human identities create audit risk in modern environments?
• Why do non-human identities create compliance risk even when policies exist?
• Who is accountable when AI agents and other non-human identities make access decisions that create risk?