Who should own the cleanup of dormant non-human identities across cloud, IAM, and application teams?

Who should own dormant NHI cleanup?

Dormant non-human identities are usually not owned cleanly by the team that created them, which is why cleanup is less a technical task than a governance decision. The right owner needs enough authority to verify whether the identity still serves a live business function and enough control to revoke or narrow access without breaking dependent systems. That is typically identity governance or IAM, with cloud and application teams supplying context on runtime dependencies, ownership, and break-glass exceptions.

This matters because dormancy is often a sign of organisational drift rather than simple neglect. Service accounts, API keys, workload identities, and automation credentials may remain valid long after the original use case changes, especially when they are tied to old deployments, shared automation, or undocumented integrations. The cleanup decision therefore has to combine entitlement review, dependency discovery, and revocation planning. NIST SP 800-53 Rev 5 Security and Privacy Controls is a useful external reference for how access control and account lifecycle governance should be treated as formal control work, not ad hoc housekeeping.

In practice, many teams discover dormant identities only after an audit, an incident review, or a platform migration exposes how many accounts no one can confidently explain.

How dormant identities should be cleaned up in practice

Effective cleanup starts with a single accountable owner, but it does not mean a single team works alone. IAM or identity governance should run the inventory, define the stale-account criteria, and coordinate decisions, while cloud and application teams validate whether an identity is still needed for specific workloads, schedules, pipelines, or vendor integrations. The practical goal is to distinguish truly dormant identities from low-frequency but still legitimate automation.

A workable process usually follows a few steps. First, classify identities by type: human-created automation, workload-to-workload access, vendor integration, and legacy service accounts. Then identify signals of activity such as recent authentication, secret rotation events, API calls, deployment hooks, or scheduled job usage. Next, confirm business ownership, because a technically active account can still be functionally obsolete, and a technically quiet account may remain essential for a monthly or quarterly process. Finally, decommission or constrain access in a way that can be reversed if an overlooked dependency appears.

That workflow is easier when the organisation maintains an authoritative inventory of non-human identities, their owners, and their permitted environments. NHIMG research shows that 35.6% of organisations cite consistent access across hybrid and multi-cloud environments as their top non-human identity challenge, which is a strong hint that dormant-account cleanup often fails because ownership and visibility are fragmented. Where identities are tied to infrastructure automation, the team that can answer “what breaks if this disappears?” is often cloud or app operations, but the team that should enforce the final decision is usually IAM.

• Use IAM or identity governance as the decision authority for retirement and recertification.
• Require cloud and application owners to validate runtime dependency before any revocation.
• Track the identity, its secret, its scope, and its last known business purpose together.
• Treat exceptions as time-bound, not permanent, when an identity cannot yet be removed.

These controls tend to break down when ownership is encoded in project history instead of live operational accountability, because no one can confidently approve removal.

Where cleanup breaks down and who has to decide

Tighter cleanup often increases coordination overhead, requiring organisations to balance risk reduction against the effort of proving that an account is truly unused. The hardest edge case is the identity that looks dormant but still supports an infrequent process, a failover path, or a legacy integration hidden inside another team’s pipeline. In those cases, the question is not just “who owns it?” but “who can safely accept the blast radius if it is removed?”

There is no universal standard for assigning every dormant non-human identity to the original creator, the platform team, or the consuming application team. Best practice is evolving toward a shared model: IAM owns the control decision, the application or cloud team owns functional verification, and a system or service owner must be named for every exception. If no business owner can be identified, the identity should be treated as higher risk and queued for containment, not left in place by default.

This is especially important in multi-cloud and hybrid environments, where identities are often duplicated, renamed, or embedded in deployment tooling. NHIMG’s 2024 Non-Human Identity Security Report found that 88.5% of organisations say their non-human IAM practices lag behind or are only on par with human IAM, which helps explain why dormant-account cleanup often stalls at the handoff between teams. The practical ownership rule is simple: the team closest to the business function validates necessity, but the team with governance authority must own the final revoke-or-retain decision.

Practitioner takeaway: Do not assign dormant NHI cleanup to the team that merely created the account; assign it to the team that can prove necessity, coordinate safe revocation, and enforce a time-bound decision when ownership is unclear.

Related resources from NHI Mgmt Group

• How should security teams govern non-human identities in cloud environments?
• How should security teams govern non-human identities at scale?
• How should security teams govern non-human identities for compliance?
• How should security teams govern non-human identities in Salesforce?