Who should own lifecycle cleanup for service accounts and vendor access?

Why This Matters for Security Teams

Lifecycle cleanup is not a clerical task. It is the point where access either returns to the organisation or quietly becomes permanent. Service accounts, vendor integrations, and API keys often outlive the business process that created them, especially when ownership is split between operations, application teams, and procurement. That is why current guidance suggests treating cleanup as a shared control: business ownership confirms the use case still exists, while technical ownership executes revocation, rotation, and review. The problem is amplified by poor visibility. In The 2025 State of NHIs and Secrets in Cybersecurity, Entro Security reported that 91% of former employee tokens remain active after offboarding, which is a strong signal that cleanup failure is not rare.

This matters because NHI sprawl rarely looks like a single breach at first. It looks like one forgotten vendor account, one stale service token, or one integration nobody wants to own after a system change. The practical risk is drift: access keeps working long after the intent disappears. The OWASP Non-Human Identity Top 10 and NHIMG lifecycle guidance both emphasise that non-human access needs explicit governance, not informal handoffs. In practice, many security teams encounter orphaned access only after a vendor renewal, application migration, or offboarding event has already created the gap.

How It Works in Practice

The most effective model assigns business and technical ownership to the same lifecycle, but with different duties. The business owner validates whether the service account or vendor access is still justified. The technical owner proves whether the account is still active, what it can reach, how it authenticates, and whether it can be safely removed or downgraded. That split supports zero standing privilege thinking: access should exist only while the workload or external service has a valid reason to use it.

For service accounts, cleanup usually includes inventory, ownership tagging, secret rotation, dependency checks, and decommissioning rules. For vendor access, it also includes contract triggers, offboarding checkpoints, and verification that shared credentials or delegated tokens are revoked everywhere they were issued. The NHI Lifecycle Management Guide and Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs both reinforce that lifecycle state, not just creation, must be governed.

• Tag each service account or vendor identity with a named business owner and technical owner.
• Require an active ticket or change record before extending access beyond the original use case.
• Revoke credentials, tokens, and keys on a fixed schedule or when the integration is retired.
• Verify that secrets are removed from code, CI/CD systems, vaults, and shared documentation.
• Review third-party access after system migrations, renewals, and offboarding events.

Technical controls should align with least privilege, short-lived credentials, and explicit revalidation, especially where PAM, RBAC, or JIT workflows are already in place. The cleanup model also fits Zero Trust Architecture because trust is continuously re-earned rather than assumed. These controls tend to break down in environments with unmanaged vendor portals and locally stored secrets because revocation is incomplete and ownership is not enforced at the point of change.

Common Variations and Edge Cases

Tighter lifecycle control often increases coordination overhead, requiring organisations to balance faster change delivery against stronger accountability. That tradeoff is real in environments with many integrations, outsourced operations, or legacy systems that cannot support modern identity tooling. Best practice is evolving, but there is no universal standard for this yet: some organisations place cleanup authority in application ownership, while others route it through security operations or IAM teams. The key is that the business owner must be able to justify continued access, and the technical owner must be able to remove it without ambiguity.

Edge cases appear when one service account supports multiple applications, or when a vendor uses shared infrastructure credentials across several customer-facing functions. In those cases, cleanup should not depend on a single team’s memory. It should depend on documented dependencies, a change window, and evidence that no active workflow still requires the identity. NHIMG research shows how costly this drift can be: the Top 10 NHI Issues and Ultimate Guide to NHIs — Key Challenges and Risks highlight the operational impact of excessive privilege and weak visibility.

For third-party access, cleanup should also be contract-aware. A vendor relationship ending on paper does not mean credentials are dead in practice, especially if the vendor maintains backups, automation jobs, or delegated support channels. The Ultimate Guide to NHIs — Static vs Dynamic Secrets is useful here because short-lived secrets reduce the blast radius when cleanup is delayed. Where local tooling or shared admin consoles still dominate, cleanup can fail even with good ownership because revocation is not technically enforced.

Related resources from NHI Mgmt Group

• When do NHI access reviews create more value than a one-time cleanup?
• What problem does ownership attribution solve for service accounts and API keys?
• When do service accounts become a higher risk than ordinary user accounts?
• How should security teams govern Active Directory service accounts?