Ghost Logins, Real Breaches: The Offboarding Failures Companies Refuse to Fix

The Door That Never Quite Closes

When a developer leaves a company, HR handles the paperwork, IT collects the laptop, and everyone moves on. What too often stays behind is something far more dangerous than a missing badge: a still-active account with privileges that would make an outside attacker weep with envy.

WhistleDev spoke with engineers and IT administrators across a dozen US companies — from venture-backed startups in Austin to enterprise shops in the Midwest — and a pattern emerged with unsettling consistency. Offboarding, when it happens at all, is a checklist of visible assets. The invisible ones — service accounts, API tokens, SSH keys, cloud console access, VPN certificates — frequently survive the departure untouched.

The result is what security practitioners grimly call "ghost accounts": credentials that belong to people who no longer work there, but whose access remains fully functional, sometimes for years.

Case Studies in Neglect

The history of American data breaches is, in large part, a history of forgotten credentials.

Consider the 2019 Capital One incident, where a former employee of Amazon Web Services exploited her residual familiarity with the cloud environment — and a misconfigured firewall — to access data on roughly 100 million customers. The attacker no longer worked for either company. The access pathways she understood had not been meaningfully restructured after her departure.

Or take the pattern documented repeatedly in healthcare breaches reported to the US Department of Health and Human Services: terminated employees accessing patient records months after their last day, in violations discovered only during audits triggered by something else entirely.

The most instructive cases, however, never make headlines. They surface in the anonymous accounts of the people who clean up the mess. One infrastructure engineer at a mid-sized SaaS firm described discovering that a departing staff engineer's production database credentials — shared, in violation of policy, among half the team — had never been rotated. "We treated the departure as an HR event," they said. "The database treated it as nothing at all."

Why Companies Let It Happen

The excuses are predictable, and WhistleDev has heard them all.

The contractor problem. Third-party developers are provisioned quickly and de-provisioned slowly, if ever. Billing ends; access doesn't. In the scramble of agile delivery, nobody owns the cleanup.

The startup shrink. When a company lays off 20 percent of its engineering staff in a single morning, the offboarding process is often reduced to cutting off email and hoping for the best. Production access, in the chaos, is an afterthought.

The shared-secret culture. Where teams pass around credentials in Slack or a plaintext wiki, removing one person's account removes nothing. The real key — the shared one — is still in everyone's pocket, including the pockets of people who left.

The grudge variable. Most departed employees are benign. But offboarding security is not designed for the median case; it is designed for the tail. A laid-off engineer who felt wronged, a contractor whose invoice was disputed, an executive pushed out mid-scandal — these are the scenarios that turn a forgotten credential into a breach. Insider incidents involving former employees remain among the most underreported categories in US breach data, largely because companies are not eager to advertise that they left the keys in the door.

The Whistleblower's Dilemma

Here is where the problem acquires an ethical dimension that our readers know well. Engineers who discover ghost accounts — their own former colleagues' access, still live — face a familiar bind. Reporting it internally may implicate the very managers who oversaw the sloppy offboarding. Fixing it quietly may violate change-control policies. Saying nothing feels complicit.

And in some cases, the ghost account is not an accident. Access retained deliberately — for a "friend at the company," for deniable future use — crosses from negligence into something regulators and prosecutors treat very differently. Under computer fraud statutes and increasingly under state data security laws, knowing retention of unauthorized access is not a paperwork problem. It is a liability.

Developers who document these failures — timestamps, ticket numbers, the date access should have been revoked — are doing the work that post-breach forensics teams wish someone had done in advance.

A Practical Audit Checklist

You do not need a security budget to start closing these doors. You need a list.

1. Inventory every identity source. SSO provider, cloud IAM, version control, CI/CD pipelines, VPN, database logins, third-party SaaS. Export them. Compare against your current payroll.

2. Hunt for orphans. Any account whose owner is no longer employed or contracted is a ghost. Disable first; investigate second.

3. Rotate what was shared. Any credential that appeared in a group channel, wiki, or deployment script must be treated as compromised by definition. Rotate it.

4. Audit service accounts. These outlive everyone. Map each to a named owner and a documented purpose. Unowned service accounts are the longest-lived ghosts of all.

5. Revoke API tokens and SSH keys. These do not appear in standard HR-driven deprovisioning. They require their own sweep.

6. Review physical and hardware access. Badge systems, YubiKeys, hardware security modules. The laptop comes back; the registered authenticator sometimes doesn't.

7. Run the sweep on a schedule. Quarterly at minimum. After every layoff, immediately.

8. Write down who is responsible. Offboarding fails most often because it belongs to everyone and therefore to no one.

Expose. Report. Build Better Tech.

Unrevoked access is not a sophisticated attack vector. It is a mundane, fixable, embarrassingly common failure of follow-through — the kind of problem that persists because nobody is embarrassed enough, early enough, to fix it. WhistleDev exists to make sure someone is.

If your former employer still has your credentials working, or your current one has ghosts in the directory, the paper trail you build today may be the only thing that separates a near miss from a headline. Change the lock. Then verify the lock was changed. That, more than any scanner or compliance checkbox, is what security actually looks like.