Offboarding: The Access Nobody Remembers to Revoke

The integration nobody remembers approving

Somewhere in most engineering orgs, there’s a small script or integration a departed engineer set up eighteen months ago — a Slack export tool, a personal automation, a one-off dashboard — authenticated with an API token issued to their account. They left. The token didn’t. Nobody put it on a list, because nobody wrote it down anywhere except a comment on the Jira ticket where they originally set it up.

That’s not a hypothetical. It’s close to the median case, according to the data on how offboarding actually goes.

What the data says

Gartner’s research on access revocation timing found that only 44% of companies revoke all access rights within 24 hours of an employee’s departure. Flip that number around: for the majority of departures, some access — an app login, an API key, a shared service account — lingers past day one, and often much longer, because deprovisioning is spread across a dozen different systems and nobody owns the full checklist.

That gap has a measurable cost. The Ponemon Institute found that 20% of data breaches involve a former employee within six months of their departure. Not a freak occurrence — a pattern common enough that one in five breaches traces back to it.

Why this specific gap matters so much

Old credentials aren’t just dormant — they’re valuable, and there’s a real market for them. Verizon’s 2026 Data Breach Investigations Report found that stolen credentials still appear in 39% of all breaches, and remain the primary way attackers move laterally and escalate privileges once they’ve gotten in. On criminal marketplaces, VPN credentials make up 44% of what Initial Access Brokers sell, with non-privileged account access going for around $700 and admin-level access for roughly $1,300 — nearly double, because it skips the privilege-escalation step entirely. An unrevoked account from a departed employee, especially one with elevated access, is exactly the kind of asset that ends up for sale.

Why it’s so hard to fully revoke access

It’s rarely one system. A typical employee has credentials scattered across SSO-federated apps (usually handled automatically), plus a long tail that isn’t: a personal API token for a monitoring tool, a shared database password they knew because they set it up, a service account they created “temporarily” for a migration two years ago. IT can turn off SSO in minutes. Nobody has a complete list of the rest — and the rest is exactly where the 20% comes from.

What actually closes the gap

1. Treat offboarding as a checklist with an owner, not a hope. SSO deprovisioning is necessary but not sufficient — someone needs to be responsible for the non-SSO tail: service accounts, personal API tokens, anything set up ad hoc.

2. Rotate shared secrets on departure, not just on suspicion. If a departing engineer ever had access to a shared credential — a database password, a deploy key — rotate it as part of offboarding, by default, not only if something looks wrong later. envseal’s per-person keypairs make this specific case cheaper: revoking one person’s access to an encrypted vault doesn’t require re-issuing every secret for everyone else who still needs it.

3. Find the credentials nobody remembers exist. The token mentioned at the top of this post — the one living in a comment on an old Jira ticket, or a “how we set this up” page in Confluence — won’t show up on any offboarding checklist, because nobody remembers to put it there. Secret Sentinel scans Confluence and Jira content directly for exactly this: credentials that were never rotated because nobody remembered they existed in the first place, regardless of whether the person who wrote them down still works there.

Install Secret Sentinel for Confluence · Install Secret Sentinel for Jira