They Left in March. Their Account Didn't: The One-Afternoon Offboarding Review
Last week CISA added vulnerabilities from 2015 to the actively-exploited catalog. The mechanism that keeps an eleven-year-old bug exploitable is the same one that keeps a departed employee's API token alive — and here's the afternoon review that finds it.
Decay, with a date stamp on it
On August 26, 2026, the Known Exploited Vulnerabilities catalog picked up four entries worth reading twice: CVE-2015-3246 and CVE-2015-5287, both Red Hat, both from 2015; CVE-2019-1068, a SQL Server remote code execution; and CVE-2021-23758, a deserialization flaw in Ajax.NET Professional. Entries land in that catalog on evidence of active exploitation. Somebody is still exploiting a bug that turned eleven years old.
The catalog doesn't say why. But the simplest explanation for an eleven-year-old bug still being exploited is that it is still running somewhere, on a host nobody owns, that nobody has deliberately logged into since the person who built it left.
Five days later the same catalog added two PaperCut NG/MF flaws, one of which is described in its own entry as Missing Authentication for Critical Function — on a print management server, the archetypal thing an MSP installs once in year one and never revisits. And in between, on August 27, an ownCloud improper-authentication bug from 2023 was added with a three-day federal remediation deadline.
Read together, those look less like three patching stories than one ownership story. The risk factor is not unpatched; unpatched is a symptom. The risk factor is unowned — and access decays exactly the same way, only more quietly, because an orphaned account never throws an alert.
HR closes a person. Security has to close identities.
Offboarding gets filed as an HR event, and that framing is why it quietly fails. HR closes a person. Access lives as identities, and the mapping is one-to-many.
The directory account is the one identity that reliably has a human's name attached and a process pointed at it. It gets disabled on day one, and it is what everyone points to when you ask whether offboarding works. Underneath it sits everything that was created ad hoc, is owned by nobody in particular, and has no lifecycle tied to employment at all.
So the process reports success while most of the surface is untouched.
The six-month rule
Before the hunt, one decision determines whether this review measures anything: who you audit.
Reviewing last week's leaver tells you almost nothing. The ticket is still open, the manager remembers, someone is still copied on the thread. Of course it looks clean — you are measuring your attention, not your process.
Pull five people who left six months ago or longer, or five contractors whose engagement ended that long back. That tells you what your process produces once attention has moved on, which is the only condition it will actually operate under for the rest of its life.
It is the same logic as testing a restore instead of trusting a green backup job. The green light describes an intention. The restored file describes reality.
Ten places access hides
One row per identity, not per person. A single departure usually produces several:
- Directory / SSO account — the easy one, and the one that flatters the process
- Local accounts on appliances — firewall, hypervisor, NAS, print server, switch; tied to no directory
- Shared credentials in the team vault — four people know it, so rotating it means telling four people, so it never gets rotated
- Service accounts — nobody offboards one, because nobody thinks of it as a person; yet it carries their naming convention and their permissions
- API tokens and app passwords — they outlive the human because the token appears in no list anyone reads
- MFA enrolments on personal devices — the account is disabled, the phone is still a registered authenticator
- Vendor and support portals — they are still the registered contact, so resets and license changes still route to them
- Client tenants and delegated access — MSP-specific, and the highest blast radius on the list
- Repos, CI, and deploy keys — org membership and personal access tokens both outlive employment
- Mailbox rules and forwarding — survives the mailbox being converted to shared, and quietly keeps delivering
If your hunt produces one row per person, you have found the checklist, not the access.
Verify in the system, not on the checklist
This is the step most reviews skip, and skipping it makes the other steps decorative.
A completed offboarding checklist is a claim. The system's actual user list is evidence.
On a first pass those two usually disagree — and when they do, the checklist is what's wrong. It recorded an intention formed at the moment of ticking, and nothing re-validated it afterwards. A user list pulled today is a statement about now.
The failure modes are mundane, which is exactly why they persist:
- The account was disabled but never removed from its security groups, so a re-enable for a mailbox restore silently returns full access.
- The human was revoked and the token they generated wasn't, because the token isn't attached to them anywhere a person looks.
- The shared vault entry was never rotated, because rotating it is a conversation with four people.
- Two admins each assumed the other one did it.
None of these require carelessness. They require a process that stops at ticked.
The artifact is the point
The review is just how you produce the record. The record is what survives.
Log what you revoked, from where, on what date, verified how, and checked by whom — and fill it as you go, because retro-filling is how dates stop being true. Then write the per-departure summary: systems checked, identities found, how many were still active, when they were closed, and what process gap let it happen.
That last field matters more than it looks. What you found is a gap in the runbook, not in one person's file. Patching the record leaves the next departure exactly where this one was.
The rule carries over from every review in this series: every claim gets a number and a date. "We offboard people properly" is a mood. Something shaped like "five departures reviewed, 31 identities found across 9 systems, 6 still active, all revoked, Sep 4, verified by J.R." is an artifact — and it is the one an assessor asks for when they want to know whether your access-control process is real or aspirational.
When you find something
Preserve before you act — screenshots, exports, timestamps — and if there is any sign the access was used after the person left, stop and follow your incident-response plan. A worksheet is not one. Engage counsel and your insurer per your policy's terms before external communications.
And a clean review is still a deliverable. Identities counted, nothing still open, dated and signed, filed. An identity nobody owns goes on the risk register with one owner and one fix-by date, not in a drawer.
The worksheets are free. The Offboarding Evidence Kit is a self-contained offline HTML file — identity hunt across all ten categories, verification pass, revocation log, per-departure review record, evidence register — plus CSV and Excel copies of the three registers. No account required — thesecuritygator.gumroad.com/l/gb011-offboarding-evidence-kit
This is a review format and a practical starting point to adapt for your organization. It supports access-review and audit-preparation workflows; it is not legal, compliance, or audit advice, and not a substitute for managed security or incident-response services. Account and token lifecycle behaviour varies by product and license — verify against your vendor's current documentation.
Sources: CISA KEV catalog · KEV alert, Aug 26 · KEV alert, Aug 27 · KEV alert, Aug 31
Top comments (0)