What Happens When an Employee Leaves and Nobody Owns Device Offboarding

An employee gives notice, works their last two weeks, and hands back a laptop on their final day. HR closes the file. IT disables the email account, maybe. What almost never happens in the same afternoon is a full accounting of every system that laptop and that login could still reach: the shared drive, the CRM, the Slack workspace, the SaaS tools purchased with a personal card and never centrally tracked. Nobody decided to leave those doors open. They stayed open because no single person was ever assigned to close them.

The Offboarding Gap, Defined

Device and account offboarding is the set of steps that fully removes a departing employee's access to company systems and data, not just their building badge or their corporate email. Done completely, it covers identity provider deprovisioning, session and token revocation, device retrieval and wipe, removal from every SaaS application the person touched, rotation of any shared credentials they knew, and a documented record of when each step happened.

Most companies do some of this. Almost none do all of it, and the gap between "some" and "all" is where risk lives. A password reset without session revocation leaves active login tokens working. A disabled email account doesn't touch the marketing tool the person logged into with a personal Google account. A returned laptop that's never wiped still holds cached credentials and local copies of files. Each individual gap looks minor. Together, they add up to a former employee who can, in practice, still get to company data weeks or months after their last day.

Why This Falls Through the Cracks Between 25 and 200 Employees

Below roughly 25 employees, a founder or office manager usually knows every tool the company uses and every account each person has, so offboarding happens by memory and it mostly works. Past 200 employees, most companies have been forced to formalize this, often because a cyber insurance underwriter or a client's vendor security questionnaire demanded proof that access gets revoked on a defined schedule.

The gap opens in between. Headcount is large enough that nobody can hold the full list of who has access to what in their head, but the company hasn't yet hit the size, or the external pressure, that forces a written and enforced offboarding policy. Ownership defaults to whoever happens to be in the room when someone resigns, usually a mix of HR and whoever is doing IT that week. Nobody is wrong to assume offboarding is happening. Nobody is actually confirming that it is.

The problem compounds with how modern companies buy software. A 75-person company commonly runs 60 to 100 SaaS applications, and a meaningful share of those were purchased by an individual department or employee, not provisioned through a central identity system. IT can deprovision what it knows about. It can't deprovision an account it never knew existed, which is exactly the kind of access that survives a standard offboarding checklist untouched.

What the Data Says About Skipping It

The exposure this creates isn't theoretical. NIST's control catalog for federal and commercial information systems, SP 800-53 Revision 5, addresses this directly under control PS-4, Personnel Termination: on termination, an organization must disable system access within an organization-defined time period, terminate or revoke all authenticators and credentials tied to that individual, and retrieve any organizational property. The control exists because deprovisioning is treated as a security control with a required timeline, not a courtesy task that happens whenever someone gets to it.

The cost of getting this wrong shows up clearly in breach research. According to IBM's Cost of a Data Breach Report 2025, the global average cost of a data breach reached $4.44 million, and breaches caused by a malicious insider took the longest of any category to identify and contain, averaging roughly 267 days, nearly nine months, compared to a 241-day mean across all breach types. A former employee's still-active credentials sit in exactly that blind spot: nothing about the access looks unusual to a monitoring system, because it's a real account that was never told to stop working.

Credential-based access remains the way most breaches actually start. Verizon's 2025 Data Breach Investigations Report, based on more than 22,000 security incidents, found credential abuse was the leading initial access vector for the second consecutive year, present in 22% of confirmed breaches. An account that should have been deprovisioned on someone's last day is not a hypothetical entry point, it's one of the most ordinary ones.

The financial scale of insider-related risk, which includes negligent and accidental exposure alongside malicious activity, is substantial on its own. The Ponemon Institute's 2026 Global Cost of Insider Risks Report put the average annual cost of insider risk at $19.5 million in 2025, with credential-related incidents accounting for roughly a fifth of cases and just over half of incidents overall traced to negligence rather than malicious intent. An incomplete offboarding process is negligence in exactly the form that research describes: nobody intended harm, the access just never got closed.

What Complete Offboarding Actually Covers

A device offboarding process that only covers the physical laptop is incomplete by design. The table below reflects what NIST PS-4 and standard identity-security practice treat as the full scope, in the order it should happen.

