Who should own OAuth app and service account cleanup?

Why This Matters for Security Teams

OAuth app and service account cleanup is not a hygiene task that can be handed to identity administration alone. It is a control over access persistence, vendor sprawl, and hidden machine-to-machine trust. When ownership is unclear, stale integrations survive app retirements, teams keep tokens alive for convenience, and over-privileged non-human identities remain active long after the business need disappears. That is exactly how dormant access turns into active exposure.

Current guidance aligns cleanup ownership with the application or business system that depends on the connection, while security and identity teams enforce policy, logging, and revocation standards. That split matters because the people closest to the workflow know whether the connection is still needed, but only central control teams can make revocation consistent. The problem is especially visible in third-party OAuth ecosystems, where visibility is often incomplete and approvals are scattered across business units. NHI Management Group research on the Ultimate Guide to NHIs — What are Non-Human Identities shows how frequently organisations struggle with lifecycle control and offboarding discipline, and NIST Cybersecurity Framework 2.0 reinforces the need for clear accountability in access governance. In practice, many security teams encounter cleanup only after a breach review or failed audit, rather than through intentional lifecycle ownership.

How It Works in Practice

The practical model is simple: the business owner of the connected application owns the decision to keep or remove the OAuth app or service account, while identity, platform, or security teams own the control plane that enforces retirement. That means every non-human identity needs a named owner, a purpose, an expiry or review date, and a revocation path. Without those fields, cleanup becomes a guessing game.

Operationally, teams should tie ownership to the system of record for the integration, not to a person who requested it months ago. A good cleanup process usually includes:

• Inventorying all OAuth apps, API clients, and service accounts by business system and dependency.
• Assigning a named application owner and a technical custodian for each connection.
• Reviewing last use, scopes, and privilege level before renewal or retirement.
• Removing credentials, tokens, and grants when the business workflow no longer exists.
• Requiring security or identity approval for exceptions, with a documented expiration date.

For third-party integrations, ownership needs extra scrutiny because the connection may outlive the vendor relationship or the original use case. NHIMG’s Salesloft OAuth token breach is a good reminder that revoked trust is not the same as deleted access, especially when tokens and scopes are not actively managed. Cleanup should also be measured against the broader lessons in the 52 NHI Breaches Analysis, where stale access and weak lifecycle discipline repeatedly appear as contributing factors. These controls tend to break down when ownership is spread across multiple product teams and no single system tracks renewals, approvals, and decommissioning in one workflow.

Common Variations and Edge Cases

Tighter cleanup ownership often increases operational overhead, requiring organisations to balance faster deprovisioning against the friction of more approvals and more inventory maintenance. That tradeoff is real, especially in large environments with many short-lived integrations.

There is no universal standard for every edge case, but current guidance suggests a few patterns. Shared service accounts should still have one accountable business owner, even if multiple teams consume them. Platform-managed automation accounts should belong to the platform team, but the service consuming the account must still sign off on continued need. For vendor-managed OAuth apps, the internal business sponsor remains accountable for whether the connection should exist at all, while security enforces revocation when the sponsor disappears.

Cleanup also becomes difficult when applications are owned by shadow IT, merger-and-acquisition systems, or abandoned workflows that nobody admits to using. In those cases, identity teams can force review and disablement, but they should not be made the default owner of business decisions. The best practice is evolving toward explicit lifecycle ownership, automated review prompts, and exception handling tied to expiry dates rather than permanent approvals. That approach is stronger than informal ticketing, but it still depends on business owners responding on time.

Where this guidance breaks down most often is in highly federated enterprises with dozens of SaaS platforms and no authoritative application inventory, because cleanup cannot be assigned cleanly when nobody can prove who owns the integration.

Related resources from NHI Mgmt Group

• When does a service account become a compliance problem?
• What is the difference between a service account and an OAuth-connected app?
• 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?