employee offboarding security checklist employee offboarding security checklist

Employee Offboarding Security Checklist: What Actually Gets Missed

In December 2025, South Korean retail giant Coupang disclosed a breach affecting 33.7 million customers, including names, email addresses, physical addresses, and order information. Investigators traced the intrusion to a former employee who retained access to internal systems after leaving the company. Authentication keys, by some reports — exactly the class of credential that gets missed when offboarding focuses on email, laptops, and the identity provider.

Coupang is not an outlier. CISA’s joint advisory AA24-046A documents a state-sponsored intrusion at a U.S. organization where a threat actor authenticated to a victim organization’s internal VPN using a former employee’s credentials, then pivoted to LDAP queries against the domain controller. CISA explicitly warned that attackers “commonly leverage valid accounts, including accounts of former employees that have not been properly removed from the Active Directory.” The pattern repeats often enough that “former-employee credential” is now a named initial-access category in incident reporting.

Most offboarding checklists exist. Most are wrong about what matters. The standard list — disable AD, collect laptop, forward email, revoke VPN — covers maybe 60% of the actual access surface. The other 40% is where breaches happen: OAuth grants, API tokens, shared credentials, SaaS apps that never touched the identity provider, personal cloud syncs holding company data, contractor pathways nobody documented. This piece walks through what a serious offboarding program covers, why it almost always falls short on the same predictable items, and how to fix the upstream problems that make revocation incomplete.

Why Offboarding Failures Keep Showing Up in Breach Reports

The financial weight is significant. Ponemon’s 2025 insider-risk research puts the average annualized cost of insider risk at $17.4 million, up from $15.4 million in 2022, with malicious insider incidents carrying an average breach cost of $4.92M, exceeding the $4.44M global average cost of a data breach. Detection takes time too: the average detection and containment time for insider incidents was 81 days in 2025. Three months is plenty of room for a former employee — or someone using a former employee’s credential — to do damage.

The deeper issue is structural. Offboarding doesn’t fail because IT teams are lazy; it fails because the access surface has fragmented faster than identity governance has matured. A 2025 academic study presented at USENIX SOUPS 2025 by researchers from Fraunhofer FKIE and the University of Bonn examined offboarding processes across 15 organizations and found that practitioners were often unaware of relevant standards from BSI, ISO, and NIST, and that processes varied widely even within companies of comparable size and regulation. The work bluntly titled itself “You go now! No trouble!” — a fair caricature of how many organizations treat the security side of departures.

Three forces compound the problem. First, SaaS sprawl: enterprises now run hundreds of SaaS applications, with industry estimates suggesting the average enterprise uses +500 SaaS applications, with 90% remaining unmanaged. Second, informal provisioning — Slack invites, direct app sign-ups, shared service accounts created during a sprint and never documented. Third, the rise of non-human identities: OAuth tokens, API keys, service accounts, CI/CD credentials, and AI agent permissions that often outlive the human who created them. The offboarding checklist that worked in 2015 was built for a world without any of that.

The Items That Actually Get Missed

Standard checklists capture the visible surface. The misses cluster in predictable categories — almost every post-incident review of a former-employee breach surfaces the same five or six gaps. Categorizing them honestly is the first step toward closing them.

Offboarding Gap Map
Where Access Survives After Departure
Critical — Often Missed
Non-Human Credentials
API tokens, OAuth grants, service accounts, personal access tokens in CI/CD, AWS keys committed to repos, signed JWTs with long expirations.
Critical — Often Missed
Shadow SaaS Outside SSO
Apps signed up with corporate email but never integrated with the IdP. Direct logins survive when the directory account is disabled.
High — Frequently Missed
Active Sessions & Cookies
Disabling an account doesn’t kill open browser sessions. Tools without forced reauthentication can stay logged in for weeks.
High — Frequently Missed
Shared Credentials
Team passwords in shared vaults, social media logins, vendor portals, root-level admin accounts that aren’t tied to one person.
Medium — Sometimes Missed
Personal Devices & BYOD
Cached email on a personal phone, OneDrive synced to a home laptop, browser-saved company passwords, MDM profiles never wiped.
Medium — Sometimes Missed
External Identities
Vendor portals, customer Slack workspaces as guest, partner GitHub orgs, conference platforms, certificate authorities.

