Who should own lifecycle cleanup for access changes?

Why This Matters for Security Teams

Lifecycle cleanup is not a clerical afterthought. When access changes are not removed at the same pace as they are granted, service accounts, API keys, and other NHIs accumulate privilege that no longer matches business need. That creates hidden attack paths, audit failures, and offboarding gaps that are hard to detect until damage is already underway. NHI Management Group’s NHI Lifecycle Management Guide treats removal as a first-class control, not a downstream ticket.

The operational problem is that identity teams often own provisioning tools, while application owners assume someone else will clean up stale access. That split responsibility is where removal fails. The issue is not just human offboarding either; the same pattern applies to role changes, workload decommissioning, rotated integrations, and deprecated pipelines. The OWASP Non-Human Identity Top 10 calls out overprivileged and unmanaged NHIs as a common weakness, and the risk grows when no team is explicitly accountable for the revoke step. In practice, many security teams encounter stale access only after a breach review or audit exception, rather than through intentional lifecycle control.

How It Works in Practice

Best practice is to assign cleanup ownership to the identity governance process that receives the lifecycle event, then make IAM, IGA, PAM, and system owners accountable for executing the removal in their own control plane. That means the source event, usually HR for people and CMDB, workload registry, or service catalog for non-human identities, triggers a workflow that verifies what access exists, what must be removed, and who approves exceptions. The control is only reliable when the revoke step is automated, logged, and time-bound.

For NHIs, the mechanics should be explicit: identify the workload, map its entitlements, revoke unused secrets, disable service accounts, rotate shared tokens, and remove trust relationships from downstream apps. Where possible, use short-lived credentials and workload identity rather than long-lived static secrets. NHI Management Group’s Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs and Ultimate Guide to NHIs — Static vs Dynamic Secrets both reinforce that removal is safer when credentials are ephemeral and centrally governed.

• HR, CMDB, or service catalog emits the lifecycle event.
• IGA determines which identities and entitlements are in scope for removal.
• IAM, PAM, or platform owners execute revocation in their systems of record.
• Application owners validate that the access path is no longer used.
• Security records evidence for audit and exception handling.

Current guidance suggests that cleanup ownership should be written into the control objective, not left to informal handoffs, because shared responsibility without a single remover leads to orphaned access. These controls tend to break down in federated environments with multiple clouds and bespoke service accounts because no single system has a complete view of every entitlement.

Common Variations and Edge Cases

Tighter cleanup control often increases coordination overhead, requiring organisations to balance speed of change against certainty of removal. That tradeoff matters most when the identity owner and the platform owner are different teams, or when a workload is decommissioned before its dependencies are fully discovered. There is no universal standard for this yet, but current guidance favours a named remover for each identity class and a separate approver for exceptions.

One common edge case is shared or legacy access. If multiple applications use the same NHI, removal may break production unless the team first untangles those dependencies. Another is emergency access: break-glass credentials should have their own cleanup path and shorter TTLs, not be folded into ordinary lifecycle tickets. The OWASP model and NHI Management Group’s Top 10 NHI Issues both point to entitlement sprawl as a recurring failure mode, especially when ownership is split across IAM, IGA, and PAM without a clear revoke authority.

For organisations still maturing their process, the practical question is less “who approves access” and more “who can prove it was actually removed.” That is why revocation evidence, periodic recertification, and exception expiry dates matter as much as the original change ticket. If the control cannot show who removed access, when, and in which system, the lifecycle process is not complete.

Related resources from NHI Mgmt Group

• Who should own access changes during role transitions?
• When do NHI access reviews create more value than a one-time cleanup?
• Who should own lifecycle cleanup for service accounts and vendor access?
• Who should own approval decisions for access tickets?