Why Offboarding Still Leaks Access 30 Days After Termination

Ask any IT team how their offboarding process works, and they will describe an Okta workflow that runs the moment HR flips the "terminated" flag. Then ask them what happens to the GitHub personal access token the person created six months ago, and there is a pause. That pause is the mechanism behind the "one in three departed employees retains access" number that shows up in every identity report.

The offboarding failure is not laziness. It is that most offboarding processes only see the part of the surface the IdP knows about. Here is what the rest of the surface looks like and how to close it.

What are the actual access leaks after termination?

Five leak paths. Ranked by frequency across mid-market companies.

• Personal access tokens. GitHub PATs, GitLab PATs, Slack tokens, Figma tokens. Created by the user, never expire by default, invisible to the IdP.
• Cloud access keys. AWS access keys, GCP service account keys downloaded to a laptop, Azure principal secrets. Once created, live outside the SSO path entirely.
• SaaS apps not behind SSO. Anything the user signed up for with a corporate email and a personal password. Marketing tools, design tools, dev productivity tools bought before IT knew about them.
• Shared credentials. The team's shared Netflix-of-monitoring login. The password never changed when the person left. Everyone still uses it.
• Service account ownership. A cron job runs under a service account owned by the departed user. When the account is deprovisioned, the job breaks; when it is not, the departed user technically still owns production infrastructure.

Each of these has its own detection and closure path. Grouping them into one "offboarding" checkbox is why the leaks persist.

What percentage of the surface does SSO actually cover?

Depends on how mature the identity program is. Rough benchmarks.

Even at 95% SSO coverage, the 5% delta is where the offboarding leaks live. And the 5% skews heavily toward high-privilege systems (cloud, source code, secrets) because those are where personal access tokens and keys concentrate.

What does a complete offboarding checklist look like?

Twelve items. Any one skipped is a leak.

1. Terminate SSO account in Okta or Google Workspace. Immediate.
2. Revoke active sessions across all connected apps. Force re-auth.
3. Rotate credentials for shared accounts the user knew.
4. Revoke all personal access tokens in GitHub, GitLab, Slack, and any dev tool that supports them.
5. Deactivate all AWS access keys and GCP/Azure equivalents. Confirm no keys remain active.
6. Reassign service account ownership. Every cron, every integration, every automation.
7. Audit and remove SaaS access outside SSO. Cross-reference AP and card records.
8. Retrieve or wipe managed endpoints. Laptop, phone, any device with company data.
9. Revoke VPN and network access. Certificates, static IPs, VPN accounts.
10. Remove from mailing lists and Slack. Especially confidential distribution lists.
11. Transfer or archive owned data. Drive documents, code repos where they were the only maintainer.
12. 48-hour audit sweep. Confirm every item above is complete in the source system, not just in the checklist.

The 48-hour sweep is the item most programs skip. It is also the one auditors sample-test.

Why does the sweep matter more than the workflow?

Because workflows produce ticket closes, not access removal.

• The workflow says "revoked GitHub". The sweep confirms the user no longer appears in the GitHub org.
• The workflow says "deactivated AWS keys". The sweep queries AWS IAM for active keys under the user's principal.
• The workflow says "reassigned service accounts". The sweep confirms no service account still has the departed user as owner.

Auditors, incident responders, and red teamers all check the source system, not the ticket. Your offboarding process should do the same.

What is different about hostile or involuntary terminations?

Compressed timeline, same content. The differences are mechanical.

• SLA under 60 seconds for SSO revocation. IT gets a heads-up before HR delivers the news; revocation happens during the conversation.
• All active sessions terminated before the conversation. Not after.
• Endpoint access disabled remotely at the moment of termination. MDM push to lock the device.
• Password reset lockdown on all account recovery paths. Email, phone, backup codes. All rotated at termination, before self-service recovery becomes a threat.
• Extended 30-day monitoring on any accounts the user knew about, including shared credentials that were rotated. Look for reset attempts, VPN attempts from unusual geographies, SaaS logins from unmanaged devices.

Hostile terminations are the offboarding scenario every process should be designed to handle. If your process cannot execute a hostile termination in under 60 seconds, it also cannot execute a standard termination cleanly. Design for the harder case.

How do you handle contractor and vendor offboarding?

Different surface, same principles, one extra rule.

• Time-bound access from day one. Every contractor account expires on contract end date. Extensions require a re-grant, not a rolling assumption.
• Named engagement owner. Not "procurement". A specific human who confirms the engagement is over.
• Same 12-item checklist, with vendor-supplied credentials rotated at contract end.
• Extra: revoke shared vendor accounts if any vendor employee knew a shared credential. Rotate immediately, notify the vendor.

Contractors are more likely to have SaaS accounts, tokens, and shared credentials outside the IdP than full-time employees. Their offboarding surface is broader per capita.

What does the metric look like for a healthy offboarding program?

Four numbers.

• Time from termination to SSO revocation. Under 15 minutes for standard, under 60 seconds for hostile.
• Time from termination to 48-hour sweep close. Under 48 hours (obviously) with 100% checklist completion.
• Residual access rate at 30 days. Terminated users with any active access, measured by sweep and by discovery. Target: zero.
• Service account re-ownership rate at 24 hours. Percentage of departed-user-owned service accounts reassigned. Target: 100%.

If you cannot report on all four, you probably have a leak. Instrument the metric first, then the fix follows naturally.

The mistake to avoid

Most offboarding programs treat the SSO deprovisioning as the finish line. It is the start line. The leaks live in personal access tokens, cloud access keys, shared credentials, and service account ownership, none of which the IdP sees. Close the loop with a 48-hour sweep against the source systems, not against the ticket. And design the process for hostile termination, because a process that handles hostile termination cleanly handles standard termination cleanly, but the reverse is not true.