Non-human identity is the most consistent miss. A developer who leaves often takes weeks of artifacts with them — not in their head, but in code. Personal access tokens generated against the GitHub org. AWS access keys hardcoded in a forgotten Lambda. An OAuth app they authorized that still has full mailbox scope on the corporate Microsoft 365 tenant. The directory disable does nothing to these. They live until they’re individually revoked or they expire, and many enterprise tokens have expirations measured in years.

Shadow SaaS is the second. Research by SaaS management vendors consistently finds that the SaaS ecosystem doesn’t always align with centralized security models — apps onboarded through self-service signups, departmental purchases, and team-level adoption. JumpCloud’s analysis notes nearly 90% of IT admins are alarmed by shadow IT, and estimate most employees use one to five unauthorized applications. When a person leaves, the directory disables their identity but the standalone passwords for those apps survive. If the employee used a personal email mixed with corporate work, the account doesn’t even surface in any IT inventory.

Active sessions are the silent gap. Most SaaS tools issue session tokens with lifetimes far longer than business assumes. Disabling a Google Workspace account terminates new logins but doesn’t always immediately invalidate every refresh token in flight. Some tools — especially older ones — keep a logged-in employee logged in for hours or days even after backend access is revoked. Forced session revocation is a separate API call that most checklists never trigger.

Shared credentials are the embarrassment. Every organization has them. The Twitter/X login the marketing team uses. The vendor billing portal that requires “[email protected].” The break-glass admin password sitting in 1Password’s “Engineering Shared” vault. These don’t belong to any one identity, so they don’t get rotated when an identity leaves. A departing employee with the vault password can keep that access indefinitely unless someone — usually an underfunded someone — remembers to rotate every single shared secret on departure.

Personal devices and BYOD complete the surface. The corporate-email-on-personal-phone problem isn’t solved just by removing the Exchange profile if the phone has cached attachments locally. OneDrive Personal sometimes ends up syncing work files when an employee logs into both accounts on the same machine. MDM helps when it’s enforced; many organizations enroll only company-issued devices and leave the personal-phone-with-work-email scenario to policy.

What a Defensible Checklist Actually Covers

The checklist below isn’t novel in its items — most appear in some form in NIST SP 800-53 control PS-4 (Personnel Termination) and ISO/IEC 27001:2022 Annex A control 6.5. The value is in completeness and in tying timing to risk. Termination scenarios warrant minute-zero revocation; voluntary departures with notice can sequence over days. Both need every category covered.

Comprehensive Reference
Offboarding Security Checklist
Grouped by domain. Timing column indicates target completion relative to last day worked (LDW).
Identity & Access
7 items
Disable IdP account (Okta, Entra ID, Google Workspace)
LDW
Force session revocation across all federated apps
LDW
Revoke OAuth grants and third-party app authorizations
LDW
Disable Active Directory account, remove from AD groups
LDW
Revoke VPN, ZTNA, and remote access certificates
LDW
Remove privileged role memberships (PIM, sudoers, IAM)
LDW
Disable MFA enrollments and recovery methods
LDW
SaaS & Cloud
6 items
Run discovery for shadow SaaS tied to corporate email
LDW −3
Deprovision non-SSO SaaS accounts directly via admin console
LDW
Transfer ownership of cloud documents, projects, calendars
LDW −1
Reassign SaaS app admin roles (esp. solo-admin tools)
LDW −1
Remove from external workspaces (customer Slacks, vendor portals)
LDW
Reclaim license seats; verify deprovisioning in billing
LDW +7
Non-Human Identities
5 items
Revoke personal access tokens (GitHub, GitLab, Jira, Datadog)
LDW
Rotate cloud access keys created or known by user (AWS, GCP, Azure)
LDW
Audit and rotate API keys in vaults, CI/CD, and config
LDW −1
Remove SSH keys from servers and bastions
LDW
Reassign or rotate service accounts owned by user
LDW −1
Shared & Privileged
4 items
Rotate every shared password the user had vault access to
LDW
Rotate root and break-glass credentials if user knew them
LDW
Reassign social media account ownership (LinkedIn, X, etc.)
LDW −1
Update DNS, registrar, and certificate authority contacts
LDW +3
Devices & Data
5 items
Recover and securely wipe company laptops, phones, tablets
LDW −1
MDM-wipe corporate profile from BYOD devices
LDW
Review pre-departure access logs for anomalous data movement
LDW −1
Snapshot mailbox; configure forwarding for 30–90 days
LDW
Revoke physical access (badges, keys, biometric enrollments)
LDW
Governance
4 items
Conduct exit interview covering data handling and IP
LDW −1
Confirm signed NDA and IP assignment acknowledgment
LDW −1
Generate audit log of every revocation step
LDW +1
30-day post-departure access reverification scan
LDW +30

