Someone leaves the company on a Friday. By Monday, their email account is disabled, and their laptop is back in the pile of loaners waiting to be wiped and reassigned. Standard procedure, handled well, everyone moves on.
What nobody checks is their login to the project management tool they signed up for back in Q3, the cloud storage folder they shared with a contractor eighteen months ago, or the CRM access they still technically have from two roles ago. Three months later, those sessions are still active, sitting quietly, valid, and completely unnoticed.
This is how zombie accounts form at businesses across South Bend, Goshen, and Elkhart, and it’s rarely negligence. It happens because an offboarding process built around corporate IT assets no longer reflects how people actually use software day to day. The average company now runs more than 100 SaaS applications. Most offboarding checklists were written when there were three, and nobody’s gone back to update the checklist as the number quietly climbed into the hundreds.
This post covers what a zombie account actually is, the three apps where this access most reliably never gets removed, and how to run the audit that finds and closes these gaps before they turn into an incident.
What a zombie account actually is
A zombie account is an active login that belongs to someone who no longer works for you. The name is informal. The risk it represents is not.
What makes zombie accounts particularly dangerous is that they’re valid credentials, not stolen ones. There’s nothing to detect in the traditional sense. The access was granted intentionally at the time, and the system has no reason to question it. If a former employee walks back in through that door, whether out of curiosity or worse, or if their credentials get compromised somewhere after they leave, the access is simply there, waiting.
Industry research finds that 50% of organizations have discovered former employees still accessing SaaS applications months after their departure date. For most of those organizations, the discovery was accidental rather than the result of any deliberate audit — someone stumbled onto it, rather than found it on purpose.
The three apps where access never gets removed
Cloud storage and collaboration tools
Google Drive, OneDrive, and Dropbox are where zombie access causes the most immediate damage, because they’re where the actual files live. These platforms are where offboarding tends to get messy fastest. Files may be shared with a departing employee’s personal account rather than their work one. Guest permissions granted during a project may never get cleaned up once the project wraps. Folders set to “anyone with the link” access may still be bookmarked somewhere, working exactly as they did on day one.
The departure triggers a license removal in the identity provider, which feels like the job is done. The shared folders, external links, and personal-account shares go completely untouched, because nobody’s process actually looks there.
Project management and CRM platforms
Tools like Asana, Monday.com, Notion, Jira, HubSpot, and Salesforce are frequently provisioned by team leads rather than IT, which means the standard offboarding checklist has zero visibility into them by design.
A former account executive’s Salesforce login, or a project manager’s Notion workspace with access to company strategy documents, can persist for months without anyone noticing, simply because the people who could remove it never knew it existed in the first place.
The tools IT didn’t know existed
This is the most dangerous category, precisely because nobody’s looking for it. These are the tools employees signed up for using their work email address: a survey platform, an AI writing assistant, a data visualization tool. They were never formally provisioned, and as a direct result, they were never formally revoked either.
When the employee leaves, the account doesn’t get disabled, because nobody knew to disable it. It just sits there, attached to a work email address that may now redirect to an IT catch-all inbox nobody actively monitors.
Running the zombie SaaS audit
Step 1: Build your SaaS inventory
Start by pulling a list of every SaaS application connected to your identity provider — Microsoft Entra ID, Google Workspace Admin, or Okta, if you use one. Cross-reference that list with billing records, browser extension installs, and email domains showing regular login notifications, since a surprising amount of shadow SaaS shows up in exactly those places.
Grip Security’s 2025 SaaS Security Risks Report, analyzing 29 million user accounts, identified 23,987 distinct SaaS applications in use across its customer base. That’s far more than any IT team tracks manually, and of those applications, 90% remained entirely outside IT’s management. For smaller teams without a dedicated identity platform, a 30-minute review of active subscriptions and recent login notifications will surface most of the high-risk tools without needing anything more sophisticated than that.
Step 2: Cross-reference against your offboarding list
Take the last 12 months of departures and check each name against the SaaS inventory you just built. For each application, ask three questions: does this platform have an admin console, can you see who’s still active, and when did this account last log in.
Access that’s months old and belongs to someone who’s left the business is a zombie. Flag it for immediate revocation and document exactly what you find, including when the access was originally granted if that’s traceable at all.
Step 3: Revoke, document, and set a review cadence
Remove the access you found. Record what was discovered and when. Then use the audit itself as the baseline for an offboarding checklist that covers more than just the corporate email and laptop — the two assets every existing checklist already handles well.
Going forward, enforce multi-factor authentication on all remaining active accounts and schedule a SaaS access review every quarter, not just when someone happens to notice something odd. That cadence is what turns a one-time cleanup into a repeatable control instead of a problem that quietly regrows the moment nobody’s watching for it.
What this looks like at a real small business
Picture a 35-person professional services firm in Elkhart, the kind of business we work with regularly. Over four years, three account managers have come and gone. Each one had their own Salesforce login, their own shared folders on the company’s cloud storage, and at least one tool they signed up for independently to make their own job easier — a proposal-writing assistant, a scheduling app, something small that never went through a formal request.
When we ran the audit, two of those three departed employees still had active Salesforce logins, one with full visibility into the current client pipeline. One of the independently signed-up tools was still billing the company’s credit card monthly, a small enough charge that nobody had questioned it on the statement. None of this was the result of carelessness on the business owner’s part. It was simply nobody’s specific job to check, quarter after quarter, until we made it ours for that engagement.
The fix took an afternoon. The exposure it closed had been sitting open for the better part of two years.
Why this connects to your onboarding, not just your exits
Every zombie account started as a legitimate access grant at some point, usually during onboarding or a mid-tenure role change nobody circled back to close out. The businesses that struggle most with this problem tend to be the same ones where SaaS tools get provisioned informally — a team lead sets someone up in Notion or Asana without looping in IT, because it’s faster and the deadline is tomorrow.
Fixing the audit side helps immediately, but the more durable fix is tightening how access gets granted in the first place, so there’s a central record of what any given employee has access to from day one. That record is what makes a future offboarding a 30-minute checklist instead of a forensic exercise reconstructed from credit card statements and best guesses.
A simple rule that solves most of this going forward: any new SaaS tool a team member wants to use gets requested through a single, lightweight form or a quick message to whoever manages IT, rather than signed up for independently with a work email. It takes thirty seconds longer than just clicking sign-up, and that thirty seconds is the entire difference between a tool that’s on your radar and one that isn’t. Businesses that adopt this habit find their next audit takes a fraction of the time, because there’s far less to discover in the first place.
What happens if you skip this
It’s worth being direct about what’s actually at stake here, because “outdated login somewhere” can sound abstract until it’s framed concretely. A former employee with lingering CRM access can see your current pipeline, your pricing, and your client contact details, all of which are useful to a competitor if that person’s new employer happens to be one. A forgotten cloud storage share can expose client files to someone who has no ongoing obligation to protect them, and no employment agreement left binding them to confidentiality in any meaningful practical sense.
And if that former employee’s personal accounts are ever compromised somewhere else entirely, unrelated to your business, any lingering access they still hold into your systems becomes a door an attacker didn’t even have to work to find. It was simply left unlocked, waiting.
None of these scenarios require a sophisticated attacker or an unusual set of circumstances. They require exactly what most businesses already have: normal staff turnover and an offboarding checklist that was never updated to match how many tools the business actually runs on today.
Making offboarding a security process
Zombie accounts cannot be removed if no one’s actually looking for them. The SaaS offboarding audit is the starting point, not a one-and-done project you check off and forget about. Want to close the gaps in your SaaS offboarding process before they turn into something worse? That’s exactly the kind of audit we run for businesses across Michiana, and it usually takes less time than people expect once we know where to start looking.
Frequently Asked Questions
How do zombie accounts differ from ordinary inactive accounts?
A zombie account belongs to someone who has actively left the organization, meaning there’s no legitimate reason for the access to continue at all. An inactive account may belong to a current employee who simply doesn’t log in often. Both carry risk, but zombie accounts carry the added exposure of belonging to someone entirely outside the business.
What is the fastest way to identify zombie accounts?
Start with your identity provider. Microsoft Entra ID, Google Workspace Admin, and Okta all allow you to filter active users and connected applications by account status. Cross-referencing those lists against HR’s exit records from the past 12 months will surface most of the obvious gaps within a few hours.
Do shared or team SaaS accounts create zombie access too?
Yes, and they’re harder to clean up because the original access is difficult to attribute to a single person. As a general rule, shared logins should be replaced with individual accounts wherever a SaaS platform allows it, both for the audit trail and for genuinely clean offboarding later.
How often should a SaaS access audit run?
Quarterly is a reasonable baseline for most small businesses. Any employee exit should also trigger an immediate SaaS access review as part of the offboarding checklist itself, rather than waiting for the next scheduled audit to catch it.
Can a small business realistically track 100+ SaaS apps?
Yes, without needing enterprise-grade tooling. Identity provider reports combined with a quarterly credit card and browser extension review will catch the large majority of accumulated SaaS access for most businesses under 100 employees.
Graham’s Take
Every time we run this audit for a new client in the South Bend or Goshen area, we find at least one account that genuinely surprises them — a tool they forgot existed, an ex-employee still technically able to log in somewhere. It’s never a reflection of poor management. It’s just what happens when a hundred small, reasonable decisions accumulate over a few years without anyone circling back. The audit itself is the easy part once someone actually runs it.
