Left Behind: How Dormant SaaS Accounts Become the Skeleton Keys to Your Corporate Infrastructure

Somewhere inside your company's cloud environment, there is almost certainly an account that no one is watching. Its owner accepted a job offer elsewhere, or was laid off in a restructuring, or simply moved to a different department and was provisioned fresh credentials. The old account was never deactivated. It still holds a valid session token. It still receives notifications. And in the wrong hands, it still opens doors.

This is the quiet crisis at the center of modern enterprise security — not a sophisticated zero-day exploit or an elaborate nation-state campaign, but something far more mundane: the chronic failure to shut off the digital lights when someone leaves the building.

The Scale of the Problem

The average mid-sized American company now runs dozens of Software-as-a-Service platforms simultaneously. Slack, Microsoft Teams, Dropbox, Notion, Asana, Trello, Salesforce, GitHub, Zoom, and Google Workspace are only the most recognizable names on a list that can stretch well past fifty tools in organizations with distributed teams or active project cultures. Each platform represents an independent identity silo — and most of them are provisioned directly by department managers or individual employees rather than centralized IT.

That decentralization is the root of the problem. When a formal IT department provisions an account, there is at least a theoretical process for revoking it. When a marketing manager signs up for a Canva team account using a corporate email address, or a developer spins up a shared Figma workspace, those accounts frequently exist entirely outside the visibility of any security team. According to research from identity security firm Nudge Security, the average enterprise has hundreds of SaaS applications in use — with IT aware of fewer than half of them.

When employees depart, these shadow accounts persist. Credentials remain valid. Files remain accessible. And in many cases, the accounts retain active integrations with other, more sensitive systems.

How Threat Actors Find the Gaps

Attackers pursuing this vector do not typically stumble into orphaned accounts by accident. The discovery process is methodical.

The first avenue is credential harvesting from prior breaches. Dark web forums and dedicated leak repositories contain billions of username-and-password combinations from historical data breaches. Threat actors routinely run automated credential-stuffing campaigns against the login portals of popular SaaS platforms, testing whether former employees reused passwords from accounts that were compromised elsewhere. Because offboarded accounts are no longer monitored — no one is checking for failed login alerts, no one is reviewing access logs — a successful authentication can go entirely unnoticed.

The second avenue is open-source intelligence, or OSINT. LinkedIn alone is a remarkably effective tool for identifying former employees of a target organization. An attacker can enumerate departed staff, cross-reference their professional histories with known breach data, and build a prioritized list of accounts worth testing. Public GitHub repositories sometimes contain hardcoded API keys or OAuth tokens tied to former employees' identities, providing direct access to integrated services without requiring a password at all.

A third, less appreciated avenue involves OAuth and third-party application permissions. Many SaaS platforms allow users to grant external applications persistent access tokens that survive password changes and, crucially, remain active even when the primary account is supposedly inactive. An attacker who obtains one of these tokens — through a phishing campaign targeting a former employee's personal email, for instance — may be able to access corporate data without ever touching the original account credentials.

What Attackers Do Once They Are Inside

The consequences of a successfully compromised orphaned account depend heavily on what that account was connected to — and the answer is often: more than anyone realized.

In documented incident patterns, attackers who gain access to a former employee's Slack account have used it to impersonate that individual in messages to current staff, requesting password resets, file shares, or wire transfers under the guise of a familiar name. The social engineering dimension is significant: a message from a known former colleague carries a degree of implicit trust that a cold phishing email from an unknown sender does not.

Dropbox and Google Drive accounts belonging to departed employees frequently contain sensitive materials — contracts, financial models, customer lists, HR records — that were never formally archived or permissions-restricted. An attacker with read access to these repositories can exfiltrate substantial data without triggering any anomaly detection, because the access pattern looks identical to a legitimate user reviewing their own files.

Perhaps most concerning is the pivot potential. SaaS accounts routinely hold single sign-on credentials or serve as identity providers for other platforms. A compromised Okta or Google Workspace account tied to a former employee can, in some configurations, authenticate into a wide range of downstream applications — effectively handing an attacker a master key assembled from a forgotten lock.

Why Offboarding Fails

The technology to prevent most of this exists. The problem is organizational, not technical.

IT offboarding checklists at many companies remain focused on the obvious: retrieving the laptop, disabling the primary Active Directory or Google Workspace account, revoking VPN access. The long tail of SaaS applications — especially those provisioned outside of IT's purview — simply does not appear on those checklists, because IT does not know those accounts exist.

Human Resources and IT departments frequently operate on misaligned timelines. An employee may give two weeks' notice, yet the formal IT offboarding ticket may not be filed until the final day or, in some cases, days after departure. During that window, credentials remain live.

Start-ups and fast-growing companies are disproportionately exposed. In high-growth environments, the priority is velocity, not governance. SaaS sprawl accumulates rapidly, and the institutional memory of which accounts exist — and who owns them — degrades as teams scale and turn over.

What Organizations and Individuals Can Do

The defensive posture here requires both systemic process changes and technical controls operating in parallel.

For organizations, the starting point is visibility. Security teams should conduct a full SaaS discovery audit — tools such as Nudge Security, Torii, or BetterCloud can automate the enumeration of cloud applications in use across a corporate environment, surfacing accounts that exist outside of IT's formal inventory. That audit should be repeated on a regular schedule, not treated as a one-time exercise.

Offboarding procedures must be expanded to include SaaS account revocation as a formal, tracked checklist item — not a courtesy reminder. Tying SaaS provisioning to a centralized identity provider, enforcing single sign-on wherever platforms support it, and mandating that all third-party app permissions be granted only through managed identities are structural controls that significantly reduce the orphaned-account attack surface.

Access reviews — periodic checks of who holds active credentials to which systems — should be automated and assigned clear ownership. Any account that has not been accessed within a defined threshold (commonly 30 to 90 days) should trigger a review workflow.

For individuals, particularly those who have recently changed employers, the prudent step is to audit personal and professional account linkages before departing. Review which services are connected to your corporate email address, revoke OAuth permissions granted to third-party applications, and ensure that any accounts you created on behalf of the organization are formally handed off or documented — rather than simply left dormant.

The Broader Lesson

The security industry spends considerable energy defending the perimeter — firewalls, endpoint detection, network monitoring. But the orphaned SaaS account problem is a reminder that the perimeter has effectively dissolved. Identity is now the perimeter, and every forgotten account is a crack in it.

Threat actors are patient. They are systematic. And they have learned that the most reliable way into a well-defended organization is often not through the front door at all — but through the one that was left open when someone quietly cleared out their desk.