The 30-day post-departure scan is the single most underused control on the list. It catches the OAuth token nobody remembered, the SaaS app the discovery tool didn’t surface on day one, the API key that was rotated incorrectly. Treat it as part of the standard process, not an exception.

Termination Versus Voluntary Departure

The same checklist applies, but timing collapses for involuntary terminations. Ideal practice has IT prep all revocation actions in advance — ready to execute the moment HR notifies them — with the manager and HR coordinating the conversation so revocation happens during it, not after. The risk window in a hostile termination is measured in minutes. The Coupang and FinWise cases both involved former employees who maintained access well past departure; in the FinWise incident, the breach occurred because a former employee retained valid access, and the bank lacked visibility into account use.

Voluntary departures earn a longer runway, but not infinite. The two-week notice period is the highest-risk window for data exfiltration — pre-departure access log review (item LDW−1 on the checklist) is specifically designed to catch unusual bulk downloads or atypical access patterns during this period. Look at volume, not just file names. A salesperson exporting their entire CRM contact list the week before they leave is rarely doing it for handoff.

Contractors, Vendors, and the Long Tail

Contractor offboarding fails more often than employee offboarding because contractors fall outside the HR system that triggers the workflow. The contract ends, but nobody pulls a lever in Workday or BambooHR. Industry research has flagged this gap repeatedly — contractor offboarding sits alongside privileged access and departing employees as one of the highest-consequence insider risk use cases.

Three fixes help. First, mirror contractors in the HR system with hard end dates, even if they’re stored as a separate worker type. Second, default contractor access to time-bound roles that auto-expire at contract end rather than relying on a deprovisioning trigger. Third, for any contractor with privileged access — and many have it because the work demands it — apply the full employee checklist, not a stripped-down version.

Vendor and partner offboarding adds another tail. When a third-party relationship ends, the vendor’s people lose access — but did the vendor’s systems lose access? API integrations, webhooks, federated identity trusts, SAML connections all have to come down with the relationship. Ascension’s 2025 disclosure illustrated the failure mode: a former business partner who continued to retain patient data on outdated software, which attackers exploited to gain unauthorized access, contributing to a breach that affected 437,385 patients.

Why Your Checklist Misses What It Misses

A clean checklist run against incomplete inventory still produces incomplete revocation. The siit.io analysis of automated offboarding makes the structural point: orphaned permissions are a provisioning problem, not an offboarding problem. You can’t revoke access you don’t know exists. If grants happened informally — a Slack message, a direct invite, a self-signup — they don’t appear in your records, and your offboarding process can’t reference them.

Three fixes attack the upstream problem.

Route every access grant through a workflow. Every new app, every new permission, every new integration goes through a documented request with manager approval. The grant is recorded against the user. Now offboarding has a complete inventory to revoke against.

Map the SaaS surface continuously, not at offboarding time. Discovery tools that scan email, financial records, and OAuth grant histories surface apps employees signed up for that IT never knew existed. Run them as a standing process, tie discovered apps to identities, and feed them into the offboarding workflow automatically.

Build employee-level access profiles. A single view aggregating IdP membership, SaaS access, cloud roles, repository permissions, and vault entries per person turns offboarding from “ask around and check the wiki” into “execute the workflow against the profile.” The completeness of offboarding is downstream of the completeness of the profile.

