Subscribe to the Non-Human & AI Identity Journal

Who is accountable when a leaver still has access to SaaS apps?

Accountability sits with the organisation that owns offboarding, even if a platform only discovered part of the app estate. If access persists because discovery was incomplete, that is a governance failure in lifecycle management. The fix is to make revocation coverage auditable across every application in scope.

Why This Matters for Security Teams

When a leaver still has access to SaaS apps, the issue is rarely only one missed deprovisioning task. It usually signals that ownership, discovery, and revocation are split across teams without a complete control map. NHI Management Group’s Ultimate Guide to NHIs notes that only 20% of organisations have formal processes for offboarding and revoking API keys, which is a useful warning sign for broader access lifecycle gaps.

Security teams often assume the SaaS platform will enforce the handoff, but platform visibility is not the same as governance. If the app estate is incomplete, or if identity data is not reconciled against HR and IAM sources, leavers can retain access long after termination. That creates exposure across email, file sharing, CRM, support tools, and embedded integrations. The OWASP Non-Human Identity Top 10 is relevant here because the same lifecycle weaknesses that affect service accounts also apply to SaaS-linked identities and tokens. In practice, many security teams encounter persistent access only after an audit, incident, or data leak has already exposed the control failure.

How It Works in Practice

Accountability should sit with the organisation that owns offboarding, even when a third-party app holds the last active credential. That means HR, IAM, security, and application owners must share a revocation workflow, but one team needs explicit operational ownership for closure. Best practice is to treat leaver access as a lifecycle control, not a one-time ticket. The goal is auditable revocation coverage across every SaaS application in scope, including shadow IT and admin consoles.

In practice, that requires four linked controls:

  • authoritative termination events from HR or workforce systems
  • application discovery that includes direct, federated, and API-based access
  • automated deprovisioning for each app and token type
  • verification that access was actually removed, not just requested

This matters because SaaS access is often delegated through SSO, OAuth tokens, shared mailboxes, service accounts, or embedded API keys. A leaver can lose interactive login but still retain access through persistent sessions, delegated tokens, or third-party integrations. The risk is well illustrated by incidents documented in NHI Mgmt Group research such as the 52 NHI Breaches Analysis and the Salesloft OAuth token breach, where credential persistence and incomplete revocation widened impact.

Current guidance suggests measuring offboarding as a closure rate, not a ticket completion rate. That means proving the account is disabled, the token is revoked, the session is invalidated, and the app record is reconciled. These controls tend to break down in environments with many SaaS tenants, decentralized procurement, and app-specific admin rights because no single console can see the full access path.

Common Variations and Edge Cases

Tighter offboarding control often increases operational overhead, requiring organisations to balance revocation speed against app-specific complexity. That tradeoff is especially visible when departments buy their own SaaS tools, contractors use separate identity domains, or business units manage privileged app access outside central IAM.

There is no universal standard for this yet, but current guidance is clear on one point: if the organisation cannot prove revocation, it does not have effective offboarding accountability. A leaver might retain access through a dormant account, a synced directory object, or an OAuth grant that survives password reset. Those cases are common in collaboration suites, support platforms, and low-code tools where access is tied to integrations rather than direct login.

Edge cases also include shared accounts, inherited admin roles, and applications that do not support SCIM or dependable lifecycle APIs. In those environments, security teams should document compensating controls such as periodic access attestations, token inventory checks, and manual closure evidence. NHI Management Group’s Key Challenges and Risks section is a practical reminder that visibility gaps are often the root cause, not malicious intent. The same applies to the BeyondTrust API key breach, where secret handling and revocation discipline were central concerns. When the app estate is fragmented or discovery is incomplete, offboarding breaks down because no team can verify the whole path from identity to access removal.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.

Framework Control / Reference Relevance
OWASP Non-Human Identity Top 10 NHI-01 Leaver access often persists through unmanaged non-human identity lifecycle gaps.
NIST CSF 2.0 PR.AC-4 Offboarding is an access management control that must be enforced and verified.
NIST AI RMF Governance is needed where automated access decisions depend on dynamic, multi-system context.

Inventory all SaaS-linked identities and revoke access on termination with automated closure checks.