Every IT manager who handles offboarding knows the version of this problem that keeps them up at night: someone leaves the organization, the SSO-connected applications get deprovisioned cleanly, and then three months later a security review surfaces an active account in a tool nobody remembered to check. The former employee's Figma account. The analytics platform the marketing team bought on a credit card. The vendor portal that's been running on local credentials since before SSO was even in the picture.

These aren't edge cases. They're the predictable outcome of a gap in how most identity infrastructure is designed: your SSO governs what it knows about, and everything outside that perimeter is invisible to your offboarding process.

Here's how to close that gap.

Why Ghost Accounts Happen

The root cause isn't that IT teams are careless. It's that the tools designed to manage identity — SSO platforms, SCIM provisioning, directory sync — operate on an opt-in model. An application appears in your governance perimeter only after someone formally connects it. Everything else is invisible by design.

The "everything else" in most organizations is substantial. Applications that employees signed up for directly without going through IT procurement. SaaS tools that departments purchased on corporate cards and configured themselves. Legacy systems that predate SSO adoption in the organization. Vendor portals with local authentication that were set up for a specific project and never formally onboarded.

When someone leaves, your offboarding process reaches the applications it knows about. It has no reach into the applications it doesn't know about — and those applications retain active accounts indefinitely, because nothing triggered a deprovisioning action.

Step One: Discover What You Don't Know Exists

Governing applications that aren't connected to your SSO requires knowing they exist in the first place. This means pulling from signal sources that surface application usage regardless of whether it went through formal IT channels.

Browser and desktop activity is the most comprehensive signal. Lightweight agents on managed devices track which URLs employees are launching and which desktop applications they're running. This surfaces browser-based SaaS tools regardless of whether they're SSO-connected, and captures local application usage that never produces an SSO log event.

Financial and expense data surfaces applications that appear in procurement records but not in IT's application catalog. Subscription purchases on corporate cards, vendor invoices, and expense reports all contain application names that can be correlated with user identities.

SSO and HRMS logs catch the partial cases — applications that support "Login with Google" or "Login with Microsoft" but aren't formally configured as SAML or OIDC integrations. These produce authentication events in your IdP logs even though the application isn't formally managed.

The combination of these signals produces an application inventory that reflects what employees are actually using rather than what IT formally manages. This is the starting point for everything else.

Step Two: Build the User Footprint Before Triggering Offboarding

The key difference between offboarding that works and offboarding that misses half the seats is whether the offboarding workflow starts with the right scope. Standard offboarding processes start from the list of formally managed applications and deprovision those. A complete offboarding process starts from the discovered list of every application the departing employee has touched — managed and unmanaged.

When an employee's exit date is set in the HRMS, the offboarding workflow should automatically populate with the full user footprint derived from discovery data: every application where that user has a known account or recorded activity, not just the applications IT formally manages. This is the automation that closes the gap between "we offboarded them" and "we actually revoked all their access."

Connecting the HRMS as the offboarding trigger — so the workflow fires automatically on the exit date rather than requiring manual initiation — eliminates the additional gap of timing. Offboarding that depends on someone manually marking a user as a leaver runs the risk of delay, and delay is when orphaned accounts accumulate.

Step Three: Deprovision Through Whatever Mechanism the Application Supports

Applications without SSO or SCIM still need to be offboarded — the mechanism just has to match what the application supports. There are three tiers of approach depending on the application's technical capabilities.

Direct API integration for applications that have APIs but no pre-built SSO or SCIM connector. If an application exposes API endpoints for user management, a custom API action — a POST or DELETE call to the application's user management endpoint — can execute the deprovisioning without requiring the application to support standard protocols. This is more work to configure than a pre-built connector, but it's fully automated once set up.

Browser-based automation for applications with no API at all. For web-based applications with admin interfaces but no programmable access, deterministic browser automation can navigate to the user management page and execute the deprovisioning steps the way an admin would manually. This is more brittle than API-based integration — UI changes in the application can break the automation — but for browser-accessible legacy tools that aren't going to be modernized, it's a meaningful improvement over pure manual process.

Governed manual tasks for truly legacy on-premises systems and applications where no programmatic access exists. When a revocation decision is made, the system generates a structured work item assigned to the designated application owner, with a deadline and a required completion confirmation. The critical distinction from an informal email is accountability: the offboarding workflow doesn't close until the task is confirmed complete. The completion record is the audit evidence that the action was taken.

Step Four: Continuously Monitor for Orphaned Access

Even with a well-designed offboarding process, some accounts will slip through. Legacy systems with irregular access patterns, applications that weren't captured in discovery at the time of offboarding, accounts created after the initial discovery run — these produce orphaned accounts that persist after the user has left.

Continuous monitoring that cross-references active application accounts against current employment status catches these. When an account exists in an application for a user whose HRMS record shows as terminated or inactive, that's an orphaned account that should be flagged immediately rather than discovered in the next quarterly review.

Dormant account identification extends this to users who are technically still active but whose access patterns suggest the application is no longer being used — accounts where the last login was 60 or more days ago, licenses being paid for that generate no activity. These represent both cost recovery opportunities and unnecessary access surface that can be reduced without waiting for a formal offboarding event.

The Ongoing Discipline

The ghost account problem doesn't get solved once and stay solved. New applications enter your environment continuously — employees adopt tools, departments purchase subscriptions, integrations get set up for specific projects. Each new application that's adopted outside formal IT oversight is a future ghost account waiting to happen.

The operational practice that keeps this under control is maintaining discovery as a continuous function rather than a periodic audit. Discovery data that updates in near-real-time means the offboarding user footprint is always based on current application usage rather than a point-in-time snapshot that may already be outdated. New applications that enter the environment get captured in discovery before the next offboarding event requires covering them.

The organizations that have eliminated the ghost account problem haven't solved it through a one-time cleanup. They've built the discovery and offboarding infrastructure that makes it structurally impossible for accounts to persist beyond the employment relationship — because the process reaches every application the user touched, not just the ones IT was already tracking.