These shifts are not free. They mean some friction at provisioning time. But friction at the front door is much cheaper than gaps at the back. Ponemon’s 2025 finding that in 2025, most organizations remained in early insider risk maturity, with 51% at Level 2, 25% at Level 1, 18% at Level 3 reflects how few organizations have actually done this work.

Standards Reference
Where Offboarding Lives in Major Frameworks
NIST SP 800-53
PS-4 Personnel Termination — disable access within defined timeframe, terminate credentials, conduct exit interviews, retrieve assets, retain access to data, notify personnel.
ISO/IEC 27001
A.6.5 Termination or change of employment and A.5.16 Identity management — access rights revoked at termination; identity lifecycle covers full duration including exit.
CIS Controls v8
Control 5.3 requires disabling dormant accounts after 45 days of inactivity. Control 6.2 establishes a process to revoke access upon termination.
SOC 2 (TSC)
CC6.2 / CC6.3 — common criteria require timely user access removal upon termination, with auditable evidence. Failed offboarding is a frequent SOC 2 audit finding.
HIPAA Security Rule
§164.308(a)(3)(ii)(C) — Termination Procedures: implement procedures for terminating access to ePHI when employment ends or access is no longer needed.

Frequently Asked Questions

How fast does access revocation actually need to happen?

For involuntary terminations, before or during the termination conversation. For voluntary departures with notice, the identity disable and high-risk credential rotations should complete on the last day worked, with longer-tail items (license reclamation, audit log generation) running over the following days. CISA’s AA24-046A advisory and similar incidents make clear that “we’ll get to it next week” is not a defensible posture.

Should we monitor employee activity in the days before they leave?

Yes, with a documented policy that employees are aware of. Pre-departure data exfiltration is real — sales contacts, source code, customer lists, internal documents — and the notice period is when it happens. UEBA tools and DLP can flag bulk downloads, mass emails to personal addresses, and unusual after-hours activity. The legal grounding matters: monitoring needs to be disclosed in employment terms, applied consistently, and reviewed by counsel for jurisdiction-specific privacy law (GDPR, CCPA, state biometric laws, EU works councils where applicable).

What about email forwarding after departure — is it safe?

It’s common, but it’s a gray area legally and creates a small ongoing exposure. If an ex-employee’s mailbox is forwarding to a manager, the manager can read messages potentially sent in confidence to the former employee. Most organizations forward for 30–90 days then delete or archive. A safer pattern is an autoresponder pointing to a successor’s address, with the mailbox itself disabled.

How do we handle SaaS apps we don’t even know about?

Continuous discovery, not point-in-time review. Tools that pull from email metadata, financial records, OAuth grant histories, and DNS to surface SaaS apps tied to corporate identities will find roughly an order of magnitude more apps than IT inventories list. Run discovery monthly, tie findings to identities, and either bring apps under SSO or document them in the offboarding workflow.

The Underlying Point

Offboarding is not a checklist problem; it is a systems-of-record problem. The failure mode is rarely that someone forgot to click “disable” in Active Directory. The failure mode is that the access surface for a given person was never fully visible, so the disable button only ever covered part of it. Coupang’s authentication keys, the State Department contractor’s VPN credential, the FinWise account that wasn’t being monitored — all are downstream symptoms of the same upstream condition: provisioning that wasn’t tracked, so revocation couldn’t be complete.

The work to fix this is unglamorous. Inventory every access grant against every identity. Push grants through workflows that produce records. Run continuous SaaS discovery. Build per-person access profiles that aggregate everything. Run a 30-day post-departure verification scan as standard practice. None of these are exciting, but each one converts a category of “we hope we got everything” into “we know we got everything.” Insider risk programs that mature past Level 2 do this work; the ones that don’t keep showing up in breach disclosures.

The next former-employee breach is already in motion at some company today, with credentials that were issued informally, never tracked, and won’t be revoked when the person leaves. Whether it lands at your company or someone else’s is mostly a function of which checklist you’ve built — and which one you’ve actually wired into systems that don’t depend on anyone remembering.

Add a comment

Leave a Reply

Your email address will not be published. Required fields are marked *

Cybersecurity intelligence delivered directly to your inbox.

By pressing the Subscribe button, you confirm that you have read and are agreeing to our Privacy Policy and Terms of Use
Advertisement