How to Find Orphaned SaaS Accounts After Offboarding

Most companies assume offboarding is complete the moment someone disappears from Okta, Google Workspace, or the HR system.

In reality, that is usually where the problems start.

An employee leaves. Their SSO access is disabled. The IT ticket gets marked complete. Everyone moves on. But weeks later, that same user still exists inside Salesforce. Or GitHub. Or Atlassian. Or the AI coding tool engineering adopted six months ago without telling anyone. The account is no longer tied to an active employee lifecycle. Nobody owns it anymore. Nobody reviews it. Nobody notices it.

That is an orphaned account. And in modern SaaS environments, orphaned accounts are everywhere.

Traditional identity systems were built around authentication. Modern environments are built around distributed access. Those are not the same thing anymore. The result is that companies often disable the front door login while leaving the actual authority behind.

Why Orphaned Accounts Happen

The root issue is simple: most identity programs still think about users through the lens of the IdP. If someone is disabled in Okta or Entra, the assumption is that access is gone.

But applications increasingly maintain their own local access models:

• App-specific roles
• Local administrators
• OAuth grants
• API tokens
• Service accounts
• Shared accounts
• AI agents
• Workspace-level permissions
• Embedded automation identities

Disabling SSO only guarantees one thing: the user probably cannot authenticate through the normal login flow anymore.

It does not guarantee:

• The SaaS account was deleted
• API keys were revoked
• OAuth grants were removed
• Local credentials were disabled
• Tokens expired
• Shared accounts were rotated
• Service ownership transferred
• SCIM deprovisioning succeeded
• Manual access was removed

And in many organizations, provisioning coverage is incomplete from the beginning.

Some systems support SCIM. Some are partially automated. Some rely entirely on manual administration. Some were connected years ago and nobody trusts the sync anymore.

Over time, access drifts away from the intended lifecycle model. That is how orphaned accounts accumulate.

The Dangerous Part Is Usually Invisible

Most orphaned accounts do not initially look dangerous.

They often appear as:

• “Inactive” SaaS users
• Old contractor accounts
• Shared engineering logins
• Service identities with no clear owner
• Legacy admin accounts
• OAuth-connected applications nobody remembers approving
• Bot accounts still holding Slack or Jira permissions
• AI agents connected through delegated OAuth

The dangerous part is usually not the existence of the identity itself. It is the hidden authority attached to it. A stale Canva account is different from a stale Salesforce account with export permissions. A dormant Zoom account is different from a forgotten GitHub bot with write access to production repositories. A service account attached to a deprecated workflow may still hold administrative access across dozens of systems.

Most organizations do not have a continuously updated model of that blast radius.They know the account exists. They do not know what the account can actually reach.

Why Traditional Offboarding Audits Miss This

A surprising number of offboarding validations still follow the same pattern:

1. Disable the user in the IdP
2. Confirm mailbox forwarding
3. Remove a few group memberships
4. Check several critical applications manually
5. Close the ticket

That process worked better when applications delegated most identity decisions back to Active Directory. Modern SaaS ecosystems do not behave that way anymore. Applications increasingly maintain their own independent authority models. The IdP becomes one signal among many instead of the single source of truth. That means orphaned access often survives long after the employee lifecycle ends.

Organizations typically discover these accounts during:

• Security incidents
• Audit preparation
• M&A diligence
• Breach investigations
• Privilege reviews
• Shadow IT cleanups

Rarely during the original offboarding itself.

What You Actually Need to Look For

Finding orphaned accounts is not just a directory synchronization problem. It is a correlation problem.

You are trying to answer a harder question:

What identities still exist that no longer map cleanly to a living employee, contractor, approved service owner, or sanctioned business process?

That requires visibility across:

• HR systems
• Identity providers
• SaaS applications
• Cloud infrastructure
• OAuth grants
• API inventories
• Service accounts
• Automation tooling
• AI agents and delegated systems

The useful signals tend to look like this.

Accounts With No Active HR Identity

This is the obvious starting point. The SaaS account still exists, but the employee no longer exists in the HR system or directory. These accounts are usually easy to identify.

The harder question is whether they still hold meaningful permissions. A dormant user with no access may be operational clutter. A dormant user with export privileges, billing permissions, or production access is a security problem.

Accounts With No Recent Authentication

Dormant access is often forgotten access. An account that has not authenticated in 90 or 180 days but still retains administrative authority should immediately stand out.

Many organizations discover entire layers of stale access simply by comparing privilege levels against authentication activity. The important part is understanding that inactivity alone is not enough. Some non-human identities rarely authenticate interactively but still operate continuously through APIs and automation.

That is why access context matters more than login events alone.

Accounts Owned by Disabled Managers or Teams

This happens constantly in shared tooling environments. A service account technically exists for a business workflow, but the original owner left years ago. Nobody transferred accountability. Nobody revalidated the permissions. The identity survives because the workflow still functions. Over time, ownership becomes ambiguous. And once ownership becomes ambiguous, governance usually disappears with it.

OAuth Grants With No Clear Human Owner

OAuth-based SaaS access is becoming one of the biggest sources of orphaned authority. An employee authorizes an application against Google or Microsoft. The employee later leaves. The delegated OAuth relationship continues operating because the third-party application itself is still active. The identity disappears. The delegated authority remains.

This becomes even harder to manage as organizations adopt AI agents, copilots, browser automation tools, and embedded SaaS integrations that request broad delegated permissions.

The approval event was temporary. The access often becomes permanent.

SaaS Accounts That Drifted Away From Provisioning

A surprising number of applications operate partially outside automated provisioning. Emergency admins get created manually. Contractors are added directly inside applications. Teams bypass the IdP because onboarding needed to happen quickly. An engineer generates an API token to solve an operational problem and nobody rotates it afterward. Over time, these identities stop matching the intended RBAC model entirely.

The organization still believes provisioning is automated. In practice, large portions of the environment drift into manual exception handling. That drift is where orphaned access tends to hide.

The Hardest Part: False Positives

Not every orphaned-looking account is actually bad. Some systems legitimately require persistent service identities. Some automation workflows intentionally survive employee turnover. Some integrations are designed to operate independently of human lifecycles.

The real challenge is distinguishing: approved persistence from accidental persistence

Most organizations do not formally model that difference. That is why orphaned account cleanup projects often become operationally sensitive. Teams worry about breaking workflows nobody fully understands anymore. And honestly, that fear is usually justified. Because by the time orphaned access becomes visible, the surrounding business context has often been lost.

What Mature Organizations Eventually Realize

The real problem is not stale users.

The real problem is the lack of a continuously updated model of effective access across the environment.

Once organizations move beyond a single IdP-centric world, identity becomes fragmented across:

• SaaS applications
• OAuth relationships
• APIs
• Service accounts
• Delegated systems
• AI agents
• Cloud infrastructure
• Manual exceptions
• Application-local roles

Offboarding stops being a single transactional event.

It becomes a continuous reconciliation process between:

• what should exist
• what actually exists
• what is temporarily acceptable
• what has silently drifted into risk

That gap between policy and reality is where orphaned accounts live. And in modern SaaS environments, that gap grows surprisingly fast. Effective offboarding is no longer just disabling an employee account. It is understanding the full surface area of authority that identity accumulated over time, including delegated access, non-human identities, OAuth relationships, automation workflows, and application-local permissions.

Because in modern environments, access rarely disappears cleanly on its own. It lingers. Quietly. Until someone finally notices it.