Step	What It Covers	When
Identity provider disable	Suspend the account at the source, blocking every connected app at once	Day of departure, before end of day
Session and token revocation	Force logout of active sessions so a password change alone can't be bypassed	Same time as disable
Device retrieval and wipe	Collect company-owned hardware and remotely wipe or reset it	Within 1-3 business days
SaaS application audit	Remove access from every app the person used, including ones bought outside IT	Within 1 week
Shared credential rotation	Change any shared logins, service accounts, or passwords the person knew	Same week
Data retrieval and reassignment	Transfer ownership of files, shared drives, and active work to a current employee	Same week
Documentation	Log what was disabled, when, and by whom, for audit purposes	Same day as each action

The order matters. Disabling the identity provider account first closes the widest door immediately, since most modern companies connect the bulk of their tools through single sign-on. Everything after that narrows the remaining exposure: the apps SSO didn't cover, the hardware still holding local data, the passwords one person happened to know.

Who Should Own This

The most common failure isn't a missing step on the checklist. It's that no single role is accountable for running the checklist at all. HR owns the fact that someone is leaving. IT owns the technical ability to revoke access. When those two functions don't have a defined handoff, with a clear trigger and a clear owner for each item, the process depends on someone remembering, and memory is not a control.

This is also where the confusion between "we have an MSP" and "we have offboarding covered" tends to show up. A managed service provider can execute the technical steps, disabling accounts, wiping devices, resetting shared passwords, but an MSP typically acts on a ticket. If HR doesn't file the ticket the day someone resigns, or doesn't know which of the 80 SaaS tools the person actually used, the MSP has nothing to act on. The gap isn't a tooling gap. It's a leadership gap: someone has to own the offboarding policy itself, decide what "complete" means for this specific company, and make sure HR and IT are actually triggering each other correctly. That's a fractional IT leadership function sitting on top of the MSP relationship, not a replacement for it.

Building an Offboarding Process That Doesn't Depend on Memory

The most reliable fix is structural rather than procedural: tie deprovisioning to the HR system of record instead of to a person remembering to send an email. When a termination date is entered in the HRIS, an automated workflow through the identity provider can disable the account, trigger device retrieval, and kick off the SaaS audit without anyone having to initiate each step manually. This closes the single biggest failure mode, the ticket that never gets filed, without adding headcount.

Three things make this work in practice. First, a single system of record for every application in use, kept current through periodic access reviews rather than assembled once and forgotten. Second, single sign-on covering as much of the software stack as realistically possible, since every app outside SSO is an app that has to be manually remembered and manually removed. Third, a written policy that states exactly what happens, in what order, and within what timeframe, so the process survives turnover on the IT and HR side as well as on the employee side.

Frequently Asked Questions

How much does it cost to fix a broken offboarding process?

The direct cost is usually smaller than companies expect: most of the fix is policy, documentation, and connecting systems that already exist, like the HRIS and the identity provider, rather than buying new software. Where cost does show up is in centralizing SaaS access that was purchased outside IT, since bringing 60 to 100 applications under a single sign-on umbrella takes real project time. Weighed against the cost of a single breach involving a former employee's credentials, the offboarding fix is a small line item.

Does this replace what our MSP already does for offboarding?

No. An MSP is typically the team executing the technical steps, disabling an account, wiping a device, resetting a password, and that work continues exactly as it does today. What's usually missing isn't execution, it's ownership of the process itself: deciding what "complete" offboarding means for your company, making sure HR and IT are triggering each other reliably, and auditing that it actually happened every time. That's a leadership layer on top of the MSP relationship, not a substitute for it.

How do we know if our current offboarding process actually works?

Pick three employees who left in the past six months and trace every system they had access to on their first day. If any of those accounts are still active, or nobody can produce a record of when each one was disabled, the process has a gap. This kind of spot-check usually takes an afternoon and reliably surfaces the SaaS tools that never made it onto anyone's list.

What's the single highest-priority fix if we can only do one thing?

Disable the identity provider account the same day someone leaves, and revoke active sessions at the same time, not just the password. For most companies running single sign-on, this one step closes access to the majority of connected applications immediately and buys time to work through the rest of the checklist without the highest-risk exposure sitting open.

How do we get started?

Start with the audit described above: trace a handful of recent departures through every system they touched, and note exactly where the process broke down or took too long. That audit tells you whether the gap is technical, missing automation between the HRIS and identity provider, or organizational, no clear owner triggering the process, and points directly at which fix to prioritize first.