What should organisations do when a user leaves but their app integrations remain active?

Why This Matters for Security Teams

When a person leaves, the obvious question is not just who still has a login, but what automations, OAuth grants, service accounts, and API tokens remain active in that person’s name. Those artefacts often outlive the employee because they are treated as “app setup” rather than identity. That gap creates a hidden access path that bypasses normal offboarding controls and weakens accountability.

This is especially dangerous in environments where personal productivity tools, chatbots, CI/CD hooks, and low-code workflows are connected to business systems. A revoked human account does not automatically revoke the machine paths that account authorized. NIST’s NIST Cybersecurity Framework 2.0 treats identity lifecycle and access governance as continuous, not one-time tasks, and that same logic applies to non-human identities created by users. NHIMG’s reporting on the DeepSeek breach shows how exposed secrets and embedded credentials can turn into broad downstream exposure once they are left unmanaged.

In practice, many security teams discover these lingering integrations only after an ex-employee account is reused, a token is abused, or an audit exposes access that nobody can confidently explain.

How It Works in Practice

The right response is to make offboarding trigger a full review of all machine access linked to the departing user. That means not only disabling the person’s directory account, but also finding every delegated grant, refresh token, personal API key, webhook, connected app, and automation they created or approved. The key point is that the user’s human identity and the app integration’s non-human identity are related, but they are not the same control object.

A practical offboarding workflow usually includes:

• Enumerate all OAuth consented apps, cloud tokens, and personal automations attached to the user.
• Revoke long-lived credentials first, then replace any required service access with centrally managed integrations.
• Rotate any secrets that the user may have copied into scripts, notebooks, or workflow tools.
• Review ownership of schedulers, bots, and CI jobs so the integration is transferred or retired.
• Log the revocation event as part of identity governance, not as an informal IT cleanup task.

Current guidance suggests treating these integrations as part of the access review process, because many platforms preserve consent even after the original user is disabled. The NHIMG article on the DeepSeek breach is a useful reminder that secret sprawl and hidden exposure can persist long after the original owner is gone. For broader identity governance principles, NIST Cybersecurity Framework 2.0 reinforces that access must be monitored and adjusted across the full identity lifecycle, including termination events.

These controls tend to break down when organisations allow users to self-authorize apps in multiple tenants, because no single system has complete visibility into every consent, token, and side channel.

Common Variations and Edge Cases

Tighter offboarding often increases operational overhead, requiring organisations to balance rapid account shutdown against the time needed to inventory every linked integration. That tradeoff is unavoidable when users have built shadow automation around their own credentials.

There is no universal standard for this yet, but current guidance suggests a few patterns. If the user created a business-critical automation, the integration should be re-homed to a managed service identity rather than left running under a personal grant. If the app is low value or unapproved, revoke it outright. If the integration uses refresh tokens, assume the active session may persist until all token families are invalidated, not just the primary password. If a departing employee was using a personal developer account in a shared environment, the review should also include source repositories, CI secrets, and workstation credential stores.

NHIMG’s DeepSeek breach coverage and the broader secret-management findings in The State of Secrets in AppSec both point to the same operational reality: hidden credentials last longer than people expect, and leaked or orphaned secrets are rarely discovered through normal access reviews. Best practice is evolving toward central ownership, ephemeral access, and automatic revocation tied to HR events, but many organisations still rely on manual cleanup. That is where the gap appears, especially in fast-moving SaaS and developer-tool environments where the original user was also the integration administrator.

Related resources from NHI Mgmt Group

• How can organisations reduce the risk of stale API keys and machine tokens?
• How can organisations keep credentials from becoming a remote-work weak point?
• When should organisations prioritise credential lifecycle management over login convenience?
• Why do revoked user sessions sometimes remain active on other devices?